Re: Understanding SIGSEGV issues
On Tue, 2019-01-08 at 09:59 -0500, Steven Schveighoffer via Digitalmars-d- learn wrote: > […] > > Russel, make sure your destructor both checks whether the underlying > resource is set, and clears it to invalid when freeing it. > > Even types that can't be copied can be moved, or temporarily created as > rvalues. When they are moved the shell they get moved out of is still > destructed! So it has to have a state where it can be destroyed, even > though there is no resource. I have added tests in the destructor but given the constructor should throw an exception on a failure to initialise the internal state correctly, it really ought to be unnecessary. but I guess it cant hurt being there! As I noted to Nicholas it seems the application is getting a valid data structure returned with invalid data and that is where the SIGSEGV is. This is really weird as I have just finished a Rust version of the same application and it works fine. And this D version used to work fine. It is a real mystery why there is a problem now. Sadly the D plugin to CLion doesn't as yet have the same functionality as the Rust plugin. Debugging these sorts of thing is just so much better in CLion than trying to work GDB manually. > Maybe some inspiration here: > https://github.com/MartinNowak/io/blob/master/src/std/io/file.d#L189-L196 > I will check that out, thanks for the pointer. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Understanding SIGSEGV issues
On Tue, 2019-01-08 at 11:51 +, Nicholas Wilson via Digitalmars-d-learn wrote: > […] > Ahh. Good that you've found that, I can't help you much more with > that then. Indeed. :-) Your hep to get to this point though has been invaluable. Thanks you for putting in the time and effort. […] > Good luck figuring out why your data is dud. It really is totally weird. My new Rust binding to libdvbv5 and associated version of the same application works fine. So libdvbv5 itself is not the cuprit. This has to mean it is something about the D compilers that has changed the way the D binding to libdvbv5 behaves. If only the D plugin to CLion were much further down the road this would be much easier to fix. I had an issue in the Rust and it was fixed in a couple of minutes because of the way CLion drives GDB for you. Using GDB manually is such a f## pain. This alone becomes a mountain that leads to the thought of giving up on the D version. In an ideal world JetBrains would take over the D plugin, but that isn't gong to happen – unlike what happened for Go and Rust. What the D plugin needs is some full time workers: the great work by the current volunteers is slow progress by nature of it being volunteer effort by a few people. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Pass reference to void*
On Monday, 7 January 2019 at 13:15:44 UTC, Andre Pany wrote: On Monday, 7 January 2019 at 13:01:57 UTC, Stefan Koch wrote: On Monday, 7 January 2019 at 12:19:57 UTC, Andre Pany wrote: [...] From the function declaration &model seems to be the correct thing to use here. Have you checked that Open is not null ? Yes, Open is not null and the strange thing is, everything is working fine for DMD on windows. (I call a lot other dll functions afterwards). By switching to LDC the subsequent calls to DLL functions are failing. Thanks. Kind regards André Might be an calling convention issue? Are they declared with extern(Windows) ?
Re: Understanding SIGSEGV issues
On Wednesday, 9 January 2019 at 16:48:47 UTC, Russel Winder wrote: On Tue, 2019-01-08 at 11:51 +, Nicholas Wilson via Digitalmars-d-learn wrote: [...] […] [...] [...] If debugger integration is that important to you, you might want to try out visual studio code with the corresponding plugins (you need a separate plugin for debugger support). I found it to work quite decently.
Re: Pass reference to void*
On Wednesday, 9 January 2019 at 18:37:57 UTC, Stefan Koch wrote: On Monday, 7 January 2019 at 13:15:44 UTC, Andre Pany wrote: On Monday, 7 January 2019 at 13:01:57 UTC, Stefan Koch wrote: On Monday, 7 January 2019 at 12:19:57 UTC, Andre Pany wrote: [...] From the function declaration &model seems to be the correct thing to use here. Have you checked that Open is not null ? Yes, Open is not null and the strange thing is, everything is working fine for DMD on windows. (I call a lot other dll functions afterwards). By switching to LDC the subsequent calls to DLL functions are failing. Thanks. Kind regards André Might be an calling convention issue? Are they declared with extern(Windows) ? I finally got it solved. The d coding was right. There was an error in the dll which caused an issue for LDC on Windows. The SO (linux) I got working by chance. The SO has some dependencies to a system package. After installing this package by chance on my Alpine, the cryptic error message disappeared and everything works fine. Kind regards Andre
Re: reimplementing an interface in a derived class
On Thursday, 3 January 2019 at 23:23:12 UTC, Neia Neutuladh wrote:
On Thu, 03 Jan 2019 22:30:48 +, kdevel wrote:
class A : D {
int foo() { return 1; }
}
class B : A, D {
[...]
What is the meaning of the ", D"? It does not seem to make a
difference if it is omitted.
B must provide its own implementation of D. It can't simply use
A's implementation.
As for class B, it has already included foo(), even if it doesn't
override this method. So, is it necessary to override it again?
It not always needed to override foo(). Sometimes, we just want
to keep it as the one in class A and override it as necessary.
Honestly hope that the compiler can do this.
Libraries, versions, API changes, and Dub
It appears that libdvbv5 has undergone an (unnoticed by me till just now) version change. This raises a general question for creators of D bindings. libdvbv5 has versions 1.12.x, 1.14.x, 1.16.x, etc, following the "odd is internal, even is released" minor version number strategy. It seems wrong somehow to follow that numbering for the D binding; the binding needs to have a separate evolution. However the binding has to allow the user to choose the major.minor number of the underlying library they have – though that should perhaps be done automatically using the pkg-config system. Has anyone had previous experience of this situation and can give advice/direction so I don't have to build a solution from first principles? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Understanding SIGSEGV issues
On Wed, 2019-01-09 at 20:03 +, Johannes Loher via Digitalmars-d-learn wrote: > […] > If debugger integration is that important to you, you might want > to try out visual studio code with the corresponding plugins (you > need a separate plugin for debugger support). I found it to work > quite decently. Or I could stop doing D and Rust programming and switch to Kotlin and Java and get stuck into helping the IntelliJ-DLanguage team as I said I would a couple of years ago. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Generating API documention
What do people use to generate nice looking and simple html documentation for their projects? I would be glad (and if possible), someone could share some actual instructions rather than just tell me ddoc. For example I have seen the libmir (http://docs.mir.dlang.io/latest/index.html) and I would love to generate something similar for a project I am working on. Thank you and best wishes. George
Re: Understanding SIGSEGV issues
On Wednesday, 9 January 2019 at 16:48:47 UTC, Russel Winder wrote: It really is totally weird. My new Rust binding to libdvbv5 and associated version of the same application works fine. So libdvbv5 itself is not the cuprit. This has to mean it is something about the D compilers that has changed the way the D binding to libdvbv5 behaves. Hmm, if you think the binding could be the problem you could try using app as an alternative, see if it makes any difference.
