On Monday, 19 December 2016 at 19:48:39 UTC, Guillaume Piolat wrote:
> On Monday, 19 December 2016 at 19:42:42 UTC, Ilya Yaroshenko wrote:
>> No,
>> 1. DRuntime has not fixed API
>
> Can't you static link with it? If you static link with it, your client don't deal with DRuntime.
>
>
>> 2. It has not backward binary compatibility
>
> Ditto. If you static link with it, your client don't deal with binary compatibility.
>
>
>> 3. It has not cross-compiler binary compatibility.
>
> Mandate that every D code in the project is built with the same compiler, which is realistic.

How this can work for libraries? Please read this thread.
This is not realistic. This a huge constraint for D libraries to be modular, replaceable and distributed in binary form.

On Monday, 19 December 2016 at 19:52:43 UTC, Ilya Yaroshenko wrote:
> On Monday, 19 December 2016 at 19:48:39 UTC, Guillaume Piolat wrote:
>> On Monday, 19 December 2016 at 19:42:42 UTC, Ilya Yaroshenko wrote:
>>> No,
>>> 1. DRuntime has not fixed API
>>
>> Can't you static link with it? If you static link with it, your client don't deal with DRuntime.
>>
>>
>>> 2. It has not backward binary compatibility
>>
>> Ditto. If you static link with it, your client don't deal with binary compatibility.
>>
>>
>>> 3. It has not cross-compiler binary compatibility.
>>
>> Mandate that every D code in the project is built with the same compiler, which is realistic.
>
> How this can work for libraries? Please read this thread.
> This is not realistic. This a huge constraint for D libraries to be modular, replaceable and distributed in binary form.

To be more precise: I do not build library exclusively for D. They should be easily interacted with other languages.

On Monday, 19 December 2016 at 19:52:43 UTC, Ilya Yaroshenko wrote:
> How this can work for libraries? Please read this thread.
> This is not realistic. This a huge constraint for D libraries to be modular, replaceable and distributed in binary form.

They can be at the MIR level.

How this can work: Mir libraries are distributed as static and dynamic libs, whatever.
Each one of these links statically with the same druntime and libphobos. When the user replace one MIR library it also replaces the others.

I don't see what isn't realistic here.

See also: CUDA, Intel Performance Primitives...
People update CUDA in bunch, they don't use cuDNN from release 6.15 with cuRuntime from release 7.8

On Monday, 19 December 2016 at 19:54:54 UTC, Ilya Yaroshenko wrote:
>
> To be more precise: I do not build library exclusively for D. They should be easily interacted with other languages.

Non sequitur, you can enable the runtime/attah threads withing callbacks.

On Monday, 19 December 2016 at 19:57:45 UTC, Guillaume Piolat wrote:
> On Monday, 19 December 2016 at 19:52:43 UTC, Ilya Yaroshenko wrote:
>> How this can work for libraries? Please read this thread.
>> This is not realistic. This a huge constraint for D libraries to be modular, replaceable and distributed in binary form.
>
> They can be at the MIR level.
>
> How this can work: Mir libraries are distributed as static and dynamic libs, whatever.
> Each one of these links statically with the same druntime and libphobos. When the user replace one MIR library it also replaces the others.
>
> I don't see what isn't realistic here.
>
> See also: CUDA, Intel Performance Primitives...
> People update CUDA in bunch, they don't use cuDNN from release 6.15 with cuRuntime from release 7.8

Mir CPUID was created for Mir GLAS, which is BLAS implementation.

How Mir GLAS be a default BLAS implementation in linux distributives if it is depends on DRuntime?

What about other non Mir numerical library written in Dlang, say for FFT?

How they should be linked together.

This example is already in this thread multiple times.

Do you propose to constraint Dlang library distribution in binary form?

I do not write D libraries for Dlang. I wrote them for people, which uses different languages. Most of them do not know about D.

On Monday, 19 December 2016 at 19:59:01 UTC, Guillaume Piolat wrote:
> On Monday, 19 December 2016 at 19:54:54 UTC, Ilya Yaroshenko wrote:
>>
>> To be more precise: I do not build library exclusively for D. They should be easily interacted with other languages.
>
> Non sequitur, you can enable the runtime/attah threads withing callbacks.

No, DRuntime based numerical libraries will never replace C analogs.

On 19 December 2016 at 20:42, Ilya Yaroshenko via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 19 December 2016 at 19:31:24 UTC, Guillaume Piolat wrote:
>>
>> On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote:
>>>
>>> [...]
>>
>>
>> If I understand correctly, the only reaon not to disable the runtime instead of going betterC (what I call runtime-free vs runtime-less) is because Phobos and druntime aren't ported to every platform you need, but the libC is.
>
>
> No,
> 1. DRuntime has not fixed API
> 2. It has not backward binary compatibility
> 3. It has not cross-compiler binary compatibility.
>
> So, it can not be used.

You're confusing druntime with phobos.  I haven't changed any bindings to druntime in years...

On Monday, 19 December 2016 at 20:05:20 UTC, Ilya Yaroshenko wrote:
> What about other non Mir numerical library written in Dlang, say for FFT?
>
> How they should be linked together.

If Mir libs are static libs this can indeed be a problem.
If someone has made another D library like this, it will either have to be its own dynlib or come with a runtime with the same API. You can manage to use very little of druntime such as "emplace"/"destroy" and that's about it when it comes to API.


I'll concede that my solution will not get you packaged on official package lists for Debian/Ubuntu, because shared libraries will get preferred there.

But I just checked and libcublas is just put in the non-free packages.
https://packages.debian.org/jessie/libcublas6.0
If it's good enough for CUDA then maybe it's good enough for MIR?

Note that with MIR being several dynlibs everyone of Mir library can come with any runtime (and then use it or not) without interaction of these runtimes.

When you use a CUDA dynamic library you don't know if it has a C runtime inside (or a X runtime, whatever).


> Do you propose to constraint Dlang library distribution in binary form?

No. Not sure how that question ensues from the premises.

On Monday, 19 December 2016 at 20:22:29 UTC, Iain Buclaw wrote:
> On 19 December 2016 at 20:42, Ilya Yaroshenko via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Monday, 19 December 2016 at 19:31:24 UTC, Guillaume Piolat wrote:
>>>
>>> On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote:
>>>>
>>>> [...]
>>>
>>>
>>> If I understand correctly, the only reaon not to disable the runtime instead of going betterC (what I call runtime-free vs runtime-less) is because Phobos and druntime aren't ported to every platform you need, but the libC is.
>>
>>
>> No,
>> 1. DRuntime has not fixed API
>> 2. It has not backward binary compatibility
>> 3. It has not cross-compiler binary compatibility.
>>
>> So, it can not be used.
>
> You're confusing druntime with phobos.  I haven't changed any bindings to druntime in years...

If someone build a library with GCC and another one with Clang they will work together. What about LDC and GDC?

On 19 December 2016 at 21:29, Ilya Yaroshenko via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 19 December 2016 at 20:22:29 UTC, Iain Buclaw wrote:
>>
>> On 19 December 2016 at 20:42, Ilya Yaroshenko via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Monday, 19 December 2016 at 19:31:24 UTC, Guillaume Piolat wrote:
>>>>
>>>>
>>>> On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote:
>>>>>
>>>>>
>>>>> [...]
>>>>
>>>>
>>>>
>>>> If I understand correctly, the only reaon not to disable the runtime instead of going betterC (what I call runtime-free vs runtime-less) is because Phobos and druntime aren't ported to every platform you need, but the libC is.
>>>
>>>
>>>
>>> No,
>>> 1. DRuntime has not fixed API
>>> 2. It has not backward binary compatibility
>>> 3. It has not cross-compiler binary compatibility.
>>>
>>> So, it can not be used.
>>
>>
>> You're confusing druntime with phobos.  I haven't changed any bindings to druntime in years...
>
>
> If someone build a library with GCC and another one with Clang they will work together. What about LDC and GDC?

Clang developers decided that they should be ABI compatible with GCC. I'm not sure if the LDC developers are doing the same thing. :-)