On 12/18/2016 1:02 PM, Ilya Yaroshenko wrote:
> I need to understand how it is can be done because I did not find a valid solution.
>
> mir-cpuid has global symbols, they are accessed using extern(C) API. If multiple
> libraries trying to initialize it than it will be initialized only once.
>
> extern C API does not solve a problem with DRuntime because current DRuntime is
> not a betterC library and it is huge. A huge betterC library is a problem too
> because it is less portable.

cpuid can be written in a manner that it is self-contained. If so, it doesn't matter how large druntime is, as it won't have references to any of the rest of it and so the rest won't be pulled in by the linker.

https://github.com/dlang/druntime/blob/master/src/core/cpuid.d

Currently, core.cpuid has no imports. It does have a static constructor, though, which references the startup code in druntime. This can be changed so it uses the static construction support in the C runtime library. Then it will be independent of druntime.

On Tuesday, 20 December 2016 at 12:00:43 UTC, Walter Bright wrote:
> On 12/18/2016 1:02 PM, Ilya Yaroshenko wrote:
>> I need to understand how it is can be done because I did not find a valid solution.
>>
>> mir-cpuid has global symbols, they are accessed using extern(C) API. If multiple
>> libraries trying to initialize it than it will be initialized only once.
>>
>> extern C API does not solve a problem with DRuntime because current DRuntime is
>> not a betterC library and it is huge. A huge betterC library is a problem too
>> because it is less portable.
>
> cpuid can be written in a manner that it is self-contained. If so, it doesn't matter how large druntime is, as it won't have references to any of the rest of it and so the rest won't be pulled in by the linker.

This is true for application but not for libraries. mir-glas depends on mir-cpuid. If I want GLAS to be ported for a new target then I will release a new CPUID version and will be able to use it the same day. With DRuntime (as solid project), I need to wait up to 6 months before it will be released with DMD and then with LDC. Workaround are possible, but they requires more efforts, more time, more code.

Please do not force Mir to use DRuntime. We need a solid solution

I do not force anyone to drop DRuntime: Mir libraries can be used with DRuntime/Phobos. We have full backward compatibility. DRuntime does not satisfy portability requirements (which was repeated multiple times in this thread). DRuntime (at least for now and future few years) is a big constraint for betterC libs to replace existing C analogs. Please do not force me to use DRuntime.

On Tuesday, 20 December 2016 at 09:56:34 UTC, Ilya Yaroshenko wrote:
>> 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.

What does "you can bundle your own phobos" have to do with that? No one's forcing you to do anything.

You're suggesting something radical*, other people are suggesting that maybe there are good compromises where everybody wins, avoiding fragmentation. Then you say that "looks like DRuntime religion" and claim you're being forced to modify your code to add extra dependencies. It doesn't make sense.

Your technical arguments have good content, in my opinion everyone would benefit from you writing them up with sufficient context for people who don't know what you know and without hyperbole (none of that "D will fail if we don't do X" or "phobos is bloated and useless" stuff, it doesn't help communicate your points). Developing the case study / thought experiment of getting two libraries (blas and fft) in to a traditional linux distro would be a great central point.

See https://github.com/dlang/DIPs/pull/51 where Andrei describes not only how he thinks things should be, but also explains in detail why other approaches won't work. Now consider that what you're talking about is a lot more important and different/disruptive than a new import syntax, so it deserves at least comparably good description.

* D used to have 2 standard libraries. That was not a happy time for the community. People are wary partly because of that.

P.S. a good example of the sort of statement that needs more explanation, at least for me:
> 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."
How? Why? Is ndslice actually capable of the same level of flexibility as std.algorithm and std.range? You're effectively saying "all that stuff that Andrei (and others) designed and wrote, I can do better" without really showing anyone why they should believe that.

On Tuesday, 20 December 2016 at 12:33:27 UTC, John Colvin wrote:
> * D used to have 2 standard libraries. That was not a happy time for the community. People are wary partly because of that.

To bring some cool to the discussion, let's remember that they also weren't compatible.
Of course it's a concern but this case is different and deserve full consideration. let's say the thread title was "A runtime-less modular library?"

On 12/20/2016 4:30 AM, Ilya Yaroshenko wrote:
> This is true for application but not for libraries. mir-glas depends on
> mir-cpuid. If I want GLAS to be ported for a new target then I will release a
> new CPUID version and will be able to use it the same day. With DRuntime (as
> solid project), I need to wait up to 6 months before it will be released with
> DMD and then with LDC. Workaround are possible, but they requires more efforts,
> more time, more code.
>
> Please do not force Mir to use DRuntime. We need a solid solution
>
> I do not force anyone to drop DRuntime: Mir libraries can be used with
> DRuntime/Phobos. We have full backward compatibility. DRuntime does not satisfy
> portability requirements (which was repeated multiple times in this thread).
> DRuntime (at least for now and future few years) is a big constraint for betterC
> libs to replace existing C analogs.

Here's how anyone can override druntime's cpuid for their application without touching druntime:

    dmd -c mycpuid
    dmd myapp mycpuid.o

I.e. the way linkers work is if the symbol's definition exists, it is not pulled in from the library.

> Please do not force me to use DRuntime.

I don't propose forcing anyone to use Druntime. What I do propose is reducing interdependencies among the object files in Druntime. Druntime is not a monolithic chunk of code, it is a library of object files.

I don't see the need to rewrite cpuid because its sole dependency on other object files in Druntime is the static constructor, because the static constructor can be adjusted to not rely on anything else in Druntime.

If there are other issues with cpuid, please elucidate.

On Tuesday, 20 December 2016 at 12:33:27 UTC, John Colvin wrote:

Mir uses deprecated native complex numbers because we can not spend days explaining why they are better then std.complex (in short: std.complex breaks compiler optimization logic, function inlining works, but it breaks optimization logic). I have already spend 4 hours for forum discussions and PRs about this issue without any result.

We are doing the best things we can do with current D. If something will be improved in future we will upgrade codebase.

> P.S. a good example of the sort of statement that needs more explanation, at least for me:
>> 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."
> How? Why? Is ndslice actually capable of the same level of flexibility as std.algorithm and std.range? You're effectively saying "all that stuff that Andrei (and others) designed and wrote, I can do better" without really showing anyone why they should believe that.

The explanation of new idioms will appear after its code.

I did not say "better". I said "betterC" plus "faster".

Yes, i can say that for DCV library new idioms are much better then Phobos.

But new idioms have another issues, for example D language is not capable to infer their safety for many of them. Other issues is that there a lot of fast non CTFE-able types and their CTFE-able analogs.

One good things for safety and CTFE is allow multiple return value. In combination with `auto ref` it is _very_ powerful:

----
auto ref front()
{
  // Returns 2 values, each value is returned by reference if possible
  return (a.front, b.front);
}
----

This would be interesting to discuss and to have it in D in CTFE and @safe mode. But I am not good in DIPs.

This sorts of features is very desirable.

On Tuesday, 20 December 2016 at 12:49:53 UTC, Walter Bright wrote:

> I don't see the need to rewrite cpuid because its sole dependency on other object files in Druntime is the static constructor, because the static constructor can be adjusted to not rely on anything else in Druntime.
>
> If there are other issues with cpuid, please elucidate.

1. https://issues.dlang.org/show_bug.cgi?id=16028
2. The code is very hard to maintain, fix, extend. This is a reason why mir-cpuid was written from scratch without any copy-pasting.
3. Library is x86 oriented. Some OSs has interface to fetch unified CPU information.
4. No TLB information provided.
5. Number of CPUs per cache is not know. ARM CPUs may have complex topology (plus 3.)

On Tuesday, 20 December 2016 at 12:45:13 UTC, Guillaume Piolat wrote:
> On Tuesday, 20 December 2016 at 12:33:27 UTC, John Colvin wrote:
>> * D used to have 2 standard libraries. That was not a happy time for the community. People are wary partly because of that.
>
> To bring some cool to the discussion, let's remember that they also weren't compatible.
> Of course it's a concern but this case is different and deserve full consideration. let's say the thread title was "A runtime-less modular library?"

Thanks! Good point

On 12/20/2016 5:35 AM, Ilya Yaroshenko wrote:
> On Tuesday, 20 December 2016 at 12:49:53 UTC, Walter Bright wrote:
>
>> I don't see the need to rewrite cpuid because its sole dependency on other
>> object files in Druntime is the static constructor, because the static
>> constructor can be adjusted to not rely on anything else in Druntime.
>>
>> If there are other issues with cpuid, please elucidate.
>
> 1. https://issues.dlang.org/show_bug.cgi?id=16028
> 2. The code is very hard to maintain, fix, extend. This is a reason why
> mir-cpuid was written from scratch without any copy-pasting.
> 3. Library is x86 oriented. Some OSs has interface to fetch unified CPU
> information.
> 4. No TLB information provided.
> 5. Number of CPUs per cache is not know. ARM CPUs may have complex topology
> (plus 3.)

Thank you, but I meant issues that would require it to be separate from druntime, not bug fixes or enhancements to account for ever more things being added to the CPUID instruction.

BTW, of course it is x86 oriented. Any use of cpuid must be. After all, what does "SSSE3.1" mean on ARM?

On Tuesday, 20 December 2016 at 12:49:53 UTC, Walter Bright wrote:
> I don't propose forcing anyone to use Druntime.

Perhaps this is not part of Ilya's concern, but druntime is required to get a build.

  //----test.d---------
  module test;

  void main() { }

  dmd -m64 -defaultlib= -debuglib= -conf= test.d

  Error: cannot find source code for runtime library file 'object.d'
       dmd might not be correctly installed. Run 'dmd -man' for installation
       instructions.
       config file: (null)
  Specify path to file 'object.d' with -I switch


There's nothing here that really requires druntime, unless you want to count the plumbing required to call DMain.  In that case, we can just call CMain directly:

  module test;

  extern(C) void main() { }

  Same Error:
  Error: cannot find source code for runtime library file 'object.d'


Try with the -betterC switch:

  dmd -m64 -defaultlib= -debuglib= -conf= -betterC test.d

  Same Error:
  Error: cannot find source code for runtime library file 'object.d'

Ok, fine, let's add an empty object.d

  //object.d
  module object;

  //test.d
  module test;

  extern(C) void main() { }

  dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d

  Error: undefined identifier 'Error'
  Error: undefined identifier 'Error'

Ok, now I need something called 'Error'.  I don't see anywhere in my code where that's necessary, but it must be important because it told me twice.

  //object.d
  module object;

  class Throwable { }

  class Error : Throwable { }

  //test.d
  module test;

  extern(C) void main() { }

  dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d

  object.d(3): Error: class object.Throwable missing or corrupt object.d

Ok, that's weird. I just added it.  Luckily I've done this before, so I know what to do.

  //object.d
  module object;

  class Object { }

  class Throwable { }

  class Error : Throwable
  {
      this(string x) { }
  }

  //test.d
  module test;

  extern(C) void main() { }

  dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d

  Error: no constructor for Error
  Error: no constructor for Error

Hmm. Again with the double error messages.  Ok, let's add a constructor.

  //object.d
  module object;

  class Object { }

  class Throwable { }

  class Error : Throwable
  {
      this(string x) { }
  }

  //test.d
  module test;

  extern(C) void main() { }

  dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d

  object.d(9): Error: undefined identifier 'string'

At least its only telling me once.  Easy fix.

  //object.d
  module object;

  alias immutable(char)[] string;

  class Object { }

  class Throwable { }

  class Error : Throwable
  {
      this(string x) { }
  }

  //test.d
  module test;

  extern(C) void main() { }

  dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d

  Error: TypeInfo not found. object.d may be incorrectly installed or corrupt,
    compile with -v switch

I could go on, but I'm not going to.  The final result to get a build looks like this, but you have to link with --gc-sections to avoid having to implement a buch of other stuff.

  module object;

  extern(C) void __dmd_personality_v0() { }

  extern(C) void _d_dso_registry() { }

  alias immutable(char)[] string;

  class Object { }

  class TypeInfo { }

  class TypeInfo_Class : TypeInfo
  {
      ubyte[136] ignore;
  }

  alias TypeInfo_Class ClassInfo;

  class Throwable { }

  class Error : Throwable
  {
      this(string x) { }
  }

  //test.d
  module test;

  extern(C) void main() { }

  dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d -L=--gc-sections

If you add structs or classes to your code, you have to add even more druntime stuff.

The point I'm trying to make here is druntime is required just to get a build, even though your code doesn't need it.

Mike