[dmd-internals] 8th Sprint Planning

Andrei Alexandrescu via dmd-internals dmd-internals at puremagic.com
Tue Oct 27 14:45:22 PDT 2015


On 10/27/2015 06:15 AM, Martin Nowak via dmd-internals wrote:
> Again I'd like to see 313&314 being fixed b/c any delay on that makes it
> more painful to fix later on. As this change has a big impact we all
> need to agree on the direction and should start the work as early as
> possible in the next release cycle.
> https://trello.com/c/YoAFvV5n/6-313-314

I'd very much want to get Walter's 100% approval on this. We seem to 
have a growing complexity problem in that overly complicated solutions 
are being pushed that nobody but their author understands and reviews 
properly. They don't get enough review and change the language in 
intractable ways.

Same is happening with the library, as I mentioned discussing the 
DirEntry regression aftermath. (Another historical example: the @trusted 
morass.) Mechanical, large, non-scalable changes are pushed following a 
too literal interpretation of desirable points (such as "don't break 
backwards compatibility") yet at the cost of long-term crucial goals, 
such as preserving the spirit of the language and a sense and 
sensibility in its standard library.

Please run absolutely all important changes of the standard library by 
me personally. Email me - I address all of my emails, albeit with 
delays. If urgent email me again. I'm also on skype at 
andrei.tudor.alexandrescu. Thanks.

Also, I'm thinking we should pass all new names through std.experimental 
- thoughts? For a random example: 
https://github.com/D-Programming-Language/phobos/pull/3765. Looks like a 
sensible addition, but I'd want us all to get disciplined about vetting 
additions before committing to maintaining them forever.

> A lot of GC work remains and I'd like to get back on that in 2-3 weeks.
> https://trello.com/c/Xp44NwHG/87-ttas-spinlock-for-gc
> https://trello.com/c/K7HrSnwo/28-thread-cache-for-gc
> https://trello.com/c/Dsdxd1r3/56-ptr-data-section
> https://trello.com/c/0WxZP9KL/11-freelist-for-large-objects

These look great. Also, there's a lot of stuff of interest in 
std.experimental.allocator that I'd want to integrate with the GC. To 
that end, we need to make the GC more statically modular so we get to 
plug in various allocation strategies. Do you have an image of what can 
be done for better integration?

> # Plans for the next sprint:
>
> For the next 2 weeks I want to finish the work on slist_reset
> (https://trello.com/c/qMjMxduV/98-optimize-slist-reset) which speeds up
> static library compilation by about 20%. Hope that only a small OSX
> issue remains.

Awesome. BTW what's the status of dynamic libraries on the three major 
OSs? I'm sorry, that topic has been out of my mind for a while so I lost 
contact with the matters.

> Other than that I want to focus on finishing the smart refs
> implementation
> (https://trello.com/c/pTlDuyBD/16-finish-smartref-implementation). I've
> decided to do this in the form of a new std.experimental module rather
> than breaking any of the existing std.typecons implementations. We're
> still in need of a good name for that module.
>
> planned feature list:
>
> - RC/WeakRef/Unique
> - full support for polymorphism (and RC for interfaces)
> - only shared(RC) uses atomic ref counting
> - full attribute inference
> - support for allocators (defaulting Mallocator)
> - message passing for Unique (if the payload doesn't alias anything mutable)
>
> ...your plans...

Oddly enough I want to dissuade you from doing RC - per my post "Safe 
reference counting cannot be implemented as a library" it's impossible 
to make library-level RC safe, which decreases its interest 
dramatically. We plan to do language-level reference counting, which, if 
we succeed, would obviate any RC library for classes.

However, working on uniqueness is great! We'll either see how far we can 
get within the current language, or figure the minimal language 
additions needed to make it work.

For message passing, TDPL mentions a UniqueArray that can be passed 
across threads but has not been yet implemented.


Thanks,

Andrei


More information about the dmd-internals mailing list