Re: Are @safe unittests actually checked for safety?
On Monday, 7 September 2020 at 20:33:26 UTC, 0xEAB wrote: Are unittests that are marked @safe actually checked for safety? https://github.com/dlang/phobos/blob/v2.093.1/std/file.d#L4937 How comes this unittest is @safe when `dirEntries` appears to be @system? I see what happened now: those nested functions are defined, but never actually called. The definition did NOT inherit the @safe from the unittest, but since they were never called, it never actually mattered; the check happens on call, not on definition.
Re: Building LDC runtime for a microcontroller
On Monday, 7 September 2020 at 20:55:54 UTC, IGotD- wrote: I guess this was written before betterC existed. Well, -betterC existed even then, but it was *completely* useless. It didn't become useful until 2016 or 2017. But around that same time, going minimal runtime got even easier, so I never really got on the betterC train anyway. On my tetris webassembly thing last month, I went with a minimal druntime http://dpldocs.info/this-week-in-d/Blog.Posted_2020_08_10.html#druntime And it has some class support too in not a lot of code: https://github.com/adamdruppe/webassembly/blob/master/arsd-webassembly/object.d (and if you aren't doing classes and built-in arrays, you can cut a bunch of that out too). To be honest I like this approach better as it opens up for gradually adding functionality. Yes, indeed. betterC is nice that it gives a library community a shared target to rally around, but for your own custom application it is probably better to do your own thing (though betterC might work for you too, worth considering at least).
Re: Building LDC runtime for a microcontroller
On Monday, 7 September 2020 at 19:12:59 UTC, aberba wrote: How about an alternative runtime + standard library for embedded systems...with a least bare minimum. I've seen a number of efforts to get D to run in those environments but almost none of them is packaged for others to consume. Adam D. Ruppe's book "D cookbook" describes another way by augmenting object.d in order to get "full D" to compile. I guess this was written before betterC existed. It will be similar to betterC, a very naked system without druntime. To be honest I like this approach better as it opens up for gradually adding functionality. A small runtime + standard library is about the only possibility in order to fit in those microconroller systems. Alternatively it might be better just start from scratch and implement often limited functionality they requires. The problem as I mentioned before was that OS dependent stuff is mixed with OS independent. I think that OS independent should be broken out so that it can more easily be used for embedded programming. Memory management can be a problem too. OS independent library code might expect full GC support and there seems to be no documentation which functions that does and which doesn't. I was thinking GC might not be that much of a problem for medium sized microcontroller systems. In practice you can have a fixed pool that is initialized from the beginning, non expandable. Still there is a GC memory overhead penalty. In the C/C++ world generic standard C libraries for embedded systems are rare, often unfinished, limited, GPL soiled so there are difficulties there as well. Often there are tons of POSIX filth in them as they are assumed to run on some kind Linux system.
Are @safe unittests actually checked for safety?
Are unittests that are marked @safe actually checked for safety? https://github.com/dlang/phobos/blob/v2.093.1/std/file.d#L4937 How comes this unittest is @safe when `dirEntries` appears to be @system? Example I: https://run.dlang.io/is/Vf0STw Error: @safe function onlineapp.listdir cannot call @system function std.file.dirEntries Example II (by adr): int* a = cast(int*) 0xdeadbeef; also was allowed.. making me think @safe unittest doesn't actually check the safety - Elias PS: is there a @safe version of `dirEntries`?
Re: Building LDC runtime for a microcontroller
On Monday, 7 September 2020 at 16:18:00 UTC, IGotD- wrote: On Monday, 7 September 2020 at 15:23:28 UTC, Severin Teona wrote: [...] Use betterC, which is much better suited for microcontrollers than the full D. The disadvantage is that many great features are disabled in betterC. [...] How about an alternative runtime + standard library for embedded systems...with a least bare minimum. I've seen a number of efforts to get D to run in those environments but almost none of them is packaged for others to consume.
Re: Building LDC runtime for a microcontroller
On Monday, 7 September 2020 at 15:23:28 UTC, Severin Teona wrote: CMake Error at /snap/cmake/549/share/cmake-3.18/Modules/CMakeTestCCompiler.cmake:66 (message): This is apparently a non-LDC specific issue, a default CMake C compiler sanity check fails. When looking at that file, you'll see that this test should be skipped when providing CMAKE_C_COMPILER_WORKS=TRUE in the CMake cmdline, as provided in one of the exemplary cmdlines on the Wiki page (just append it to the ldc-build-runtime cmdline).
Re: Building LDC runtime for a microcontroller
On Monday, 7 September 2020 at 15:23:28 UTC, Severin Teona wrote:
I would also appreciate any advice regarding ways to build or
create a small runtime for microcontrollers (runtime that can
fit in the memory of a microcontroller).
Thank you very much,
Teona
[1]: https://wiki.dlang.org/Building_LDC_runtime_libraries
[2]:
https://github.com/golang/go/issues/36633#issuecomment-576411479
Use betterC, which is much better suited for microcontrollers
than the full D. The disadvantage is that many great features are
disabled in betterC.
I have ported druntime/phobos to my system. This is pretty large
job because structure of druntime/phobos is not very good for
adding/porting to new systems. It's a cascade of version(this) {}
else version(that) {}. Some functionality must be ported, some
others can just be stubbed.
Keep in mind that you in general have to port phobos as well
because it contains many useful functions like parsing and
conversion. The OS dependent stuff is mixed together with OS
independent.
For an ARM target I get about a compiled size of about 500KB of a
simple Hello world program when linked statically. This isn't
really microcontroller size to begin with. The size quickly
increases as you start to use more modules from druntime/phobos.
Another interesting observation is that druntime has a option to
use malloc/free in a clib rather than map/VirtualAlloc for GC
allocations. What druntime does is over allocate because it
requires page aligned memory. The result is that this workaround
waste a lot of memory.
The conclusion is that D as it is isn't really suitable for
systems that are memory limited or lack an MMU (reason is that
shared libraries don't work). D is like C++ will full STL support
which is also very large. Embedded programmers who use C++ almost
never use STL because of this, among other things.
Building LDC runtime for a microcontroller
Hello, I have been trying to build the LDC runtime for a Nucleo-f429zi board with a Cortex-M4 CPU, by following [1]. The target is not dependent on any operating system (as the target board uses a STM32 microcontroller), so the gcc toolchain I have used is arm-none-eabi-gcc(9.3.1). The error I am getting after running “CC=arm-none-eabi-gcc ldc-build-runtime --reset --ninja --dFlags="-mtriple=thumb-none-linux-eabi” is: ——— CMake Error at /snap/cmake/549/share/cmake-3.18/Modules/CMakeTestCCompiler.cmake:66 (message): The C compiler "/home/teona/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/teona/runtime_thumb/ldc-build-runtime.tmp/CMakeFiles/CMakeTmp Run Build Command(s):/usr/bin/ninja cmTC_31c30 && [1/2] Building C object CMakeFiles/cmTC_31c30.dir/testCCompiler.c.o [2/2] Linking C executable cmTC_31c30 FAILED: cmTC_31c30 : && /home/teona/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc -rdynamic CMakeFiles/cmTC_31c30.dir/testCCompiler.c.o -o cmTC_31c30 && : arm-none-eabi-gcc: error: unrecognized command line option '-rdynamic' ninja: build stopped: subcommand failed. CMake will not be able to correctly generate this project. ——— After searching online for a solution, I found that the same issue appeared when using Golang and one answer [2] stated that it might work by passing to the linker “-Wl,-export-dynamic” instead of “-rdynamic”. Do you have any idea how I could do that? CMake version is 3.18, arm-none-eabi-gcc version is 6.3.1, ldc2 version is 1.23.0 and the system I am running on is Ubuntu 18.04 LTS. I would also appreciate any advice regarding ways to build or create a small runtime for microcontrollers (runtime that can fit in the memory of a microcontroller). Thank you very much, Teona [1]: https://wiki.dlang.org/Building_LDC_runtime_libraries [2]: https://github.com/golang/go/issues/36633#issuecomment-576411479
Re: Why is there no throws, @gc, impure, mutable ?
On Monday, 7 September 2020 at 11:44:40 UTC, Paul Backus wrote: On Monday, 7 September 2020 at 11:25:15 UTC, wjoe wrote: It's easy to declare the entire module @safe and functions which can't be can be declared @system. However there is const, immutable, pure, @nogc and nothrow but no mutable, impure, @gc and throws. Why is that ? Mostly because nobody's bothered to add them (yet). There's an accepted proposal to add a "throw" attribute as the opposite of nothrow [1], but it looks like it still hasn't been implemented in the compiler. For const and immutable, you can use std.traits.Unconst [2] to remove them in most cases. [1] https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1029.md [2] http://dpldocs.info/experimental-docs/std.traits.Unconst.html Very interesting. Thanks.
Re: Why is there no throws, @gc, impure, mutable ?
On Monday, 7 September 2020 at 11:25:15 UTC, wjoe wrote: It's easy to declare the entire module @safe and functions which can't be can be declared @system. However there is const, immutable, pure, @nogc and nothrow but no mutable, impure, @gc and throws. Why is that ? Mostly because nobody's bothered to add them (yet). There's an accepted proposal to add a "throw" attribute as the opposite of nothrow [1], but it looks like it still hasn't been implemented in the compiler. For const and immutable, you can use std.traits.Unconst [2] to remove them in most cases. [1] https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1029.md [2] http://dpldocs.info/experimental-docs/std.traits.Unconst.html
Why is there no throws, @gc, impure, mutable ?
It's easy to declare the entire module @safe and functions which can't be can be declared @system. However there is const, immutable, pure, @nogc and nothrow but no mutable, impure, @gc and throws. Why is that ?
