Symmetry Autumn of Code

[Mike Franklin]

On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote:

> Moreover, The term "dependency-free" in the project description 
> often confuses me, because as a hardware-agnostic library the 
> project does have to depend on external implementations like 
> "sin"/"memset" or even "thread_start", and I'm not sure which 
> kind of dependency is proper for this project: Should we assume 
> a multi-threading model? Should this library rely on 
> "malloc"/"free"? Correct me if my understanding is wrong since 
> I had few experience on embedded programming.

There is more to this project than just getting a software 
rasterizer in D.  Part of the goal is to demonstrate D as a 
formidable alternative to C in micrcontroller firmware 
programming.  D will never achieve that notoriety if it's always 
depending on C, the C runtime, the C standard library, or some 
library implemented in C.

So, IMO, if you need to link in a library or object file that was 
not compiled from D code, then you're cheating.  This is also one 
of the reasons why I suggested re-implementing software building 
blocks such as `memcpy`, `memset`, `malloc`, `free`, etc. in D as 
another potential project for the Autumn of Code.

So, to keep this software rasterizer project within scope, I 
suggest creating naive implementations of those functions in D 
for now to stay true to spirit of the project (no dependencies, 
everything in D), and "make the point".  You can those software 
building blocks in their own module, and let the user of the 
software rasterizer library link it their own implementation if 
they wish to deviate from the spirit of the proposal.

Mike