Jump to page: 1 2
Thread overview
Status of Deimos bindings
May 25, 2015
FreeSlave
May 25, 2015
rsw0x
May 26, 2015
Laeeth Isharc
May 26, 2015
lobo
May 26, 2015
Rikki Cattermole
May 26, 2015
weaselcat
May 26, 2015
Rikki Cattermole
May 26, 2015
Mike Parker
May 26, 2015
ketmar
May 26, 2015
Rikki Cattermole
May 26, 2015
Jacob Carlborg
May 25, 2015
What's the current status of Deimos? I don't think that this kind of bindings is useless, since not everyone always wants dynamic bindings. E.g. for the sake of simplicity or static linking. Actually Walter even fixes issues in these bindings time by time, so I guess the idea is still alive. But I see some problems now:

1. Some of Deimos bindings are not made into the dub packages. Also not all of those which have dub.json (or package.json) are presented in dub registry.
2. No consistency on names. There're repos named with lib prefix and without it either.
3. I could not find information on how to propose new binding to Deimos.
Currently we have some bindings in dub registry which are not in D-Programming-Deimos. Would be better to keep these things in the same place. One can filter dub registry by choosing the Development library -> D language bindings -> Deimos header-only binding, but some bindings (for example, flac) are not assigned to this section, so you will not see them.

Thoughts?
May 25, 2015
On Monday, 25 May 2015 at 21:33:15 UTC, FreeSlave wrote:
> What's the current status of Deimos? I don't think that this kind of bindings is useless, since not everyone always wants dynamic bindings. E.g. for the sake of simplicity or static linking. Actually Walter even fixes issues in these bindings time by time, so I guess the idea is still alive. But I see some problems now:
>
> 1. Some of Deimos bindings are not made into the dub packages. Also not all of those which have dub.json (or package.json) are presented in dub registry.
> 2. No consistency on names. There're repos named with lib prefix and without it either.
> 3. I could not find information on how to propose new binding to Deimos.
> Currently we have some bindings in dub registry which are not in D-Programming-Deimos. Would be better to keep these things in the same place. One can filter dub registry by choosing the Development library -> D language bindings -> Deimos header-only binding, but some bindings (for example, flac) are not assigned to this section, so you will not see them.
>
> Thoughts?

I like how nim approaches this by making important C bindings such as SDL, Lua, etc first class members of the language. I believe that they ship directly with the nim implementation as ported headers barely take up any space. These are libraries that pretty much any language is expected to support.
Bye.
May 26, 2015
On Monday, 25 May 2015 at 21:43:18 UTC, rsw0x wrote:
> On Monday, 25 May 2015 at 21:33:15 UTC, FreeSlave wrote:
>> What's the current status of Deimos? I don't think that this kind of bindings is useless, since not everyone always wants dynamic bindings. E.g. for the sake of simplicity or static linking. Actually Walter even fixes issues in these bindings time by time, so I guess the idea is still alive. But I see some problems now:
>>
>> 1. Some of Deimos bindings are not made into the dub packages. Also not all of those which have dub.json (or package.json) are presented in dub registry.
>> 2. No consistency on names. There're repos named with lib prefix and without it either.
>> 3. I could not find information on how to propose new binding to Deimos.
>> Currently we have some bindings in dub registry which are not in D-Programming-Deimos. Would be better to keep these things in the same place. One can filter dub registry by choosing the Development library -> D language bindings -> Deimos header-only binding, but some bindings (for example, flac) are not assigned to this section, so you will not see them.
>>
>> Thoughts?
>
> I like how nim approaches this by making important C bindings such as SDL, Lua, etc first class members of the language. I believe that they ship directly with the nim implementation as ported headers barely take up any space. These are libraries that pretty much any language is expected to support.
> Bye.

+1

Anything without much cost one can do to make it easy for people to get started with D will pay off, because small frictions in life cumulatively have large consequences.

(Not cost-free given maintenance and desire to sync them with dmd releases, but if the bindings are clearly identified as not part of core D then it's better to make it easy than force people to hunt them down).
May 26, 2015
On Monday, 25 May 2015 at 21:33:15 UTC, FreeSlave wrote:
> What's the current status of Deimos? I don't think that this kind of bindings is useless, since not everyone always wants dynamic bindings. E.g. for the sake of simplicity or static linking. Actually Walter even fixes issues in these bindings time by time, so I guess the idea is still alive. But I see some problems now:
>
> 1. Some of Deimos bindings are not made into the dub packages. Also not all of those which have dub.json (or package.json) are presented in dub registry.
> 2. No consistency on names. There're repos named with lib prefix and without it either.
> 3. I could not find information on how to propose new binding to Deimos.
> Currently we have some bindings in dub registry which are not in D-Programming-Deimos. Would be better to keep these things in the same place. One can filter dub registry by choosing the Development library -> D language bindings -> Deimos header-only binding, but some bindings (for example, flac) are not assigned to this section, so you will not see them.
>
> Thoughts?

If you submit a PR adding dub support for to a Deimos repo it will be pulled.

It just needs someone with enough time (and interest) to write and test the dub.json files for all the repos then register those packages with code.dlang.

bye,
lobo
May 26, 2015
On 26/05/2015 9:33 a.m., FreeSlave wrote:
> What's the current status of Deimos? I don't think that this kind of
> bindings is useless, since not everyone always wants dynamic bindings.
> E.g. for the sake of simplicity or static linking. Actually Walter even
> fixes issues in these bindings time by time, so I guess the idea is
> still alive. But I see some problems now:
>
> 1. Some of Deimos bindings are not made into the dub packages. Also not
> all of those which have dub.json (or package.json) are presented in dub
> registry.
> 2. No consistency on names. There're repos named with lib prefix and
> without it either.
> 3. I could not find information on how to propose new binding to Deimos.
> Currently we have some bindings in dub registry which are not in
> D-Programming-Deimos. Would be better to keep these things in the same
> place. One can filter dub registry by choosing the Development library
> -> D language bindings -> Deimos header-only binding, but some bindings
> (for example, flac) are not assigned to this section, so you will not
> see them.
>
> Thoughts?

Really what needs to happen is getting Derelict-Util into phobos.
And some CTFE magic to create static bindings from those (if wanted).

From there its just port the derelict libraries and deimos ones to it and PR for phobos.

Perhaps bindings shouldn't go through the review process. After all there isn't exactly bugs that can be introduced from it.
May 26, 2015
On Tuesday, 26 May 2015 at 03:51:22 UTC, Rikki Cattermole wrote:
> On 26/05/2015 9:33 a.m., FreeSlave wrote:
>> What's the current status of Deimos? I don't think that this kind of
>> bindings is useless, since not everyone always wants dynamic bindings.
>> E.g. for the sake of simplicity or static linking. Actually Walter even
>> fixes issues in these bindings time by time, so I guess the idea is
>> still alive. But I see some problems now:
>>
>> 1. Some of Deimos bindings are not made into the dub packages. Also not
>> all of those which have dub.json (or package.json) are presented in dub
>> registry.
>> 2. No consistency on names. There're repos named with lib prefix and
>> without it either.
>> 3. I could not find information on how to propose new binding to Deimos.
>> Currently we have some bindings in dub registry which are not in
>> D-Programming-Deimos. Would be better to keep these things in the same
>> place. One can filter dub registry by choosing the Development library
>> -> D language bindings -> Deimos header-only binding, but some bindings
>> (for example, flac) are not assigned to this section, so you will not
>> see them.
>>
>> Thoughts?
>
> Really what needs to happen is getting Derelict-Util into phobos.
> And some CTFE magic to create static bindings from those (if wanted).
>
> From there its just port the derelict libraries and deimos ones to it and PR for phobos.
>
> Perhaps bindings shouldn't go through the review process. After all there isn't exactly bugs that can be introduced from it.

Please no, derelict bindings are incredibly heavyweight. I cut my application's size from ~6mb to 200kb by using glad openGL loader over derelict GL3.
May 26, 2015
> And some CTFE magic to create static bindings from those (if wanted).

May 26, 2015
On 2015-05-25 23:33, FreeSlave wrote:
> What's the current status of Deimos? I don't think that this kind of
> bindings is useless, since not everyone always wants dynamic bindings.
> E.g. for the sake of simplicity or static linking. Actually Walter even
> fixes issues in these bindings time by time, so I guess the idea is
> still alive. But I see some problems now:
>
> 1. Some of Deimos bindings are not made into the dub packages. Also not
> all of those which have dub.json (or package.json) are presented in dub
> registry.
> 2. No consistency on names. There're repos named with lib prefix and
> without it either.
> 3. I could not find information on how to propose new binding to Deimos.
> Currently we have some bindings in dub registry which are not in
> D-Programming-Deimos. Would be better to keep these things in the same
> place. One can filter dub registry by choosing the Development library
> -> D language bindings -> Deimos header-only binding, but some bindings
> (for example, flac) are not assigned to this section, so you will not
> see them.
>
> Thoughts?

I don't think Deimos should be used. The biggest problem is that it's the D core team that owns the repositories, instead of those how maintain it. This will disturb the already busy core team with pull requests and other things related to maintaining the repository.

It's much better to have Dub be the collection where one can kind bindings. It's also easier to include the bindings if they use Dub.

-- 
/Jacob Carlborg
May 26, 2015
On Tue, 26 May 2015 15:51:20 +1200, Rikki Cattermole wrote:

> Really what needs to happen is getting Derelict-Util into phobos. And some CTFE magic to create static bindings from those (if wanted).
> 
>  From there its just port the derelict libraries and deimos ones to it
> and PR for phobos.

actually, converting Derelict back to "header bindings" is fairly easy, and can be done with sed. i did that for SDL and some others.

> Perhaps bindings shouldn't go through the review process. After all there isn't exactly bugs that can be introduced from it.

ah... Xlib bindings was all the way wrong both with `wchar_t` functions and with enum types. first took me the whole day to understand why i see no text at all, and second took me even more days to understand why XIM calls doesn't fail, but not doing what they should. mechanically translated defines with L becomes longs instead of c_longs (ints, actually, on my x86), and that broke variadic args XIM call.

so i believe that bindings should be reviewed *very* carefully. actually, bindings is the last place where people look for possible bugs, especially if those are "officially blessed bindings".

May 26, 2015
On 26/05/2015 7:24 p.m., ketmar wrote:
> On Tue, 26 May 2015 15:51:20 +1200, Rikki Cattermole wrote:
>
>> Really what needs to happen is getting Derelict-Util into phobos. And
>> some CTFE magic to create static bindings from those (if wanted).
>>
>>   From there its just port the derelict libraries and deimos ones to it
>> and PR for phobos.
>
> actually, converting Derelict back to "header bindings" is fairly easy,
> and can be done with sed. i did that for SDL and some others.
>
>> Perhaps bindings shouldn't go through the review process. After all
>> there isn't exactly bugs that can be introduced from it.
>
> ah... Xlib bindings was all the way wrong both with `wchar_t` functions
> and with enum types. first took me the whole day to understand why i see
> no text at all, and second took me even more days to understand why XIM
> calls doesn't fail, but not doing what they should. mechanically
> translated defines with L becomes longs instead of c_longs (ints,
> actually, on my x86), and that broke variadic args XIM call.
>
> so i believe that bindings should be reviewed *very* carefully. actually,
> bindings is the last place where people look for possible bugs,
> especially if those are "officially blessed bindings".

What I meant was the normal review queue process. It still should be reviewed, but more on pull request type of deal.

« First   ‹ Prev
1 2