September 17, 2020
fyi my baby was just born i'll come back to this but it might be a day or two
September 17, 2020
On Thursday, 17 September 2020 at 19:27:41 UTC, Adam D. Ruppe wrote:
> fyi my baby was just born i'll come back to this but it might be a day or two

congratulations! All the best for your family :)
September 17, 2020
On Thu, Sep 17, 2020 at 08:40:06PM +0000, wjoe via Digitalmars-d-learn wrote:
> On Thursday, 17 September 2020 at 19:27:41 UTC, Adam D. Ruppe wrote:
> > fyi my baby was just born i'll come back to this but it might be a day or two
[...]

"A day or two"??!  More likely a month for starters. :-D :-D :-D  If
even that!  (Speaking from experience here. ;-))

Congratulations!


T

-- 
Живёшь только однажды.
September 18, 2020
On Thursday, 17 September 2020 at 19:27:41 UTC, Adam D. Ruppe wrote:
> fyi my baby was just born i'll come back to this but it might be a day or two

Oh probably most unexpected answer! Congratulations!

Had 4 weeks myself, take care of your family, everything else can wait ;)
September 18, 2020
On Monday, 7 September 2020 at 19:12:59 UTC, aberba wrote:
> 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.

I use D in an automotive environment (it controls parts of the powertrain, so yeah there are cars running around on D) on various types of ARM Cortex M CPUs, I think this will be the best way to extend D to those platforms.

The existing runtime is PC-oriented. Embedded stuff doesn't need a GC or some of the more advanced features, but having things like classes, interfaces, dynamic arrays would make the development workload a lot easier.

A lot of embedded stuff is done with RTOSs now that provide memory management and threading support, so having a flexible lightweight runtime with a generic backend (mem allocation, threads) that I can hook to the RTOS' libraries would be great.
September 18, 2020
On Thursday, 17 September 2020 at 09:53:57 UTC, Remi wrote:
> My problem here is mostly understanding the __initZ symbol and where it comes from.

The compiler generates that when it spits out something that uses TypeInfo, which is a lot of things: ~= and ~ operators on built in arrays, the new operator, class dynamic casting, exception catching, and more. Annoyingly, even having a class member of a type will trigger a TypeInfo dependency too. Why? idk, probably to do with precise GC hook support.

The error you mentioned in your other message about the order of files is interesting.. I suspect that is because the compiler creates these symbols when it first sees a need... then tries to reuse it, and that must have made the conflict here since it made it in the wrong context... or something.

The error says something about constness being different, well, why the eff would an init symbol ever be mutable? And ldc is so strict about this stuff too where dmd just doesn't care and that can be annoying too.

idk this probably doesn't help you much since I don't know why it is generating it this way either. It is possible it is actually pulling the definition from the original druntime or something.

(on my webassembly.arsdnet.net site btw I made my own little on-demand build web service to pass the right args. p convenient but also specialized for me and prolly not too general purpose)

I'll keep investigating as I have time, but I do kinda prefer th idea of improving the system rather than hacking around it lol

> I'll probably try what you describe in your "Zero-runtime classes" actually, and hopefully I can get away without the string manipulation or replace it with my own version of it.

oh the string manip there is just looking up the symbol, it isn't too bad.

The betterC thing also kinda sorta works with classes btw if you combine this with extern(C++) class definitions.
September 19, 2020
On Friday, 18 September 2020 at 23:00:33 UTC, Adam D. Ruppe wrote:
>
> The error says something about constness being different, well, why the eff would an init symbol ever be mutable?

See https://forum.dlang.org/post/edngcvtlkjpykxvxyndq@forum.dlang.org for why TypeInfo is mutable. (In this case, the __initZ symbol is more than just an init symbol).

-Johan



September 19, 2020
On Monday, 7 September 2020 at 22:13:20 UTC, Adam D. Ruppe wrote:
> On Monday, 7 September 2020 at 20:55:54 UTC, IGotD- wrote:
>> [...]
>
> Well, -betterC existed even then, but it was *completely* useless. It didn't become useful until 2016 or 2017.
>
> [...]

Cool!
September 19, 2020
On Friday, 18 September 2020 at 07:44:50 UTC, Dylan Graham wrote:
> On Monday, 7 September 2020 at 19:12:59 UTC, aberba wrote:
>> [...]
>
> I use D in an automotive environment (it controls parts of the powertrain, so yeah there are cars running around on D) on various types of ARM Cortex M CPUs, I think this will be the best way to extend D to those platforms.

Wow. Happy to hear this.

Do you attend our monthly D online meetups?

>
> The existing runtime is PC-oriented. Embedded stuff doesn't need a GC or some of the more advanced features, but having things like classes, interfaces, dynamic arrays would make the development workload a lot easier.
+1


>
> A lot of embedded stuff is done with RTOSs now that provide memory management and threading support, so having a flexible lightweight runtime with a generic backend (mem allocation, threads) that I can hook to the RTOS' libraries would be great.

I think Ali was also working on or at least talked about that OS (if I remember correctly) at Dconf, right?
September 19, 2020
On Friday, 18 September 2020 at 07:44:50 UTC, Dylan Graham wrote:
>
> I use D in an automotive environment (it controls parts of the powertrain, so yeah there are cars running around on D) on various types of ARM Cortex M CPUs, I think this will be the best way to extend D to those platforms.
>

Do I dare to ask what brand of cars that are running D code. Maybe you're supplier that sells products to several car brands.