Difference between revisions of "SAOC 2018 ideas"

From D Wiki
Jump to: navigation, search
(→‎Re-implement Software Building Blocks (e.g. memcpy, memset, memcmp, malloc, free, etc.) in D: Add suggestion for scope)
m (A little wordsmitthing)
Line 88: Line 88:
 
Unfortunately, this means that the runtime hooks (now templates) need to rewritten in a manner to ensure they are <code>@safe</code>, <code>pure</code> and <code>nothrow</code>.  That is quite difficult as many of the software building blocks employed by implementation of those runtime hooks (e.g. <code>memcpy</code>, <code>memset</code>, and <code>memcmp</code>) are not written to be used in a memory-safe language.  For example, to copy blocks of memory in D, one would likely use a function declared as <code>void memcpy(T[] dest, const T[] src)</code> not <code>void* memcpy(void* dest, const void* src, size_t n)</code>.
 
Unfortunately, this means that the runtime hooks (now templates) need to rewritten in a manner to ensure they are <code>@safe</code>, <code>pure</code> and <code>nothrow</code>.  That is quite difficult as many of the software building blocks employed by implementation of those runtime hooks (e.g. <code>memcpy</code>, <code>memset</code>, and <code>memcmp</code>) are not written to be used in a memory-safe language.  For example, to copy blocks of memory in D, one would likely use a function declared as <code>void memcpy(T[] dest, const T[] src)</code> not <code>void* memcpy(void* dest, const void* src, size_t n)</code>.
  
−
Furthermore, those software building blocks are currently taken from the C standard library.  The fact that D requires the C standard library is an artificial dependency.  D, being a suitable alternative to C, should not need to rely on toolchains and libraries written in other languages.  It might be expedient to leverage such implementations, but it is not good design as it prevents D from building freestanding software, and complicates the software development environment as it becomes necessary to obtain and configure a C toolchain in addition to D toolchain.
+
Furthermore, those software building blocks are currently taken from the C standard library.  The fact that D requires the C standard library is an artificial dependency.  D, being a suitable alternative to C, should not need to rely on toolchains and libraries written in other languages.  It might be expedient to leverage such implementations, but it is not good design as it prevents D from building freestanding software, and complicates the software development environment as it becomes necessary to obtain and configure a C toolchain in addition to a D toolchain.
  
 
Also, having the runtime hooks available as templates would allow the language features they implement to be used in -betterC code, as the implementation will be generated at compile-time; no longer requiring linking in a pre-compiled runtime implementation.
 
Also, having the runtime hooks available as templates would allow the language features they implement to be used in -betterC code, as the implementation will be generated at compile-time; no longer requiring linking in a pre-compiled runtime implementation.
Line 94: Line 94:
 
Therefore, to help address all of the issues above, it would be ideal to rewrite those software building blocks in <code>@safe</code>, <code>pure</code>, <code>nothrow</code>, typesafe, idiomatic D, so they can be used to implement the runtime hooks, compiler intrinsics, freestanding software, and more, while simplifying the development environment setup required to use D.
 
Therefore, to help address all of the issues above, it would be ideal to rewrite those software building blocks in <code>@safe</code>, <code>pure</code>, <code>nothrow</code>, typesafe, idiomatic D, so they can be used to implement the runtime hooks, compiler intrinsics, freestanding software, and more, while simplifying the development environment setup required to use D.
  
−
A preliminary investigation of this idea can be found at [https://github.com/JinShil/memcpyD memcpyD].
+
A preliminary investigation of implementing <code>memcpy</code> n D can be found at [https://github.com/JinShil/memcpyD memcpyD].
  
 
<code>malloc</code>, <code>free</code>, and friends would be good candidates for this project as well.  They may be able to take implementation details from [https://dlang.org/phobos/std_experimental_allocator.html std.experimental.allocator].
 
<code>malloc</code>, <code>free</code>, and friends would be good candidates for this project as well.  They may be able to take implementation details from [https://dlang.org/phobos/std_experimental_allocator.html std.experimental.allocator].

Revision as of 02:04, 24 July 2018

This is a list of potential project ideas for applicants to the Symmetry Autumn of Code. Projects on this page are simply suggestions, not detailed proposals. It is up to any applicant who chooses one to flesh out the idea to a degree suitable for a project proposal as part of the SAoC application.

HTTP/2 for Vibe.d

HTTP/2 is a major revision of the HTTP network protocol. Among its advantages belong decreased latency due to (e.g. due to compressed HTTP headers or pipelined requests) or server-push from the server which allows the server to send resources to the client before they are requested. Therefore, Vibe.d - D's flagship web application framework - would vastly profit from implementing HTTP/2.

Graphics library for resource constrained embedded systems

Create a 2D rasterizer, rich drawing primitives, and 2D graphics library suitable for resource constrained embedded systems (e.g. ARM Cortex-M) to be used in industrial controls, home appliances, medical devices, consumer electronics, and IoT just to name a few. The end goal would be something similar to Segger's emWin. The library would be used to drive LDCs similar to https://www.adafruit.com/product/3396 Requirements:

  • Hardware agnostic; should simply render to a frame buffer
  • No dependencies (No Phobos, no C standard library, and no official D runtime).
  • Consider using -betterC, but a custom minimal D runtime is also a viable option

Related work:

DUB: D's package manager

DUB - D's package manager - is one of the central infrastructure tools in the D world as a convenient build and package management tool for the D community. With D gaining more and more popularity, it's also a key tool to guarantee D's further adoption. Thus there are many great ideas to improve DUB:

Multi IDE debugger support (for windows)

Mago, the debug engine used in VisualD, includes a tool called Mago-MI, which has a GDB compatible interface. Therefore, you can use Mago-MI on Windows as replacement for GDB. Several IDEs uses this feature to enable debugging with 1 code line for Windows/Linux/MacOS. It is used in an experimental state in IntelliJ. There is also support in Visual Studio Code and in DLangIDE for which it was originally built.

There are several issues which could be addressed in Symmetry Autumn of Code:

  • Mago-MI is written in C++. This makes bug fixing hard. Rewriting it in D might make sense.
  • While the installation of Mago-MI is easy if you want to debug OMF executables, it is very hard if you want to debug COFF executables. You need another executable from Mago, you have to register DLLs via regserv and you have to manually create a registry entry. An installation procedure for installing Mago-MI would be great.
  • As Visual Studio Code is already supported by the D Language Foundation, using this as a reference client of Mago-MI would make sense.

While this proposal seems only related to Windows, the nature of Mago-Mi is to enable IDEs having 1 code line for debugging on Windows/Linux/MacOS. Therefore, overall investment in this project is good for all platforms.

Convert DMD, DRuntime, and Phobos Makefiles to D

Building DMD, DRuntime, and Phobos on Windows is too cumbersome. It appears to require the user to first set up a Posix environment and then battle environment configuration and other vague dependencies such as whether you are building for 32-bit or 64-bit and whether Visual Studio is installed.

Sometimes there are bugs that only manifest themselves on Windows, so they need to be investigated in a Windows environment. To do that that we need to be able to build and troubleshoot dlang repositories on Windows without hassle.

It would be nice if the requirement for a Posix environment was removed by porting all Makefiles to D, so the same code (with appropriate versioning of course) could be used to compile and build dlang repositories on all platforms without a lot of environment setup and configuration. All that would be required would be a recent D compiler in one's PATH and D's intrinsic dependencies (e.g. a C standard library).

Work on this has already been started at https://github.com/dlang/dmd/pull/8293. It just needs to be taken to completion and duplicated to other dlang repositories (e.g. DRuntime and Phobos).

Re-implement Software Building Blocks (e.g. memcpy, memset, memcmp, malloc, free, etc.) in D

It is currently possible to dynamically set the length of an array in @safe, pure and nothrow D: 

void main() @safe pure nothrow
{
    int[] a;
    a.length = 10;  // No problem!
}

That code gets lowered to a runtime hook _d_arraysetlengthT. However that function is neither @safe, pure or nothrow. The compiler is being deceitful. This is just one of *many* such problems in the compiler/runtime interface.

Another problem with those runtime hooks is that they almost always require TypeInfo, a runtime entity. The primary reason for requiring TypeInfo is to get the size of the type. The size of the type is a value that is known at compile-time, so there is no need to defer obtaining that information to runtime, but the runtime hooks were created before D had templates and many other meta-programming facilities. The solution is to convert the runtime hooks to templates.

However, if a runtime hook is converted to a template, and the compiler lowers expressions to that template, then the code will be verified in the semantic pass of the compiler. That will force the the compiler to be honest; it will no longer be able to lie about @safe, pure and nothrow, as the semantic pass will verify it.

Unfortunately, this means that the runtime hooks (now templates) need to rewritten in a manner to ensure they are @safe, pure and nothrow. That is quite difficult as many of the software building blocks employed by implementation of those runtime hooks (e.g. memcpy, memset, and memcmp) are not written to be used in a memory-safe language. For example, to copy blocks of memory in D, one would likely use a function declared as void memcpy(T[] dest, const T[] src) not void* memcpy(void* dest, const void* src, size_t n).

Furthermore, those software building blocks are currently taken from the C standard library. The fact that D requires the C standard library is an artificial dependency. D, being a suitable alternative to C, should not need to rely on toolchains and libraries written in other languages. It might be expedient to leverage such implementations, but it is not good design as it prevents D from building freestanding software, and complicates the software development environment as it becomes necessary to obtain and configure a C toolchain in addition to a D toolchain.

Also, having the runtime hooks available as templates would allow the language features they implement to be used in -betterC code, as the implementation will be generated at compile-time; no longer requiring linking in a pre-compiled runtime implementation.

Therefore, to help address all of the issues above, it would be ideal to rewrite those software building blocks in @safe, pure, nothrow, typesafe, idiomatic D, so they can be used to implement the runtime hooks, compiler intrinsics, freestanding software, and more, while simplifying the development environment setup required to use D.

A preliminary investigation of implementing memcpy n D can be found at memcpyD.

malloc, free, and friends would be good candidates for this project as well. They may be able to take implementation details from std.experimental.allocator.

It may be more feasible to choose one of two of these building block functions to keep the project within the scope and duration of the event.

Retrieved from "https://wiki.dlang.org/?title=SAOC_2018_ideas&oldid=9272"