arsd 9.5 -- UPDATE: false alarm i forgot to tag it!

Core D Development Statistics

• 20 bugs fixed
• 9 bugs and enhancement requests opened
• 53 pull requests merged into the language: 23 into DMD, 21 into Phobos, and 9 into druntime.
• 1 pull requests merged into the website.

In the community

Community announcements

• Silicon Valley D Meetup - April 15, 2021 - "Compile Time Function Execution (CTFE)"
• (Oh My) Gentool 0.1.0
• Beta 2.096.1

See more at the announce forum.

What Adam is working on

arsd 9.5

arsd-official 9.5 recently tagged. This brings some rudimentary support for arsd.http2 event loop integration and proxy support in the http client object. You can also change the verify peer setting via an undocumented member called defaultVerifyPeer but I reserve the right to change that at any time.

I actually prefer batching my release and spacing them further out so there's more in them, but someone requested this ASAP so I tagged it quicker.

Also a few small bug fixes rolled up in it including a jsvar serialization regression with nested objects (introduced with property support a few months back).

Coming in the next release will be more Terminal.getline control enhancements to help match emacs user's habits, better copy/paste handling in the embedded gui terminal emulator and surely other random things as they come up.

dlls and gc

I was going to write this week about discovering a bug in druntime that was leading to dll crashes, but that got derailed when I completely failed to reproduce the bug outside of a proprietary private codebase.

I can see it clearly in the debugger there and made a that patched it... so obviously something is going on, but being unable to reproduce it in a reduced, public test case leaves me without confidence that it is ACTUALLY what I thought it was.

The druntime code is not 100% correct, that's for sure, but it also doesn't appear to be wrong in the exact way I thought it was wrong. It is probably an interaction of various things (could be gc initialization order, thread creation, mark thread race condition, dll loading, many, many things going on by the time it manifests) and the fix I thought was fundamental may instead just be moving it to somewhere else, or papering over it (like doing if(x is null) return; without identifying why x is null in the first place. Sure, it doesn't crash anymore, but it also leaves a lingering problem).

My understanding of the dll and gc are slowly expanding though, so perhaps one of these days I'll get to the bottom of it. But alas, that day will not be this week. The hunt continues.