Re: LWDR (Light Weight D Runtime) v0.3.0
On Saturday, 19 June 2021 at 13:31:11 UTC, Dylan Graham wrote: [Github](https://github.com/0dyl/LWDR) [DUB](https://code.dlang.org/packages/lwdr) [Previous announcement](https://forum.dlang.org/post/giigcnoyxfoxxaevj...@forum.dlang.org) Once LWDR is stable enough, I want the next version to include module info, static ctor/dtor support and to look into Object monitor support and other multithreading tools (Mutexes, Conditions, etc).
Re: Release D 2.097.0
On Friday, 18 June 2021 at 06:14:03 UTC, Martin Nowak wrote: Don't have much of a clue about Windows nowadays, maybe there are more suitable alternatives. windows is my main development platform and personally i have no need for the installer at all- i just grab the 7z. however i would use the chocolatey package exclusively instead if it would be maintained more timely. https://community.chocolatey.org/packages/dmd i haven't used the new windows package manager by microsoft yet. https://github.com/microsoft/winget-cli
LWDR (Light Weight D Runtime) v0.3.0
[Github](https://github.com/0dyl/LWDR) [DUB](https://code.dlang.org/packages/lwdr) [Previous announcement](https://forum.dlang.org/post/giigcnoyxfoxxaevj...@forum.dlang.org) LWDR (Light Weight D Runtime) is a ground-up implementation of a D runtime targeting the ARM Cortex-M microcontrollers and other barebones environments. It works by providing a series of basic API hooks (as defined in [rtoslink.d](https://github.com/0dyl/LWDR/blob/master/source/rtoslink.d) that you must implement and/or point to your RTOS implementation. This is V0.3.0 of LWDR. Since V0.2.3, the following has been worked on: 1. Thread Local Storage support 2. Primitive memory tracking for Phobos allocations that would normally rely on a GC 3. Transition to an opt-in system 4. Replacement of `delete` with `LWDR.free(..)` due to deprecation 5. Source code documentation improvements 6. `RefCount!T` and `Unique!T` LWDR-specific implementations **Thread Local Storage** This feature is rather abstract, and it is an opt-in with version `LWDR_TLS`. You must provide support in your linker script for `tdata` and `tbss` sections. It works by utilising the underlying RTOS's TLS implementation ([example](https://www.freertos.org/pvTaskGetThreadLocalStoragePointer.html)). When `LWDR.registerCurrentThread()` is called a block of D memory is allocated containing the TLS variables for the current thread, and the pointer to the block is stored in the thread's TCB (Thread Control Block). When a TLS variable (ie, a static variable) is accessed, `__aeabi_read_tp` is called, yielding the pointer. **Memory Tracking** This is very primitive. It's *only* meant to assist with stopping GC-reliant stdlib allocations from leaking. It pretty much behaves as defined [here](https://forum.dlang.org/post/gfyhdqecjxszrgutl...@forum.dlang.org). **Opt In** To be able to keep the size of `TypeInfo` vtables down and such, LWDR has adopted an opt-in system, which relies on [D's version feature](https://dlang.org/spec/version.html). The current opt-ins are: 1. `LWDR_TLS` - Enables TLS support 2. `LWDR_DynamicArray` - Enables dynamic arrays 3. `LWDR_TrackMem` - Enables the mess above. **Replacement of `delete`** `delete` has been [deprecated](https://dlang.org/deprecate.html#delete). `LWDR.free` has been implemented in its place to prevent compiler warnings. **Source Code Documentation** Runtimes are hairy and scary - so I'm beginning to put more effort into documenting how things work. So far, it's only [ddoc](https://dlang.org/spec/ddoc.html) comments. **`RefCount!T` and `Unique!T`** To alleviate the lack of GC, I have implemented an LWDR-specific solution inspired by [automem](https://code.dlang.org/packages/automem). **What works?** 1. Class allocations and deallocations (via `new` and `LWDR.free`) 2. Struct heap allocations and deallocations (via `new` and `LWDR.free`) 3. Invariants 4. Asserts 5. Contract programming 6. Basic RTTI (via `TypeInfo` stubs) 7. Interfaces 8. Static Arrays 9. Virtual functions and overrides 10. Abstract classes 11. Static classes 12. Allocation and deallocation of dynamic arrays (opt in by version `LWDR_DynamicArray`) 13. Concatenate an item to a dynamic array (opt in by version `LWDR_DynamicArray`) 14. Concatenate two dynamic arrays together (opt in by version `LWDR_DynamicArray`) 15. Dynamic array resizing (opt in by version `LWDR_DynamicArray`) 16. Thread local storage (opt in by version `LWDR_TLS`) **What doesn't work?** 1. Exceptions and Throwables (experimental implementation was removed) 2. Module constructors and destructors 3. Static constructors and destructors 4. Shared static constructors and destructors 5. Module info 6. There is no GC implementation (primitive memory tracking is now available with `LWDR_TrackMem`, `RefCount!T` and `Unique!T` are now available) 7. Delegates/closures 8. Associative arrays 9. Object monitors 10. `shared`/`synchronised` 11. Object hashing 12. Other things I can't remember off the top of my head. It's still a beta - so expect bugs and warts. Some bits have been thoroughly tested, others not so much. Because the runtime has ballooned so quickly, I want to pause on development for a little bit so that I can begin using LWDR in a proper project and find and squash bugs. The project is pretty much the successor to my [Driving with D article](https://dlang.org/blog/2021/06/01/driving-with-d/) (it's an automotive project). I'm also thinking of applying with LWDR to the Autumn of Code thingo.
Re: Release D 2.097.0
On Friday, 18 June 2021 at 06:14:03 UTC, Martin Nowak wrote: On Monday, 7 June 2021 at 08:51:52 UTC, Bastiaan Veelo wrote: I am having issues as well, but I don't think the installer is at fault: I see the `C:\D\dmd2` directory get filled as the installer progresses, then files just disappear. It doesn't seem to be consistent though. After failure I tried with `dmd-2.096.1.exe` and the same thing happened, whereas it had installed fine before. I tried `dmd-2.097.0.exe` and this time the whole directory got wiped. I tried again and it installed fine. Windows 10 Pro N version 20H2 build 19042.985. I suspect MS cloud security scan. -- Bastiaan. Maybe we could recruit someone to replace the dated NSIS installer with a native msi installer. https://issues.dlang.org/show_bug.cgi?id=15375 https://en.wikipedia.org/wiki/List_of_installation_software#Windows Don't have much of a clue about Windows nowadays, maybe there are more suitable alternatives. Speaking with my Windwos dev hat on, the suitable alternative would be to use MSIX package files, the replacement for MSI files, that date back to Windows 2000. https://docs.microsoft.com/en-us/windows/msix/packaging-tool/tool-overview In what concerns typical Windows development workflows, its use is quite simple for basic use cases, namely add a MSIX project to solution, configure the manifest file and add as dependencies the .NET and C++ projects whose binaries are going to be part of MSIX. With something like D I expect a bit more convoluted process. https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-third-party-installer
