Jump to page: 1 2 3
Thread overview
druntime: proposed changes in code organization
Nov 14, 2023
Denis Feklushkin
Nov 14, 2023
Iain Buclaw
Nov 14, 2023
Denis Feklushkin
Nov 16, 2023
Denis Feklushkin
Nov 16, 2023
IGotD-
Nov 16, 2023
Denis Feklushkin
Nov 19, 2023
Denis Feklushkin
Nov 20, 2023
IGotD-
Dec 01, 2023
Denis Feklushkin
Dec 01, 2023
Denis Feklushkin
Dec 01, 2023
IGotD-
Dec 02, 2023
Denis Feklushkin
Dec 02, 2023
IGotD-
Dec 02, 2023
Denis Feklushkin
Dec 05, 2023
Denis Feklushkin
Dec 13, 2023
Johan
Dec 16, 2023
Denis Feklushkin
Dec 16, 2023
Johan
Dec 16, 2023
Denis Feklushkin
Dec 16, 2023
Johan
Dec 16, 2023
Denis Feklushkin
Dec 17, 2023
Johan
Dec 17, 2023
Denis Feklushkin
Dec 17, 2023
Johan
Dec 16, 2023
Denis Feklushkin
November 14, 2023

Hi!

I propose to discuss a possibility of reorganizing code by this way:

For example, druntime/src/core/sys/posix/setjmp.d file contains few version branches of libc and OSes versions. It can be reorganized as:

druntime/impl/arm/core/sys/posix/-no-file-
druntime/impl/x86/core/sys/posix/-no-file-
druntime/impl/netbsd/core/sys/posix/setjmp.d
druntime/impl/openbsd/core/sys/posix/setjmp.d
druntime/impl/linux/core/sys/posix/-no-file-
druntime/impl/glibc/core/sys/posix/setjmp.d
druntime/impl/default/core/sys/posix/setjmp.d

(druntime/impl contains directories what named like most frequently used versions names)

Platform will be switched on tag-based by build script without "branches of branches" inside of code. I.e., if we build for a wide available Debian Linux for x86 it would be 3 tags: linux+glibc+x86, and for module core/sys/posix/setjmp.d these directories will be used:

druntime/impl/x86/core/sys/posix/-no-file-
druntime/impl/glibc/core/sys/posix/setjmp.d <- this will be used
druntime/impl/linux/core/sys/posix/-no-file-

(Obviously, except default, only one file must be found - otherwise this is error condition)

You should remember: not all modules are so complex as setjmp.d, most files will be in default directory (and many will not be in druntime/impl hierarchy at all). And, also, druntime is a special sort of software and this approach will help to maintain duplicated nature of druntime's bindings.

This approach will force us to avoid difficult branching schemas and to separate common logic and OS- or arch- related stuff

It opens ability to import modules with foreign data structures on non-native OSes: it will be possible to remove module "guards" like "version (Linux):" at start of modules and your Windows app will be able to import Linux data structures

This approach also helps to add new platforms (most important for me)

November 14, 2023

On Tuesday, 14 November 2023 at 00:33:34 UTC, Denis Feklushkin wrote:

>

Hi!

I propose to discuss a possibility of reorganizing code by this way:

Be warned, this has a very long history and ulti ended up nowhere.

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

https://github.com/dlang/druntime/pull/1255
https://github.com/dlang/druntime/pull/744
https://github.com/dlang/druntime/pull/741
https://github.com/dlang/druntime/pull/731

November 14, 2023

On Tuesday, 14 November 2023 at 06:04:27 UTC, Iain Buclaw wrote:

>

On Tuesday, 14 November 2023 at 00:33:34 UTC, Denis Feklushkin wrote:

>

Hi!

I propose to discuss a possibility of reorganizing code by this way:

Forgot to add to the potential benefits list:

Proposed approach eliminates tons of these identical lines:

version (AArch64) version = ARM_Any;
version (ARM)     version = ARM_Any;
[...]
version (X86)     version = X86_Any;
version (X86_64)  version = X86_Any;

version (OSX)
    version = Darwin;
else version (iOS)
    version = Darwin;
else version (TVOS)
    version = Darwin;
else version (WatchOS)
    version = Darwin;
>

Be warned, this has a very long history and ulti ended up nowhere.

Yes! And I suggested something similar too - https://forum.dlang.org/thread/rwmqulighwecqyxqbnkt@forum.dlang.org

This all suggests that something needs to be done with the existing approach. For example, for more than 10 years we haven't seen the expected creation of "lightweight druntime" for embedded. No one was able to solve such static branches puzzle gracefully.

By the way, proposed here "tags+directories" solution is the full equivalent of currently used "version branching"? (Can anyone refute this proposition?)

November 16, 2023

On Tuesday, 14 November 2023 at 11:48:00 UTC, Denis Feklushkin wrote:

Proof of concept: https://github.com/dlang/dmd/pull/15822

November 16, 2023

On Tuesday, 14 November 2023 at 00:33:34 UTC, Denis Feklushkin wrote:

>

Hi!

I propose to discuss a possibility of reorganizing code by this way:

For example, druntime/src/core/sys/posix/setjmp.d file contains few version branches of libc and OSes versions. It can be reorganized as:

druntime/impl/arm/core/sys/posix/-no-file-
druntime/impl/x86/core/sys/posix/-no-file-
druntime/impl/netbsd/core/sys/posix/setjmp.d
druntime/impl/openbsd/core/sys/posix/setjmp.d
druntime/impl/linux/core/sys/posix/-no-file-
druntime/impl/glibc/core/sys/posix/setjmp.d
druntime/impl/default/core/sys/posix/setjmp.d

I suggested this a while ago that druntime should be refactored to files instead of the version hell like #ifdef hell in C. However, in order this to properly work was that import should be able to use version strings in the filename path.

Also, one question in the example. Why two files

druntime/impl/arm/core/sys/posix/-no-file-
druntime/impl/x86/core/sys/posix/-no-file-

as I assume these are stubs. Isn't a stub no OS at all?

Apart from that. I strongly support having stubbed versions in druntime, also with more fine granularity which would be great for embedded systems. Some systems have file systems but no process support for example.

>

It opens ability to import modules with foreign data structures on non-native OSes: it will be possible to remove module "guards" like "version (Linux):" at start of modules and your Windows app will be able to import Linux data structures

This approach also helps to add new platforms (most important for me)

First thing is that we need version strings in imports. This has been suggested for years but nothing has happened. If we add this, then modularizing druntime will fall more naturally (and perhaps their own projects too).

November 16, 2023

On Thursday, 16 November 2023 at 15:13:44 UTC, IGotD- wrote:

> >

For example, druntime/src/core/sys/posix/setjmp.d file contains few version branches of libc and OSes versions. It can be reorganized as:

druntime/impl/arm/core/sys/posix/-no-file-
druntime/impl/x86/core/sys/posix/-no-file-
druntime/impl/netbsd/core/sys/posix/setjmp.d
druntime/impl/openbsd/core/sys/posix/setjmp.d
druntime/impl/linux/core/sys/posix/-no-file-
druntime/impl/glibc/core/sys/posix/setjmp.d
druntime/impl/default/core/sys/posix/setjmp.d

I suggested this a while ago that druntime should be refactored to files instead of the version hell like #ifdef hell in C. However, in order this to properly work was that import should be able to use version strings in the filename path.

If I understand you, this is ~same approach as I implementing

>

Also, one question in the example. Why two files

druntime/impl/arm/core/sys/posix/-no-file-
druntime/impl/x86/core/sys/posix/-no-file-

as I assume these are stubs. Isn't a stub no OS at all?

No, there is only for illustration what this dirs isn't contain file setjmp.d. These directories can contain another files, of course

If you ask about "no-OS environment" supporting, then, in my opinion, at the druntime level it is not make sense to discuss about this: if you implement needed calls then druntime will work in this environment. Briefly, "No-OS" - is just a kind of OS type.

>

Apart from that. I strongly support having stubbed versions in druntime, also with more fine granularity which would be great for embedded systems. Some systems have file systems but no process support for example.

I believe that such granularity will formed naturally if the code is reorganized in the proposed way

And I think processes (threads?) are necessary part of the D language. Even on MCUs: the fact is that threads are involved into the garbage collection process

November 19, 2023

On Thursday, 16 November 2023 at 17:13:37 UTC, Denis Feklushkin wrote:

I made update of the proposal description text, https://github.com/dlang/dmd/pull/15822

November 20, 2023

On Sunday, 19 November 2023 at 19:53:53 UTC, Denis Feklushkin wrote:

>

On Thursday, 16 November 2023 at 17:13:37 UTC, Denis Feklushkin wrote:

I made update of the proposal description text, https://github.com/dlang/dmd/pull/15822

Not sure If I'm going to reply here or on github.

First, I think that you need to more precisely explain what a "tag" is. What is the underlying data type and how does it differ from a version identifier. I don't understand what a tag is by reading the PR.

The PR doesn't mention anything about the generic part of the implementation. Where should the generic part be?

Also how the source code hierarchy, how would it look like?

Let's take really small example like setjmp.d and show how it should be implemented, both inside the file and where the files should located.

December 01, 2023

On Monday, 20 November 2023 at 13:39:21 UTC, IGotD- wrote:

>

On Sunday, 19 November 2023 at 19:53:53 UTC, Denis Feklushkin wrote:

>

On Thursday, 16 November 2023 at 17:13:37 UTC, Denis Feklushkin wrote:

I made update of the proposal description text, https://github.com/dlang/dmd/pull/15822

Not sure If I'm going to reply here or on github.

Doesn't matter. Sorry for a response delay, I was away

>

First, I think that you need to more precisely explain what a "tag" is.

Okay, I'll write here and when everything is discussed I’ll add it to the PR description

>

What is the underlying data type and how does it differ from a version identifier. I don't understand what a tag is by reading the PR.

Proposed tags are similar to a D's versions, but I decided to separate its name because tags become not corresponding to a built-in D versions, at least.

For example, most likely, tags with names like “posix_compatible_threads” will appear, because in the future we will understand that some OSes use Posix interace API to provide threads functionality but while not being a Posix system. The same goes for working with files, etc.

I also suggest to write sets of tags for each target in this form:

x86_64,posix,osx

and not in:

x86_64-posix-osx

to prevent attempts to combine proposed druntime tags with compiler target triplets

>

The PR doesn't mention anything about the generic part of the implementation. Where should the generic part be?

I don’t understand what is meant by "generic part" here

>

Also how the source code hierarchy, how would it look like?

All tags-driven code will be placed into druntime/config/ directory

Inside of config/ each tag provides it's own files hierarchy corresponding to main druntime modules hierarchy.

For example, file:

druntime/config/posix/core/sync/event.d

will be used as module "core.sync.event" if "posix" tag choised

>

Let's take really small example like setjmp.d and show how it should be implemented, both inside the file and where the files should located.

For now, all *.d files involved into discussed PR is a such examples

December 01, 2023

On Friday, 1 December 2023 at 05:29:31 UTC, Denis Feklushkin wrote:

> >

What is the underlying data type and how does it differ from a version identifier. I don't understand what a tag is by reading the PR.

Proposed tags are similar to a D's versions, but I decided to separate its name because tags become not corresponding to a built-in D versions, at least.

Most importantly, new name need to avoid confusion. If we call them "version", we will inevitably begin to confuse it with D versions.

"Tags" (in various uses in the different software) are a similar scheme. Therefore, I think the name fits well.

« First   ‹ Prev
1 2 3