Re: A betterC modular standard library?

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=

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard 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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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,

Re: A betterC modular standard library?

@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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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: [...] Thats why I asked for moderation in forums. +1, and ability to edit own posts.

Re: A betterC modular standard library?

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,

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

On 19 December 2016 at 21:29, Ilya Yaroshenko via Digitalmars-d 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 >> wrote: >>> >>> On Monday, 19

Re: A betterC modular standard library?

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 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

Re: A betterC modular standard library?

On 19 December 2016 at 20:42, Ilya Yaroshenko via Digitalmars-d 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,

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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.

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 09:26:09 UTC, 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? We already have better `cpuid` and better `random` packages. The betterC std.range and

Re: A betterC modular standard library?

On Monday, 19 December 2016 at 18:04:14 UTC, safety0ff wrote: On Sunday, 18 December 2016 at 18:02:58 UTC, Ilya Yaroshenko wrote: Thank you for the answer (it is hard to understand me because English and other reasons), Ilya It was difficult to understand your vision until this post, now

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 18:02:58 UTC, Ilya Yaroshenko wrote: Thank you for the answer (it is hard to understand me because English and other reasons), Ilya It was difficult to understand your vision until this post, now I think I grasp it. Let me try to summarize what I've

Re: A betterC modular standard library?

On Monday, 19 December 2016 at 05:59:07 UTC, Ilya Yaroshenko wrote: 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

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 19:28:24 UTC, Andrei Alexandrescu wrote: On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote: On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote: On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote: We already have better `cpuid` and better `random` packages.

Re: A betterC modular standard library?

On Monday, 19 December 2016 at 05:22:10 UTC, Ilya Yaroshenko wrote: What exactly do you mean by "betterC"? As far as I know, the `-betterC` switch just removes ModuleInfo generation. Because -betterC was not implemented yet. I'm curious to know what a complete implementation entails. Do

Re: A betterC modular standard library?

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

Re: A betterC modular standard library?

On Monday, 19 December 2016 at 01:33:42 UTC, Mike wrote: On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote: Who is interested in betterC _modular_* standard library? What exactly do you mean by "betterC"? As far as I know, the `-betterC` switch just removes ModuleInfo

Re: A betterC modular standard library?

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)? Let's do something about it! I've said this several times, and it bears repeating. We want to make D entirely

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote: Who is interested in betterC _modular_* standard library? What exactly do you mean by "betterC"? As far as I know, the `-betterC` switch just removes ModuleInfo generation. Do you actually mean, a standard library that

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 18:49:33 UTC, Ilya Yaroshenko wrote: 1. Modularity: D should provide a very slim library (like std.traits and may be default GC with old core, which can be turned off or replaced). Other parts or Phobos/Druntime should be split into parts and the parts should

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 20:16:11 UTC, Andrei Alexandrescu wrote: On 12/18/2016 03:10 PM, Ilya Yaroshenko wrote: On Sunday, 18 December 2016 at 19:28:24 UTC, Andrei Alexandrescu wrote: On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote: On Sunday, 18 December 2016 at 17:41:31 UTC, Walter

Re: A betterC modular standard library?

On 12/18/2016 03:10 PM, Ilya Yaroshenko wrote: On Sunday, 18 December 2016 at 19:28:24 UTC, Andrei Alexandrescu wrote: On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote: On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote: On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote: We already

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 19:28:24 UTC, Andrei Alexandrescu wrote: On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote: On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote: On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote: We already have better `cpuid` and better `random` packages.

Re: A betterC modular standard library?

On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote: On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote: On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote: We already have better `cpuid` and better `random` packages. Great! Please PR them for Phobos. cpuid is used in Mir GLAS and it

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 14:37:55 UTC, Radu wrote: On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko Who is interested in betterC _modular_* standard library? I am planing to make libmir org a community for it. Thought and concerns? I hope this doesn't turn into a new Tango

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote: On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote: We already have better `cpuid` and better `random` packages. Great! Please PR them for Phobos. cpuid is used in Mir GLAS and it should be a betterC library. Without DRuntime

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 15:18:37 UTC, Andrei Alexandrescu wrote: On 12/18/16 4: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? We already have better `cpuid` and better

Re: A betterC modular standard library?

On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote: We already have better `cpuid` and better `random` packages. Great! Please PR them for Phobos. The betterC std.range and std.algorithm analogs would be released with new ndslice implementation. Mir's algorithm would be faster then Phobos and

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 15:20:48 UTC, Radu wrote: 2. In the same time many thing is not possible to create with Phobos/Druntime. The simplest example is numeric libraries. I can create a multithread GLAS with core.thread, but if I do so GLAS will never be accepted as default BLAS

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 15:20:48 UTC, Radu wrote: I get point 2, but I should be able to use your new modules without giving up druntime/phobos, right?. They should not be mutual exclusive! I think that being able to use them the same as any other C library should be sufficient.

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 15:01:55 UTC, Ilya Yaroshenko wrote: On Sunday, 18 December 2016 at 14:37:55 UTC, Radu wrote: [...] Maybe I will be able to propose them on DConf. [...] Yes/No in the same time. 1. It would be always possible to use Mir and Phobos together, 100% guarantee.

Re: A betterC modular standard library?

On 12/18/16 4: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? We already have better `cpuid` and better `random` packages. The betterC std.range and std.algorithm analogs would

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 14:37:55 UTC, Radu wrote: On Sunday, 18 December 2016 at 09:26:09 UTC, 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? We already have better `cpuid`

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 09:26:09 UTC, 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? We already have better `cpuid` and better `random` packages. The betterC std.range and

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 11:06:58 UTC, Temtaime wrote: Let's write a D, phobos. Then we drop all the features and use a BetterC mode. Then we write all modules against betterC mode. Sounds like a plan! --Ilya

Re: A betterC modular standard library?

On Sunday, 18 December 2016 at 09:26:09 UTC, 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? We already have better `cpuid` and better `random` packages. The betterC std.range and

A betterC modular standard library?

Hi, Who is interested in betterC _modular_* standard library? I am planing to make libmir org a community for it. Thought and concerns? We already have better `cpuid` and better `random` packages. The betterC std.range and std.algorithm analogs would be released with new ndslice