On 2020-03-17 20:34, IGotD- wrote:

> This is where something like
> 
> import core.sys.<compiletime identifier>.semaphore;
> 
> would be an absolute great help.

Can be easily handled with a string mixin and a utility function:

version (linux)
    enum platform = "linux";
else version (Windows)
    enum platform = "windows";

string import_(string[] imports ...)
{
    string result;

    foreach (i, imp; imports)
    {
        if (i != 0)
            result ~= '.';

        result ~= imp;
    }

    return "import " ~ result ~ ';';
}

mixin(import_("core", "sys", platform, "semaphore"));

-- 
/Jacob Carlborg

On Tuesday, 17 March 2020 at 20:27:21 UTC, Jacob Carlborg wrote:
> On 2020-03-17 18:38, Denis Feklushkin wrote:
>> On Tuesday, 17 March 2020 at 17:12:39 UTC, IGotD- wrote:
>>> On Tuesday, 17 March 2020 at 16:25:22 UTC, Johan wrote:
>>>>
>>>> Rather than setting the import directory, I think a much nicer solution is something like this:
>> 
>> Yes, already implemented in new PR: https://github.com/dlang/druntime/pull/2997
>
> That PR kind of misses the point. What I did with Mecca was to manage to remove, more or less, all version identifiers from outside of the `platform` package.
>
> If you're doing this for druntime I recommend you have a package for each platform. Currently you still have all version identifiers in the file for Posix.

This is not a problem as long as all of these platforms are supported by druntime.

But yes, some another Posix files can be divided into smallest platform parts, but such small file as posix's time.d can be left and so - there will no be problem.

I didn’t think about staying on this state with splitted core.stdc.time. I wanted to divide core.time too and some of its parts maybe become divided to smallest sys modules as you say.
But now I stuck into these Makefiles and don't know how to solve this gracefully.

On Tuesday, 17 March 2020 at 20:37:04 UTC, Jacob Carlborg wrote:
> On 2020-03-17 20:34, IGotD- wrote:
>
>> This is where something like
>> 
>> import core.sys.<compiletime identifier>.semaphore;
>> 
>> would be an absolute great help.
>
> Can be easily handled with a string mixin and a utility function:
>
> version (linux)
>     enum platform = "linux";
> else version (Windows)
>     enum platform = "windows";
>
> string import_(string[] imports ...)
> {
>     string result;
>
>     foreach (i, imp; imports)
>     {
>         if (i != 0)
>             result ~= '.';
>
>         result ~= imp;
>     }
>
>     return "import " ~ result ~ ';';
> }
>
> mixin(import_("core", "sys", platform, "semaphore"));

Thank you, didn't know that mixins even works for imports. This greatly would help a generic ABI as the import would just select the specific files for the particular OS. The OS implementations could then have dedicated names that like SemapholeImpl as type and dedicated methods like SemapholeImpl.wait(). This really open ups the degrees of freedom.

On Tuesday, 17 March 2020 at 17:38:41 UTC, Denis Feklushkin wrote:

> This strategy looks good, but again there is a problem that is not directly related to the code: changing one module required changing only 8 lines in the code, but 15 lines in build scripts. And this is not all of needed changes - LDC uses its own cmake build scripts.
>
> And each module will require approximately same changes. It will be like a disaster. Thus, at first stage we need to clear up build scripts.

This problem is solved by Rainer Schuetze, thank you!
https://github.com/dlang/druntime/pull/3026

Discussion related to this topic continues for a little in this PR:
https://github.com/dlang/druntime/pull/2997

Trying to adapt druntime has been a cascade of version (this) {} else version (that). druntime and phobos is a ball of wool.

After porting druntime I realized that I need Phobos as well because there is a lot of simple stuff like converting int to string and so on. Converting an int to string doesn't rely on an operating system. However, I'm forced to go through this version cascade over again which is even bigger that druntime.

The situation is similar to the C library which also might have dependencies all over. Some C library implementations are more simple and OS support can be stubbed. What D needs is a stubbed ABI for druntime/phobos. This means no file support, no threading etc. This ties into the "pay as you go" goal of D. D should be able to compile with minimal OS support instead of now require a rich OS.

What we need is an ABI. Then we also need a stubbed implementation of the ABI. This gives any implementer a good overview what needs to be implemented as well as that the OS support can be done incrementally. Some OSes don't support everything like memory mapped files and we should support this possibility as well.

We should also try to isolate the OS independent functionality more. Convenience functions that doesn't need an OS should be broken out, or at least with switches be compiled isolated from the OS dependent code.

If we are able to do this, D will make a rocket career in embedded systems.

On 2020-05-02 22:24, IGotD- wrote:

> Some OSes don't support everything like memory mapped files and we should support this possibility as well.

Yes, I noticed this the hard way when I added support for iOS. It was assumed to be Posix compatible but there are a couple of edge cases where some system calls are not available.

> We should also try to isolate the OS independent functionality more. Convenience functions that doesn't need an OS should be broken out, or at least with switches be compiled isolated from the OS dependent code.

I agree. Everything that is platform specific should be in its own package, with one sub-package for each platform. I managed to do this when I added support for macOS to Mecca [1], turned out quite nice. The only remaining version blocks outside the platform package was to select the correct platform specific import.

[1] https://github.com/weka-io/mecca/pull/12

-- 
/Jacob Carlborg

On Wednesday, 6 May 2020 at 07:54:31 UTC, Jacob Carlborg wrote:
> On 2020-05-02 22:24, IGotD- wrote:
>
>> Some OSes don't support everything like memory mapped files and we should support this possibility as well.
>
> Yes, I noticed this the hard way when I added support for iOS. It was assumed to be Posix compatible but there are a couple of edge cases where some system calls are not available.
>

POSIX has kind of lost relevance, hence why Microsoft went with Linux for their new new POSIX subsystem.

"POSIX Has Become Outdated"

http://www.cs.columbia.edu/~vatlidak/resources/POSIXmagazine.pdf

On Saturday, 2 May 2020 at 20:24:46 UTC, IGotD- wrote:
> Trying to adapt druntime has been a cascade of version (this) {} else version (that). druntime and phobos is a ball of wool.

This fork of ldc version of druntime is close to success:

https://github.com/denizzzka/druntime/tree/non_posix

Not so much has been added there (look at the diff between ldc and this branch).

> The situation is similar to the C library which also might have dependencies all over. Some C library implementations are more simple and OS support can be stubbed. What D needs is a stubbed ABI for druntime/phobos. This means no file support, no threading etc. This ties into the "pay as you go" goal of D. D should be able to compile with minimal OS support instead of now require a rich OS.

It is important to understand that libc library is not actually a library for use C language.

Yes, it contains some C string and math functions, but OS API functions what provided by libc is convient wrapper for OS syscalls what used by everyone, because no one wants to support all number of OSes syscalls.

So, libc de facto is OS API.

It would be great to replace them. But this does not look as a priority, because you can always use parts of any libc as a static library for baremetal.

Perhaps it is better to wait for the "worldwide libc replacement" to appear? Personally, I don't like the concept of errno in libc.

> We should also try to isolate the OS independent functionality more. Convenience functions that doesn't need an OS should be broken out, or at least with switches be compiled isolated from the OS dependent code.

$ grep -r " core.stdc" --include='*.d' druntime/src/core/ |grep import

displays that at least druntime contains not so much number of libc calls.

On Saturday, 2 May 2020 at 20:24:46 UTC, IGotD- wrote:

> After porting druntime I realized that I need Phobos as well because there is a lot of simple stuff like converting int to string and so on. Converting an int to string doesn't rely on an operating system. However, I'm forced to go through this version cascade over again which is even bigger that druntime.

I briefly looked (grep) which "versions" are used in Phobos. It seems to me that everything that is about different OSes support can be transferred to druntime without problem. (And in druntime can be added ability to select arbitrary OS code as repeatedly described above.)

...And then druntime could become "the new libc"

On Tuesday, 17 March 2020 at 20:37:04 UTC, Jacob Carlborg wrote:
>
> Can be easily handled with a string mixin and a utility function:
>
> version (linux)
>     enum platform = "linux";
> else version (Windows)
>     enum platform = "windows";
>
> string import_(string[] imports ...)
> {
>     string result;
>
>     foreach (i, imp; imports)
>     {
>         if (i != 0)
>             result ~= '.';
>
>         result ~= imp;
>     }
>
>     return "import " ~ result ~ ';';
> }
>
> mixin(import_("core", "sys", platform, "semaphore"));

I see many occurrences like this insinde the version blocks:

import core.sys.platform.subfunctionality : subFuncImpl;
alias functionality = subFuncImpl;

We could provide with an abstract interface like this as you suggested.

mixin(import_("core", "sys", platform, "semaphore")) : SemaphoreAcquireImpl;
The Semaphore class can use SemaphoreAcquireImpl.

SemaphoreAcquireImpl would have a type like this where SemaphoreOSType also needs to be imported in similar fashion:
void SemaphoreAcquireImpl(SemaphoreOSType sem), but this function would be the same for every system. I think this type of interface could be repeated for almost all OS dependent functionality. The type of the semaphore descriptor must also be be provided, as some are a descriptor on certain systems or a pointer type on others.

Some functions can just be aliased
mixin(import_("core", "sys", platform, "process")) : getPidImpl;
alias getpid = getPidImpl;


This type of interface could just be added under one version block like:

version(druntimeAbstractInterface)
{
   ...
}



Something that we all can work on is a generic C library interface for "C library style OS" for compatibility. This of course would have limited functionality but could provide basic functionality. This also makes important to selectively choose what to support. A stub would be an alternative, that just goes through silently or raises a "not implemented exception". Nim has an --os:any option which means it will just use the C library.