On Friday, 23 November 2012 at 11:57:19 UTC, Gor Gyolchanyan wrote:
> Derelict doesn't define extern functions and includes tons of code for
> dynamic loading. It's not a direct translation and since I'm aiming for
> deimos, I need to make a direct translation.

Well, I wouldn't call it tons of code! And it *is* a direct translation. The OpenGL headers can be configured to declare function pointers. At any rate, I think it wouldn't take much to cobble together a script to transform the function pointer declarations in Derelict to the static style. The constants can be copied and used as is.

You'll still need to use function pointers on Windows for anything above and including OpenGL 1.2, though, unless there's a way to statically link OpenGL on Windows systems now that I'm not aware of.

With a little work the bindings worked for me as well, but they aren't fit
for druntime.
also, they don't aim to preserve the interface as it is.


On Fri, Nov 23, 2012 at 3:52 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com
> wrote:

> On 11/23/12, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
> > 2. It uses version identifiers to determine the, you guessed it, version
> of
> > Windows in question. This is very bad, since it won't compile without at least some version identifiers and I'm sure we can make the OS version available at compile-time to obviate the need for those version identifiers.
>
> The identifiers you typically need to pass is the unicode and windows
> specs, e.g.:
> -version=Unicode -version=WindowsXP
>
> The reason you need to pass the Windows version is because you might want to limit compilation to only certain platforms.
>
> The bindings work ok for me, here's one project where I use them: https://github.com/AndrejMitrovic/DWinProgramming
>



-- 
Bye,
Gor Gyolchanyan.

It'll take more time trying to extract stuff from Derelict, rather then regexp search/replace -ing the headers.

There's always a way to statically link. The original headers define extern
functions.
If the static library doesn't exist yet, it;'s very easy to make and have
it dynamically load the symbols.


On Fri, Nov 23, 2012 at 4:06 PM, Mike Parker <aldacron@gmail.com> wrote:

> On Friday, 23 November 2012 at 11:57:19 UTC, Gor Gyolchanyan wrote:
>
>> Derelict doesn't define extern functions and includes tons of code for dynamic loading. It's not a direct translation and since I'm aiming for deimos, I need to make a direct translation.
>>
>
> Well, I wouldn't call it tons of code! And it *is* a direct translation. The OpenGL headers can be configured to declare function pointers. At any rate, I think it wouldn't take much to cobble together a script to transform the function pointer declarations in Derelict to the static style. The constants can be copied and used as is.
>
> You'll still need to use function pointers on Windows for anything above and including OpenGL 1.2, though, unless there's a way to statically link OpenGL on Windows systems now that I'm not aware of.
>



-- 
Bye,
Gor Gyolchanyan.

On 11/23/12, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
> It'll take more time trying to extract stuff from Derelict, rather then regexp search/replace -ing the headers.

You really believe that your regex script is going to do a better job than what Mike has been using and maintaining for years? The same applies to WinAPI, these bindings have been developed and used in years. Introducing new bindings to the same APIs which aren't compatible with existing bindings is just going to create compatibility issues when you use multiple libraries, and it's going to create confusion for new users.

Instead of trying to reinvent, why not just contribute to the existing bindings if they're missing functionality or some of their code is outdated?

I'll also say that IMO the concept of Deimos turns out to be a bad idea, and I'm not alone in thinking this. Only few people have write access, which means all pull requests have to go through a handful of people who may not even know what the code in the bindings does, and if the devs aren't around you'll have to wait days or even months (see dmd/druntime/phobos) for a pull to be merged. Now some projects use module names without a root (module curses), others encode the deimos name (module deimos.zmq.utils), and then others use their own encoding (module libexif.exif_byte_order).

And then you have Walter which merges all pull requests without any review whatsoever. Deimos should have been a wiki page that lists active bindings. And each binding project would have a maintainer or a team of maintainers (who would review pull requests properly). And that's it.

(Disclosure: I contributed to this project)

The Win32 bindings are excellent. I believe your points are invalid.

On Friday, 23 November 2012 at 11:43:21 UTC, Gor Gyolchanyan wrote:
> 1. It has some pragma(lib, ...) declarations which aren't being met and
> which assume some things, that aren't true.

The libraries are here:
http://dsource.org/projects/bindings/browser/trunk/lib

And the definition files for these libraries are here:
http://dsource.org/projects/bindings/browser/trunk/def

> 2. It uses version identifiers to determine the, you guessed it, version of
> Windows in question. This is very bad, since it won't compile without at
> least some version identifiers

This is how the C headers work. The targeted Windows version is a preprocessor define.

It compiles just fine without any version identifiers, but it will target an old Windows version (95 or 98).

> and I'm sure we can make the OS version
> available at compile-time to obviate the need for those version identifiers.

This is a horrible idea. YOU ARE NOT TARGETING THE ENVIRONMENT YOU ARE BUILDING FROM!

> 3. It includes tons of obsolete stuff, that cannot and will not be used
> ever, which are hard to track down and extract.

These headers have a long development history and are generally rather polished. You are suggesting to throw away all that and replacing them with something of your own?

Derelict is not a direct binding it contains lots of tools to automatically load symbols from DLLs and call library initialization and finalization routines. That takes a while to make. Direct translations do not change anything and do not add anything. When done correctly (checked by compiling it) the code cannot be broken, since the underlying API is already tested by the respective developers.

I'll look into the opportunity to refactor the dsource.org WinAPI binding, because it's much closer to reality then Derelict. In that case It'll take a few hours to finish (quite fast). Would you suggest me to send a pull request to druntime with the new modules? How long will it take to be merged?

If the only problem with Deimos is the speed at which libraries end up there, why not make the review process more loose and allow the code to be submitted and then fixed as necessary? It would be much more useful, then just having nothing at all.


On Fri, Nov 23, 2012 at 4:56 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com
> wrote:

> On 11/23/12, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
> > It'll take more time trying to extract stuff from Derelict, rather then regexp search/replace -ing the headers.
>
> You really believe that your regex script is going to do a better job than what Mike has been using and maintaining for years? The same applies to WinAPI, these bindings have been developed and used in years. Introducing new bindings to the same APIs which aren't compatible with existing bindings is just going to create compatibility issues when you use multiple libraries, and it's going to create confusion for new users.
>
> Instead of trying to reinvent, why not just contribute to the existing bindings if they're missing functionality or some of their code is outdated?
>
> I'll also say that IMO the concept of Deimos turns out to be a bad idea, and I'm not alone in thinking this. Only few people have write access, which means all pull requests have to go through a handful of people who may not even know what the code in the bindings does, and if the devs aren't around you'll have to wait days or even months (see dmd/druntime/phobos) for a pull to be merged. Now some projects use module names without a root (module curses), others encode the deimos name (module deimos.zmq.utils), and then others use their own encoding (module libexif.exif_byte_order).
>
> And then you have Walter which merges all pull requests without any review whatsoever. Deimos should have been a wiki page that lists active bindings. And each binding project would have a maintainer or a team of maintainers (who would review pull requests properly). And that's it.
>



-- 
Bye,
Gor Gyolchanyan.

I agree, that WinAPI binding from dsource.org is very close to what needs to be in druntime. I'll look into it. That's why I decided to bind the OpenGL headers first (because it needs manual binding more, then WinAPI). Derelict is heavily packed with auxilliary stuff, that makes the everyday use of OpenGL quite easy, but it's not a direct translation and has some overhead. And the OpenGl headers are FAR FAR FAR simpler and smaller then WinAPI ones. I'm half-way through with OpenGL.


On Fri, Nov 23, 2012 at 5:09 PM, Vladimir Panteleev < vladimir@thecybershadow.net> wrote:

> (Disclosure: I contributed to this project)
>
> The Win32 bindings are excellent. I believe your points are invalid.
>
>
> On Friday, 23 November 2012 at 11:43:21 UTC, Gor Gyolchanyan wrote:
>
>> 1. It has some pragma(lib, ...) declarations which aren't being met and which assume some things, that aren't true.
>>
>
> The libraries are here: http://dsource.org/projects/**bindings/browser/trunk/lib<http://dsource.org/projects/bindings/browser/trunk/lib>
>
> And the definition files for these libraries are here: http://dsource.org/projects/**bindings/browser/trunk/def<http://dsource.org/projects/bindings/browser/trunk/def>
>
>
>  2. It uses version identifiers to determine the, you guessed it, version
>> of
>> Windows in question. This is very bad, since it won't compile without at
>> least some version identifiers
>>
>
> This is how the C headers work. The targeted Windows version is a preprocessor define.
>
> It compiles just fine without any version identifiers, but it will target an old Windows version (95 or 98).
>
>
>  and I'm sure we can make the OS version
>> available at compile-time to obviate the need for those version identifiers.
>>
>
> This is a horrible idea. YOU ARE NOT TARGETING THE ENVIRONMENT YOU ARE BUILDING FROM!
>
>
>  3. It includes tons of obsolete stuff, that cannot and will not be used
>> ever, which are hard to track down and extract.
>>
>
> These headers have a long development history and are generally rather polished. You are suggesting to throw away all that and replacing them with something of your own?
>
>


-- 
Bye,
Gor Gyolchanyan.

And yes, I've already looked at OpenGL bindings in the same bindings project. They're D1 and OpenGL 2.1 only.


On Fri, Nov 23, 2012 at 5:15 PM, Gor Gyolchanyan < gor.f.gyolchanyan@gmail.com> wrote:

> I agree, that WinAPI binding from dsource.org is very close to what needs to be in druntime. I'll look into it. That's why I decided to bind the OpenGL headers first (because it needs manual binding more, then WinAPI). Derelict is heavily packed with auxilliary stuff, that makes the everyday use of OpenGL quite easy, but it's not a direct translation and has some overhead. And the OpenGl headers are FAR FAR FAR simpler and smaller then WinAPI ones. I'm half-way through with OpenGL.
>
>
> On Fri, Nov 23, 2012 at 5:09 PM, Vladimir Panteleev < vladimir@thecybershadow.net> wrote:
>
>> (Disclosure: I contributed to this project)
>>
>> The Win32 bindings are excellent. I believe your points are invalid.
>>
>>
>> On Friday, 23 November 2012 at 11:43:21 UTC, Gor Gyolchanyan wrote:
>>
>>> 1. It has some pragma(lib, ...) declarations which aren't being met and which assume some things, that aren't true.
>>>
>>
>> The libraries are here: http://dsource.org/projects/**bindings/browser/trunk/lib<http://dsource.org/projects/bindings/browser/trunk/lib>
>>
>> And the definition files for these libraries are here: http://dsource.org/projects/**bindings/browser/trunk/def<http://dsource.org/projects/bindings/browser/trunk/def>
>>
>>
>>  2. It uses version identifiers to determine the, you guessed it, version
>>> of
>>> Windows in question. This is very bad, since it won't compile without at
>>> least some version identifiers
>>>
>>
>> This is how the C headers work. The targeted Windows version is a preprocessor define.
>>
>> It compiles just fine without any version identifiers, but it will target an old Windows version (95 or 98).
>>
>>
>>  and I'm sure we can make the OS version
>>> available at compile-time to obviate the need for those version identifiers.
>>>
>>
>> This is a horrible idea. YOU ARE NOT TARGETING THE ENVIRONMENT YOU ARE BUILDING FROM!
>>
>>
>>  3. It includes tons of obsolete stuff, that cannot and will not be used
>>> ever, which are hard to track down and extract.
>>>
>>
>> These headers have a long development history and are generally rather polished. You are suggesting to throw away all that and replacing them with something of your own?
>>
>>
>
>
> --
> Bye,
> Gor Gyolchanyan.
>



-- 
Bye,
Gor Gyolchanyan.

On Friday, 23 November 2012 at 13:10:56 UTC, Gor Gyolchanyan wrote:
> I'll look into the opportunity to refactor the dsource.org WinAPI binding,
> because it's much closer to reality then Derelict. In that case It'll take
> a few hours to finish (quite fast). Would you suggest me to send a pull
> request to druntime with the new modules? How long will it take to be
> merged?

Does this include adapting druntime to use the new bindings?

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.

On Friday, 23 November 2012 at 13:57:14 UTC, Vladimir Panteleev wrote:
> 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.

Oh, I think I remembered. I believe the proper solution is to create a dummy struct type, and make HANDLE a const pointer to it. Then it cannot be confused with other types, but still accepts null assignments.