On 2019-01-11 06:31, Russel Winder wrote:
DStep generated bindings tend to need some manual tweaking that cannot be
automated, which is surprising given that bindgen can do things without manual
intervention for Rust.
It's not surprising at all. Different tools, different approaches,
On Thu, 2019-01-10 at 13:09 -0500, Steven Schveighoffer via Digitalmars-d-
learn wrote:
>
[…]
> That is one problem with linking against C or C++ code -- changes to
> certain things (e.g. struct layout) don't change the mangling.
I am having nightmares trying to decide what to do with the Rust
On Thu, Jan 10, 2019 at 01:09:22PM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 1/10/19 12:30 PM, Russel Winder wrote:
> > On Thu, 2019-01-10 at 10:00 -0500, Steven Schveighoffer via Digitalmars-d-
> > learn wrote:
> > […]
> > > Hm... your description of having the problem
On 1/10/19 12:30 PM, Russel Winder wrote:
On Thu, 2019-01-10 at 10:00 -0500, Steven Schveighoffer via Digitalmars-d-
learn wrote:
[…]
Hm... your description of having the problem happen at the end of main
seems to suggest it has something to do with destruction.
It seems that there was a
On Thu, 2019-01-10 at 10:00 -0500, Steven Schveighoffer via Digitalmars-d-
learn wrote:
[…]
>
> Hm... your description of having the problem happen at the end of main
> seems to suggest it has something to do with destruction.
>
It seems that there was a change in one file of libdvbv5 1.14.x →
On Thu, 2019-01-10 at 07:36 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
[…]
> Hmm, if you think the binding could be the problem you could try
> using app as an alternative, see if it makes any difference.
I did a proper update of the generated files of the binding, and magically
On 1/9/19 11:39 AM, Russel Winder wrote:
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
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
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
>
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
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.
[…]
>
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
On 1/5/19 6:33 AM, Russel Winder wrote:
On Sat, 2019-01-05 at 10:52 +, Russel Winder wrote:
On Sat, 2019-01-05 at 10:31 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
[…]
Maybe it is a problem with copying a File_Ptr (e.g. missing a
increase of the reference count)? Like, `auto a =
On Tuesday, 8 January 2019 at 10:23:30 UTC, Russel Winder wrote:
Actually that is not a worry since the TransmitterData instance
is only needed to call the scan function which creates a
ChannelsData instance that holds no references to the
TransmitterData instance.
It turns out that whilst
On Sat, 2019-01-05 at 13:14 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
>
[…]
> Your problem possibly (probably?) stems from
>
> auto channelsData = TransmitterData(args[1]).scan(frontendId);
>
> The temporary TransmitterData(args[1]) is, well, temporary and
> its destructor runs
On Saturday, 5 January 2019 at 12:14:15 UTC, Russel Winder wrote:
Indeed. I should do that to see if I can reproduce the problem
to submit a proper bug report.
File_Ptr is wrapping a dvb_file * from libdvbv5 to try and make
things a bit for D and to ensure RAII. libdvbv5 is a C API with
On Sat, 2019-01-05 at 11:30 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
>
[…]
> Could you post a minimised example? Its a bit hard to guess
> without one.
Indeed. I should do that to see if I can reproduce the problem to submit a
proper bug report.
[…]
> From the name, File_Ptr
On Saturday, 5 January 2019 at 10:52:48 UTC, Russel Winder wrote:
I found the problem and then two minutes later read your email
and bingo we have found the problem.
Well done.
Previously I had used File_Ptr* and on this occasion I was
using File_Ptr and there was no copy constructor because
On Sat, 2019-01-05 at 10:52 +, Russel Winder wrote:
> On Sat, 2019-01-05 at 10:31 +, Nicholas Wilson via Digitalmars-d-learn
> wrote:
> […]
> > Maybe it is a problem with copying a File_Ptr (e.g. missing a
> > increase of the reference count)? Like, `auto a = File_Ptr(); {
> > auto b =
On Sat, 2019-01-05 at 10:31 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
[…]
>
> Maybe it is a problem with copying a File_Ptr (e.g. missing a
> increase of the reference count)? Like, `auto a = File_Ptr(); {
> auto b = a; }` and b calls the destructor on scope exit.
> That would be
On Saturday, 5 January 2019 at 07:34:17 UTC, Russel Winder wrote:
TransmitterData has a destructor defined but with no code in
it. This used to work fine – but I cannot be certain which
version of LDC that was.
The problem does seem to be in the construction of the
TransmitterData object
On Thu, 2019-01-03 at 11:23 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
> On Thursday, 3 January 2019 at 08:35:17 UTC, Russel Winder wrote:
> > Sorry about that, fairly obvious that the backtrace is needed
> > in hindsight. :- )
> >
> > #0 __GI___libc_free (mem=0xa) at malloc.c:3093
>
On Thursday, 3 January 2019 at 08:35:17 UTC, Russel Winder wrote:
Sorry about that, fairly obvious that the backtrace is needed
in hindsight. :- )
#0 __GI___libc_free (mem=0xa) at malloc.c:3093
#1 0x5558f174 in dvb_file_free
(dvb_file=0x555a1320) at dvb_file.d:282
#2
On Thu, 2019-01-03 at 07:52 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
> On Thursday, 3 January 2019 at 06:25:46 UTC, Russel Winder wrote:
> > So I have a D program that used to work. I come back to it,
> > recompile it, and:
> >
> > [...]
> > __GI___libc_free (mem=0xa) at
On Thursday, 3 January 2019 at 06:25:46 UTC, Russel Winder wrote:
So I have a D program that used to work. I come back to it,
recompile it, and:
[...]
__GI___libc_free (mem=0xa) at malloc.c:3093
You've tried to free a pointer that, while not null, was derived
from a pointer that was,
So I have a D program that used to work. I come back to it, recompile it, and:
|> dub run -- ~/lib/DigitalTelevision/DVBv5/uk-CrystalPalace__RW
Performing "debug" build using /usr/bin/ldc2 for x86_64.
libdvbv5_d 0.1.1: target for configuration "library" is up to date.
dvb-tune ~master: target
26 matches
Mail list logo
