Re: D and GDB
On Monday, 5 June 2017 at 01:07:51 UTC, H. S. Teoh wrote: It can't be any more trivial than just running ddemangle, which is found in the dlang/tools repo on github. Trivial i don't know but i had the feeling that the OP complained about the stack trace not being readable although all the answers went in another direction. (Arguably this should be shipped by default with dmd... or is it already?) Of course it is. Currently i don't use it much but at the beginning of 2017 it's been very useful to me, to process valgrind's output, dozen and dozen of times. How can anyone ignore that it's shipped with dmd ?
Re: Make enum auto castable
On Monday, 5 June 2017 at 03:15:46 UTC, Jonathan M Davis wrote: On Monday, June 05, 2017 02:14:14 Mike B Johnson via Digitalmars-d-learn wrote: On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote: > On Monday, June 05, 2017 01:30:47 Mike B Johnson via > > Digitalmars-d-learn wrote: >> [...] > > It's not a bug. The alias this conversion only goes one way. > It provides a way to convert _from_ the type that it's > declared on to another type, not from the other type to the > type that it's declared on. There is no way in D to declare > an implicit conversion in the direction you're trying. So, > if you have a struct that wraps an int like this, and you > want to assign it an int, you're going to need to explicitly > construct the struct - e.g. EnumX(1). > > - Jonathan M Davis That's pretty crappy! Defeats the whole point! Well, implicit conversions tend to cause a lot of bugs in C++ code, so Walter decided to restrict them quite a bit more in D than they are in C++. This therefore prevents a number of bugs in D, but it also prevents implicit conversions from being used in a number of situations where they're useful. Whether the end result is better or worse, I don't know and certainly YMMV. As it is, some of the implicit conversions that we still allow have a tendency to cause bugs (e.g. conversions between integral values and character types tend to be error-prone - especially when arrays are involved - and using implicit conversions with templated code is almost always a bad idea). So, at times, I tend to think that all implicit conversions should be banned. But at other times, it would be really nice to be able to have more than we do (e.g. it would be a lot more user-friendly if you could pass a T to a function that takes a Nullable!T). In any case, I think that the reality of the matter with D is that you tend to have to use explicit conversions rather than implicit ones, and if you're looking to do much with implicit conversions, you're usually going to be frustrated, and obviously, that sucks, but at least you're less likely to have bugs related to implicit conversions. - Jonathan M Davis The problem is bugs are only a possibility. If you remove a feature from a language the feature does not exist, period. So, throwing the baby out with the bath water because he pooped in it is not a solution. Instead, if there is a problem with implicit autonomous conversion or construction, then the solution is not to remove all implicit conversions or constructions but to remove the autonomous part. e.g., make the user specify the implicit conversion explicitly. This way, if bugs do creep in, it is due to the user. It is much easier to diagnose and fix then.
Re: Make enum auto castable
On Sun, Jun 04, 2017 at 08:15:46PM -0700, Jonathan M Davis via Digitalmars-d-learn wrote: > Well, implicit conversions tend to cause a lot of bugs in C++ code, so > Walter decided to restrict them quite a bit more in D than they are in C++. So D has plenty of implicit conversion. It is implicit *construction* that it lacks. And alas, C++'s mistake is implicit is default, so it gets used in places it wasn't intended. We should have just had explicit default with implicit as an option.
Re: Make enum auto castable
On Monday, June 05, 2017 02:14:14 Mike B Johnson via Digitalmars-d-learn wrote: > On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote: > > On Monday, June 05, 2017 01:30:47 Mike B Johnson via > > > > Digitalmars-d-learn wrote: > >> [...] > > > > It's not a bug. The alias this conversion only goes one way. It > > provides a way to convert _from_ the type that it's declared on > > to another type, not from the other type to the type that it's > > declared on. There is no way in D to declare an implicit > > conversion in the direction you're trying. So, if you have a > > struct that wraps an int like this, and you want to assign it > > an int, you're going to need to explicitly construct the struct > > - e.g. EnumX(1). > > > > - Jonathan M Davis > > That's pretty crappy! Defeats the whole point! Well, implicit conversions tend to cause a lot of bugs in C++ code, so Walter decided to restrict them quite a bit more in D than they are in C++. This therefore prevents a number of bugs in D, but it also prevents implicit conversions from being used in a number of situations where they're useful. Whether the end result is better or worse, I don't know and certainly YMMV. As it is, some of the implicit conversions that we still allow have a tendency to cause bugs (e.g. conversions between integral values and character types tend to be error-prone - especially when arrays are involved - and using implicit conversions with templated code is almost always a bad idea). So, at times, I tend to think that all implicit conversions should be banned. But at other times, it would be really nice to be able to have more than we do (e.g. it would be a lot more user-friendly if you could pass a T to a function that takes a Nullable!T). In any case, I think that the reality of the matter with D is that you tend to have to use explicit conversions rather than implicit ones, and if you're looking to do much with implicit conversions, you're usually going to be frustrated, and obviously, that sucks, but at least you're less likely to have bugs related to implicit conversions. - Jonathan M Davis
Re: Make enum auto castable
On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote: On Monday, June 05, 2017 01:30:47 Mike B Johnson via Digitalmars-d-learn wrote: [...] It's not a bug. The alias this conversion only goes one way. It provides a way to convert _from_ the type that it's declared on to another type, not from the other type to the type that it's declared on. There is no way in D to declare an implicit conversion in the direction you're trying. So, if you have a struct that wraps an int like this, and you want to assign it an int, you're going to need to explicitly construct the struct - e.g. EnumX(1). - Jonathan M Davis That's pretty crappy! Defeats the whole point!
Re: Make enum auto castable
On Monday, June 05, 2017 01:30:47 Mike B Johnson via Digitalmars-d-learn
wrote:
> enum X : EnumX
> {
> a = 1,
> }
>
>
> struct EnumX
> {
> int x;
> alias x this;
> void opAssign(int y)
> {
> x = y;
> }
> double opCall()
> {
> return x;
> }
> }
>
> doesn't work because "1" is not castable to EnumX, even though
> EnumX is aliased to an int, and hence it should work fine.
>
> Seems like a bug to me.
It's not a bug. The alias this conversion only goes one way. It provides a
way to convert _from_ the type that it's declared on to another type, not
from the other type to the type that it's declared on. There is no way in D
to declare an implicit conversion in the direction you're trying. So, if you
have a struct that wraps an int like this, and you want to assign it an int,
you're going to need to explicitly construct the struct - e.g. EnumX(1).
- Jonathan M Davis
Re: Make enum auto castable
On Monday, 5 June 2017 at 00:51:15 UTC, Jonathan M Davis wrote:
On Monday, June 05, 2017 00:16:15 Mike B Johnson via
Digitalmars-d-learn wrote:
On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote:
> [...]
I might be able to change the enum, I assume you mean
something like
enum myenum : S { }
where S is the struct that implicitly converts?
Yes.
However, be aware that you can currently only define one alias
this per type. So, the rest of the code will then need to be
able to deal with the fact that the enum is a struct that
implicitly converts to VARIANT and does not implicitly convert
to int. So, if you're just passing the enums around and
comparing them, you're fine, but if you need to treat them as
ints somewhere, then you'll need to provide an explicit
conversion (via overloading opCast or by creating a specific
function for it or just exposing a member with the int value or
whatever), and that could get annoying in the same way that
you're annoyed about the VARIANT issue right now.
But if you don't actually need to treat the enum as an int, and
you can make it a struct that implicitly converts to VARIANT
instead, then that will fix your VARIANT conversion problem.
- Jonathan M Davis
enum X : EnumX
{
a = 1,
}
struct EnumX
{
int x;
alias x this;
void opAssign(int y)
{
x = y;
}
double opCall()
{
return x;
}
}
doesn't work because "1" is not castable to EnumX, even though
EnumX is aliased to an int, and hence it should work fine.
Seems like a bug to me.
Re: Make enum auto castable
On Monday, June 05, 2017 01:12:20 Mike B Johnson via Digitalmars-d-learn wrote: > Well, I do need to to treat it as an int at times and opCast only > works with cast. While I could set it up to do a cast(VARIANT), > which is better than nothing, I'd get same result as to!VARIANT, > which is shorter and effectively the same. > > When will we get multiple alias this? all I need is two? > > Hell, why not make alias this an "overloadable" function similar > to opCast and such? I don't know when we're getting multiple alias thises. TDPL talks about it being a thing, and the spec claims that it's a thing, but until someone implements it, we won't have it, and it hasn't been a priority for Walter. IIRC, someone tried to implement it at one point, but I don't know where that went. There was a thread in the main newsgroup a couple of months ago about how to simulate multiple alias thises, so you might want to check that out: https://forum.dlang.org/post/uniyvmvjopeyyxmph...@forum.dlang.org - Jonathan M Davis
Re: Implicit casting of int enum members to int
On Mon, Jun 05, 2017 at 01:23:22AM +, Mike B Johnson via
Digitalmars-d-learn wrote:
> On Monday, 3 October 2016 at 09:21:37 UTC, Jonathan M Davis wrote:
> > [...]
>
> Is this bug ever going to be fixed?
>
> I can't do
>
> enum X : Y
> {
>a = 1
> }
>
> because 1 is not implicitly convertible to Y, even though Y is aliased
> to an int so it should be.
Works for me:
alias Y = int;
enum X : Y {
a = 1
}
Please post a minimal example that doesn't work.
T
--
Try to keep an open mind, but not so open your brain falls out. -- theboz
Re: dmd casts but ldc doesn't, and doesn't work in template in dmdm
On Sun, Jun 04, 2017 at 06:12:42PM -0700, H. S. Teoh wrote:
> On Mon, Jun 05, 2017 at 01:14:31AM +, Mike B Johnson via
> Digitalmars-d-learn wrote:
> [...]
> > Guid is a struct and I am trying to get the "bytes" of the struct" to
> > get the guid bytes. It is quicker than accessing all the elements one
> > at a time.
>
> union U {
> typeof(guid) guid;
> ubyte[guid.sizeof] bytes;
> }
> U u;
> u.guid = guid;
> // ... do something with u.bytes.
[...]
And if you're going to be doing this a lot on many different types, you
could ease the typing by declaring a template for it, for example:
union AsBytes(T) {
T t;
ubyte[T.sizeof] bytes;
}
ubyte[T.sizeof] asBytes(T)(T t) {
AsBytes!T u;
u.t = t;
return u.bytes;
}
...
struct S {
/* stuff */
}
S s;
auto bytes = s.asBytes;
... /* do stuff with bytes, which is a static array of ubyte */
Note, of course, that this will be @system if T contains any pointers.
T
--
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
Re: Implicit casting of int enum members to int
On Monday, 3 October 2016 at 09:21:37 UTC, Jonathan M Davis wrote:
[...]
Is this bug ever going to be fixed?
I can't do
enum X : Y
{
a = 1
}
because 1 is not implicitly convertible to Y, even though Y is
aliased to an int so it should be.
Re: dmd casts but ldc doesn't, and doesn't work in template in dmdm
On Mon, Jun 05, 2017 at 01:14:31AM +, Mike B Johnson via
Digitalmars-d-learn wrote:
[...]
> Guid is a struct and I am trying to get the "bytes" of the struct" to
> get the guid bytes. It is quicker than accessing all the elements one
> at a time.
union U {
typeof(guid) guid;
ubyte[guid.sizeof] bytes;
}
U u;
u.guid = guid;
// ... do something with u.bytes.
T
--
Why are you blatanly misspelling "blatant"? -- Branden Robinson
Re: dmd casts but ldc doesn't, and doesn't work in template in dmdm
On Monday, 5 June 2017 at 00:56:52 UTC, Jonathan M Davis wrote: On Monday, June 05, 2017 00:18:04 Mike B Johnson via Digitalmars-d-learn wrote: [...] I assume that guid is a string or array of byte or somesuch? If it's an array of byte or char, then you can probably do auto bytes = cast(byte[16])guid[0 .. 16]; I doubt that it will work with CTFE though, because this is basically a reinterpret cast, and CTFE gets picky about casts like that. If you need to do something like that in CTFE, you'll probably need to use if(__ctfe) to add a branch that does this it in a for loop or something without any casts. Also, you probably want ubyte, not byte. byte is signed, so it really only makes sense to use it as an integral value that holds [-128, 128] rather than for an actual byte value. - Jonathan M Davis Guid is a struct and I am trying to get the "bytes" of the struct" to get the guid bytes. It is quicker than accessing all the elements one at a time.
Re: D and GDB
On Sun, Jun 04, 2017 at 07:24:17PM +, Basile B. via Digitalmars-d-learn wrote: [...] > you have to pipe the output to ddemangle. Here's the output: > > #0 0x7fffc770 in ?? () > > #1 0x77bb3d80 in dvb_scan_transponder () from > > /usr/lib/x86_64-linux-gnu/libdvbv5.so.0 > > #2 0x5557026d in ref libdvbv5.ScanHandler_Ptr > > libdvbv5.ScanHandler_Ptr.__ctor(dvb_fe.dvb_v5_fe_parms*, > > dvb_file.dvb_entry*, int, extern (C) int function(void*, > > dvb_fe.dvb_v5_fe_parms*)*, uint, uint) > > (this=..., frontendParameters=0x557b4830, > > entry=0x557aa0b0, dmx_fd=4, check_frontend=0x5556f730 > > , other_nit=0, timeout_multiplier=1) at > > /home/users/russel/Repositories/Git/Masters/DVBTune/source/libdvbv5.d:140 > > #3 0x5556fcea in channels.ChannelsData > > channels.TransmitterData.scan(const(libdvbv5.FrontendId), const(uint), > > const(uint), const(uint), const(uint), const(bool)) > > (this=..., fei=..., other_nit=0, timeout_multiplier=1, get_detected=1, > > get_nit=1, > > dont_add_new_frequencies=false) at > > /home/users/russel/Repositories/Git/Masters/DVBTune/source/channels.d:159 > > #4 0x55583251 in _Dmain (args=...) at > > /home/users/russel/Repositories/Git/Masters/DVBTune/source/main.d:35 The ?? on the first line is probably a function that has no debugging info, perhaps from a library that wasn't compiled with debugging symbols added. > Personally i don't know how to do this by hand since my IDE does the > task automatically > (http://bbasile.github.io/Coedit/widgets_gdb_commander). It can't be any more trivial than just running ddemangle, which is found in the dlang/tools repo on github. (Arguably this should be shipped by default with dmd... or is it already?) T -- My program has no bugs! Only unintentional features...
Re: Make enum auto castable
On Monday, 5 June 2017 at 00:51:15 UTC, Jonathan M Davis wrote:
On Monday, June 05, 2017 00:16:15 Mike B Johnson via
Digitalmars-d-learn wrote:
On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote:
> On Sunday, June 04, 2017 22:52:55 Mike B Johnson via
>
> Digitalmars-d-learn wrote:
>> [...]
>
> Aside from whatever implicit conversions are built into the
> language, the only way to define an implicit conversion in D
> is via alias this on a user-defined type, which then tells
> that type that it can convert to whatever type the result of
> the alias this is. e.g. if you have
>
> [...]
I might be able to change the enum, I assume you mean
something like
enum myenum : S { }
where S is the struct that implicitly converts?
Yes.
However, be aware that you can currently only define one alias
this per type. So, the rest of the code will then need to be
able to deal with the fact that the enum is a struct that
implicitly converts to VARIANT and does not implicitly convert
to int. So, if you're just passing the enums around and
comparing them, you're fine, but if you need to treat them as
ints somewhere, then you'll need to provide an explicit
conversion (via overloading opCast or by creating a specific
function for it or just exposing a member with the int value or
whatever), and that could get annoying in the same way that
you're annoyed about the VARIANT issue right now.
But if you don't actually need to treat the enum as an int, and
you can make it a struct that implicitly converts to VARIANT
instead, then that will fix your VARIANT conversion problem.
- Jonathan M Davis
Well, I do need to to treat it as an int at times and opCast only
works with cast. While I could set it up to do a cast(VARIANT),
which is better than nothing, I'd get same result as to!VARIANT,
which is shorter and effectively the same.
When will we get multiple alias this? all I need is two?
Hell, why not make alias this an "overloadable" function similar
to opCast and such?
Re: dmd casts but ldc doesn't, and doesn't work in template in dmdm
On Monday, June 05, 2017 00:18:04 Mike B Johnson via Digitalmars-d-learn wrote: > The following line is causing some problems. > > > auto bytes = cast(byte[16])guid; > > > compiles fine in dmd but ldc says it can't convert... also, it > doens't work in ctfe/template either. (I'm not sure if ctfe is > kicking in or not though, but definitely doesn't work in a > template) I assume that guid is a string or array of byte or somesuch? If it's an array of byte or char, then you can probably do auto bytes = cast(byte[16])guid[0 .. 16]; I doubt that it will work with CTFE though, because this is basically a reinterpret cast, and CTFE gets picky about casts like that. If you need to do something like that in CTFE, you'll probably need to use if(__ctfe) to add a branch that does this it in a for loop or something without any casts. Also, you probably want ubyte, not byte. byte is signed, so it really only makes sense to use it as an integral value that holds [-128, 128] rather than for an actual byte value. - Jonathan M Davis
Re: Make enum auto castable
On Monday, June 05, 2017 00:16:15 Mike B Johnson via Digitalmars-d-learn
wrote:
> On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote:
> > On Sunday, June 04, 2017 22:52:55 Mike B Johnson via
> >
> > Digitalmars-d-learn wrote:
> >> [...]
> >
> > Aside from whatever implicit conversions are built into the
> > language, the only way to define an implicit conversion in D is
> > via alias this on a user-defined type, which then tells that
> > type that it can convert to whatever type the result of the
> > alias this is. e.g. if you have
> >
> > [...]
>
> I might be able to change the enum, I assume you mean something
> like
>
> enum myenum : S { }
>
> where S is the struct that implicitly converts?
Yes.
However, be aware that you can currently only define one alias this per
type. So, the rest of the code will then need to be able to deal with the
fact that the enum is a struct that implicitly converts to VARIANT and does
not implicitly convert to int. So, if you're just passing the enums around
and comparing them, you're fine, but if you need to treat them as ints
somewhere, then you'll need to provide an explicit conversion (via
overloading opCast or by creating a specific function for it or just
exposing a member with the int value or whatever), and that could get
annoying in the same way that you're annoyed about the VARIANT issue right
now.
But if you don't actually need to treat the enum as an int, and you can make
it a struct that implicitly converts to VARIANT instead, then that will fix
your VARIANT conversion problem.
- Jonathan M Davis
dmd casts but ldc doesn't, and doesn't work in template in dmdm
The following line is causing some problems. auto bytes = cast(byte[16])guid; compiles fine in dmd but ldc says it can't convert... also, it doens't work in ctfe/template either. (I'm not sure if ctfe is kicking in or not though, but definitely doesn't work in a template)
Re: Make enum auto castable
On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote:
On Sunday, June 04, 2017 22:52:55 Mike B Johnson via
Digitalmars-d-learn wrote:
[...]
Aside from whatever implicit conversions are built into the
language, the only way to define an implicit conversion in D is
via alias this on a user-defined type, which then tells that
type that it can convert to whatever type the result of the
alias this is. e.g. if you have
[...]
I might be able to change the enum, I assume you mean something
like
enum myenum : S { }
where S is the struct that implicitly converts?
Re: Make enum auto castable
On Sunday, June 04, 2017 22:52:55 Mike B Johnson via Digitalmars-d-learn
wrote:
> I am dealing with some COM stuff and some functions use VARIANT,
> which can hold an enum.
>
> Instead of having to manually convert the enum(and for that
> matter, other things) to VARIANT, is it possible to have them
> automatically converted?
>
> This is because an enum is always convertible to a VARIANT but
> not the other way around. So, when a enum is passed to a function
> accepting a VARIANT, it should just work. Overloading is not an
> option.
Aside from whatever implicit conversions are built into the language, the
only way to define an implicit conversion in D is via alias this on a
user-defined type, which then tells that type that it can convert to
whatever type the result of the alias this is. e.g. if you have
struct S
{
int x;
alias x this;
}
then S can implicitly convert to int, and when it does, the value of x is
used (alternatively, a member function could be used, in which case, the
result of the member function would be used as the result of the
conversion). So, that allows you to tell how to convert a type _to_ another
type, but it does not allow you to convert _from_ another type. So, if
you're implicitly converting from type A to type B, it will work if type A
has been told how to convert to B, but there is no way for B to say that an
A can be converted to a B. Only A can define the conversion.
So, if you have control of the definition of the base type of the enum, then
you can define an alias this on it to convert to a VARIANT, but if you don't
have control over the definition of the base type of the enum (e.g. if it's
int, as is the default), then you're out of luck. And if you're dealing with
COM, then I'm guessing that your enum has a base type of int, and you
obviously don't control the definition of int, so you can't add an alias
this to it.
So, if you can't change the enum, and you can't change the function that
you're calling, then you'll have to insert something in between - be it a
conversion function, an explicit construction of VARIANT with the enum, or
some kind of wrapper function around the one that you're calling. But unless
the enum itself knows how to implicitly convert to a VARIANT thanks to alias
this, there is no implicit conversion.
std.typecons.Nullable has this sort of problem, which has historically
forced folks to do stuff like Nullable!int(42) when passing the actual type
to a function that accepts a Nullable wrapper around the type, which is
pretty annoying. Recently, a nullable function was added to std.typecons
which uses IFTI to infer the type of the Nullable
auto nullable(T)(T t)
{
return Nullable!T(t);
}
and then you could pass nullable(42) instead of Nullable!int(42), so it's
more user-friendly, but it still requires an explicit conversion unless you
overload the function. It's a downside to D's stricter approach to implicit
conversions.
- Jonathan M Davis
Re: Linker cannot find malloc and free on OS X
On Sunday, 4 June 2017 at 16:13:22 UTC, Jacob Carlborg wrote: On 2017-06-04 12:45, Nordlöw wrote: My gmp-d tests successfully on Linux as dub test but on OS X it fails as Undefined symbols for architecture x86_64: "free", referenced from: ... "malloc", referenced from: ... Any ideas on why? https://github.com/nordlow/gmp-d/issues/4#issuecomment-305974761 I would recommend adding the --verbose flag to see the exact commands invoked. That will print how the D compiler was invoked. The copy-paste the exact command and add the -v flag (for verbose). To the same with the C compiler and the linker. The flag -L-lc seems to have been passed to the library. This is the full error message after running it with dub test --verbose Using dub registry url 'http://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /Users/kdkdk/.dub/packages/local-packages.json Determined package version using GIT: gmp-d 0.0.3+commit.16.gedb1291 Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /Users/kdkdk/.dub/packages/local-packages.json Found dependency libgmp 1.0.0 Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /Users/kdkdk/.dub/packages/local-packages.json Found dependency libgmp 1.0.0 Checking for upgrades. Using cached upgrade results... Generating test runner configuration 'gmp-d-test-library' for 'library' (library). Get module name from path: /Users/kdkdk/Documents/psi/gmp-d/src/gmp/dbgio.d Get module name from path: /Users/kdkdk/Documents/psi/gmp-d/src/gmp/f.d Excluding package.d file from test due to https://issues.dlang.org/show_bug.cgi?id=11847 Get module name from path: /Users/kdkdk/Documents/psi/gmp-d/src/gmp/q.d Get module name from path: /Users/kdkdk/Documents/psi/gmp-d/src/gmp/traits.d Get module name from path: /Users/kdkdk/Documents/psi/gmp-d/src/gmp/z.d Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /Users/kdkdk/.dub/packages/local-packages.json Found dependency libgmp 1.0.0 Generate target gmp-d (executable /Users/kdkdk/Documents/psi/gmp-d gmp-d-test-library) Generate target libgmp (staticLibrary /Users/kdkdk/.dub/packages/libgmp-1.0.0/libgmp libgmp) Performing "unittest" build using dmd for x86_64. libgmp 1.0.0: target for configuration "library" is up to date. Using existing build in /Users/kdkdk/.dub/packages/libgmp-1.0.0/libgmp/.dub/build/library-unittest-posix.osx-x86_64-dmd_2074-0CBFB25E65B46672F7CAF7CC5BABCE87/. Copying target from /Users/kdkdk/.dub/packages/libgmp-1.0.0/libgmp/.dub/build/library-unittest-posix.osx-x86_64-dmd_2074-0CBFB25E65B46672F7CAF7CC5BABCE87/liblibgmp.a to /Users/kdkdk/.dub/packages/libgmp-1.0.0/libgmp Target '/Users/kdkdk/Documents/psi/gmp-d/.dub/build/gmp-d-test-library-unittest-posix.osx-x86_64-dmd_2074-6A4F59B4FBEFFE587575F03F4A8B5BD0/gmp-d-test-library' doesn't exist, need rebuild. gmp-d 0.0.3+commit.16.gedb1291: building configuration "gmp-d-test-library"... Using direct -l... flags for gmp, c. dmd -c -of.dub/build/gmp-d-test-library-unittest-posix.osx-x86_64-dmd_2074-6A4F59B4FBEFFE587575F03F4A8B5BD0/gmp-d-test-library.o -debug -g -unittest -w -version=VibeCustomMain -version=Have_gmp_d -version=Have_libgmp -Isrc/ -I../../../.dub/packages/libgmp-1.0.0/libgmp/source/ ../../../../../var/folders/7s/rl2b7bj92t7c2dlnnmgzmc20gn/T/dub_test_root-94ea7d66-86c6-4a27-9ede-42b0d74e6604.d src/gmp/dbgio.d src/gmp/f.d src/gmp/package.d src/gmp/q.d src/gmp/traits.d src/gmp/z.d -vcolumns Linking... dmd -of.dub/build/gmp-d-test-library-unittest-posix.osx-x86_64-dmd_2074-6A4F59B4FBEFFE587575F03F4A8B5BD0/gmp-d-test-library .dub/build/gmp-d-test-library-unittest-posix.osx-x86_64-dmd_2074-6A4F59B4FBEFFE587575F03F4A8B5BD0/gmp-d-test-library.o ../../../.dub/packages/libgmp-1.0.0/libgmp/.dub/build/library-unittest-posix.osx-x86_64-dmd_2074-0CBFB25E65B46672F7CAF7CC5BABCE87/liblibgmp.a -L-lgmp -L-lc -g Undefined symbols for architecture x86_64: "free", referenced from: _D3gmp1z3MpZ6__ctorMFNaNbNcNiNexAyakZS3gmp1z3MpZ in gmp-d-test-library.o _D3gmp1z3MpZ10fromStringMFNaNbNcNiNjNexAyakZS3gmp1z3MpZ in gmp-d-test-library.o (maybe you meant: _D2rt4util9container5treap33__T5TreapTS2gc11gcinterface4RootZ5Treap8freeNodeFNbNiPS2rt4util9container5treap33__T5TreapTS2gc11gcinterface4RootZ5Treap4NodeZv, _D2gc4impl12conservative2gc3Gcx8log_freeMFNbPvZv , _D2gc4impl12conservative2gc15LargeObjectPool9freePagesMFNbmmZv , _D4core6memory2GC4freeFNaNbPvZv ,
Re: Make enum auto castable
On Sunday, 4 June 2017 at 22:52:55 UTC, Mike B Johnson wrote: I am dealing with some COM stuff and some functions use VARIANT, which can hold an enum. Instead of having to manually convert the enum(and for that matter, other things) to VARIANT, is it possible to have them automatically converted? This is because an enum is always convertible to a VARIANT but not the other way around. So, when a enum is passed to a function accepting a VARIANT, it should just work. Overloading is not an option. Not sure if this breaks your requirement but you could generate overloads or rather templated version of your variant accepting function with a mixin that introspects on functions with a certain uda in the module. See excel-d for an example.
Make enum auto castable
I am dealing with some COM stuff and some functions use VARIANT, which can hold an enum. Instead of having to manually convert the enum(and for that matter, other things) to VARIANT, is it possible to have them automatically converted? This is because an enum is always convertible to a VARIANT but not the other way around. So, when a enum is passed to a function accepting a VARIANT, it should just work. Overloading is not an option.
Re: D and GDB
On Sunday, 4 June 2017 at 18:13:41 UTC, Russel Winder wrote: On Sun, 2017-06-04 at 20:31 +0300, ketmar via Digitalmars-d-learn wrote: [...] Sadly even using the correct command, I am not getting any data that helps infer what the is going on. :-( [...] My guess is a null pointer :) check your pointers :)
Re: D and GDB
On 2017-06-04 20:13, Russel Winder via Digitalmars-d-learn wrote: On Sun, 2017-06-04 at 20:31 +0300, ketmar via Digitalmars-d-learn wrote: maybe 'cause backtrace is called with `bt` command? ;-) Sadly even using the correct command, I am not getting any data that helps infer what the is going on. :-( #0 0x7fffc770 in ?? () If you refer to ??, I'm guessing that's inside libdvbv5.so which might not have been compiled with debug information enabled. -- /Jacob Carlborg
Re: std.path.buildPath
On 2017-06-04 19:05, Patrick Schluter wrote:
buildPath("/usr/bin", "/usr/bin/gcc")
/usr/bin/usr/bin/gcc is obviously wrong.
Says who? It might be exactly what I want. The case that came up is
inside DStep. The user provides a set of files C header to be translated
to D modules. The user also provides a flag to indicate where to place
the resulting files. I wanted to be able to keep the existing directory
structure of the header files in the new target location. Example:
dstep -o result /usr/include/libxml2/libxml/*.h
The internals of DStep will do something like:
buildPath("result", "/usr/include/libxml2/libxml");
Which currently results in "/usr/include/libxml2/libxml". The end result
is that DStep will try to write a file to "/usr/include/libxml2/libxml",
which the user most likely will not have access to (without using sudo).
I expected the result of buildPath to be
"result/usr/include/libxml2/libxml".
--
/Jacob Carlborg
Re: D and GDB
On Sunday, 4 June 2017 at 19:24:17 UTC, Basile B. wrote: On Sunday, 4 June 2017 at 18:13:41 UTC, Russel Winder wrote: [...] you have to pipe the output to ddemangle. Personally i don't know how to do this by hand since my IDE does the task automatically (http://bbasile.github.io/Coedit/widgets_gdb_commander). Also i suppose you compiled with -g -gs ? at `libdvbv5.d:140` you are calling the native `dvb_scan_transponder` in `libdvbv5.so` that's segfaulting... Try to just log the arguments values you are using there... /Paolo
Re: D and GDB
On Sunday, 4 June 2017 at 18:13:41 UTC, Russel Winder wrote: Sadly even using the correct command, I am not getting any data that helps infer what the is going on. :-( #0 0x7fffc770 in ?? () #1 0x77bb3d80 in dvb_scan_transponder () from /usr/lib/x86_64-linux-gnu/libdvbv5.so.0 #2 0x5557026d in _D8libdvbv515ScanHandler_Ptr6__ctorMFNcPS6dvb_fe15dvb_v5_fe_parmsPS8dvb_file9dvb_entryiPUPvPS6dvb_fe15dvb_v5_fe_parmsZikkZS8libdvbv515ScanHandler_Ptr (this=..., frontendParameters=0x557b4830, entry=0x557aa0b0, dmx_fd=4, check_frontend=0x5556f730 , other_nit=0, timeout_multiplier=1) at /home/users/russel/Repositories/Git/Masters/DVBTune/source/libdvbv5.d:140 #3 0x5556fcea in _D8channels15TransmitterData4scanMFxS8libdvbv510FrontendIdxkxkxkxkxbZC8channels12ChannelsData (this=..., fei=..., other_nit=0, timeout_multiplier=1, get_detected=1, get_nit=1, dont_add_new_frequencies=false) at /home/users/russel/Repositories/Git/Masters/DVBTune/source/channels.d:159 #4 0x55583251 in _Dmain (args=...) at /home/users/russel/Repositories/Git/Masters/DVBTune/source/main.d:35 you have to pipe the output to ddemangle. Personally i don't know how to do this by hand since my IDE does the task automatically (http://bbasile.github.io/Coedit/widgets_gdb_commander). Also i suppose you compiled with -g -gs ?
Re: std.path.buildPath
On Sun, 2017-06-04 at 17:56 +0200, Jacob Carlborg via Digitalmars-d-
learn wrote:
> On 2017-06-04 07:44, Jesse Phillips wrote:
>
> > What is your expected behavior? Throw an exception? You can't
> > really
> > append an absolute path to another.
>
> Of course you can. I expect buildPath("/foo", "/bar") to result in
> "/foo/bar". That's how Ruby behaves.
And Python, Groovy, Java, Kotlin, Ceylon, C++, …
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: D and GDB
On Sun, 2017-06-04 at 20:31 +0300, ketmar via Digitalmars-d-learn wrote: > > > maybe 'cause backtrace is called with `bt` command? ;-) Sadly even using the correct command, I am not getting any data that helps infer what the is going on. :-( #0 0x7fffc770 in ?? () #1 0x77bb3d80 in dvb_scan_transponder () from /usr/lib/x86_64-linux-gnu/libdvbv5.so.0 #2 0x5557026d in _D8libdvbv515ScanHandler_Ptr6__ctorMFNcPS6dvb_fe15dvb_v5_fe_parmsPS8dvb_file9dvb_entryiPUPvPS6dvb_fe15dvb_v5_fe_parmsZikkZS8libdvbv515ScanHandler_Ptr (this=..., frontendParameters=0x557b4830, entry=0x557aa0b0, dmx_fd=4, check_frontend=0x5556f730 , other_nit=0, timeout_multiplier=1) at /home/users/russel/Repositories/Git/Masters/DVBTune/source/libdvbv5.d:140 #3 0x5556fcea in _D8channels15TransmitterData4scanMFxS8libdvbv510FrontendIdxkxkxkxkxbZC8channels12ChannelsData (this=..., fei=..., other_nit=0, timeout_multiplier=1, get_detected=1, get_nit=1, dont_add_new_frequencies=false) at /home/users/russel/Repositories/Git/Masters/DVBTune/source/channels.d:159 #4 0x55583251 in _Dmain (args=...) at /home/users/russel/Repositories/Git/Masters/DVBTune/source/main.d:35 -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D and GDB
On Sun, 2017-06-04 at 20:31 +0300, ketmar via Digitalmars-d-learn wrote: > […] > maybe 'cause backtrace is called with `bt` command? ;-) :-) Well it is 14 years since I started a gdb instance. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D and GDB
Russel Winder wrote: I thought I had left SIGSEGV debugging behind, but it seems not. However whilst the C++/CLion debug tooling is excellent, D seems to be without. I guess there must be some gdb magic I am missing, but: Program received signal SIGSEGV, Segmentation fault. 0x7fffc788 in ?? () gdb>b Breakpoint 1 at 0x7fffc788 gdb> Not the most illuminating backtrace I have seen. maybe 'cause backtrace is called with `bt` command? ;-)
D and GDB
I thought I had left SIGSEGV debugging behind, but it seems not. However whilst the C++/CLion debug tooling is excellent, D seems to be without. I guess there must be some gdb magic I am missing, but: Program received signal SIGSEGV, Segmentation fault. 0x7fffc788 in ?? () gdb>b Breakpoint 1 at 0x7fffc788 gdb> Not the most illuminating backtrace I have seen. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: std.path.buildPath
On Sunday, 4 June 2017 at 15:56:58 UTC, Jacob Carlborg wrote:
On 2017-06-04 07:44, Jesse Phillips wrote:
What is your expected behavior? Throw an exception? You can't
really
append an absolute path to another.
Of course you can. I expect buildPath("/foo", "/bar") to result
in "/foo/bar". That's how Ruby behaves.
buildPath("/usr/bin", "/usr/bin/gcc")
/usr/bin/usr/bin/gcc is obviously wrong. I think the semantic is
not as illogical as it seem at first glance.
Re: Linker cannot find malloc and free on OS X
On 2017-06-04 12:45, Nordlöw wrote: My gmp-d tests successfully on Linux as dub test but on OS X it fails as Undefined symbols for architecture x86_64: "free", referenced from: ... "malloc", referenced from: ... Any ideas on why? https://github.com/nordlow/gmp-d/issues/4#issuecomment-305974761 I would recommend adding the --verbose flag to see the exact commands invoked. That will print how the D compiler was invoked. The copy-paste the exact command and add the -v flag (for verbose). To the same with the C compiler and the linker. -- /Jacob Carlborg
Re: std.path.buildPath
On 2017-06-04 07:44, Jesse Phillips wrote:
What is your expected behavior? Throw an exception? You can't really
append an absolute path to another.
Of course you can. I expect buildPath("/foo", "/bar") to result in
"/foo/bar". That's how Ruby behaves.
--
/Jacob Carlborg
Re: How to cleanup array of structs?
On Sunday, 4 June 2017 at 12:24:44 UTC, Suliman wrote:
// Will reuse the array, overwriting existing data.
// If other parts of the program are using existing data
// in the array, this will lead to hard-to-track-down bugs.
mytracks.length = 0;
mytracks.assumeSafeAppend();
Could you give an example where it can lead bugs? Do you mean
multi-thread apps?
it is not restricted to multithreads but is perhaps easiest to
think about it in those terms.
so you do
mytracks.length = 0;
mytracks.assumeSafeAppend();
and then you start building up the array again with some new data
so that the array is sorted (or some other property of the array)
and you do this over a period of time.
foreach(i; iota(N))
{
mytracks ~= MyTrack(i, "",0,0); // id is sorted
Fibre.yield(); // do something else, maybe wating for more
data
} func(mytracks); // precondition that arg is sorted.
meanwhile you have a reference to the `mytracks`buffer somewhere
else (another global variable for instance) and it is not
expecting to have its data 'stomped' and then it writes to it
then it will this may make `mytracks` no longer sorted.
Re: How to cleanup array of structs?
// Will reuse the array, overwriting existing data. // If other parts of the program are using existing data // in the array, this will lead to hard-to-track-down bugs. mytracks.length = 0; mytracks.assumeSafeAppend(); Could you give an example where it can lead bugs? Do you mean multi-thread apps?
Re: Linker cannot find malloc and free on OS X
On Sunday, 4 June 2017 at 10:45:23 UTC, Nordlöw wrote: My gmp-d tests successfully on Linux as dub test but on OS X it fails as Undefined symbols for architecture x86_64: "free", referenced from: ... "malloc", referenced from: ... Any ideas on why? https://github.com/nordlow/gmp-d/issues/4#issuecomment-305974761 try giving it -lc
Linker cannot find malloc and free on OS X
My gmp-d tests successfully on Linux as dub test but on OS X it fails as Undefined symbols for architecture x86_64: "free", referenced from: ... "malloc", referenced from: ... Any ideas on why? https://github.com/nordlow/gmp-d/issues/4#issuecomment-305974761
Re: difference between x = Nullable.init and x.nullify
On Sunday, June 04, 2017 09:31:24 vit via Digitalmars-d-learn wrote: > On Sunday, 4 June 2017 at 09:04:14 UTC, Jonathan M Davis wrote: > > [...] > > Why Nullable!T call destroy for reference types? It calls destroy for everything. Why it does that instead of simply assigning T.init and setting _isNull to true, I don't know. Maybe the commit history would say, but unless it was done as part of a bugfix, it's more likely that you'd have to use the commit history to figure out who made it do that and ask them. Thinking about it though, it does seem like it's probably the wrong behavior. I'd guess that it was done with structs in mind, and it doesn't usually make sense to put a class reference in Nullable outside of generic code, since they can be null on their own. - Jonathan M Davis
Re: difference between x = Nullable.init and x.nullify
On Sunday, 4 June 2017 at 09:04:14 UTC, Jonathan M Davis wrote: [...] Why Nullable!T call destroy for reference types?
Re: difference between x = Nullable.init and x.nullify
On Sunday, 4 June 2017 at 09:04:14 UTC, Jonathan M Davis wrote: if throwing in a destructor is considered a runtime error, perhaps another valid enhancement would be to statically disallow throwing Exceptions in destructors, i.e. *require* them be nothrow?.. My initial reaction would be that destructors should always be nothrow, though I vaguely recall there being some reason why it was supposed to be nice that destructors in D could cleanly deal with exceptions. And remember that when we're talking about rt_finalize, we're talking about finalizers, not destructors in general. When a destructor is in a GC heap-allocated object, it's treated as a finalizer and may or may not be run (since the object may or may not be collected), It doesn't matter. The only thing that matters is that it may be run, and therefore rt_finalize has to count on that. And it sort of does, at the moment, by assuming the worst possible combination of attributes. Problem is, with current language rules, it cannot be any other way, as the runtime doesn't carry any information about attributes of finalized object, or the context in which finalization takes place (i.e. is it within a @safe function?), which, sadly, makes unsafe code silently executable in a safe context, in direct contradiction to language guarantees. whereas when a destructor is on an object that's on the stack, it's really a destructor. So, while they use the same syntax, It's worse than that. There are two "destructors": __xdtor that calls destructors of RAII members, and, on classes, __dtor that actually calls ~this() for the class. But only that class, not it's ancestors or descendants. Such segregation is, as it turns out, as useful as it is unwieldy. and in the case of a struct, the same function could be either a destructor or a finalizer depending on where the struct is declared, they're not quite the same thing. And destroy muddies the water a bit, because it then explicitly calls the finalizer on a class, whereas it would normally be the GC that does it (and while calling GC-related functions in a finalizer is forbidden when called by the GC, it's fine when called via destroy, since the GC is then not in the middle of a collection). So, I don't know whether it would be reasonable to require that destructors be nothrow. Certainly, it's _more_ likely for it to be reasonable for destructors on classes to be nothrow, since classes always live on the heap (and are thus finalizers) unless you're playing games with something like std.typecons.scoped, but I'd have to study the matter quite a bit more to give a properly informed answer as to whether it would be reasonable to require that all destructors be nothrow. Scoped is not necessary. Classes may not necessarily exist in the GC heap, thanks to custom allocators and emplace(). But because the language does not enforce propagation of destructor attributes, destroy() is @system and not nothrow, which spills out into user code that would otherwise take advantage of static inference. Unfortunately, right now making it any other would impose certain restrictions on classes without real language support, and that is... scary.
Re: C macros vs D can't do the right thing
On Saturday, June 03, 2017 14:22:11 David Nadlinger via Digitalmars-d-learn wrote: > On Saturday, 3 June 2017 at 14:19:00 UTC, Jacob Carlborg wrote: > > Perhaps using the variadic template with a constraint on one > > element trick will work. Ugly, but I think that will work. > > We could also finally fix the frontend to get around this. At > DConf 2015, Walter officially agreed that this is a bug that > needs fixing. ;) He did agree, but AFAIK, no one has ever actually done the work, and I suspect that unless Walter gets frustrated over the problem himself, he won't get around to fixing it himself, but I don't know. I also have no idea how easy or hard the implementation would be. It really should be fixed at some point though, since it's clearly causing problems and consistently forcing us to have workarounds in the standard library. - Jonathan M Davis
Re: difference between x = Nullable.init and x.nullify
On Saturday, June 03, 2017 08:17:18 Stanislav Blinov via Digitalmars-d-learn wrote: > On Saturday, 3 June 2017 at 08:01:14 UTC, Jonathan M Davis wrote: > > On Saturday, June 03, 2017 06:41:44 Stanislav Blinov via > > > > Digitalmars-d-learn wrote: > >> On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis > >> > >> wrote: > >> > looking at what rt_finalize does, I don't see why it > >> > couldn't be nothrow. So, unless I'm missing something, it > >> > seems like that would be a good enhancement. > >> > > >> > - Jonathan M Davis > >> > >> Presently, rt_finalize cannot be made nothrow, or un-made > >> @system, because "reasons": > >> http://forum.dlang.org/thread/aalafajtuhlvfirwf...@forum.dlang.org > >> > >> Fixing that would require significant changes to the runtime, > >> and probably the compiler. I don't think it qualifies as a > >> simple "enhancement" :) > > > > Well, as I said, I could be missing something, but all > > rt_finalize does is call rt_finalize2, and rt_finalize2 _is_ > > nothrow (it catches any Exceptions that are thrown by the > > destructor/finalizer). So, I have no idea why it would be the > > case that rt_finalize couldn't be nothrow, and I saw nothing in > > that thread which contradicts that, but I could have read it > > too quickly. Regardless, it's a perfectly valid enhancement > > request whether it's easy to implement or not. > > > > - Jonathan M Davis > > Whoops, my bad, I forgot it indeed swallows exceptions and does > the onFinalizeError instead. So... yep, then it seems that > rt_finalize probably should be marked nothrow too. Hmm... if > throwing in a destructor is considered a runtime error, perhaps > another valid enhancement would be to statically disallow > throwing Exceptions in destructors, i.e. *require* them be > nothrow?.. My initial reaction would be that destructors should always be nothrow, though I vaguely recall there being some reason why it was supposed to be nice that destructors in D could cleanly deal with exceptions. And remember that when we're talking about rt_finalize, we're talking about finalizers, not destructors in general. When a destructor is in a GC heap-allocated object, it's treated as a finalizer and may or may not be run (since the object may or may not be collected), whereas when a destructor is on an object that's on the stack, it's really a destructor. So, while they use the same syntax, and in the case of a struct, the same function could be either a destructor or a finalizer depending on where the struct is declared, they're not quite the same thing. And destroy muddies the water a bit, because it then explicitly calls the finalizer on a class, whereas it would normally be the GC that does it (and while calling GC-related functions in a finalizer is forbidden when called by the GC, it's fine when called via destroy, since the GC is then not in the middle of a collection). So, I don't know whether it would be reasonable to require that destructors be nothrow. Certainly, it's _more_ likely for it to be reasonable for destructors on classes to be nothrow, since classes always live on the heap (and are thus finalizers) unless you're playing games with something like std.typecons.scoped, but I'd have to study the matter quite a bit more to give a properly informed answer as to whether it would be reasonable to require that all destructors be nothrow. - Jonathan M Davis
Re: difference between x = Nullable.init and x.nullify
On Saturday, June 03, 2017 14:30:05 Kagamin via Digitalmars-d-learn wrote: > On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis wrote: > > Assigning Nullable!Test.init is equivalent to setting the > > internal value to Test.init and setting _isNull to false. > > Eh? Does it mean Nullable is default initialized to some non-null > default value? Well, that depends on what you mean by null. Nullable!T doesn't use pointers, so it can't be null like a pointer is null. The whole point of Nullable!T is to emulate the null behavior of pointers while keeping everything on the stack. It's a struct that contains two members: T _value; bool _isNull = true; So, _value is default-initialized to T.init, and _isNull defaults to true. Whether Nullable!T is "null" or not depends on the value of _isNull. So, Nullable!T is default-initialized to null in the sense that _isNull is true, and all of its member functions that check for "null" check whether _isNull is true, so it's treated as "null" when it's default-initialized, but it's not truly null in the sense that a pointer or class reference can be null. If that's what you want, just create a T* rather than a Nullable!T. - Jonathan M Davis
