Move VisualD to github/d-programming-language ?

[Rainer Schuetze]

On 24.09.2013 21:31, Andrei Alexandrescu wrote:
> On 9/24/13 11:19 AM, Rainer Schuetze wrote:
>>
>>
>> On 24.09.2013 19:16, Andrei Alexandrescu wrote:
>>> On 9/22/13 7:05 AM, Rainer Schuetze wrote:
>>>> Should we add links to Mono-D and DDT aswell?
>>>
>>> I think so.
>>>
>>
>> Ok, will add these. Bruno and Alex, is it ok for you? What are the
>> appropriate links? Are there any direct download links?
>
> Thanks very much for leading this.
>
>>>> Links are still to other sites, how do we get the installer and the
>>>> Visual D pages uploaded to dlang.org?
>>
>>>
>>> Walter, Brad, or I need to do the upload for now (we're working on
>>> improving the process). What you'd need to do is just create pull
>>> requests for the site and the installer. Once pulled, we'll build and
>>> upload.
>>>
>>
>> Do you mean that I should add the documentation to the dlang.org
>> repository? It's currently part of the visuald repository, and it could
>> also be referred to by the makefile in dlang.org, but that might mean
>> that people building that will also have to clone the visuald repository.
>
> I preapprove any pages that refer exclusively to Visual D in the
> dlang.org repo. I trust you to design and write them within the site
> look and feel, and to organize them in directories appropriately.
>
> Alternatively, if you prefer to distinguish Visual D's identity, feel
> free to keep your own site and pages for it. I'd personally prefer
> integration - we're small enough to thrive on integration.

The documentation has already been converted to ddoc and can be seen 
here: http://rainers.github.io/visuald/visuald/StartPage.html

I'll see how these can be intgrated with the dlang.org makefiles.

>
>> Regarding the installer: Visual D should be built with a precise GC, but
>> that's currently only possible with a patched compiler and runtime. I'll
>> have to provide the binaries somehow, but I think git isn't appropriate
>> to do so.
>
> Hmmm, where's that effort right now? The fact that we have a serious
> application needing precise GC is a good argument to make it the
> default, or at least an easy to choose option.

One big issue with it is correct RTInfo generation. I've made an attempt 
to fix the compiler ( 
https://github.com/D-Programming-Language/dmd/pull/2480 ), but that 
didn't get any reviews so far.

Druntime patches are here: 
https://github.com/rainers/druntime/tree/gcx_precise but they break the 
test suite without the patch above.

In addition something has to be done about specifying type info for the 
data segment. I have some compiler/druntime patches for that, but they 
are specific to the OMF file format so far. Some general solution would 
be better.