On 2017-05-29 18:08, Russel Winder via Digitalmars-d wrote:

> My biggest problem of the moment is libdvbv5 and librtlsdr. DStep
> seemingly cannot help as yet.

I know you have reported a few bugs for DStep. Are those all or anything else that has not been reported yet?

-- 
/Jacob Carlborg

On Tue, 2017-05-30 at 08:39 +0200, Jacob Carlborg via Digitalmars-d wrote:
> On 2017-05-29 18:08, Russel Winder via Digitalmars-d wrote:
> 
> > My biggest problem of the moment is libdvbv5 and librtlsdr. DStep seemingly cannot help as yet.
> 
> I know you have reported a few bugs for DStep. Are those all or
> anything
> else that has not been reported yet?

I am leading up to working more on this – but I need a statically linked executable that will run on Debian Sid and Fedora Rawhide.

Looking at the problem of wrapping libdvbv5, what is in Deimos, etc., manually wrapping C libraries strikes me as a dead-end of dead-ends. As with GtkD and GStreamerD automated (or at least mostly automated) generation of wrappers is the only way forward. So if I cannot automatically generate libdvbv5 D wrappers, then I am not sure I can progress with D for Me TV. So DStep becomes a crucial factor. Except I cannot build it (as we discussed elsewhere, hence I need pre-built executables).

Others have mentioned widening D's appeal by widening the number of C APIs there are wrappers for. This is a good idea, I agree – in my case libdvbv5 and librtlsdr are the beasties of interest. I argue Deimos is the wrong direction since it is about manually managing evolving API, DStep is the right direction since it is about creating the API of the moment. However DStep may not yet be ready. I need to tinker more. libdvbv5 effectively includes the whole Linux DVB API, there are a lot of C header files. It's alla question of how best to do the wrapping.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 30 May 2017 at 07:15:08 UTC, Russel Winder wrote:
> Others have mentioned widening D's appeal by widening the number of C APIs there are wrappers for. This is a good idea, I agree – in my case libdvbv5 and librtlsdr are the beasties of interest. I argue Deimos is the wrong direction since it is about manually managing evolving API, DStep is the right direction since it is about creating the API of the moment. However DStep may not yet be ready. I need to tinker more. libdvbv5 effectively includes the whole Linux DVB API, there are a lot of C header files. It's alla question of how best to do the wrapping.

The problem is, that wrappers alone is not the solution. Lets say i write a wrapper, have no more time and abandon the project. Later people see these half finished and not maintain wrapper ( and others ). How does this reflect on the language itself.

Its been my firm believe that lose packages are a detriment to a language. There is no controle over the quality of the work and yet the use of those third party packages can have a impact on the language perception ( unsupported, badly written, licencing issues ).

Half baked solutions are no solutions. Packages need to be part of the language standard or "extended" library. Having the ownership under the language. Allowing people who are dissatisfied to grieve there bugs or issues, directly to the language maintainers. It also adds oversight to the packages.

You mention Debian and look how they manage there packages. Code has issue: Rejected. Not maintained: Rejected. Licencing issues: Rejected.

Simply trowing wrappers around C libraries does not make a language more interesting. Quality, standardization, one location, supported, ... those are the keywords.

One can simply look at Go. 100.000 packages, 98% are junk, unfinished, not maintained, etc. And people are forced to dive into the junk to find the good ones. Its the same with other languages and there unenforced third party packages.

This applies to enterprise users and normal users, everybody wants to have the quality and security that packages are maintained, have a standard, have the same API structure, ...

But this requires a lot of coordination and manpower. Frankly, i do not see this happening any time soon in D ( and other languages ) that work with volunteers.

On Tuesday, 30 May 2017 at 07:56:43 UTC, Wulfklaue wrote:
> Its been my firm believe that lose packages are a detriment to a language.

It isn't good if many of the interesting packages are unmaintained, as it gives an sense of being in the past.

> Half baked solutions are no solutions. Packages need to be part of the language standard or "extended" library.

Standard libraries should stay small as they are hard to deprecate. Have official lists instead.

> One can simply look at Go. 100.000 packages, 98% are junk, unfinished, not maintained, etc. And people are forced to dive into the junk to find the good ones. Its the same with other languages and there unenforced third party packages.

There is a solution for this: "awesome lists"

https://github.com/avelino/awesome-go

The problem for a small language is more when a very useful library become unmaintained, then people wonder why not somebody else took over.

On Tuesday, 30 May 2017 at 05:50:13 UTC, Ola Fosheim Grostad wrote:

> Focusing on getting many libraries won't work, because you need to maintain them. I never use unmaintained libraries... Having many unmaintained libraries is in a way worse than having a few long-running ones that improve at a steady pace.

One of the things I hated when I started using D was links to dsource libraries. I think that writing new libraries in D is often a mistake for that very reason. Bindings to C libraries is what we need. Put everything into one D file if possible, wrapping just the stable core functionality with a few convenience features tossed in, and maintenance is no longer an issue. There's nothing sexy abut that approach, and that's kind of the point.

And in good news, despite Dub's inability to understand the way things are on Debian, and using some egregious hacks, I have a DStep build on Debian Sid that appears to work. No such luck on Fedora but that is a "known issue" for DStep (*).

It seems libdvbv5 D wrapper generation may be working. Me TV may yet become a D code.

I shall also have to try librtlsdr.


(*) What DStep needs is some folk knowledgeable about libclang 3.9,
4.0, and 5.0 to help moving up from 3.7 (and 3.8).

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 30 May 2017 at 11:22:29 UTC, bachmeier wrote:
> One of the things I hated when I started using D was links to dsource libraries. I think that writing new libraries in D is often a mistake for that very reason. Bindings to C libraries is what we need. Put everything into one D file if possible, wrapping just the stable core functionality with a few convenience features tossed in, and maintenance is no longer an issue. There's nothing sexy abut that approach, and that's kind of the point.

What happend to that Calypso project?  I suppose libclang also would allow you to inspect C header-files and then maybe it would be possible to synthesize Dish bindings from it on the fly? Not that I have given it much thought.

On Tuesday, 30 May 2017 at 12:26:22 UTC, Ola Fosheim Grøstad wrote:
> What happend to that Calypso project?  I suppose libclang also would allow you to inspect C header-files and then maybe it would be possible to synthesize Dish bindings from it on the fly? Not that I have given it much thought.

Maybe even turning some macros into functions?

On Tuesday, 30 May 2017 at 11:22:29 UTC, bachmeier wrote:
> One of the things I hated when I started using D was links to dsource libraries. I think that writing new libraries in D is often a mistake for that very reason. Bindings to C libraries is what we need. Put everything into one D file if possible, wrapping just the stable core functionality with a few convenience features tossed in, and maintenance is no longer an issue. There's nothing sexy abut that approach, and that's kind of the point.

I do not see anything massive wrong with that idea, beyond that your are open to libraries written in C.  Potential unsafe memory function call inside the libraries...

On 2017-05-30 14:26, Ola Fosheim Grøstad wrote:

> What happend to that Calypso project?  I suppose libclang also would
> allow you to inspect C header-files and then maybe it would be possible
> to synthesize Dish bindings from it on the fly? Not that I have given it
> much thought.

I did that by integrating DStep in DMD as a proof of concept [1]. But at that time, IIRC, it was preferred to run DStep as a separate step to generate the bindings.

http://forum.dlang.org/post/ks3kir$1ubq$1@digitalmars.com

-- 
/Jacob Carlborg