On 2020-05-06 14:18, IGotD- wrote:

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

It doesn't need to be an abstract interface. Since the implementation will be selected at compile time the only thing that is required that all implementation implements the same API. The API can be functions, structs, classes, whatever. For an existing example see [1].

[1] https://github.com/dlang/druntime/blob/master/src/rt/sections.d

-- 
/Jacob Carlborg

On 2020-05-06 10:40, Paulo Pinto wrote:

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

The Linux subsystem is now actually a proper Linux kernel, running side by side with the Windows kernel, and not a reimplementation of the Linux kernel API.

-- 
/Jacob Carlborg

On 2020-05-06 13:42, Denis Feklushkin wrote:

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

I'm not sure that I agree. I would say that libc is the library containing the functions and types defined by the C standard.

Then it just happens so that on most platforms they will bake in the OS APIs in the same library. I just checked, on macOS all programs are linked with libSystem. This is mostly an umbrella library that brings in other libraries. The library itself only contains 36 symbols, but it depends on 33 other libraries. One of them being libsystem_c, which seems to contain the actual C standard library. Then there's libsystem_kernel, which seems to contain the OS APIs.

> So, libc de facto is OS API.

That depends on the platform as well. On Linux the system calls provide a stable API. On macOS they don't. Apple explicitly specifies that the stable API is the syscall wrappers.

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

You cannot. glibc doesn't fully support static linking, not even on Linux. For example, DNS lookup does not work/is not fully supported in a fully statically linked binary.

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

Yeah, I don't like it either.

-- 
/Jacob Carlborg

On Wednesday, 6 May 2020 at 18:03:40 UTC, Jacob Carlborg wrote:

>> 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.
>
> You cannot. glibc doesn't fully support static linking, not even on Linux. For example, DNS lookup does not work/is not fully supported in a fully statically linked binary.


"any libc" -> "any suitable libc" :-)

(picolibc is my choise for this purposes)

On Wednesday, 6 May 2020 at 18:03:40 UTC, Jacob Carlborg wrote:
>
> You cannot. glibc doesn't fully support static linking, not even on Linux. For example, DNS lookup does not work/is not fully supported in a fully statically linked binary.
>

Networking is not really part of the C library standard, despite it is often linked into libc. Supporting C library functionality gives you a limited system but at least a system that will be able to work on most system without any modifications, like lowest common denominator.

On Wednesday, 6 May 2020 at 17:38:40 UTC, Jacob Carlborg wrote:
> On 2020-05-06 10:40, Paulo Pinto wrote:
>
>> POSIX has kind of lost relevance, hence why Microsoft went with Linux for their new new POSIX subsystem.
>
> The Linux subsystem is now actually a proper Linux kernel, running side by side with the Windows kernel, and not a reimplementation of the Linux kernel API.

Indeed, which was the point I was making, Linux compatibility has become more valuable than plain old POSIX.

They are also not the first vendor to go for that approach, other UNIXes and mainframes also offer similar compatibility, through various means.

On Wednesday, 6 May 2020 at 18:56:55 UTC, Denis Feklushkin wrote:
> On Wednesday, 6 May 2020 at 18:03:40 UTC, Jacob Carlborg wrote:
>
>>> 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.
>>
>> You cannot. glibc doesn't fully support static linking, not even on Linux. For example, DNS lookup does not work/is not fully supported in a fully statically linked binary.
>
>
> "any libc" -> "any suitable libc" :-)
>
> (picolibc is my choise for this purposes)

for druntime to working with MCU platform, we probably can rely only on [newlib] or even [newlib-nano] style `libC`, and make all other things to OS APIs, although some RTOS has implemented several POSIX api, it's all only a subset of POSIX.

but the embedded programmer will happy if we support newlib-nano + FreeRTOS or NuttX or Zephyr.

On Thursday, 7 May 2020 at 06:46:27 UTC, dangbinghoo wrote:
> On Wednesday, 6 May 2020 at 18:56:55 UTC, Denis Feklushkin wrote:
>> On Wednesday, 6 May 2020 at 18:03:40 UTC, Jacob Carlborg wrote:
>>
>>>> [...]
>>>
>>> You cannot. glibc doesn't fully support static linking, not even on Linux. For example, DNS lookup does not work/is not fully supported in a fully statically linked binary.
>>
>>
>> "any libc" -> "any suitable libc" :-)
>>
>> (picolibc is my choise for this purposes)
>
> for druntime to working with MCU platform, we probably can rely only on [newlib] or even [newlib-nano] style `libC`, and make all other things to OS APIs, although some RTOS has implemented several POSIX api, it's all only a subset of POSIX.
>
> but the embedded programmer will happy if we support newlib-nano + FreeRTOS or NuttX or Zephyr.

sorry, I don't know [newlib-nano] is now called [picolibc]!  ^_^

Ok, now my project runs druntime and can blink by LED. Binary size is 200Kb :-)

https://github.com/denizzzka/d_c_arm_test/

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.

About Phobos: here is only one issue with it and supporting any platform for "blinking LED project":

file std/ascii.d:

/// Newline sequence for this system.
version (Windows)
    immutable newline = "\r\n";
else version (Posix)
    immutable newline = "\n";
else
    static assert(0, "Unsupported OS");

Compilation fails here because "OS" isn't Windows and isn't Posix. It is need to clarify way to pass external OS version into Phobos.

https://dlang.org/spec/version.html#predefined-versions

FreeStanding

\n is probably correct for this version, but it probably should be discussed in a PR.