DIP80: phobos additions

[Rikki Cattermole via Digitalmars-d]

On 8/06/2015 4:12 p.m., Manu via Digitalmars-d wrote:
> On 8 June 2015 at 13:59, Rikki Cattermole via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 8/06/2015 3:53 p.m., Manu via Digitalmars-d wrote:
>>>
>>> On 8 June 2015 at 13:15, weaselcat via Digitalmars-d
>>> <digitalmars-d at puremagic.com> wrote:
>>>>
>>>> On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote:
>>>>>
>>>>>
>>>>> Phobos is awesome, the libs of go, python and rust only have better
>>>>> marketing.
>>>>> As discussed on dconf, phobos needs to become big and blow the rest out
>>>>> of
>>>>> the sky.
>>>>>
>>>>> http://wiki.dlang.org/DIP80
>>>>>
>>>>> lets get OT, please discuss
>>>>
>>>>
>>>>
>>>> I think a std.bindings or something similar for ubiquitous C libraries
>>>> would
>>>> go a long way - _quality_(not just a wrapper) SDL, OpenGL, etc bindings.
>>>>
>>>> D is very attractive to game developers, I think with a little push it
>>>> would
>>>> get a lot of traction from this.
>>>
>>>
>>> I've been humoring the idea of porting my engine to D. It's about 15
>>> years of development, better/cleaner than most proprietary engines
>>> I've used at game studios.
>>> I wonder if there would be interest in this? Problem is, I need all
>>> the cross compilers to exist before I pull the plug on the C code... a
>>> game engine is no good if it's not portable to all the consoles under
>>> the sun. That said, I think it would be a good case-study to get the
>>> cross compilers working against.
>>
>>
>> I'm definitely interested. Imagine getting something like that into phobos!
>> Would be utterly amazing for us.
>> Or atleast parts of it, once D-ified.
>
> I can't really see a place for many parts in phobos...
> large parts of it are hardware/platform abstraction; would depend on
> many system library bindings present in phobos.
>
>
>> Although might be worth doing tests using e.g. ldc to see how many platforms
>> you can actually get working.
>> Then perhaps an acceptance criteria before you port it?
>
> Yeah, it's a lot of work to do unit tests for parallel runtime systems
> that depend almost exclusively on user input or large bodies of
> external data... and where many of the outputs don't naturally
> feedback for analysis (render output, audio output). I can see a unit
> test framework being more code than most parts of the engine ;) .. not
> that it would be bad (it would be awesome!), I just can't imagine a
> simple/acceptable design.
> The thing I'm most happy about with Fuji is how relatively minimal it
> is (considering its scope and capability).

They would have to be manual tests.
So e.g. throws exceptions happily and uses threads kind of thing.
But where you load it up and run it.

It could help the ldc and gdc guys know what is still missing for this 
use case.