DIP80: phobos additions

[Manu via Digitalmars-d]

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).