date:20171023

2017-10-23 Thread Johan Engelen via Digitalmars-d-announce


On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:

On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:

On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

[...]


Whats about this one?

auto foo = 42;
auto bar = "bar";
writeln(`Foo is {foo} and bar is {bar}`);


writeln("Foo is ", foo, "and bar is ", bar");

Two more characters.

Atila


Okay, but what about now?

void sendAMessage(string message)
{

}


sendAMessage(text(...));

Atila

[Issue 16997] Integral promotion rules not being followed for unary + - ~ expressions

2017-10-23 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #11 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/71403b6cd3781cd4d97104be1f4194e168a75d02
fix Issue 16997 - Integral promotion rules not being followed for unary + - ~
expressions

https://github.com/dlang/dmd/commit/7253190083cd66ae11711f2f6ff15497810d34c5
Merge pull request #7013 from WalterBright/fix16997

fix Issue 16997 - Integral promotion rules not being followed for neg…

--

[Issue 16997] Integral promotion rules not being followed for unary + - ~ expressions

2017-10-23 Thread d-bugmail--- via Digitalmars-d-bugs

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: My two cents

2017-10-23 Thread Adam Wilson via Digitalmars-d


On 10/23/17 08:21, Kagamin wrote:

On Friday, 20 October 2017 at 09:49:34 UTC, Adam Wilson wrote:

Others are less obvious, for example, async/await is syntax sugar for
a collection of Task-based idioms in C#.


Now I think it's doesn't fit D. async/await wasn't made for performance,
but for conservation of thread resources, async calls are rather
expensive, which doesn't fit in D if we prefer raw performance. Also I
found another shortcoming: it doesn't interoperate well with cache:
cache flip flops between synchronous and asynchronous operation: when
you hit cache it's synchronous, when you miss it it performs IO.


Actually I think it fits perfectly with D, not for reason of 
performance, but for reason of flexibility. D is a polyglot language, 
with by far the most number of methodologies supported in a single 
language that I've ever encountered.


Additionally, MSFT/C# fully recognizes that the benefits of Async/Await 
have never been and never were intended to be for performance. 
Async/Await trades raw performance for an ability to handle a truly 
massive number of simultaneous tasks. And it is easy to implement both 
blocking and non-blocking calls side-by-side (MSFT appends 'Async' to 
the blocking call name).


Here is the thing. Many projects (particularly web-scale) are not all 
that sensitive to latency. Adding 10ms to the total call duration isn't 
going to effect the user experience much when you've got 500ms of IO 
calls to make. But blocking calls will lock up a thread for those 500ms. 
That can disastrous when you have thousands of calls coming in every 
second to each machine.


On the flip side, if you're a financial service corp with millions to 
throw at hardware and an extreme latency sensitivity, you'll go for the 
blocking calls, because they absolutely do cost less in overall 
milliseconds. And you'll make up for the thread blockages by throwing an 
obscene amount of hardware at the problem. Because hey, you're a 
multi-billion dollar corp, you'll make back the few million you spent on 
over-provisioning hardware in a day or two.


The point is that not everyone wants, or needs, maximum raw performance 
per individual task. In the spirit of flexibility, D needs to provide 
the other choice, because it's not our job to tell our users how to run 
their business.


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: D could catch this wave: web assembly

2017-10-23 Thread bioinfornatics via Digitalmars-d


On Thursday, 18 June 2015 at 08:05:48 UTC, John Colvin wrote:
This appears to have involvement from all major browser 
vendors, which provides hope it might actually catch on 
properly. An llvm backend will be created which will compile to 
"wasm", hopefully LDC and/or SDC could glue to this.


https://www.w3.org/community/webassembly/

https://github.com/WebAssembly

In particular, see 
https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/FAQ.md and https://github.com/WebAssembly/design/blob/master/MVP.md


WebAssembly reach a first step a first consensus on the design of 
the initial (MVP) WebAssembly API and binary format:

- http://webassembly.org/
- https://developer.mozilla.org/en-US/docs/WebAssembly
- https://github.com/webassembly

To remember it will be the next  open standard by a W3C Community 
Group to create portable and efficient application across major 
web browser. A such feature can offer to D a chance to have a 
killer app in 3D web application instead to develop complex C++ 
code.


Some examples:
- https://github.com/JasonWeathersby/WASMSobel/
- https://github.com/mdn/webassembly-examples/

Re: So why double to float conversion is implicit ?

2017-10-23 Thread Basile B. via Digitalmars-d


On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
I was working on some sort of math library for use in graphical 
computing and I wrote something like this:


const float PiOver2 = (atan(1.0) * 4) / 2;

Interestingly enough, I realized that atan() returns double (in 
this case) but wait, it's assigned to a float variable! 
Compiler didn't even emit warnings, let alone errors.


I see no reason as to why would this be legal in this century, 
especially in D.

So can someone tell me what's the argument against this?
Why type conversions differ between integral and floating types?
Why can't I assign a long to an int but it's fine when 
assigning double to float?


I think this is a serious topic and needs clarification.


In the meantime:

---
/**
 * Wraps a floating point type that doesn't follow D permissive 
float conversion

 * rules.
 *
 * In D, as in C++, implicit conversion from $(D double) to $(D 
float) is allowed,
 * leading to a possible precision loss. This can't happen when 
using this wrapper.

 */
struct CoercionSafeFloat(T)
if (isFloatingPoint!T)
{
private T _value;
alias _value this;

enum antiCoercion =
q{
static assert(V.sizeof <= T.sizeof, "coercion from " ~ 
V.stringof ~

" to " ~ T.stringof ~ " is not allowed");
};

/// Prevent Coercion from construction.
this(V)(V v) {mixin(antiCoercion); _value = v;}
/// Prevent Coercion from assignation.
void opAssign(V)(V v) {mixin(antiCoercion); _value = v;}
/// Prevent Coercion from operator assignation.
void opOpAssign(string op, V)(V v)
{
mixin(antiCoercion);
mixin("_value " ~ op ~ "= v;");
}
}
///
unittest
{
alias Float = CoercionSafeFloat!float;
alias Double = CoercionSafeFloat!double;
alias Real = CoercionSafeFloat!real;

Float f; Double d; Real r;

import std.math;
static assert(!__traits(compiles, f = (atan(1.0) * 4) / 2));
static assert( __traits(compiles, f = (atan(1.0f) * 4f) / 
2f));
static assert(!__traits(compiles, d = (atan(1.0L) * 4L) / 
2L));

static assert(__traits(compiles, d = f));
static assert(!__traits(compiles, f = d));
static assert(!__traits(compiles, d = r));
static assert(!__traits(compiles, d += r));
static assert(__traits(compiles, r *= d));
}
---

you can get a safer float type if this is a concern.

Re: D for microservices

2017-10-23 Thread Adam Wilson via Digitalmars-d


On 10/23/17 05:08, Jacob Carlborg wrote:

* Database drivers for the common databases (PostgreSQL, MySQL, SQLite)
compatible with vibe.d
* Database driver abstraction on top of the above drivers, perhaps some
lightweight ORM library


I've been looking pretty extensively at these two items recently.

If the database drivers are compatible with Vibe.d AND we wish to 
provide a common abstraction layer for them (presumably via Phobos) then 
order for the abstraction layer to aware of the whether the driver is 
making a blocking or non-blocking call we must include Vibe.D in the 
abstraction layer. Ergo, we must include at least the vibe-core package 
in Phobos, or more preferably, DRT.


I had heard noises about that a few months ago. Anything happening on 
that front?


An event loop is a key piece of a project (Async/Await) that I want to 
work on, and having it in DRuntime would make that project fantastically 
simpler. IMHO, the bulk of the time required is in getting an event loop 
into DRT, the rest is a LOT of relatively straightforward compiler lowering.


IMHO, DRT is in significant need of an event loop system. This would 
allow us to simplify a large number of problems (Async/Await, GUI's, IO, 
etc). As near as I can tell, the problem isn't so much doing the work, 
but getting the required sign-off's for inclusion into DRT.


Another problem that I've been made aware of is that vibe-core may not 
be ideal in certain situations. As this would be landed in DRT itself 
this would obviously need to be addressed.


What would the appetite be for working together to come up with a 
reasonably generic event loop for DRT that vibe and other systems could 
then leverage?


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: LDC 1.5.0-beta1

On Monday, 23 October 2017 at 21:26:46 UTC, Guillaume Piolat 
wrote:
Some measurements for some audio processing. Output are 
identical across compilers (30 measures).


Guillaume, can you try with building your own LTO version of the 
standard library and do new measurements?


Something like this should work:
```
ldc-build-runtime --reset --dFlags="-flto=full" 
BUILD_SHARED_LIBS=OFF


ldc2 -your-normal-compile-flags -flto=full 
-L-L./ldc-build-runtime.tmp/lib

```

Use `--dFlags="-flto=full;-ar="` for now if you are using macOS 
(will not be needed with the next beta).


(you can try with `-flto=thin` too for much faster link times)

Cheers,
  Johan

Re: LDC 1.5.0-beta1

2017-10-23 Thread Guillaume Piolat via Digitalmars-d-announce


On Monday, 23 October 2017 at 22:06:43 UTC, Johan Engelen wrote:
Guillaume, can you try with building your own LTO version of 
the standard library and do new measurements?


Something like this should work:
```
ldc-build-runtime --reset --dFlags="-flto=full" 
BUILD_SHARED_LIBS=OFF


ldc2 -your-normal-compile-flags -flto=full 
-L-L./ldc-build-runtime.tmp/lib

```

Use `--dFlags="-flto=full;-ar="` for now if you are using macOS 
(will not be needed with the next beta).


(you can try with `-flto=thin` too for much faster link times)

Cheers,
  Johan


So far my benchmark scripts are Windows-only so no LTO is 
available AFAIK. I can work on providing such measures (or any 
flags you want) on OSX in the future.

Re: D for microservices

2017-10-23 Thread rikki cattermole via Digitalmars-d


On 23/10/2017 11:02 PM, Adam Wilson wrote:

On 10/23/17 05:08, Jacob Carlborg wrote:

* Database drivers for the common databases (PostgreSQL, MySQL, SQLite)
compatible with vibe.d
* Database driver abstraction on top of the above drivers, perhaps some
lightweight ORM library


I've been looking pretty extensively at these two items recently.

If the database drivers are compatible with Vibe.d AND we wish to 
provide a common abstraction layer for them (presumably via Phobos) then 
order for the abstraction layer to aware of the whether the driver is 
making a blocking or non-blocking call we must include Vibe.D in the 
abstraction layer. Ergo, we must include at least the vibe-core package 
in Phobos, or more preferably, DRT.


I had heard noises about that a few months ago. Anything happening on 
that front?


An event loop is a key piece of a project (Async/Await) that I want to 
work on, and having it in DRuntime would make that project fantastically 
simpler. IMHO, the bulk of the time required is in getting an event loop 
into DRT, the rest is a LOT of relatively straightforward compiler 
lowering.


IMHO, DRT is in significant need of an event loop system. This would 
allow us to simplify a large number of problems (Async/Await, GUI's, IO, 
etc). As near as I can tell, the problem isn't so much doing the work, 
but getting the required sign-off's for inclusion into DRT.


Another problem that I've been made aware of is that vibe-core may not 
be ideal in certain situations. As this would be landed in DRT itself 
this would obviously need to be addressed.


What would the appetite be for working together to come up with a 
reasonably generic event loop for DRT that vibe and other systems could 
then leverage?




*whispers* heyyy, heard about SPEW[0]?

[0] 
https://github.com/Devisualization/spew/blob/master/src/base/cf/spew/event_loop/defs.d

Re: D could catch this wave: web assembly

2017-10-23 Thread codephantom via Digitalmars-d


On Monday, 23 October 2017 at 22:32:55 UTC, bioinfornatics wrote:
To remember it will be the next  open standard by a W3C 
Community Group to create portable and efficient application 
across major web browser. A such feature can offer to D a 
chance to have a killer app in 3D web application instead to 
develop complex C++ code.


Consensus is irrelevant.

Google will lead, others will simply follow.

The web stack is like rubbish...a heterogeneous mixture of 
discardable material!

PixelPerfectEngine v0.9.2

2017-10-23 Thread solidstate1991 via Digitalmars-d-announce


https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.9.2

New features:
* More use of D's own language features, this will be improve 
even further in the future.
* WindowMaker for PPE/Concrete enables the creation of GUI 
elements. Currently it's in its very early stages, lot of 
functions are missing or don't work correctly, but it's made well 
enough now to help to finish itself, alongside PixelPerfectEditor.
* Some levels of parallelization in the rendering that works 
similarly to 3DFX's own SLI technology, currently has too much 
artifacting thanks to threading issues. Going to fix it soon, 
even if it only has some advantage with CPU rendering (GPU 
rendering will be done either through custom shaders, or through 
some form of GPGPU method, probably DCompute to make portability 
easier).

* Started working on its own audio engine.

Coming soon:
* Various ways of soundFX/music generation (FM, sample/wavetable).
* Sprite scaling/rotation/3D effects.
* Some way to reduce redraw calls and area, for GUI mainly.
* Multiple system support, including the Raspberry Pi.

Re: What is the Philosophy of D?

2017-10-23 Thread Tony via Digitalmars-d


Combine C and Java.

Mir Random v0.2.8 release

2017-10-23 Thread Nathan S. via Digitalmars-d-announce


About package
--
Mir-Random [1] is a random number generator library that covers 
C++ STL [2]. It is compatible with mir.ndslice, std.algorithm, 
and std.range. In the same time mir.random has its own API, 
which is more secure and safe compared with std.random.


Release v0.2.8
--
Additions:
- Added xorshift1024*φ and xoroshiro128+ generators [3] 
(mir.random.engine.xorshift : Xorshift1024StarPhi, 
Xoroshiro128Plus)

- Mt19937 and Mt19937_64 can be seeded from array or ndslice
- mir.random.engine.preferHighBits!T to query new optional enum 
bool preferHighBits


Improvements:
- When the high bits of a PRNG's output are known to have better 
statistical properties than the low bits, use high bits when not 
all bits of output are required.
- On macOS, OpenBSD, and NetBSD, use arc4random_buf [4] in 
unpredictableSeed and genRandomNonBlocking.


Bugfixes:
- Fix isSaturatedRandomEngine!T not working when T.opCall is a 
function template.

- Fix address-based increment for PCGs in unique_stream mode.
- Incorporated upstream fix for seeding a MCG with a seed that's 
a multiple of the modulus.


Links
--
[1] https://github.com/libmir/mir-random
[2] http://en.cppreference.com/w/cpp/numeric/random
[3] http://xoroshiro.di.unimi.it/
[4] https://man.openbsd.org/arc4random.3

Re: Mir Random v0.2.8 release

2017-10-23 Thread Nathan S. via Digitalmars-d-announce


On Tuesday, 24 October 2017 at 03:30:19 UTC, Nathan S. wrote:
- On macOS, OpenBSD, and NetBSD, use arc4random_buf [4] in 
unpredictableSeed and genRandomNonBlocking.


Since I am not sure whether this is common knowledge, arc4random 
isn't based on RC4 on these platforms. macOS uses AES, and 
OpenBSD and NetBSD use ChaCha20.

[Issue 17927] [scope] `scope inout` parameter value can be escaped via return

2017-10-23 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #7 from Walter Bright  ---
Spec pull: https://github.com/dlang/dlang.org/pull/1914

--

Re: My two cents

2017-10-23 Thread drug via Digitalmars-d


23.10.2017 12:58, bauss пишет:

On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:

20.10.2017 17:46, Martin Nowak пишет:

On Thursday, 19 October 2017 at 06:50:12 UTC, Fra Mecca wrote:

We miss a build system that is tailored towards enterprises


Anything more specific on that?


My 2 cent:
1. dub needs ability to work with other repository than standard ones.


You can use "preGenerateCommands", "postGenerateCommands", 
"preBuildCommands" or "postBuildCommands", then simply have some shell 
script to invoke that performs what you need with other eco systems.


Of course I can, I just tried to describe what meant `a build system 
that is tailored towards enterprises` for me.


Also such build system should provide a way to build C/C++ (and others) 
codebase or let other build systems build D codebase, using generated 
makefile for example.

Re: Automatically using stack allocations instead of GC

2017-10-23 Thread Dmitry Olshansky via Digitalmars-d


On Monday, 23 October 2017 at 09:06:21 UTC, Per Nordlöw wrote:
Are there any plans (or is it already happening) to make 
D-compilers automatically use stack allocations when possible 
in cases like


int foo()
{
auto x = [1, 2]; // should be allocated on the stack
return y = x[0] + x[1];
}

where allocations are "small enough" and cannot escape the 
current scope?


And how does/should/will this interact with `@nogc`?

LDC does something like that IIRC.

Re: Automatically using stack allocations instead of GC

2017-10-23 Thread Walter Bright via Digitalmars-d


On 10/23/2017 2:06 AM, Per Nordlöw wrote:
Are there any plans (or is it already happening) to make D-compilers 
automatically use stack allocations when possible in cases like


int foo()
{
     auto x = [1, 2]; // should be allocated on the stack
     return y = x[0] + x[1];
}

where allocations are "small enough" and cannot escape the current scope?


There are no plans at the moment, but it's a good idea that `scope` can make 
possible.



And how does/should/will this interact with `@nogc`?


If it gets allocated on the stack, then it should be compatible with @nogc.

Re: My two cents


On Monday, 23 October 2017 at 11:02:41 UTC, Martin Nowak wrote:
In C++ incremental rebuilds are simple as you compile each file 
individually anyhow, but that's the crux for why C++ 
compilations are so slow in the first place.
Compiling multiple modules at once provides lots of speedups as 
you do not have to reparse and analyze common/mutual imports, 
but on the downside it cannot be parallelized that well.


dub supports --buildMode=singleFile --parallel to mimic that, but 
it's very wasteful.


For example gtk-d took way over a minute with single file 
compilation, but only a few seconds when being compiled at once

Re: My two cents

On Saturday, 21 October 2017 at 18:52:15 UTC, bitwise wrote:

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

async/await (vibe.d is nice but useless in comparison to C# or
js async/await idiom)

Reference counting when we cannot use GC...

If I understand correctly, both of these depend on
implementation of 'scope' which is being worked on right now.

Scope is about preventing pointer escaping, ref-counting also
needs to make use-after-free safe which is currently in the early
spec phase.
Whether or not that is going to be a compile-time or runtime
check has yet to be figured out. If you have a great idea that we
should consider, let us know.

The recent IOPipe window invalidation discussion was a good
example of what such a mechanism would hopefully be able to
handle
(https://gist.github.com/MartinNowak/b406a6b7aa6d0964147c107771b64333#file-safety_dance-d-L43-L45).

I think reference counting needs 'scope' to be made safe. RC
also benefits from scope in that many of the
increments/decrements of the ref count can be elided. The
performance gain can be significant, and even more so when you
use atomic reference counting (like C++ shared_ptr) for thread
safety.

Well, there can be RC and shared(RC), only the latter would need
to do atomic ref-counting.

Async/Await needs to allocate state for the function's local
variables. When it's detected that the function's
state/enumerator won't escape it's current scope, it can be put
on the stack, which is a pretty big optimization.

We should figure out how to allocate RC/unique delegate contexts.
Not that with async/await you always escape the local context, as
it's the callback in the returned Promise/Task.

Re: My two cents


On Monday, 23 October 2017 at 10:42:35 UTC, drug wrote:
Also such build system should provide a way to build C/C++ (and 
others) codebase or let other build systems build D codebase, 
using generated makefile for example.


In fact dub can generate cmake files, more generators for e.g. 
ninja or meson could be added.

Re: My two cents


On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:

20.10.2017 17:46, Martin Nowak пишет:
My 2 cent:
1. dub needs ability to work with other repository than 
standard ones.


You mount or clone whatever you want and use `dub add-local`.

2. multicore building - entire project in D builds faster than 
C++ one (I have two implementation of the same), but in case of 
incremental building C++ faster.


I always assumed this to be the main point why people are asking 
for a better build tool, but it's not sth. dub can do atm. It's a 
limitation of the compiler that requires various changes and a 
slight redesign of our build model.


In C++ incremental rebuilds are simple as you compile each file 
individually anyhow, but that's the crux for why C++ compilations 
are so slow in the first place.
Compiling multiple modules at once provides lots of speedups as 
you do not have to reparse and analyze common/mutual imports, but 
on the downside it cannot be parallelized that well.


Dub could parallelize building individual packages/sub-packages 
(target + dependencies) right now though.


3. dub single build mode does not caches builds so it builds 
entire project every time.


Could you please file an issue with a test case for that.
Why do you use single build mode in the first place?

Re: My two cents

2017-10-23 Thread Anton Fediushin via Digitalmars-d-announce


On Sunday, 22 October 2017 at 22:00:19 UTC, bitwise wrote:
I hope resumable functions for for generator/coroutine style 
usage are also part of the plan. Allocator support would be 
nice too.


Please see 
https://forum.dlang.org/post/pbnthucxpvbgzzuig...@forum.dlang.org 
for how this could be implemented and why this is not much of a 
priority right now.
If someone wants to pull this off, the effort would be very 
welcome.

Re: My two cents

2017-10-23 Thread Guillaume Piolat via Digitalmars-d


On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
dub is great for simple solutions but useless in big projects 
with multiple targets, configurations, etc.


Works here. Closed source can be handled with path-based 
dependencies and private checkouts.


Configurations are handled by... dub configurations.
Targets? by dub targets.

Still cannot easily develop closed source dlls on Windows. On 
Linux every symbol is public by default, but on Windows not so 
it's needed to export them manually.


Not anymore, you can use the "export" keyword for Windows (eg 
with LDC >= 1.2).


Every-symbol-public-by-default in Posix is annoying though :)


For me, it seems like Walter is solving edge case problems like 
return ref parameters and return functions but is unable to add 
some basic stuff.


Because **everyone has its own, different opinion of what the 
"basic stuff which is absolutely needed" is**, and adding all of 
that would be 3x the size of D and unpleasant.
For starters, some of us would like stuff to be _removed_, not 
added.


It's like a tradition: each new generation of D users ask for the 
additional, "must-have" features of the day.

Automatically using stack allocations instead of GC

2017-10-23 Thread Per Nordlöw via Digitalmars-d

Are there any plans (or is it already happening) to make 
D-compilers automatically use stack allocations when possible in 
cases like


int foo()
{
auto x = [1, 2]; // should be allocated on the stack
return y = x[0] + x[1];
}

where allocations are "small enough" and cannot escape the 
current scope?


And how does/should/will this interact with `@nogc`?

Re: My two cents

2017-10-23 Thread Satoshi via Digitalmars-d


On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

Hi,
I had been using D for almost 6 years and I want to share my 
opinion with you.
I don't want to blame anyone but I'll focus more on bad things 
and possible improvements.

And this is just how I see D from my perspective.
(Sorry for my English, I'm too lazy to take the lessons).

[...]


Whats about this one?

auto foo = 42;
auto bar = "bar";
writeln(`Foo is {foo} and bar is {bar}`);

Re: Unit Testing in Action


On Friday, 20 October 2017 at 14:04:25 UTC, Mike Parker wrote:
After a couple of weeks of quiet on the D blog, it's about to 
get noisy again. The latest is is a post by Mario Kröplin of 
Funkwerk describing how the company now uses D's built-in tests 
in their codebase after several years of using third-party 
frameworks.


Blog:
https://dlang.org/blog/2017/10/20/unit-testing-in-action/

Reddit:
https://www.reddit.com/r/programming/comments/77m8r8/ds_builtin_unit_testing_in_action/


Yay! My app - covered is in this post!

That's so cool, when somebody uses your code. Thank you, Mario.

GDC new versions weird asm code generation

2017-10-23 Thread Daniel Kozak via Digitalmars-d


https://godbolt.org/g/uEBiSi

I would expected

int example.foo():
mov eax, 3
ret

for new gdc too.

Re: My two cents

2017-10-23 Thread bauss via Digitalmars-d


On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:

20.10.2017 17:46, Martin Nowak пишет:

On Thursday, 19 October 2017 at 06:50:12 UTC, Fra Mecca wrote:

We miss a build system that is tailored towards enterprises


Anything more specific on that?


My 2 cent:
1. dub needs ability to work with other repository than 
standard ones.


You can use "preGenerateCommands", "postGenerateCommands", 
"preBuildCommands" or "postBuildCommands", then simply have some 
shell script to invoke that performs what you need with other eco 
systems.

Re: LDC 1.5.0-beta1

2017-10-23 Thread Johan via Digitalmars-d-announce


On Sunday, 22 October 2017 at 09:34:56 UTC, kinke wrote:

Hi everyone,

on behalf of the LDC team, I'm glad to announce the first beta 
for LDC 1.5.0.


Jon Degenhardt did some nice LTO testing, see: 
https://github.com/ldc-developers/ldc/issues/2380


-Johan

Re: My two cents

2017-10-23 Thread Arun Chandrasekaran via Digitalmars-d


On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

[...]


The language for sure is huge and complicated and adding new 
features will only make it grow bigger. I'm not saying we 
shouldn't add any new features. It is important to have the right 
defaults to gain the critical mass for the momentum to reach the 
next level.


I've been playing with D and most of the times I look for the 
idiomatic way of doing things in D rather than bringing my 
Java/C++ baggage with it.


p0nce's d-idioms[1] is excellent, but is still not enough. We 
should have more like it (and better).


Without the libraries like Boost and Qt, and ideas from books 
like Effective C++ series, Modern C++ design, etc it was once 
impossible for "humans" to write maintainable code in C++03. 
C++11/14 improved it a bit.


D is brilliant in many ways:

1. has the best C++ interfacing

2. very easy to write and reason about

Found this gem when reading Phobos

```
import std.algorithm, std.range, std.stdio;

void main()
{
enum size = 500;
writef("P5\n%d %d %d\n", size, size, ubyte.max);

iota(-1, 3, 2.0/size).map!(y =>
iota(-1.5, 0.5, 2.0/size).map!(x =>
cast(ubyte)(1+
recurrence!((a, n) => x + y*1i + a[n-1]^^2)(0+0i)
.take(ubyte.max)
.countUntil!(z => z.re^^2 + z.im^^2 > 4))
)
)
.copy(stdout.lockingBinaryWriter);
}
```

Such code should be on the front page to "market"

3. human readable std lib (unlike libstdc++)
4. Some features are very well thought and well designed, but 
some are not

5. TMP for humans

The community lacks language theory expert (purist?). (Rust 
community has the maximum, if I'm correct).

[Issue 16800] Minimum double inconsistency/problems + double.min + (number '4.9E-324' is not representable) / Mac / Windows

2017-10-23 Thread d-bugmail--- via Digitalmars-d-bugs

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

Octav Pelin  changed:

   What|Removed |Added

 CC||octavpe...@outlook.com

--

[Issue 17842] [scope] array append allows for escaping references

2017-10-23 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7236

--

Re: Automatically using stack allocations instead of GC

2017-10-23 Thread Daniel Kozak via Digitalmars-d


On Monday, 23 October 2017 at 09:06:21 UTC, Per Nordlöw wrote:
Are there any plans (or is it already happening) to make 
D-compilers automatically use stack allocations when possible 
in cases like


int foo()
{
auto x = [1, 2]; // should be allocated on the stack
return y = x[0] + x[1];
}

where allocations are "small enough" and cannot escape the 
current scope?


And how does/should/will this interact with `@nogc`?


AFAIK does not work right now.

Re: My two cents

2017-10-23 Thread Seb via Digitalmars-d


On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

Hi,
I had been using D for almost 6 years and I want to share my 
opinion with you.
I don't want to blame anyone but I'll focus more on bad things 
and possible improvements.

And this is just how I see D from my perspective.
(Sorry for my English, I'm too lazy to take the lessons).

[...]


Whats about this one?

auto foo = 42;
auto bar = "bar";
writeln(`Foo is {foo} and bar is {bar}`);


https://github.com/dlang/dmd/pull/6703

Requires someone to write this up as a DIP.

Re: My two cents

2017-10-23 Thread rikki cattermole via Digitalmars-d


On 23/10/2017 10:58 AM, bauss wrote:

On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:

20.10.2017 17:46, Martin Nowak пишет:

On Thursday, 19 October 2017 at 06:50:12 UTC, Fra Mecca wrote:

We miss a build system that is tailored towards enterprises


Anything more specific on that?


My 2 cent:
1. dub needs ability to work with other repository than standard ones.


You can use "preGenerateCommands", "postGenerateCommands", 
"preBuildCommands" or "postBuildCommands", then simply have some shell 
script to invoke that performs what you need with other eco systems.


"other repositories" here probably means other than github, bitbucket 
and gitlab. Which isn't actually part of dub in the first place!

Re: So why double to float conversion is implicit ?

2017-10-23 Thread codephantom via Digitalmars-d


On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:

I think this is a serious topic and needs clarification.


Just out of interest, as opposed to wanting to debate the 
merits...


I did a little investigation of how various languages deal with 
floating point precision (by default) for standard output. It is 
certainly interesting that there are differences - mostly one way 
or the other, rather than huge differences.



C
---
double d = 1.12345678912345;
printf("%lf\n", d);  // C writes -> 1.123457 (some rounding here)


C++

double d = 1.12345678912345;
std::cout << d << std::endl; // c++ writes -> 1.123456


Rust

let d = 1.12345678912345;
println!("{}", d); // Rust writes -> 1.1234568 (some rounding 
here)



D
---
double d = 1.12345678912345;
writeln(d); // D writes -> 1.12346



Java

double d = 1.12345678912345;
System.out.println(d); // java writes -> 1.12345678912345


C#

double d = 1.12345678912345;
System.Console.WriteLine(d); // C# writes -> 1.12345678912345


Python
--
d = 1.12345678912345;
print(d); // python writes -> 1.12345678912345


Go
---
d := 1.12345678912345;
fmt.Println(d); // Go prints -> 1.12345678912345


Swift
-
let d = 1.12345678912345;
print(d); // Swift prints -> 1.12345678912345

Re: My two cents

2017-10-23 Thread Nicholas Wilson via Digitalmars-d-learn


On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

Hi,
I had been using D for almost 6 years and I want to share my 
opinion with you.
I don't want to blame anyone but I'll focus more on bad things 
and possible improvements.

And this is just how I see D from my perspective.
(Sorry for my English, I'm too lazy to take the lessons).

[...]


Whats about this one?

auto foo = 42;
auto bar = "bar";
writeln(`Foo is {foo} and bar is {bar}`);


writeln("Foo is ", foo, "and bar is ", bar");

Two more characters.

Atila

Re: DMD Callstacks


On Monday, 23 October 2017 at 12:41:09 UTC, Márcio Martins wrote:
What is everyone doing to get proper file name and line number 
info for callstacks with DMD?


addr2line just gives me ??:0


What OS, etc?

Re: My two cents


On Monday, 23 October 2017 at 11:02:41 UTC, Martin Nowak wrote:

On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:

20.10.2017 17:46, Martin Nowak пишет:
My 2 cent:
1. dub needs ability to work with other repository than 
standard ones.


You mount or clone whatever you want and use `dub add-local`.

2. multicore building - entire project in D builds faster than 
C++ one (I have two implementation of the same), but in case 
of incremental building C++ faster.


I always assumed this to be the main point why people are 
asking for a better build tool, but it's not sth. dub can do 
atm. It's a limitation of the compiler that requires various 
changes and a slight redesign of our build model.


Does it? Reggae can do parallel per-package builds (in fact, the 
default) right now.


In C++ incremental rebuilds are simple as you compile each file 
individually anyhow, but that's the crux for why C++ 
compilations are so slow in the first place.


Not really. C++ is slow to compile anyway because parsing it is 
slow. C has the same compilation model and is much much faster to 
compile than C++. There's also the fact that the same headers are 
parsed over and over again. `#include ` requires 
parsing thousands of lines of code from dozens of files.


However, if all you touched was a C++ implementation file, then 
incremental builds are faster than D. Really.


Compiling multiple modules at once provides lots of speedups as 
you do not have to reparse and analyze common/mutual imports, 
but on the downside it cannot be parallelized that well.


I measured, and indeed compiling per package is faster than 
compiling all of the modules that have to be recompiled 
individually, even if done in parallel. Weirdly enough this is a 
disadvantage (time-wise) of having implementation and 
declarations in the same file.


Dub could parallelize building individual packages/sub-packages 
(target + dependencies) right now though.


reggae already does, just point it at a dub package directory. By 
default it'll even build the default target and a unittest one in 
parallel.




3. dub single build mode does not caches builds so it builds 
entire project every time.


Could you please file an issue with a test case for that.
Why do you use single build mode in the first place?


I'd assume it'd be to only rebuild the necessary files C++-style. 
However, and as stated by you above, that's usually slower anyway.


Atila

Re: My two cents

2017-10-23 Thread Guillaume Piolat via Digitalmars-d


On Monday, 23 October 2017 at 11:39:58 UTC, Martin Nowak wrote:
On Monday, 23 October 2017 at 11:23:18 UTC, Guillaume Piolat 
wrote:
Not anymore, you can use the "export" keyword for Windows (eg 
with LDC >= 1.2).


With what semantic?



We used to require .def files, and now use "export" instead on 
Windows.
Works on DMD (not sure since what version) and LDC since 
https://github.com/ldc-developers/ldc/pull/1856

Windows only and free functions only.


Every-symbol-public-by-default in Posix is annoying though :)


We agreed on hidden visibility by default for everything that's 
not exported.

This requires export to be fixed on non-Windows machines first.


This is especially interesting since hidden visibility for most 
symbols is required to make -dead_strip effective (strips most of 
the object code here).



By any means, if someone wants to help here, get in touch with 
Benjamin Thaut and me.
This has been lingering around for way to long, and Benjamin 
alone has a hard time pushing this.


Would Bountysource help be adequate?

Re: My two cents


On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

Hi,
I had been using D for almost 6 years and I want to share my 
opinion with you.
I don't want to blame anyone but I'll focus more on bad things 
and possible improvements.

And this is just how I see D from my perspective.
(Sorry for my English, I'm too lazy to take the lessons).

[...]


Whats about this one?

auto foo = 42;
auto bar = "bar";
writeln(`Foo is {foo} and bar is {bar}`);


String interpolation could be done in a library.

fmt!("Foo is ${foo} and bar is ${bar}", foo, bar)

At the moment you'd just use format.

format!"Foo is %1$s and bar is %2$s"(foo, bar);

While both are a bit more verbose, it seems to me that 
interpolated strings aren't that big a deal.
Collecting arguments and design ideas in a DIP would still be 
worthwhile and very welcome.
Even if ends up not being approved, it would ensure a good 
decision base and avoid future discussions.


Sth. like

  s"Foo is ${foo} and bar is ${bar ~ `bla`}"

to be lowered to

 format!"Foo is %1$s and bar is %2$s"(foo, bar ~ `bla`).

could be a feasible approach on a first thought.

Re: My two cents

On Monday, 23 October 2017 at 11:23:18 UTC, Guillaume Piolat 
wrote:
Not anymore, you can use the "export" keyword for Windows (eg 
with LDC >= 1.2).


With what semantic?


Every-symbol-public-by-default in Posix is annoying though :)


We agreed on hidden visibility by default for everything that's 
not exported.

This requires export to be fixed on non-Windows machines first.

By any means, if someone wants to help here, get in touch with 
Benjamin Thaut and me.
This has been lingering around for way to long, and Benjamin 
alone has a hard time pushing this.

Re: My two cents

2017-10-23 Thread drug via Digitalmars-d


23.10.2017 14:02, Martin Nowak пишет:

On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:

20.10.2017 17:46, Martin Nowak пишет:
My 2 cent:
1. dub needs ability to work with other repository than standard ones.


You mount or clone whatever you want and use `dub add-local`.
This is workaround. Now I have bash script that does all I need, but it 
would be better if I should only specify my inhouse repos.




2. multicore building - entire project in D builds faster than C++ one 
(I have two implementation of the same), but in case of incremental 
building C++ faster.


I always assumed this to be the main point why people are asking for a 
better build tool, but it's not sth. dub can do atm. It's a limitation 
of the compiler that requires various changes and a slight redesign of 
our build model.


In C++ incremental rebuilds are simple as you compile each file 
individually anyhow, but that's the crux for why C++ compilations are so 
slow in the first place.
Compiling multiple modules at once provides lots of speedups as you do 
not have to reparse and analyze common/mutual imports, but on the 
downside it cannot be parallelized that well.
I just build my project and it's silly to look at `top` output where 
seven cores idles while build takes tens of seconds. While building C++ 
project loads cores fully. I have no clear and robust opinion on this, 
considering you wrote above, but nevertheless.


Dub could parallelize building individual packages/sub-packages (target 
+ dependencies) right now though.

I should try it.


3. dub single build mode does not caches builds so it builds entire 
project every time.


Could you please file an issue with a test case for that.
Why do you use single build mode in the first place?
I have several utilities each of them is about 50 lines (including 
comment to enable single build mode) and I think this is case for single 
mode exactly. They are wrappers of rather fat library and building them 
takes about a minute what is too long for D.


I do not state that it prevents D from enterprises etc, not at all. I'm 
sure that restructuring my project can improve building time too, for 
example. Just directions where we can do more to improve tooling.

Re: My two cents


On Friday, 20 October 2017 at 15:38:53 UTC, Martin Nowak wrote:

Commercial usage, shared libraries and stuff
There isn't any handy tool to download, manage and publish 
closed source stuff.
dub is great for simple solutions but useless in big projects 
with multiple targets, configurations, etc.
Everything is primary focused on opensource development (but 
everyone here wants to see D as a next successor of C++ in 
commercial sphere).


Well, dub is a package manager to share code, so obviously OSS 
it the main target. You can easily `dub add-local` packages or 
run your private registry.



https://github.com/dlang/dub/pull/985
"A common use-case (that I currently have) is a large project 
with many dub packages in it, which much be registered with dub, 
but don't have any purpose outside that project. It also allows 
any dependencies to be easily packaged inside a project in order 
to allow building an application without an internet connection, 
by just running dub upgrade --root=$APP_PROJECT_DIR 
--defaultRepoPath=$PROJECT_ROOT/deps/ on the dev machine, then 
dub build --root=$APP_PROJECT_DIR 
--defaultRepoPath=$PROJECT_ROOT/deps/ --skip-registry=all on the 
target machine."


We've submitted a PR for our internal dub fork that we use to 
build a decent-sized project (not as big as Weka, but not much 
smaller).  Sadly it required quite a few changes and was hard to 
break into bite-sized ones.


If you're working on a big internal project, I'd say that it's 
worth thinking about things from a medium-term perspective.  With 
D you have higher costs to get the build system etc right, but 
you gain and keep gaining from having more concise, clearer, more 
maintainable, and more plastic code.  The costs are front-loaded 
though.  If one's able to take a medium-term perspective and the 
changes you want to see in dub are not all that much, it may well 
be worth finding someone in the D community you can pay to help 
make those changes.  A little money goes a long way because here 
you have strong programmers - who like programming! - from all 
over the world, and not everyone is in a situation that makes 
their opportunity cost as high as what it might be within the 
company (not just payroll, but overheads, co-ordination costs 
etc).


And you may find other commercial users are willing to split the 
costs - that's something a large media company asked me about, 
and that we would be open to also if it's something that will fit 
with what we need.


And of course there are various other options like Make, CMake, 
Meson, or Raggae.


(Reggae).  We use Reggae for building proprietary codebase.  If 
there's a feature missing, please do say - maybe we would benefit 
from it, and since Atila works with us, it's something easy to 
consider when time.



As unfortunately with almost any OSS project, we're not that 
many people, and each of us is investing a huge amount of time 
into this.


Also - for example with dub.  Dub and vibe constitute an amazing 
achievement for one man.  I don't mean to diminish the 
contribution of others, but I guess Sonke has been the creative 
spirit behind them and has done most of the work.  There's one 
challenge that arises when you can benefit from the work of 
unusually productive people (of whom there seem to be many in the 
D community - I just take Sonke as one example), is that for that 
same reason they end up getting responsibility in the commercial 
parts of their lives, which might mean less time available to 
devote to open-source at certain points.


There are 39 pull requests open on dub currently. It's not a 
super-complicated code base, but I guess the people responsible 
for dub have quite a lot on their plates.  I don't know how 
others might be able to help, but maybe that is one area that 
would benefit the language ecosystem more generally.  (I get the 
impression sometimes that people want to help, but they don't 
completely know how).


There's no mention of dub here, for example:
https://wiki.dlang.org/Get_involved

Now there is.. (I just added it).
https://wiki.dlang.org/Get_involved#Review_pull_requests

But again your best bet on getting sth. done is working on it, 
be it writing a DIP, organizing the discussion, or actually 
implementing it.


Bountysource went quiet, though I started contributing to it.  I 
wonder if there is a better way for commercial users to say what 
they might be willing to pay for and how much.  I don't think 
that keeping patches private for a while really fits.  It doesn't 
hurt me if some other D user benefits from work I sponsored.  In 
fact it helps me if it is incorporated into the main codebase, 
because that means I don't need to worry about maintaining it.  
And that's in any case way too selfish a perspective - not smart 
commercially: if D flourishes, it helps us too.



Laeeth.

[Issue 17060] betterC std.allocator

2017-10-23 Thread d-bugmail--- via Digitalmars-d-bugs

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

radu.raca...@gmail.com changed:

   What|Removed |Added

 CC||radu.raca...@gmail.com

--- Comment #1 from radu.raca...@gmail.com ---
+1.

Allocators are missing from betterC mode, and they are a very important
improvement over C's malloc/free.

I think scope(xxx) and struct destructors need to work in betterC mode as a
mandatory requirement for allocator redesign.

In my opinion they need to be split in 2 : C runtime (core?), and D runtime
based - the C runtime based ones should be obviously usable from betterC and
ideally the D runtime one should be constructed on the basic blocks provided by
the C runtime implementation.

Given the experimental nature of the allocatos package this would be a good
time to revisit their design and improve their modularity

--

Re: D for microservices

2017-10-23 Thread Atila Neves via Digitalmars-d-announce


On Sunday, 22 October 2017 at 02:48:57 UTC, Joakim wrote:
I just read the following two week-old comment on the ldc issue 
tracker, when someone tried to run D on Alpine linux:


"For now everything works(?) but I think the process could be 
improved.. Would be really cool to have LDC easily building 
alpine containers + static D binaries for microservice and 
tooling development. I'm pretty tired of reading Go code :)"

https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550

It strikes me that microservices are a great way for new 
programming languages like D to get tried and gain some uptake, 
but that D might not be that easy to deploy to that scenario 
yet.


So this is a question for those deploying microservices, as I'm 
not in that field, what can the D devs do to make it as easy as 
possible to get D microservices up and running, make some 
Docker and Alpine containers with ldc/dub/vibe.d preinstalled 
publicly available?  What else, what kinds of libraries do you 
normally use?


This is a niche that D and all newer languages should target.  
How do we do it?


We're going a bit in that direction, although it's a different 
thing in our kind of industry from a web company - we have fewer 
services and many fewer requests, but latency matters more for 
example.  I was thinking we might use Go for some services that 
integrate and monitor things, but we could also use D.


https://jobs.github.com/positions/8e98eac8-b504-11e7-9da8-0737a3dcef18

From the comment:
"Would be really cool to have LDC easily building alpine 
containers + static D binaries"


How can we generate a static binary ?  I asked about this before, 
and the response was that it's a bad idea because of security 
vulns and so on.  True if you are running on a conventional Linux 
host.  But on the other hand, it's not that great if when the 
system phobos is upgraded all the D binaries break.  You can 
write a script using rdmd or dub scripting feature, but that 
doesn't work for more complex programs.


And on the other hand, for deployment, it's much easier to copy 
over one binary.  (In a sense it's funny that the question was 
asked in the context of containers, because containers are kind 
of an alternative to having a single binary).  When you're 
properly set-up of course it doesn't matter, but when you're 
moving towards that, a single binary is much easier.


I guess I can figure out the answer to this question easily 
enough, but I think giving people the option might help with 
adoption of D for micro services.  For example it's really just 
not that fun to make an AWS Lambda using D - being able to easily 
build a static binary would make the process much more pleasant.


I wrote this up a while back:
http://awslambda-d.readthedocs.io/en/latest/

"Since dmd links phobos dynamically on linux, and phobos/druntime 
aren't installed on the AWS lambda server, we will need to upload 
these to the servers and tell the application where to find them. 
(I should really have appended to LD_LIBRARY_PATH as I did with 
PATH).


Now one can follow the regular instructions for AWS Lambda: 
create a .zip file with the D binary, the JS file, and the 
following libraries (update version numbers as appropriate):


libcrypto.so.1.0.0
libphobos2.so.0.67
libevent-2.0.so.5
libssl.so.1.0.0
"

Alpine is nice - would be good to have this as a standard target 
in time.



Laeeth.

Re: Unit Testing in Action


On Friday, 20 October 2017 at 14:04:25 UTC, Mike Parker wrote:
After a couple of weeks of quiet on the D blog, it's about to 
get noisy again. The latest is is a post by Mario Kröplin of 
Funkwerk describing how the company now uses D's built-in tests 
in their codebase after several years of using third-party 
frameworks.


Blog:
https://dlang.org/blog/2017/10/20/unit-testing-in-action/

Reddit:
https://www.reddit.com/r/programming/comments/77m8r8/ds_builtin_unit_testing_in_action/


"Only for troubleshooting should you switch to unit-threaded. You 
have to be careful, however, to only use compatible features."


I probably should have made it more widely known that 
unit-threaded now has a `unitThreadedLight` version geared 
towards fast compile times. It uses the default test runner you 
get normally with just `-unittest`, but implements all of the 
custom assertions as plain asserts for faster turnaround times 
when the tests pass.


"parallel test execution (from it’s name, the main goal of 
unit-threaded) was quite problematic with the first test suite we 
converted"


I'd love to know what the problems were, especially since it's 
possible to run in just one thread with a command-line option, or 
to use UDAs to run certain tests in a module in the same thread 
(sometimes one has to change global state, as much as that is 
usually not a good idea).


"With the new static foreach feature however, it is easy to 
implement parameterized tests without the support of a framework"


It is, but it's the same problem with plain asserts in terms of 
knowing what went wrong unless the parameterised value happens to 
be in the assertion. And there's also the issue of running the 
test only for the value/type that it failed for instead of going 
through the whole static foreach everytime.


Atila

DMD Callstacks

2017-10-23 Thread Márcio Martins via Digitalmars-d-learn

What is everyone doing to get proper file name and line number 
info for callstacks with DMD?


addr2line just gives me ??:0

Re: Unit Testing in Action

2017-10-23 Thread Martin Nowak via Digitalmars-d-announce


On Saturday, 21 October 2017 at 22:50:51 UTC, Walter Bright wrote:

Coverage would give:

1|x = 2;
2|if (x == 1 || x == 2)

I.e. the second line gets an execution count of 2. By contrast,

1|x = 1;
1|if (x == 1 || x == 2)


Interesting point, but would likely fail for more complex stuff.

1| stmt;
2| if (api1 == 1 && api2 == 2 ||
   api2 == 2 && api3 == 3)

Anyhow, I think the current state is good enough and there are 
gdc/ldc for further coverage features.

Re: Automatically using stack allocations instead of GC

2017-10-23 Thread Per Nordlöw via Digitalmars-d


On Monday, 23 October 2017 at 10:48:37 UTC, Walter Bright wrote:
There are no plans at the moment, but it's a good idea that 
`scope` can make possible.


I'm glad your open for such automatic optimizations, Walter. 
Making D compilers automate these things which are cumbersome 
manual labour in languages such as Rust is, IMHO, the competitive 
way forward for D.



And how does/should/will this interact with `@nogc`?


If it gets allocated on the stack, then it should be compatible 
with @nogc.


Great. I believe good diagnostics (for, in this case, mismatches 
between allocations and qualifiers) will play a key role in this 
regard.

Re: D for microservices


On 2017-10-22 04:48, Joakim wrote:
I just read the following two week-old comment on the ldc issue tracker, 
when someone tried to run D on Alpine linux:


"For now everything works(?) but I think the process could be improved.. 
Would be really cool to have LDC easily building alpine containers + 
static D binaries for microservice and tooling development. I'm pretty 
tired of reading Go code :)"

https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550

It strikes me that microservices are a great way for new programming 
languages like D to get tried and gain some uptake, but that D might not 
be that easy to deploy to that scenario yet.


So this is a question for those deploying microservices, as I'm not in 
that field, what can the D devs do to make it as easy as possible to get 
D microservices up and running, make some Docker and Alpine containers 
with ldc/dub/vibe.d preinstalled publicly available?  What else, what 
kinds of libraries do you normally use?


This is a niche that D and all newer languages should target. How do we 
do it?


* Support full static linking using DMD, which requires the TLS 
implementation to be modified

* Support musl as the standard C library, I've discussed that before [1]
* Database drivers for the common databases (PostgreSQL, MySQL, SQLite) 
compatible with vibe.d
* Database driver abstraction on top of the above drivers, perhaps some 
lightweight ORM library

* RabbitMQ library compatible with vibe.d
* Serialization to/from JSON and YAML
* Official Docker images with DMD and LDC wouldn't hurt
* Pre-compiled DMD that works on Alpine. Fully statically linked DMD 
would help here


That's what I can think of for now.

[1] http://forum.dlang.org/post/nhem1l$1ee3$1...@digitalmars.com

--
/Jacob Carlborg

Re: D for microservices

2017-10-23 Thread rikki cattermole via Digitalmars-d-learn


On Monday, 23 October 2017 at 12:08:52 UTC, Jacob Carlborg wrote:

On 2017-10-22 04:48, Joakim wrote:
I just read the following two week-old comment on the ldc 
issue tracker, when someone tried to run D on Alpine linux:


"For now everything works(?) but I think the process could be 
improved.. Would be really cool to have LDC easily building 
alpine containers + static D binaries for microservice and 
tooling development. I'm pretty tired of reading Go code :)"

https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550

It strikes me that microservices are a great way for new 
programming languages like D to get tried and gain some 
uptake, but that D might not be that easy to deploy to that 
scenario yet.


So this is a question for those deploying microservices, as 
I'm not in that field, what can the D devs do to make it as 
easy as possible to get D microservices up and running, make 
some Docker and Alpine containers with ldc/dub/vibe.d 
preinstalled publicly available?  What else, what kinds of 
libraries do you normally use?


This is a niche that D and all newer languages should target. 
How do we do it?


* Support full static linking using DMD, which requires the TLS 
implementation to be modified
* Support musl as the standard C library, I've discussed that 
before [1]
* Database drivers for the common databases (PostgreSQL, MySQL, 
SQLite) compatible with vibe.d
* Database driver abstraction on top of the above drivers, 
perhaps some lightweight ORM library

* RabbitMQ library compatible with vibe.d
* Serialization to/from JSON and YAML
* Official Docker images with DMD and LDC wouldn't hurt
* Pre-compiled DMD that works on Alpine. Fully statically 
linked DMD would help here


That's what I can think of for now.

[1] http://forum.dlang.org/post/nhem1l$1ee3$1...@digitalmars.com


Can you elaborate on how the TLS implementation needs to be 
changed?


If someone wanted to work on rabbit bindings/wrapper, I might be 
open to sponsoring that.  I'm not in love with Rabbit (one node 
uses more than 40% of memory so the node goes down, taking the 
cluster with it.  really?), but we use it currently.


I made a start on bindings for librabbitmq here:
https://github.com/kaleidicassociates/rabbitmq-d


Laeeth.

Re: Dynamically import() files

Don't be afraid to write a small script that is run before a build to 
generate a list of files which than can be imported.

Re: My first experience as a D Newbie


On Saturday, 21 October 2017 at 09:51:41 UTC, Mark wrote:

On Saturday, 21 October 2017 at 01:45:40 UTC, codephantom wrote:
The real challenge (and ultimate goal) for any  open-source 
project (especially a volunteer based one), is finding 
equilibria.


Honestly, I do not believe that an open-source project, beyond 
a certain scale, can sustain itself without a consistent income 
stream.


The Foundation has gone from zero to something.  That's the 
hardest part.  Over time I'm sure its revenue will grow.

Dynamically import() files

2017-10-23 Thread Andre Pany via Digitalmars-d-learn


Hi,

I have a folder "i18n" which contains message bundle files. For 
now it contains only the message bundle file written by the 
developer: "messagebundle.properties".


During the translation process additional message bundle files 
will be added to github:

messagebundle_en.properties
messagebundle_de.properties
...
Changing the github content will automatically triggering the 
compilation process.
My wish is, that every time a new message bundle file is added, 
these file is automatically included into the compilation process.



I doubt, but is there a possibility to check during compile time 
which files exists in the

i18n folder and import() these files?

I see currently only 1 chance: Create a list of all possible 
language code (max 7) and check whether the import works via 
__traits(compiles,...).


Something like:
alias languages = TypeTuple!("en", "de");
static foreach(lang; languages)
{
...
}

Kind regards
André

Re: Automatically using stack allocations instead of GC

2017-10-23 Thread Nicholas Wilson via Digitalmars-d

On Monday, 23 October 2017 at 10:42:44 UTC, Dmitry Olshansky 
wrote:

On Monday, 23 October 2017 at 09:06:21 UTC, Per Nordlöw wrote:
Are there any plans (or is it already happening) to make 
D-compilers automatically use stack allocations when possible 
in cases like


int foo()
{
auto x = [1, 2]; // should be allocated on the stack
return y = x[0] + x[1];
}

where allocations are "small enough" and cannot escape the 
current scope?


And how does/should/will this interact with `@nogc`?

LDC does something like that IIRC.


It does. 
https://github.com/ldc-developers/ldc/blob/master/gen/passes/GarbageCollect2Stack.cpp

It is enabled by default at -O2 or higher (but not -Os or -Oz).

Re: So why double to float conversion is implicit ?

2017-10-23 Thread Márcio Martins via Digitalmars-d-learn


On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
I was working on some sort of math library for use in graphical 
computing and I wrote something like this:


const float PiOver2 = (atan(1.0) * 4) / 2;

Interestingly enough, I realized that atan() returns double (in 
this case) but wait, it's assigned to a float variable! 
Compiler didn't even emit warnings, let alone errors.


I see no reason as to why would this be legal in this century, 
especially in D.

So can someone tell me what's the argument against this?
Why type conversions differ between integral and floating types?
Why can't I assign a long to an int but it's fine when 
assigning double to float?


I think this is a serious topic and needs clarification.


I think an issue here is specifying `float` to begin with. I'd 
only do that if I wanted it to be `float`, knowing that the 
expression is a different type, and even then I'd add a comment 
explaining why I felt the need to be explicity. i.e. I'd have 
written


const PiOver2 = (atan(1.0) * 4) / 2;

Atila

Re: DMD Callstacks


On Monday, 23 October 2017 at 12:54:33 UTC, Nicholas Wilson wrote:
On Monday, 23 October 2017 at 12:41:09 UTC, Márcio Martins 
wrote:
What is everyone doing to get proper file name and line number 
info for callstacks with DMD?


addr2line just gives me ??:0


What OS, etc?


Linux 64-bit (Ubuntu 16)
DMD64 2.076.1

writeln double precision

2017-10-23 Thread Arun Chandrasekaran via Digitalmars-d-learn

I've written a simple tool [1] to find the DET and CMC 
specifically for biometrics performance measurement.


When I generate the report, I expected to see high precision 
floating point numbers, but I see that writefln trims the 
precision to the last 6 digits after decimal point.


Am I doing the right thing here? Should I use a different format 
specifier?


[1] https://bitbucket.org/carun/biometrics-reports/src

Cheers,
Arun

Re: My two cents

2017-10-23 Thread Dmitry Olshansky via Digitalmars-d


On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:

On 10/23/17 17:27, flamencofantasy wrote:

On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:

On 10/23/17 08:21, Kagamin wrote:

[...]


Actually I think it fits perfectly with D, not for reason of
performance, but for reason of flexibility. D is a polyglot 
language,
with by far the most number of methodologies supported in a 
single

language that I've ever encountered.

[...]


There is a lot of misunderstanding about async/await. It has 
nothing to
do with "conservation of thread resources" or trading "raw 
performance

for an ability
to handle a truly massive number of simultaneous tasks". 
Async/await
is just 'syntactic sugar' where the compiler re-writes your 
code into
a state machine around APM (Asynchronous programming model 
which was
introduced in .NET 2.0 sometime around 2002 I believe). 
That's all

there is to it, it makes your asynchronous code look and feel
synchronous.



The only parts of Async/Await that have anything to do with APM 
are the interop stubs. C#'s Async/Await is built around the 
Task Asynchronous Programming model (e.g. Task and Task) the 
compiler lowers to those, not APM. A common misunderstanding is 
that Task/Task is based on APM, it's not, Task uses 
fundamentally different code underneath. On Linux/macOS it 
actually uses libuv (at the end of the day all of these 
programming models are callback based).




I’ll throw in my 2 rubbles.

I actually worked on a VM that has async/await feature built-in 
(Dart language).
It is a plain syntax sugar for Future/Promise explicit asynchrony 
where async automatically return Future[T] or Observable[T] (the 
latter is async stream).


Async function with awaits is then re-written as a single 
call-back with a basic state machine, each state corresponds to 
the line where you did await.


Example:

async double calculateTax(){
  double taxRate = await getTaxRates();
  double income = await getIncome();
  return taxRate * income;
}

Becomes roughly this (a bit more mechanical though):

Future!double calculateTax(){
   int state = 0;
   Promise!double __ret;
   double taxRate;
   double income;
   void cb() {
  if(state == 0) {
state = 1;
getTaxRates().andThen((double ret){
 taxRate = ret;
 cb();
});
  }
  else if (state == 1) {
 state = 2;
 getIncome().andThen((double ret){
 income = ret;
 cb();
});
   else if (state == 2){
__ret.resolve(taxRate*income);
}
   }
   cb();
  }

It doesn’t matter what mechanics you use to complete promises - 
be it IO scheduler a-la libuv or something else. Async/await is 
agnostic to that.


Still there is a fair amount of machinery to hide the rewrite 
from the user and in particular print stack trace as if it was 
normal sequential code.



Yes, C#'s async design does make code look and feel 
synchronous, and it was intentionally designed that way, but 
that is not *why* they did Async. That misunderstanding arises 
from an interview that Anders did in which he was asked why 
they held Async back for three years after announcing it at 
PDC08. In that same talk Anders specifically says that the 
purpose of the Async is to free up threads to continue 
execution, his example is a Windows Desktop Message Pump and 
fetching pictures from the internet (long-wait IO), but the 
principal applies to any thread. They held back async for three 
years because they needed to refine the language syntax to 
something that people could learn and apply in a reasonable 
amount of time. IIRC there is a Channel9 video where Anders 
explains the evolution of Async Await.


In other words - explicit asynchrony where a thread immediately 
returns with Future[T] and moves on to the next task. It’s just 
hidden by Async/Await.

Re: Dynamically import() files

2017-10-23 Thread Andre Pany via Digitalmars-d-learn


On Monday, 23 October 2017 at 20:13:20 UTC, Igor wrote:

On Monday, 23 October 2017 at 12:15:17 UTC, Andre Pany wrote:

Hi,

I have a folder "i18n" which contains message bundle files. 
For now it contains only the message bundle file written by 
the developer: "messagebundle.properties".


[...]


Can't you just create all the files that you expect to have and 
leave them empty and then you import them all and process them 
differently if there is no content?


Thanks for the hints. I have some concerns creating the files 
upfront, because the files should only be created by other 
colleagues in an official translation process.


I will check whether I can determine the files via script as 
proposed by Rikki.


Kind regards
André

Re: My two cents

2017-10-23 Thread Adam Wilson via Digitalmars-d


On 10/23/17 17:27, flamencofantasy wrote:

On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:

On 10/23/17 08:21, Kagamin wrote:

[...]


Actually I think it fits perfectly with D, not for reason of
performance, but for reason of flexibility. D is a polyglot language,
with by far the most number of methodologies supported in a single
language that I've ever encountered.

[...]


There is a lot of misunderstanding about async/await. It has nothing to
do with "conservation of thread resources" or trading "raw performance
for an ability

to handle a truly massive number of simultaneous tasks". Async/await
is just 'syntactic sugar' where the compiler re-writes your code into
a state machine around APM (Asynchronous programming model which was
introduced in .NET 2.0 sometime around 2002 I believe). That's all
there is to it, it makes your asynchronous code look and feel
synchronous.



The only parts of Async/Await that have anything to do with APM are the 
interop stubs. C#'s Async/Await is built around the Task Asynchronous 
Programming model (e.g. Task and Task) the compiler lowers to those, 
not APM. A common misunderstanding is that Task/Task is based on APM, 
it's not, Task uses fundamentally different code underneath. On 
Linux/macOS it actually uses libuv (at the end of the day all of these 
programming models are callback based).


Yes, C#'s async design does make code look and feel synchronous, and it 
was intentionally designed that way, but that is not *why* they did 
Async. That misunderstanding arises from an interview that Anders did in 
which he was asked why they held Async back for three years after 
announcing it at PDC08. In that same talk Anders specifically says that 
the purpose of the Async is to free up threads to continue execution, 
his example is a Windows Desktop Message Pump and fetching pictures from 
the internet (long-wait IO), but the principal applies to any thread. 
They held back async for three years because they needed to refine the 
language syntax to something that people could learn and apply in a 
reasonable amount of time. IIRC there is a Channel9 video where Anders 
explains the evolution of Async Await.


Source: I was at Build 2011 and sat in on the Anders Hejlsberg (C# 
language designer) and Stephen Toub (Async/Await implementer) talks 
where they discussed Async in detail. I also work for MSFT, I can email 
them directly if you want further clarification on anything. :)


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: writeln double precision

2017-10-23 Thread Ali Çehreli via Digitalmars-d-learn

On 10/23/2017 07:22 AM, Arun Chandrasekaran wrote:
> void main() {
>  double a = 22/7.0;
>  import std.stdio: writeln, writefln;
>  writefln("%.51f", a);
> }

> But why does the compiler bring the C baggage for the integer
> division? Why do I need to `cast (double)` ?

I think you mean having to write 7.0 to bring a double into the expression.

> Can't the compiler figure
> it out?

Yes, it can but we don't want that. Otherwise, the code would be too 
slippery to keep under control. For example, introducing the following 
temporary variable would change the semantics:

  // Before:
  foo(22/7);

  // After
  double temp = 22/7;
  foo(temp);// Is this the same call with the same value?

Writing the above made me aware that function overloading would be too 
cumbersome as the compiler would find too many potential matches for the 
expressions. For example, should it convert 22/7 to float or double or 
long, etc.

The rule is that every expression has a type and 22/7 is int. The rules 
are carried from C and can be tricky. Both "Integer Promotions" and 
"Usual Arithmetic Conversion" are interesting here:

  https://dlang.org/spec/type.html#integer-promotions

Ali

[Issue 17931] New: [scope] `return` == `return scope` breaks for struct methods

2017-10-23 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 17931
   Summary: [scope] `return` == `return scope` breaks for struct
methods
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: safe
  Severity: normal
  Priority: P3
 Component: dmd
  Assignee: bugzi...@digitalmars.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
struct S
{
  @safe S foo() return /* scope */
  {
return this;
  }

  int* p; // so it has an indirection
}

void test(scope S s) @safe
{
  s.foo;
}
CODE

dmd -c -dip1000 bug.d

bug.d(13): Error: scope variable s assigned to non-scope parameter this calling
bug.S.foo


Introduced with https://github.com/dlang/dmd/pull/5909.

The above code can be compiled by using `return scope` instead, but in that
case the `return scope` is still reduced to `return` in the mangling.

Maybe it's a problem with struct methods being implicity ref for the this
parameter?
Hopefully we can consistently use `return` as abbreviation for `return scope`,
if it depends on the context, then it might not be worth the confusion.

--

Re: D for microservices


On 2017-10-23 14:13, Laeeth Isharc wrote:


How can we generate a static binary ?


It's already supported by LDC, using the -static flag. This Linux binary 
[1] is statically linked.


[1] https://github.com/jacob-carlborg/remarkify/releases

--
/Jacob Carlborg

[Issue 16744] We should have a TypeOf template so that typeof can be used with templates like staticMap

2017-10-23 Thread d-bugmail--- via Digitalmars-d-bugs

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

monkeywork...@hotmail.com changed:

   What|Removed |Added

 CC||monkeywork...@hotmail.com
 Resolution|FIXED   |WONTFIX

--- Comment #15 from monkeywork...@hotmail.com ---
Rejected by Andrei, so I'm closing this.

--

Re: D for microservices


On 2017-10-23 14:17, Laeeth Isharc wrote:


Can you elaborate on how the TLS implementation needs to be changed?


# echo 'void main() {}' > main.d && dmd -c main.d && gcc main.o -o main 
-m64 -static -L/root/.dvm/compilers/dmd-2.076.1/linux/bin/../lib64 
-Xlinker -Bstatic -lphobos2  -lpthread -lm -lrt -ldl


/root/.dvm/compilers/dmd-2.076.1/linux/bin/../lib64/libphobos2.a(sections_elf_shared_782_420.o): 
In function `_D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv':
src/rt/sections_elf_shared.d:(.text._D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv[_D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv]+0x38): 
undefined reference to `__tls_get_addr'

collect2: error: ld returned 1 exit status

I need to manually invoke GCC to link because DMD will pass "-Xlinker 
--export-dynamic -Xlinker -Bdynamic" and I need to add "-static".


If someone wanted to work on rabbit bindings/wrapper, I might be open to 
sponsoring that.  I'm not in love with Rabbit (one node uses more than 
40% of memory so the node goes down, taking the cluster with it.  
really?), but we use it currently.


I made a start on bindings for librabbitmq here:
https://github.com/kaleidicassociates/rabbitmq-d


Is that compatible with vibe.d?

--
/Jacob Carlborg

Re: D for microservices