On Monday, 19 December 2016 at 20:24:21 UTC, Guillaume Piolat wrote:
> On Monday, 19 December 2016 at 20:05:20 UTC, Ilya Yaroshenko wrote:
>> [...]
>
> 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.
>
> [...]

No, Mir is not a hardware manufacturer which forces its users to do something.

> 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.
>
> [...]

Looks like bad design. Existing C libs would be better then.

On Monday, 19 December 2016 at 20:10:02 UTC, Ilya Yaroshenko wrote:
> 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.

Going to bed. Please don't take it as attacks, I'm juste trying to help find the best possible solution, with the least amount of pain.

On Monday, 19 December 2016 at 05:59:07 UTC, Ilya Yaroshenko wrote:
> On Monday, 19 December 2016 at 01:52:21 UTC, Andrei Alexandrescu wrote:
>> On 12/18/16 7:31 PM, Seb wrote:
>>> tl:dr: Phobos is very bloated.
>>
>> How does the D standard library compare in size with some other languages (C++, Rust, Go, Java, Python)?
>
> C++ and Rust are the best from this list in terms of low level programming. They have smaller libraries comparing with D.
>
> Go, Java, Python --- If I need a language like them I will you them, not D.
>
> Go - awesome GC, commercially supported, easy to write your own libs
> Java - awesome GC, commercially supported, Scala(!!!)
> Python - awesome scripting, commercially supported
>
> D - ??? awesome what ? What do we have better then Scala?
>
> Performance? NO.
> BRandomAccessRanges makes our performance less then C/C++.
>
> Clean and clever API in standard library? NO.
> We are placing our Range API whenever possible including RNGs. We have not a language standard for I/O. Half of Phobos is outdated to language standards.
>
> Best generics? NO.
> Scala is more powerful.
>
> ----------
> What do we have awesome? Where D is the best?
> ----------
> D is awesome for low-level system libraries in betterC mode.
> (and small text processing routines)
> This will make D great in other fields.
> ----------
>
>>> Let's do something about it!
>>
>> I've said this several times, and it bears repeating. We want to make D entirely pay-as-you go, and offer full support to anyone working on it. The best "something" anyone can do about it is do good engineering work in the D mainline.
>
> National D Foundation Party.
>
>> That will automatically benefit all users of the D language, instead of balkanizing the community.
>
> ...
>
>> Granted, the lure of the clean slate is strong, and more care is needed to mind backwards compatibility, but that's where the real impact is.
>>
>>
>> Andrei
>
> How Mir projects breaks backward compatibility ?
>
> How proposed direction breaks backward compatibility?
>
> Lets use other prefix for the new libraries. Mir uses `mir.` And allow Phobos to be a sandbox for C++ as it is now.
>
> Ilya

<delurk>
Thats why I asked for moderation in forums.
<lurk>

On Monday, 19 December 2016 at 21:00:57 UTC, lurker wrote:
> On Monday, 19 December 2016 at 05:59:07 UTC, Ilya Yaroshenko wrote:
>> [...]
>
> <delurk>
> Thats why I asked for moderation in forums.
> <lurk>

+1, and ability to edit own posts.

On 12/18/2016 11:26 AM, Ilya Yaroshenko wrote:
> Hi,
> 
> Who is interested in betterC _modular_* standard library?
> I am planing to make libmir org a community for it.
> Thought and concerns?

I also consider Phobos a lost cause only suitable for scripting purposes. However what you try to do won't be acceptable for me either (see below).

> We already have better `cpuid` and better `random` packages. The betterC std.range and std.algorithm analogs would be released with new ndslice implementation. Mir's algorithm would be faster then Phobos and will generate less template bloat. Then lightweight threads, multithread GLAS, matrix inversion. Fastest I/O and http2 ...

I consider only algorithms and interfaces suitable for standard library. GLAS, I/O, HTTP - this is exactly all the stuff I want to see removed into separate dub packages and maintained as such.

> (they all are betterC modular libraries)

.. and this "betterC" weirdness you use with your own meaning is definitely something I don't want to _ever_ see as standard library approach. It is similar to `malloc` vs `GC` debate for Phobos, because correct answer tends to be "neither", with rationale that any library utility that has to care about the difference is hardly generic enough for unconditional distribution.

------------------------

My own dream path for fixing Phobos may look like this:

1) Start with separating environment-agnostic core (algorithms and
API's) from utilities
2) Rewrite all higher level utilities in a way that they don't have any
inter-dependencies and only allowed to use algorithm/API modules
3) Move higher level stuff into own dub packages with a special "Phobos"
category
4) When compiler is released, provide snapshot of latest up to date
packages in that category as part of the distribution for those who
don't want to bother with fetching manually

This actually may be even possible to do within a linear deprecation process. On the other hand I doubt such drastic change to structure is possible to be sold to community.

On Tuesday, 20 December 2016 at 08:15:35 UTC, Dicebot wrote:
> On 12/18/2016 11:26 AM, Ilya Yaroshenko wrote:>
>
> This actually may be even possible to do within a linear deprecation process. On the other hand I doubt such drastic change to structure is possible to be sold to community.

Consider that plan sold to me...

---
Paolo

@ilya: regarding -betterC 's stated goal to bypass druntime:

besides static linking (which can be inefficient), why not use runtime
shared libraries to distribute mir (eg GLAS) to C clients ?

IIRC, from a single C++ program, I am able to dlopen & dlsym & run D functions defined in shared libraries built with different compilers (eg dmd and ldc) even if they use GC (and therefore dmd's and ldc's druntime) ; pseudocode:

// main.cpp
```
void main(){
  dlopen, dlsym, and run "void fun1()" from libfun_dmd.so
  dlopen, dlsym, and run "void fun2()" from libfun_ldc.so
}
```

That would provide the needed isolation without suffering from disadvantages of static libraries (eg bloat); compared to the betterC alternative, you'd have access to all of druntime/phobos and not have to reinvent the wheel


On Tue, Dec 20, 2016 at 1:06 AM, Paolo Invernizzi via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tuesday, 20 December 2016 at 08:15:35 UTC, Dicebot wrote:
>
>> On 12/18/2016 11:26 AM, Ilya Yaroshenko wrote:>
>>
>> This actually may be even possible to do within a linear deprecation process. On the other hand I doubt such drastic change to structure is possible to be sold to community.
>>
>
> Consider that plan sold to me...
>
> ---
> Paolo
>
>

On Tuesday, 20 December 2016 at 09:12:55 UTC, Timothee Cour wrote:
> @ilya: regarding -betterC 's stated goal to bypass druntime:
>
> besides static linking (which can be inefficient), why not use runtime
> shared libraries to distribute mir (eg GLAS) to C clients ?
>
> IIRC, from a single C++ program, I am able to dlopen & dlsym & run D functions defined in shared libraries built with different compilers (eg dmd and ldc) even if they use GC (and therefore dmd's and ldc's druntime) ; pseudocode:
>
> // main.cpp
> ```
> void main(){
>   dlopen, dlsym, and run "void fun1()" from libfun_dmd.so
>   dlopen, dlsym, and run "void fun2()" from libfun_ldc.so
> }
> ```
>
> That would provide the needed isolation without suffering from disadvantages of static libraries (eg bloat); compared to the betterC alternative, you'd have access to all of druntime/phobos and not have to reinvent the wheel

Because I do not have control on phobos, i can not distribute my copy of phobos with required patches like normal cache size estimation (core.cpuid is broken). Why not to fix core.cpuid?  Its source code is not manageable comparing with mir-cpuid: it is faster to write a module from scratch for this case. DUB package appears when I want it, LDC release may appear after 6-10 months (depends on distribution).

On 20/12/2016 10:32 PM, Ilya Yaroshenko wrote:
> On Tuesday, 20 December 2016 at 09:12:55 UTC, Timothee Cour wrote:
>> @ilya: regarding -betterC 's stated goal to bypass druntime:
>>
>> besides static linking (which can be inefficient), why not use runtime
>> shared libraries to distribute mir (eg GLAS) to C clients ?
>>
>> IIRC, from a single C++ program, I am able to dlopen & dlsym & run D
>> functions defined in shared libraries built with different compilers
>> (eg dmd and ldc) even if they use GC (and therefore dmd's and ldc's
>> druntime) ; pseudocode:
>>
>> // main.cpp
>> ```
>> void main(){
>>   dlopen, dlsym, and run "void fun1()" from libfun_dmd.so
>>   dlopen, dlsym, and run "void fun2()" from libfun_ldc.so
>> }
>> ```
>>
>> That would provide the needed isolation without suffering from
>> disadvantages of static libraries (eg bloat); compared to the betterC
>> alternative, you'd have access to all of druntime/phobos and not have
>> to reinvent the wheel
>
> Because I do not have control on phobos, i can not distribute my copy of
> phobos with required patches like normal cache size estimation
> (core.cpuid is broken). Why not to fix core.cpuid?  Its source code is
> not manageable comparing with mir-cpuid: it is faster to write a module
> from scratch for this case. DUB package appears when I want it, LDC
> release may appear after 6-10 months (depends on distribution).

Of course you can bundle your own Phobos.
If you put a std.* module in your path your build will be working against that instead. If you don't mess around with sc.ini it will override the default for that compilation.

On Tuesday, 20 December 2016 at 09:38:58 UTC, rikki cattermole wrote:
> On 20/12/2016 10:32 PM, Ilya Yaroshenko wrote:
>> On Tuesday, 20 December 2016 at 09:12:55 UTC, Timothee Cour wrote:
>>> @ilya: regarding -betterC 's stated goal to bypass druntime:
>>>
>>> besides static linking (which can be inefficient), why not use runtime
>>> shared libraries to distribute mir (eg GLAS) to C clients ?
>>>
>>> IIRC, from a single C++ program, I am able to dlopen & dlsym & run D
>>> functions defined in shared libraries built with different compilers
>>> (eg dmd and ldc) even if they use GC (and therefore dmd's and ldc's
>>> druntime) ; pseudocode:
>>>
>>> // main.cpp
>>> ```
>>> void main(){
>>>   dlopen, dlsym, and run "void fun1()" from libfun_dmd.so
>>>   dlopen, dlsym, and run "void fun2()" from libfun_ldc.so
>>> }
>>> ```
>>>
>>> That would provide the needed isolation without suffering from
>>> disadvantages of static libraries (eg bloat); compared to the betterC
>>> alternative, you'd have access to all of druntime/phobos and not have
>>> to reinvent the wheel
>>
>> Because I do not have control on phobos, i can not distribute my copy of
>> phobos with required patches like normal cache size estimation
>> (core.cpuid is broken). Why not to fix core.cpuid?  Its source code is
>> not manageable comparing with mir-cpuid: it is faster to write a module
>> from scratch for this case. DUB package appears when I want it, LDC
>> release may appear after 6-10 months (depends on distribution).
>
> Of course you can bundle your own Phobos.
> If you put a std.* module in your path your build will be working against that instead. If you don't mess around with sc.ini it will override the default for that compilation.

CPUID should be precompiled. So this does not work. If GLAS do not need anything but CPUID, what the reason to depend on DRuntime?

Please stop to force me to use DRuntime because you think it is better for Mir projects. This looks like DRuntime religion.

A betterC library can be used with DRuntime. So I do not force anyone to drop DRuntime. Please do not force me to use it.

GLAS already works without DRuntime and I am happy about that.