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
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, Jon
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 fin
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
On Sunday, 4 June 2017 at 09:04:14 UTC, Jonathan M Davis wrote:
[...]
Why Nullable!T call destroy for reference types?
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 _is
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
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/is
// 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 a
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 exa
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
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
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". Th
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
Breakpoin
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
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 Wi
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 0x7
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", "
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/libdvbv
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/widg
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 als
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
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 :)
c
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 VARIA
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 conver
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 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 th
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
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)
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
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 c
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:
>>
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(byt
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
> > #
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)
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.
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 ele
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 conver
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 shorte
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 my
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 wor
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 typ
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
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 *
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:
>>
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 an
On Saturday, 3 June 2017 at 17:28:36 UTC, Adam D. Ruppe wrote:
On Saturday, 3 June 2017 at 17:24:08 UTC, Russel Winder wrote:
So why isn't rdmd shipped as a separate thing if it can wrap
any of the three compilers?
it is... the link above is all there is to it, you simply
compile it. The docs
47 matches
Mail list logo
