[dmd-internals] 3rd Biweekly Sprint Planning

[Iain Buclaw via dmd-internals]

On 10 August 2015 at 18:30, Martin Nowak via dmd-internals <
dmd-internals at puremagic.com> wrote:

> With the 2.068.0 out the door let's look ahead and plan the next 2 weeks.
>
> Small retro:
>
> Lot's of momentum in the final release phase just look at our done board
> (https://trello.com/b/XoFjxiqG/active, cards will get archived in 2
> days). Thanks to the many people helping out.
>
> Let's keep it that way for the next release, though we should spare the
> initial inertia (the release took more than 4 weeks).
>
> As a reminder 2.068.1 is due in 1 month, 2.069.0 in 2 month.
> I'm aiming for a 1 week beta period for point releases and 2 weeks for
> full releases, i.e. 3 weeks until 2.068.1-b1 and 6 weeks until 2.069.0-b1.
>
> Planning:
>
> There are a few leftover things from the release phase that we should
> handle before jumping on ddmd work.
>
> - Dropping -property waits for an offical OK from Walter
>   https://trello.com/c/1dQh4gxm/35-drop-property
>
> - Debug druntime tests wait for someone to look at FBSD
>   shared library guts
>   https://trello.com/c/zmsotPH2/20-fix-debug-druntime-tests-for-fbsd
>
> - There is some pending work on VS2015 support
>   https://trello.com/c/5OWcNIGy/33-vs2015-support
>
> - m32coff targets are here and simply need to be wired
>   with the release scripts
>   https://trello.com/c/al6RlkJP/44-mscoff32-libs-for-release
>
> - We hackfixed a mangling issue for mixins and lambdas
>   and need to come up with a proper solution.
>
>
> https://trello.com/c/YuW4JycJ/45-mangling-of-mixins-and-lambdas-can-change-w-unittest-or-other-versions
>
> - I noticed a few missing things while documenting the rangified functions.
>   https://trello.com/c/vC7GfbPA/46-follow-up-on-rangified-functions
>
> - I want to finish my WIP smart refs which didn't make it for 2.068.0
>   https://trello.com/c/pTlDuyBD/16-finish-smartref-implementation
>
> - The newly added compiler internal helper functions should get their
> own module or so instead of being appended to object.d
>
>
> https://trello.com/c/Vf4Gasoa/47-follow-up-on-compiler-internal-helper-module-and-arraydtor-error-messages
>
>
> DDMD:
>
> Regarding the ddmd switch I'd suggest to first make a spec story to
> understand and break down what needs to be done. We should closely
> coordinate this with people from the GDC and LDC team.
>
>
> https://trello.com/c/4NtxWDtK/48-ddmd-bootstraping-and-backwards-compatibility-guarantees
>
> Discussing this on dmd-internals seems like a good idea to me.
>
> Then we can schedule whatever tasks fall out of the discussion for this
> and the next sprint.
>
>
- Do we need to keep ddmd working with 2.068?

For the time being, yes, and for as long as possible.

I'd like to see continual bug fix releases incase anything slipped into
2.067 or 2.068 that broke GDC or LDC's any part of their interface, codegen
or strictly-typed backend.  (See for instance, PRs 4062, 4075, 4077, 4212,
and probably many more just to get 2.066 working).


- When will gdc and ldc catch up and switch to a self-hosted frontend.

No set time on my side.  Currently I'm doing what is effectively a 70-80%
rewrite of all codegen.  Eg: This is for the complete removal of the
IRState definition from our glue.

https://github.com/D-Programming-GDC/GDC/commit/f7ad1ef43021e95eb4af387fa1cf300f9da856b9

I've written up a wiki (both myself and Johannes are crossing things off as
we complete them):

http://wiki.dlang.org/GDC/CurrentReleaseTasks


- Any bootstrap strategies for cross compiling?

Initially, use 2.068 as baseline, then bootstrap with the later versions
(written in D).  This could be integrated into the GCC build without too
much hassle, as they themselves have a three-stage build+bootstrap process.

I'm admittedly worried that this will block any work I'm doing with
upstream GCC.  In my most ideal case, I'd want 2.068 merged into the GCC
ecosystem, then have it trickled down into all major vendors in whatever
major release we end up being shipped in before switching.  This gives
distributors the best opportunity to manage building the self-hosted
sources without running into an impossible Catch-22 situation.

Debian/Ubuntu are currently in the best position as the maintainer has
kindly integrated GDC into the GCC binaries (albeit with favours):

https://packages.debian.org/sid/gdc-5

I would like to see libphobos (or at least libdruntime) being made
available for more targets though.

Current list is: [amd64, armel, armhf, i386, x32]


- How to test compatibility?

Compatibility with what?  ARM? SPARC? PPC?  Communicating across C++ <-> D?


Regards
Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20150810/2470a3c3/attachment.html>