dawg

Give git-autofixup a try, never had any incorrect fixup targets with it's hunk-based algorithm.

Same workflow here, and it's become a breeze with autofix, rebase --update-refs, and a small command to push the whole stack. I'm using magit, so I directly see what could not be matched and remains staged.

Yes, I empirically found the hunk-based approach of git autofixup to work more reliably. I use it via magit. Paired with rebase --update-refs, it's particularly helpful to automatically fixup stacked branches.

This approach is taken by https://github.com/dlang-community/drepl and https://docs.scala-lang.org/overviews/repl/overview.html. While it works surprisingly well, you need to parse and transform the REPL input to emulate some language constructs in the right scope.

Installer and binaries have been signed and submitted to Microsoft since a while to fix the issue with Windows Defender. https://dlang.org/changelog/2.082.0.html#signed_windows_bina...

Neither the last release nor the recent release candidate have been flagged by any AV according to VirusTotal. https://www.virustotal.com/#/file/e2ea2807faf41978a842f91890... https://www.virustotal.com/#/file/834d7547d395cc4080ab28a177...

Dmd releases have been signed and submitted to Microsoft since 2.082.0 to fix the issue with Windows Defender.

https://dlang.org/changelog/2.082.0.html#signed_windows_bina...

And this short snippet in D

    T max(T)(T a, T b) { return a < b ? b : a; }

without requiring explicit constexpr annotations and with less noisy template syntax ;).

For emacs it might be OK, usually mutating objects in the heap during marking is not a good idea, as it breaks sharing CoW pages with forks.

Did sth. similar a while ago for our not so great D GC. https://github.com/dlang/druntime/pull/1073

You loose builtin arrays and hashes and need to use a container library instead. Same goes for newing aggegates which can be replaced with smart pointers. Escaping closures (delegates) no longer works, but you can explicitly capture context in a struct.

Those choices for builtin language features date back to the early inspiration from Java, but are increasingly being replaced with library implementations. We've added escape checking to the type system last year, and are currently working on safe aliasing (preventing use-after-free).

So yes, atm. when opting for @nogc you're somewhat at the frontier, and it's mostly a choice if you have time, hard requirements, or am very practised.

Avoiding most (but not all) GC allocations is already widely adopted in D's community though.

You don't have to restrict yourself to betterC to use manual memory management. BetterC is mainly targetted at embedded programming and to port components of existing C applications. Malloc vs. GC vs. stdx-allocator is a separate topic, though betterC doesn't link with the GC by default.

In D which has CTFE support since ages, you'd debug such functions by invoking them at runtime. https://tour.dlang.org/tour/en/gems/compile-time-function-ev... There are also tools to print values at compile time.

A compile time debugger for the CTFE interpreter is on our extended feature list for the current interpreter rewrite, but it's less of a priority atm.

Yes, if you're willing to spent some effort on it. Somewhat simpler you can just avoid most GC allocations so you don't run into any performance issues with the GC. http://dlang.org/blog/the-gc-series/

Mind to share why a GC seems to be unaccceptable for you?

The D language is currently heading towards deterministic and safe memory management, making it possible to avoid the GC overall, hence further work on GC improvements was deprioritized. http://dlang.org/blog/2017/06/16/life-in-the-fast-lane/

The problems are known and indeed a full rewrite on this ancient GC would be in order. Since D 2.072.0 it's possible to link and use different GCs, so a faster one could be written as an external library which would be a very welcome effort. https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-ad...

I'd be interested in experimenting with a Connectivity-Based GC (https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf), leveraging type information to do partial collections. Write barriers come with a performance penalty (~3-5%) that we don't want to impose on people using deterministic memory management, but most GCs capable of performing partial collections, e.g. generational GCs, do require write barriers, Connectivity-Based GCs do not.

For the time being the pragmatic advise is to replace major sources of GC allocations with deterministic memory management when the GC heap grows too big (~1GB) and performance becomes a problem.

So far this hasn't prevented various people from writing extremely fast D programs.

Here is the archive.org link (requires an account) https://archive.org/details/LundukeHourApril14RMS.