On Thursday, 6 August 2015 at 22:48:50 UTC, Tofu Ninja wrote:

> I really feel like D needs to get over it's "not invented here" syndrome, a much easier path would to just use a pre existing cross platform windowing library. Its laughable that the people in D want to reinvent this stuff. It's been done, just use the already working version! Why have all this great c and c++ interop if we never use it.
>
> I have the same gripe with how the experimental.image is doing image loading/saving, there are plenty of already existing image libraries that already support every image format you could ever dream of. Just use them, they will work 1000x better than any reinvention that we do here.

+1

If only the effort writing "native-D" reinvented unproven, untested wheels was spent writing quality D wrappers over existing proven and tested libraries....


bye,
lobo

On 7/08/2015 9:44 a.m., karabuta wrote:
> On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole wrote:
>> On 6/08/2015 12:05 p.m., Tofu Ninja wrote:
>>>> [...]
>
>>> [...]
>> Here is what we need to do going forward (beyond what me and Manu are
>> doing):
>>
>> [...]
>
> Don't you think that's a lot to ask from phobos?

Not really.
It's pretty rudimentary stuff.

Of course, I could add in e.g. a scenegraph, rasterizer (a postscript one could be VERY useful!).
Point being what I have listed are the most reusable and important to our ecosystem code we need to allow high reuse between libraries and to settle the age old problem of, 'we didn't create it'.

On 7/08/2015 3:01 p.m., lobo wrote:
> On Thursday, 6 August 2015 at 22:48:50 UTC, Tofu Ninja wrote:
>
>> I really feel like D needs to get over it's "not invented here"
>> syndrome, a much easier path would to just use a pre existing cross
>> platform windowing library. Its laughable that the people in D want to
>> reinvent this stuff. It's been done, just use the already working
>> version! Why have all this great c and c++ interop if we never use it.
>>
>> I have the same gripe with how the experimental.image is doing image
>> loading/saving, there are plenty of already existing image libraries
>> that already support every image format you could ever dream of. Just
>> use them, they will work 1000x better than any reinvention that we do
>> here.
>
> +1
>
> If only the effort writing "native-D" reinvented unproven, untested
> wheels was spent writing quality D wrappers over existing proven and
> tested libraries....

*whispers* Hey hey you. You want tests? Well here is something you'll like[0]. Oh and check out[1].

[0] http://www.libpng.org/pub/png/pngsuite.html
[1] http://forum.dlang.org/post/zxbexpwmirzdkewhqjyx@forum.dlang.org

On 7/08/2015 10:48 a.m., Tofu Ninja wrote:
> On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole wrote:
>> Here is what we need to do going forward (beyond what me and Manu are
>> doing):
>>
>> 1. Derelict-Util needs to be put into Phobos. This is not optional
>> 2. Derelict-GL3 needs to be put into Phobos. Optional, but might be a
>> damn good idea!
>> 3. Windows API needs to be moved into either Phobos or druntime. Not
>> optional.
>> 4. X11 bindings added to Phobos. Not optional.
>> 5. Cocoa bindings added to Phobos. Not optional.
>>
>> This all needs to happen _before_ we start working on a window library
>> for Phobos.
>> Let alone a GUI.
>>
>> We're mostly got problems with Cocoa. X11 bindings just need to be
>> changed to dynamically bound.
>>
>> Windows API bindings if gone into druntime wouldn't need to go through
>> the review cycle luckily. But would need some decent review on e.g.
>> Github.
>
> I really feel like D needs to get over it's "not invented here"
> syndrome, a much easier path would to just use a pre existing cross
> platform windowing library. Its laughable that the people in D want to
> reinvent this stuff. It's been done, just use the already working
> version! Why have all this great c and c++ interop if we never use it.
>
> I have the same gripe with how the experimental.image is doing image
> loading/saving, there are plenty of already existing image libraries
> that already support every image format you could ever dream of. Just
> use them, they will work 1000x better than any reinvention that we do here.

Ok, here is what I'm willing to do.
If you are willing to get Derelict-Util into Phobos and create the bindings for what ever (appropriate) c-library. I'm willing to create the wrappers around it to make it work with the interfaces.

My intention was these to become third party libraries via dub.

Please understand that I want a reasonable experience out of the box and not have the same situation we currently have with zlib/curl. Which means we do need 1 or 2 image file format implementations and per platform a single window/context implementation. It doesn't have to be flash or highly customizable. But it does need to work for most people.

On 07-Aug-2015 08:08, Rikki Cattermole wrote:
> On 7/08/2015 10:48 a.m., Tofu Ninja wrote:
>> On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole wrote:
>>> Here is what we need to do going forward (beyond what me and Manu are
>>> doing):
>>>
>>> 1. Derelict-Util needs to be put into Phobos. This is not optional
>>> 2. Derelict-GL3 needs to be put into Phobos. Optional, but might be a
>>> damn good idea!
>>> 3. Windows API needs to be moved into either Phobos or druntime. Not
>>> optional.
>>> 4. X11 bindings added to Phobos. Not optional.
>>> 5. Cocoa bindings added to Phobos. Not optional.
>>>
>>> This all needs to happen _before_ we start working on a window library
>>> for Phobos.
>>> Let alone a GUI.
>>>
>>> We're mostly got problems with Cocoa. X11 bindings just need to be
>>> changed to dynamically bound.
>>>
>>> Windows API bindings if gone into druntime wouldn't need to go through
>>> the review cycle luckily. But would need some decent review on e.g.
>>> Github.
>>
>> I really feel like D needs to get over it's "not invented here"
>> syndrome, a much easier path would to just use a pre existing cross
>> platform windowing library. Its laughable that the people in D want to
>> reinvent this stuff. It's been done, just use the already working
>> version! Why have all this great c and c++ interop if we never use it.
>>

Both are good ways. From what I see e.g. this attempts to add STL bindings to druntime:
https://github.com/D-Programming-Language/druntime/pull/1316

D brings enough to the table to warrant re-writing most of libraries. The result typically is smaller, faster and more general, of course, it still depends on author's skill. It's important to pick battles though, there are thousands of good libraries already out there.

>> I have the same gripe with how the experimental.image is doing image
>> loading/saving, there are plenty of already existing image libraries
>> that already support every image format you could ever dream of. Just
>> use them, they will work 1000x better than any reinvention that we do
>> here.
>
> Ok, here is what I'm willing to do.
> If you are willing to get Derelict-Util into Phobos and create the
> bindings for what ever (appropriate) c-library. I'm willing to create
> the wrappers around it to make it work with the interfaces.
>

Not likely to happen (soon). Nice loaders for shared libraries are something that Druntime would very much need, not sure if there is something else in Derelic-Util.

> My intention was these to become third party libraries via dub.
>
> Please understand that I want a reasonable experience out of the box and
> not have the same situation we currently have with zlib/curl.

Truth be told if we were willing to walk extra mile we'd have proper curl/zlib experience. But linking problems plague std.net.curl usage and both libs are permanently somewhat out of date.

> Which
> means we do need 1 or 2 image file format implementations and per
> platform a single window/context implementation. It doesn't have to be
> flash or highly customizable. But it does need to work for most people.


-- 
Dmitry Olshansky

On Friday, 7 August 2015 at 05:08:27 UTC, Rikki Cattermole wrote:
>
> Ok, here is what I'm willing to do.
> If you are willing to get Derelict-Util into Phobos and create the bindings for what ever (appropriate) c-library. I'm willing to create the wrappers around it to make it work with the interfaces.
>

Well we already have DerelictFI (FreeImage), but I completely disagree with the premise than having image loaders/savers is unworthy NIH. Dropping the number of dependencies is almost always worth it in my opinion.

On Friday, 7 August 2015 at 07:24:29 UTC, Dmitry Olshansky wrote:
> Truth be told if we were willing to walk extra mile we'd have proper curl/zlib experience. But linking problems plague std.net.curl usage and both libs are permanently somewhat out of date.

boost http is currently in review.

On Friday, 7 August 2015 at 08:25:04 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 7 August 2015 at 07:24:29 UTC, Dmitry Olshansky wrote:
>> Truth be told if we were willing to walk extra mile we'd have proper curl/zlib experience. But linking problems plague std.net.curl usage and both libs are permanently somewhat out of date.
>
> boost http is currently in review.

Does it's mean that std.net.curl would be replaced by it? Could you give link to discussion?

On 07-Aug-2015 11:39, Suliman wrote:
> On Friday, 7 August 2015 at 08:25:04 UTC, Ola Fosheim Grøstad wrote:
>> On Friday, 7 August 2015 at 07:24:29 UTC, Dmitry Olshansky wrote:
>>> Truth be told if we were willing to walk extra mile we'd have proper
>>> curl/zlib experience. But linking problems plague std.net.curl usage
>>> and both libs are permanently somewhat out of date.
>>
>> boost http is currently in review.
>
> Does it's mean that std.net.curl would be replaced by it? Could you give
> link to discussion?

I guess it's Boost C++ http. Certainly has nothing to do with D and anyhow porting the whole C++ Boost (even just the relevant parts) to D is quite an effort.

-- 
Dmitry Olshansky

On Friday, 7 August 2015 at 08:41:11 UTC, Dmitry Olshansky wrote:
> I guess it's Boost C++ http. Certainly has nothing to do with D and anyhow porting the whole C++ Boost (even just the relevant parts) to D is quite an effort.

It is relevant since Boost libraries often are precursors to C++ standards and Walter has been clear on C++ compatibility as a goal. So it would be a mistake to not look at Boost http before designing a pure D http interface.