[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