On 07-Aug-2015 12:16, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> 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.
>

Already have that it's called vibe.d. There must be other stuff floating around as well (e.g.Adam's tiny http server).

-- 
Dmitry Olshansky

On Friday, 7 August 2015 at 09:43:13 UTC, Dmitry Olshansky wrote:
> Already have that it's called vibe.d. There must be other stuff floating around as well (e.g.Adam's tiny http server).

That's not what I mean. I mean being able to interface with C++ counterparts in general. E.g. use the same structures, enums, etc on both sides.

On 8/6/15 6:48 PM, 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.

I agree (though I don't know much about which library would be the best choice), at least on the basis of scarce resources. Large ambitious projects are a lot more fun to start than complete. -- Andrei

On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu wrote:
> On 8/6/15 6:48 PM, 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.
>
> I agree (though I don't know much about which library would be the best choice), at least on the basis of scarce resources. Large ambitious projects are a lot more fun to start than complete. -- Andrei

Bare windowing libraries that are well tested already exist, like GLFW.

On 8/08/2015 1:07 a.m., rsw0x wrote:
> On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu wrote:
>> On 8/6/15 6:48 PM, 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.
>>
>> I agree (though I don't know much about which library would be the
>> best choice), at least on the basis of scarce resources. Large
>> ambitious projects are a lot more fun to start than complete. -- Andrei
>
> Bare windowing libraries that are well tested already exist, like GLFW.

To be fare, the most difficult part about a windowing library, is to make it behave identically on all platforms.
For a Phobos out of the box implementation, we only need to get it close enough that programs can use it for prototyping.

For anything serious, something like GLFW is definitely a better option. As long as we keep it well known about this and a migration path that isn't at all hard, I see no problem with doing this.

On Friday, 7 August 2015 at 13:07:59 UTC, rsw0x wrote:
> On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu wrote:
>> On 8/6/15 6:48 PM, 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.
>>
>> I agree (though I don't know much about which library would be the best choice), at least on the basis of scarce resources. Large ambitious projects are a lot more fun to start than complete. -- Andrei
>
> Bare windowing libraries that are well tested already exist, like GLFW.

+1

On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu wrote:
> On 8/6/15 6:48 PM, 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.
>
> I agree (though I don't know much about which library would be the best choice), at least on the basis of scarce resources. Large ambitious projects are a lot more fun to start than complete. -- Andrei

The problem is that we get caught up with the API.

The way forward that makes the most sense IMO, is to design some nice API and use whatever already exists behind. Less work, without the lock in.

On 07/08/15 00:48, 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.

A bit more than a windowing library [1]

[1] https://github.com/d-widget-toolkit/dwt

-- 
/Jacob Carlborg

On Friday, 7 August 2015 at 17:40:16 UTC, deadalnix wrote:
>
> The problem is that we get caught up with the API.
>
> The way forward that makes the most sense IMO, is to design some nice API and use whatever already exists behind. Less work, without the lock in.

I wouldn't think what you're saying is controversial...just a lot of work to do well.

I imagine what you're saying as a two-step process: 1) Get a library working with D, 2) Write a "nice API". I would likely get stuck on the first one before even getting to the second, but I wouldn't want to bore you with how confusing I find the documentation on interfacing to C.

Anyway, I was thinking that magicport seems to be very important the process of creating ddmd. I would think we should be able to leverage this work for interfacing with C. In particular, interfacing with C requires the transformation of .h files to .di files. My assumption is that magicport is capable of converting lots of C++ files to D files, although my recollection of Daniel Murphy's talk is that there are some cases where it does not work perfectly and he has to adjust things manually. Regardless, if it works for C++, it should work for C, maybe even better since C is less complicated. So maybe magicport can be used to make it easier to get C libraries working with D. Then, you would just need to focus on writing the APIs.

On Friday, 7 August 2015 at 20:24:54 UTC, jmh530 wrote:
>
> Anyway, I was thinking that magicport seems to be very important the process of creating ddmd. I would think we should be able to leverage this work for interfacing with C. In particular, interfacing with C requires the transformation of .h files to .di files. My assumption is that magicport is capable of converting lots of C++ files to D files, although my recollection of Daniel Murphy's talk is that there are some cases where it does not work perfectly and he has to adjust things manually. Regardless, if it works for C++, it should work for C, maybe even better since C is less complicated. So maybe magicport can be used to make it easier to get C libraries working with D. Then, you would just need to focus on writing the APIs.

We already have htod and DStep.