On Friday, 23 November 2012 at 21:15:00 UTC, Walter Bright wrote:
> On 11/23/2012 3:46 AM, Gor Gyolchanyan wrote:
>> I hope the deimos folks make a repo soon, so that people can use those modules
>> as soon as possible, because I'll finish translating them today.
>
> https://github.com/D-Programming-Deimos/OpenGL

Will the library "etc" bindings (curl, sqlite3, zlib) be moved over to separate repos for Deimos?

--rt

Sent a pull request for the C headers and fully translated glcorearb.d.


On Sat, Nov 24, 2012 at 2:08 AM, Rob T <rob@ucora.com> wrote:

> On Friday, 23 November 2012 at 21:15:00 UTC, Walter Bright wrote:
>
>> On 11/23/2012 3:46 AM, Gor Gyolchanyan wrote:
>>
>>> I hope the deimos folks make a repo soon, so that people can use those
>>> modules
>>> as soon as possible, because I'll finish translating them today.
>>>
>>
>> https://github.com/D-**Programming-Deimos/OpenGL<https://github.com/D-Programming-Deimos/OpenGL>
>>
>
> Will the library "etc" bindings (curl, sqlite3, zlib) be moved over to
> separate repos for Deimos?
>
> --rt
>
>


-- 
Bye,
Gor Gyolchanyan.

On Friday, November 23, 2012 15:15:41 Gor Gyolchanyan wrote:
> As we all know, the WinAPI binding in druntime as well as the static libraries of WinAPI, which come with DMD are in horrendous state.

I am not all that well acquainted with all of the issues involved with the Win32 API, so I'm probably not the best qualified to chime in on how they should be handled. However, I would point out that given that the Win32 API is effectively the system layer API for Windows, it should be fully supported in druntime (just like glibc should be fully supported for Linux by druntime), and as Walter points out, such a layer should be thin rather than trying to fix anything (that's the job of Phobos or other wrapper libraries). And since we're about to have 64-bit Windows support, druntime should be updated with whatever C prototypes are in the 64-bit Windows API (and I really don't know how those relate to the Win32 API other than the fact that as I understand it, 64-bit Windows still uses some version of the Win32 API).

So, I would hope that the various Windows Gurus around here could come to an agreement on how the Windows API bindings should be put into druntime and then someone (or several someones) would take the time to implement that. I don't think that we should continue with the approach that anyone doing anything serious with the Win32 API has to use a 3rd party project to do it. OS-level functions should be part of druntime for every OS that we support, and it's worthy of a bug report every time that we find an OS-level function that is not in druntime.

- Jonathan M Davis

That was my point. Current WinAPI binding in druntime is not as clean and thin as it could and should be. Not to mention, that it's very very lacking.


On Sat, Nov 24, 2012 at 3:08 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Friday, November 23, 2012 15:15:41 Gor Gyolchanyan wrote:
> > As we all know, the WinAPI binding in druntime as well as the static libraries of WinAPI, which come with DMD are in horrendous state.
>
> I am not all that well acquainted with all of the issues involved with the
> Win32 API, so I'm probably not the best qualified to chime in on how they
> should be handled. However, I would point out that given that the Win32
> API is
> effectively the system layer API for Windows, it should be fully supported
> in
> druntime (just like glibc should be fully supported for Linux by druntime),
> and as Walter points out, such a layer should be thin rather than trying
> to fix
> anything (that's the job of Phobos or other wrapper libraries). And since
> we're about to have 64-bit Windows support, druntime should be updated with
> whatever C prototypes are in the 64-bit Windows API (and I really don't
> know
> how those relate to the Win32 API other than the fact that as I understand
> it,
> 64-bit Windows still uses some version of the Win32 API).
>
> So, I would hope that the various Windows Gurus around here could come to
> an
> agreement on how the Windows API bindings should be put into druntime and
> then
> someone (or several someones) would take the time to implement that. I
> don't
> think that we should continue with the approach that anyone doing anything
> serious with the Win32 API has to use a 3rd party project to do it.
> OS-level
> functions should be part of druntime for every OS that we support, and it's
> worthy of a bug report every time that we find an OS-level function that
> is not
> in druntime.
>
> - Jonathan M Davis
>



-- 
Bye,
Gor Gyolchanyan.

On Friday, 23 November 2012 at 21:21:49 UTC, Walter Bright wrote:
> On 11/23/2012 5:57 AM, Vladimir Panteleev wrote:
>> There might be some incompatibilities, for example due to how the HANDLE type is
>> declared. In C, you can use either 0 or NULL as a parameter to a function
>> accepting an integer or pointer. In D, you cannot. IIRC, some types were
>> declared differently in Druntime's modules and in the win32 bindings.
>>
>> If breaking code were not an issue, the best solution would be to make HANDLE a
>> unique, opaque type (like a struct wrapping an intptr_t or void*) - which is
>> exactly how it should be treated. It would need to support assignment/creation
>> from "null" though.
>
> This is why I don't approve of attempts to "fix" Windows APIs. It winds up being incompatible here and there, and breaks things.

I don't think I follow the logic of this argument.

Let's say that Phobos had a templated function that, by mistake, accepted arguments at compile-time the types of which made no sense for said function.

Should the bug be fixed, even though it would break compilation of code most of which used incorrect invocations of that function? Or should the bug be kept, because fixing it would break compilation of code that relied on the bug?

If the analogy is invalid, what is the exact problem with changing HANDLE's type? How much real correct code would break? How does the inconvenience of forcing users to add a few casts compare to making it easy to accidentally mix HANDLEs with other opaque types and pointers in general?

I should point out that some functions (e.g. GlobalLock, IIRC) take a value, and return the exact same value, but with another type. This forces the user to use the function as a "gate", lest they erroneously use the value directly. Using weak typing makes it too easy to e.g. assign an unlocked memory region to a pointer.

On 11/23/2012 2:08 PM, Rob T wrote:
> On Friday, 23 November 2012 at 21:15:00 UTC, Walter Bright wrote:
>> On 11/23/2012 3:46 AM, Gor Gyolchanyan wrote:
>>> I hope the deimos folks make a repo soon, so that people can use those modules
>>> as soon as possible, because I'll finish translating them today.
>>
>> https://github.com/D-Programming-Deimos/OpenGL
>
> Will the library "etc" bindings (curl, sqlite3, zlib) be moved over to separate
> repos for Deimos?

Probably not.

On Saturday, 24 November 2012 at 01:52:41 UTC, Walter Bright wrote:
> On 11/23/2012 2:08 PM, Rob T wrote:
>> Will the library "etc" bindings (curl, sqlite3, zlib) be moved over to separate
>> repos for Deimos?
>
> Probably not.

I don't know what the plan is for etc, or the what the reasoning is behind leaving a few odd bindings in etc. Etc seemed like a good candidate to be replaced by deimos.

Can you elaborate a bit on this, that would help me to understand better what needs to be done. Thanks!

--rt

On 11/23/2012 6:13 PM, Rob T wrote:
> On Saturday, 24 November 2012 at 01:52:41 UTC, Walter Bright wrote:
>> On 11/23/2012 2:08 PM, Rob T wrote:
>>> Will the library "etc" bindings (curl, sqlite3, zlib) be moved over to separate
>>> repos for Deimos?
>>
>> Probably not.
>
> I don't know what the plan is for etc, or the what the reasoning is behind
> leaving a few odd bindings in etc. Etc seemed like a good candidate to be
> replaced by deimos.
>
> Can you elaborate a bit on this, that would help me to understand better what
> needs to be done. Thanks!

etc is for stuff to be included in the D distribution.

On 11/23/2012 5:06 PM, Vladimir Panteleev wrote:
> On Friday, 23 November 2012 at 21:21:49 UTC, Walter Bright wrote:
>> On 11/23/2012 5:57 AM, Vladimir Panteleev wrote:
>>> There might be some incompatibilities, for example due to how the HANDLE type is
>>> declared. In C, you can use either 0 or NULL as a parameter to a function
>>> accepting an integer or pointer. In D, you cannot. IIRC, some types were
>>> declared differently in Druntime's modules and in the win32 bindings.
>>>
>>> If breaking code were not an issue, the best solution would be to make HANDLE a
>>> unique, opaque type (like a struct wrapping an intptr_t or void*) - which is
>>> exactly how it should be treated. It would need to support assignment/creation
>>> from "null" though.
>>
>> This is why I don't approve of attempts to "fix" Windows APIs. It winds up
>> being incompatible here and there, and breaks things.
>
> I don't think I follow the logic of this argument.

Because if we take on the task of "fixing" Windows APIs, then we also take on the task of documenting them, supporting them, educating people about them, and invalidating the river of documentation that already exists on how to program via the Windows APIs.

On Saturday, 24 November 2012 at 07:23:18 UTC, Walter Bright wrote:
> On 11/23/2012 5:06 PM, Vladimir Panteleev wrote:
>> On Friday, 23 November 2012 at 21:21:49 UTC, Walter Bright wrote:
>>> On 11/23/2012 5:57 AM, Vladimir Panteleev wrote:
>>>> There might be some incompatibilities, for example due to how the HANDLE type is
>>>> declared. In C, you can use either 0 or NULL as a parameter to a function
>>>> accepting an integer or pointer. In D, you cannot. IIRC, some types were
>>>> declared differently in Druntime's modules and in the win32 bindings.
>>>>
>>>> If breaking code were not an issue, the best solution would be to make HANDLE a
>>>> unique, opaque type (like a struct wrapping an intptr_t or void*) - which is
>>>> exactly how it should be treated. It would need to support assignment/creation
>>>> from "null" though.
>>>
>>> This is why I don't approve of attempts to "fix" Windows APIs. It winds up
>>> being incompatible here and there, and breaks things.
>>
>> I don't think I follow the logic of this argument.
>
> Because if we take on the task of "fixing" Windows APIs, then we also take on the task of documenting them, supporting them, educating people about them, and invalidating the river of documentation that already exists on how to program via the Windows APIs.

I don't think strong typing for HANDLE affects any of the above. I believe all MS examples use casts for clarification of intent even when the conversion would've been implicit.