LDC 1.19 - Android, AVR. My rant on tests, update on JNI and COM.
Posted 2019-12-23
Blog
Articles- terminal.d gets clipboard functions, ldc 1.20 out.
- DConf keynote speaker announced: Lua architect Roberto Ierusalimschy, Named args DIP discussed
- February 3, 2020
- Adam's terminal suite explained
- Understanding mixin templates, terminal.d improvements
- My attribute-by-default proposal. Also dmd 2.090 came out.
- DConf 2020 announced: June 17-20 in London. @safe by default debated. Adam did: Android, JNI, WebSocket in arsd libs
- tar.xz, --DRT tip, dom bug fixes, more Android and JNI, link to old phobos docs
- LDC 1.19 - Android, AVR. My rant on tests, update on JNI and COM.
- Walter's string interpolation proposal is OK but not great. My Android thing nearing beta release. dub downtime explained.
- Android project update, introduction to arsd.jni
- New pattern about interface contracts
- Adam shares Windows console secrets - DO NOT USE chcp!!
- Adam's rant on benchmarks
- Socket tutorial
- November 4, 2019
- October 28, 2019
- arsd package updates, forum nonsense
- Update on Android
- Adam does iOS "goodbye world"
- September 30, 2019
- D turns 20, Adam rants on software freedom
- Named arg DIPs and my thoughts on code organization
- September 9, 2019
- I wrote about mixin templates vs string mixins on Stack Overflow
- August 26, 2019
- Bug bounty in D again - my hot take, on reusing code, a fun picture, my tentative plan for the next month
- Time invested is worth a lot
- cgi.d's new scheduler, static this tricks
- July 29, 2019
- July 22, 2019
- Solving vs managing problems
- A big week in the arsd repo
- July 1, 2019
- June 24, 2019
- June 17, 2019
- CRTP thoughts, named arguments DIP review, DConf videos now on youtube
- musings on hybrid CT/RT tests, some more progress on new web framework
- a little more webassembly
- May 20, 2019
- Adam's string interpolation proposal
- DMD 2.086 live, GCC 9 with D support formally released, DConf coming soon, links to posts on builder pattern and disallowing implicit conversions with templates, and 2d array op overloads
- template constraint error improvements coming?
- dmd 2.086 beta, dstep 1.0 released, Adam works on memory usage
- obj-c and webassembly report, tips on is expressions linked.
- new ldc, new dmd, dpp on the blog
- D's future discussed in forums
- LDC beta, DConf blog link, Adam introduces gamehelpers.d
- March 18, 2019
- LDC 1.15.0-beta1, responsive design rant
- dmd 2.085.0 released
- Obj-C interop and D without druntime code to copy/paste
- dmd beta, more info coming next time, demo of new web framework initial prototype
- automatic web interface discussion, reflection tips and tricks
- Adam busy with weather and a move, lots of community announcements
- January 28, 2019
- Working on official blog 2018 retro, C++ new wrapped, dmd reading zips?
- dmd obj-c growing, Adam static foreaches an interface to RPC
- dmd 2.084, hope for future, but busy non-D week for me
- IDE tools released, my cgi.d gets new features
- DConf announced, tip, Adam rants: mouse trap
- This Week in D is back!
LDC 1.19 released with more android and AVR (the arduino chip) support built in. I rant on tests and update on JNI and COM.
Core D Development Statistics
In the community
Community announcements
See more at the announce forum.
What Adam is working on
I continued some work on my jni library, and revived my old COM library, renamed it, and tested it as a .net interop helper. I now have code that can read method definitions out of Java .class files, so soon I can auto-generate D bindings to Java APIs, including with overloading support. It may soon be possible to define new java classes in D as well. With this and the work LDC has done, official android support is right around the corner.
Meanwhile, encouraged by the beauty of the Java native interface code, I wanted to see if I could do something similar to .net. The answer is... sort of. The beginnings of my work can be seen here: http://dpldocs.info/experimental-docs/arsd.com.html and much more will be coming later.
There's three layers of COM: the low level one, directly calling IUnknown based interfaces, no assistance in memory management, no return value translations. D has this basically built in, though some helper functions can simplify it.
The middle layer calls the interfaces, but convert HRESULT returns to exceptions (and vice versa), out params to return values, and different levels of memory management. If you ask for a D type in a return value, it will copy it to the GC for convenience. If you ask for a wrapped type, it can put it in a RAII struct for more efficient, yet still assisted, access. I haven't completed most of this work yet.
The high level layer does all the translations of the mid-level, but through the IDispatch dynamic interface instead of through the function pointer interfaces. This brings a performance penalty, but is also convenient and widely compatible with the Windows ecosystem - this is how JScript and VBScript talk to other components (including yours!) and is well-supported by the .net runtime. This means you can load a .net object through COM and interact with it, even if you only know parts of the interface. Unlike the low-level interface, which requires all functions to be declared in proper order, you can use a dynamic dispatch to call just one individually declared method.
I like this kind of incremental, declare only what you use, interface because it eases experimentation and increases cross-version compatibility. You don't have to do a lot of up-front work translating the whole object when you only want a handful of methods.
Anyway, my goal with the new com.d is to allow all these layers, but right now it is biased toward the high level interface, since that is easiest to test. With C#, [ComVisible=true] is actually the default, but some VS-generated projects will set it to false in the assembly.cs file. Regardless, once it is true, you can sign your dll as you build it and register it in the registry then it is usable from D!
I am sure I'll be able to simplify it a little more in more time, but it already works if you follow the Windows rules. The other options for D to/from C# interaction tend to be:
And either or both of those approaches may be better for you, so it is possible this COM interop will not be that useful with C# per se, but since it is so common in the Windows ecosystem, I am sure we will find some value anyway eventually.
I'll keep working on this as time permits.
Adam's rant on testing
A test indicating a problem is not a failure; that's it doing exactly what it is supposed to do! On the other hand, a test is really failing when it doesn't detect a real bug, or throws up a complaint over nothing.
There's four general states tests can be in:
To make more successful tests, I suggest the following:
I also personally loathe automated style checks. I get why people do them, but a space in the source code is not a bug and should not be treated as such. If you must do an automated style check, at least make sure it is in a different category than the other tests and do not block them, so a PR gets its substance tested even before the style is perfectly aligned.