extern(C) Variant: attempting to use incompatible types int and int
I know the problem that TypeInfo != TypeInfo in main and library context. Is there are a hack to get the data from the Variant even if the TypeInfo-check fails? I assume the only workaround is using an own struct or serializer to achieve the same functionality?
Re: Error: incompatible types for 'shared(SysTime)' and 'shared(SysTime)'
On 09/13/2018 06:59 PM, ag0aep6g wrote:
On 09/13/2018 03:25 PM, Arafel wrote:
// How can we update the timestamp? Neither of those work
timestamp = Clock.currTime;
timestamp = cast(shared) Clock.currTime;
cast() timestamp = Clock.currTime;
Still not there... it doesn't work with ref parameters (and probably
other things, like AAs, or at least nested AAs / arrays):
```
import std.stdio;
import std.datetime.systime;
import core.time;
void foo(ref SysTime t) {
t += 1.dur!"minutes";
}
shared synchronized class A {
private SysTime s;
this() {
cast ()s = Clock.currTime; // OK, This works
}
void foo() {
writeln("A.foo - Before: ", cast() s);
// But how to do this??
//(cast () s).foo;
//s.foo;
writeln("A.foo - After: ", cast() s);
}
}
void main() {
SysTime s = Clock.currTime;
writeln("main - Before: ", s);
s.foo;
writeln("main - After: ", s);
shared A a = new shared A;
a.foo;
}
```
That makes me wonder if casting a lvalue makes sense at all, and how
come that the result is not another lvalue... what it is, I don't know,
because you can assign to it, but not take a reference.
Re: Error: incompatible types for 'shared(SysTime)' and 'shared(SysTime)'
(*(cast (SysTime*) ())).foo; Not exactly obvious or user-friendly...
Re: Error: incompatible types for 'shared(SysTime)' and 'shared(SysTime)'
On 09/13/2018 03:25 PM, Arafel wrote: // How can we update the timestamp? Neither of those work timestamp = Clock.currTime; timestamp = cast(shared) Clock.currTime; cast() timestamp = Clock.currTime;
Re: Error: incompatible types for 'shared(SysTime)' and 'shared(SysTime)'
On 07/05/2016 04:16 PM, ag0aep6g wrote:
On 07/05/2016 07:25 AM, ketmar wrote:
cast `shared` away. yes, this is how you supposed to use it now: cast it
away.
after having ensured thread safety that is
Sorry to resurrect an old thread, but then how can one update a SysTime
field in a shared class? Like this (using a synchronized class for
simplicity, this part works and the mutex acts as expected):
```
import std.concurrency;
import std.datetime.systime;
import core.thread;
public synchronized shared class A {
public:
void doSomething() {
// Doing something takes a couple of seconds.
Thread.sleep(2.dur!"seconds");
// How can we update the timestamp? Neither of those work
timestamp = Clock.currTime;
timestamp = cast(shared) Clock.currTime;
}
private:
SysTime timestamp;
}
void main() {
shared A a = new shared A;
spawn( (shared A a) { a.doSomething;}, a );
Thread.sleep(1.dur!"seconds");
spawn( (shared A a) { a.doSomething;}, a );
}
```
Of course the kludge (and what I'll be doing) is just to use __gshared,
but I expected this to be a convenience / hack to save you castings,
rather than the only way to achieve it.
A.
Re: Can't "is null" an interface?!?! Incompatible types???
On Thursday, 8 March 2018 at 08:04:54 UTC, Nick Sabalausky (Abscissa) wrote: Interesting. I was using vibe.d 'v0.8.3-rc.1' (which doesn't appear to work on run.dlang.io). But it does seem to work for me if I use 'v0.8.3-alpha.1'. I wonder what could have changed to result in this? It's a struct in "v0.8.3-rc.1" [1]. In "v0.8.3-rc.1" the new vibe-core package is the default configuration. [1] https://github.com/vibe-d/vibe-core/blob/master/source/vibe/core/net.d#L467 -- /Jacob Carlborg
Re: Can't "is null" an interface?!?! Incompatible types???
On 03/08/2018 03:04 AM, Nick Sabalausky (Abscissa) wrote: Interesting. I was using vibe.d 'v0.8.3-rc.1' (which doesn't appear to work on run.dlang.io). But it does seem to work for me if I use 'v0.8.3-alpha.1'. I wonder what could have changed to result in this? https://github.com/vibe-d/vibe.d/issues/2108
Re: Can't "is null" an interface?!?! Incompatible types???
On 03/08/2018 01:13 AM, Nicholas Wilson wrote:
That does seem odd.
---
/+dub.sdl:
dependency "vibe-d" version="~>0.8.3-alpha.1"
+/
import vibe.core.net;
import std.stdio;
TCPConnection mySocket;
void main() {
auto b = mySocket is null;
writeln(b);
}
---
works fine on run.dlang.io
Interesting. I was using vibe.d 'v0.8.3-rc.1' (which doesn't appear to
work on run.dlang.io). But it does seem to work for me if I use
'v0.8.3-alpha.1'.
I wonder what could have changed to result in this?
Re: Can't "is null" an interface?!?! Incompatible types???
On Thursday, 8 March 2018 at 04:48:08 UTC, Nick Sabalausky
(Abscissa) wrote:
-
import vibe.core.net;
TCPConnection mySocket;
void main() {
auto b = mySocket is null;
}
-
That's giving me:
-
Error: incompatible types for (mySocket) is (null):
TCPConnection and typeof(null)
-
WTF?!?!
The type in question (vibe.core.net.TCPConnection) is an
interface:
http://vibed.org/api/vibe.core.net/TCPConnection
https://github.com/vibe-d/vibe.d/blob/master/core/vibe/core/net.d#L344
The following works just fine:
-
interface IFoo {}
void main() {
IFoo i;
auto b = i is null;
}
-
That does seem odd.
---
/+dub.sdl:
dependency "vibe-d" version="~>0.8.3-alpha.1"
+/
import vibe.core.net;
import std.stdio;
TCPConnection mySocket;
void main() {
auto b = mySocket is null;
writeln(b);
}
---
works fine on run.dlang.io
Can't "is null" an interface?!?! Incompatible types???
-
import vibe.core.net;
TCPConnection mySocket;
void main() {
auto b = mySocket is null;
}
-
That's giving me:
-
Error: incompatible types for (mySocket) is (null): TCPConnection and
typeof(null)
-
WTF?!?!
The type in question (vibe.core.net.TCPConnection) is an interface:
http://vibed.org/api/vibe.core.net/TCPConnection
https://github.com/vibe-d/vibe.d/blob/master/core/vibe/core/net.d#L344
The following works just fine:
-
interface IFoo {}
void main() {
IFoo i;
auto b = i is null;
}
-
Re: Error: incompatible types for 'shared(SysTime)' and 'shared(SysTime)'
On 07/05/2016 07:25 AM, ketmar wrote: cast `shared` away. yes, this is how you supposed to use it now: cast it away. after having ensured thread safety that is
Re: Error: incompatible types for 'shared(SysTime)' and 'shared(SysTime)'
On Monday, 4 July 2016 at 20:54:53 UTC, Luke Picardo wrote: if (curTime - lastMsgTime).total!"seconds") ... Both are shared Durations. also when I try to do lastMsgTime = curTime; Gives me Error: non-shared method std.datetime.SysTime.opAssign is not callable using a shared object. cast `shared` away. yes, this is how you supposed to use it now: cast it away.
Error: incompatible types for 'shared(SysTime)' and 'shared(SysTime)'
if (curTime - lastMsgTime).total!"seconds") ... Both are shared Durations. also when I try to do lastMsgTime = curTime; Gives me Error: non-shared method std.datetime.SysTime.opAssign is not callable using a shared object.
Re: lovely compiler error message - incompatible types
On Thu, 02 Jul 2015 17:33:28 +, Laeeth Isharc wrote: FixedDecimal is a fixed decimal point struct that stores values as an int or long and takes number of decimal places as the second compile term argument. It's possible, if not likely I have made a mistake in implementing operator overloads. Any thoughts on whether this is the likely cause, and if so which ones are likely to be the problem? Can you show the signature for FixedDecimal's opBinary?
Re: lovely compiler error message - incompatible types
On Thursday, 2 July 2015 at 17:33:29 UTC, Laeeth Isharc wrote:
Any thoughts on what could be leading to the following:
./../../marketdata/source/pricebar.d(397): Error: incompatible
types for ((bar.high) + (bar.low)): 'FixedDecimal!(int, 8)' and
'FixedDecimal!(int, 8)'
../../../marketdata/source/pricebar.d(399): Error: incompatible
types for ((bar.high) + (bar.low)): 'FixedDecimal!(int, 8)' and
'FixedDecimal!(int, 8)'
../../../marketdata/source/pricebar.d(547): Error: incompatible
types for ((trueHigh(bars)) - (trueLow(bars))):
'FixedDecimal!(int, 8)' and 'FixedDecimal!(int, 8)'
FixedDecimal is a fixed decimal point struct that stores values
as an int or long and takes number of decimal places as the
second compile term argument. It's possible, if not likely I
have made a mistake in implementing operator overloads.
Any thoughts on whether this is the likely cause, and if so
which ones are likely to be the problem?
From the error messages it looks you didn't implement the
operator overloads properly.
You get the same message when FixedDecimal doesn't overload
anything at all:
struct FixedDecimal(T, uint n) {}
void main()
{
FixedDecimal!(int, 8) a, b;
auto c = a + b; /* line 5 */
}
test.d(5): Error: incompatible types for ((a) + (b)):
'FixedDecimal!(int, 8u)' and 'FixedDecimal!(int, 8u)'
You can get a more specific error by instantiating/calling things
explicitly. For example, here I messed up the parameter type:
struct FixedDecimal(T, uint n)
{
FixedDecimal opBinary(string op)(FixedDecimal!(T, 0))
{
return FixedDecimal.init;
}
}
void main()
{
FixedDecimal!(int, 8) a, b;
auto c = a + b; /* line 11 */
auto d = a.opBinary!+(b); /* line 12 */
}
test.d(11): Error: incompatible types for ((a) + (b)):
'FixedDecimal!(int, 8u)' and 'FixedDecimal!(int, 8u)'
test.d(12): Error: function test.FixedDecimal!(int,
8u).FixedDecimal.opBinary!+.opBinary (FixedDecimal!(int, 0u)
_param_0) is not callable using argument types
(FixedDecimal!(int, 8u))
The error for line 11 just says that something went wrong. The
one for line 12 is a little more helpful.
Re: lovely compiler error message - incompatible types
On 7/2/15 1:33 PM, Laeeth Isharc wrote: Hi. It's not easy to reduce, but I will have a go if other options fail. Any thoughts on what could be leading to the following: ../../../marketdata/source/pricebar.d(397): Error: incompatible types for ((bar.high) + (bar.low)): 'FixedDecimal!(int, 8)' and 'FixedDecimal!(int, 8)' .../../../marketdata/source/pricebar.d(399): Error: incompatible types for ((bar.high) + (bar.low)): 'FixedDecimal!(int, 8)' and 'FixedDecimal!(int, 8)' .../../../marketdata/source/pricebar.d(547): Error: incompatible types for ((trueHigh(bars)) - (trueLow(bars))): 'FixedDecimal!(int, 8)' and 'FixedDecimal!(int, 8)' FixedDecimal is a fixed decimal point struct that stores values as an int or long and takes number of decimal places as the second compile term argument. It's possible, if not likely I have made a mistake in implementing operator overloads. Any thoughts on whether this is the likely cause, and if so which ones are likely to be the problem? Can you post the signature to the operator overload? I have an idea of what it might be, but it's difficult to explain without context. -Steve
lovely compiler error message - incompatible types
Hi. It's not easy to reduce, but I will have a go if other options fail. Any thoughts on what could be leading to the following: ./../../marketdata/source/pricebar.d(397): Error: incompatible types for ((bar.high) + (bar.low)): 'FixedDecimal!(int, 8)' and 'FixedDecimal!(int, 8)' ../../../marketdata/source/pricebar.d(399): Error: incompatible types for ((bar.high) + (bar.low)): 'FixedDecimal!(int, 8)' and 'FixedDecimal!(int, 8)' ../../../marketdata/source/pricebar.d(547): Error: incompatible types for ((trueHigh(bars)) - (trueLow(bars))): 'FixedDecimal!(int, 8)' and 'FixedDecimal!(int, 8)' FixedDecimal is a fixed decimal point struct that stores values as an int or long and takes number of decimal places as the second compile term argument. It's possible, if not likely I have made a mistake in implementing operator overloads. Any thoughts on whether this is the likely cause, and if so which ones are likely to be the problem? Thanks. Laeeth.
Re: lovely compiler error message - incompatible types
On Thursday, 2 July 2015 at 18:01:39 UTC, Steven Schveighoffer wrote: On 7/2/15 1:33 PM, Laeeth Isharc wrote: Hi. It's not easy to reduce, but I will have a go if other options fail. Any thoughts on what could be leading to the following: ../../../marketdata/source/pricebar.d(397): Error: incompatible types for ((bar.high) + (bar.low)): 'FixedDecimal!(int, 8)' and 'FixedDecimal!(int, 8)' .../../../marketdata/source/pricebar.d(399): Error: incompatible types for ((bar.high) + (bar.low)): 'FixedDecimal!(int, 8)' and 'FixedDecimal!(int, 8)' .../../../marketdata/source/pricebar.d(547): Error: incompatible types for ((trueHigh(bars)) - (trueLow(bars))): 'FixedDecimal!(int, 8)' and 'FixedDecimal!(int, 8)' FixedDecimal is a fixed decimal point struct that stores values as an int or long and takes number of decimal places as the second compile term argument. It's possible, if not likely I have made a mistake in implementing operator overloads. Any thoughts on whether this is the likely cause, and if so which ones are likely to be the problem? Can you post the signature to the operator overload? I have an idea of what it might be, but it's difficult to explain without context. -Steve Thank you for this. Will do when back at my pc. It went away when I did alias this to the underlying integer, so I guess that probably confirms what you suggested. But I shouldn't leave it that way.
Re: lovely compiler error message - incompatible types
Can you post the signature to the operator overload? I have an idea of what it might be, but it's difficult to explain without context. -Steve https://gist.github.com/Laeeth/6251fa731e4cee84bcdc not really a proper implementation. I wanted something as a placeholder today that I could implement properly later...
Re: lovely compiler error message - incompatible types
On Thu, 02 Jul 2015 21:03:37 +, Laeeth Isharc wrote: Can you post the signature to the operator overload? I have an idea of what it might be, but it's difficult to explain without context. -Steve https://gist.github.com/Laeeth/6251fa731e4cee84bcdc not really a proper implementation. I wanted something as a placeholder today that I could implement properly later... I think the issue is that your opBinary requires that isNumeric!T be true. This is the case if FixedDecimal is allowed to decay to the underlying int which is why it works when you use the alias this. I recommend removing the alias this and adding another overload like this: FixedDecimal opBinary(string s, T : FixedDecimal)(const T rhs)
Re: lovely compiler error message - incompatible types
On Thursday, 2 July 2015 at 21:19:19 UTC, Justin Whear wrote: On Thu, 02 Jul 2015 21:03:37 +, Laeeth Isharc wrote: Can you post the signature to the operator overload? I have an idea of what it might be, but it's difficult to explain without context. -Steve https://gist.github.com/Laeeth/6251fa731e4cee84bcdc not really a proper implementation. I wanted something as a placeholder today that I could implement properly later... I think the issue is that your opBinary requires that isNumeric!T be true. This is the case if FixedDecimal is allowed to decay to the underlying int which is why it works when you use the alias this. I recommend removing the alias this and adding another overload like this: FixedDecimal opBinary(string s, T : FixedDecimal)(const T rhs) Thanks v much ! Of course I guess it isn't numeric to the compiler...
Re: incompatible types!
On Wed, 06 Apr 2011 12:32:37 -0400, simendsjo simen.end...@pandavre.com wrote: Both the d1 and d2 homepage states the following: There are two versions of the language: 1. D version 1 which is in maintenance mode. 2. D version 2 which is recommended for new projects. Should it mention that d2 is beta and phobos alpha? Or are you alone in thinking that? I would recommend that it said this. Maybe I'm alone, and everyone else has no issues when they use D2. It's not up to me what to say on digitalmars, I am not in charge of that page. BTW, if it's a choice between D1/phobos and D2/phobos, I highly recommend D2/phobos. D1 phobos is woefully inadequate for any real projects (when I first learned D it was for a networking project at work, and I tried D1/phobos for about a week before looking for something better), I recommend D1/tango if you want to use D1. -Steve
Re: incompatible types!
On 06.04.2011 02:15, Steven Schveighoffer wrote: On Tue, 05 Apr 2011 19:37:15 -0400, Caligo iteronve...@gmail.com wrote: It's just frustrating, that's all. Writing thousands of lines of code and having everything stop because of a compiler bug is just frustrating. I completely understand. It's why I have to periodically stop using D. Dcollections sat idle for over a year while I waited for a compiler bug to be fixed. I know progress is being made, and all that is appreciated. But, I don't remember ever hearing anything about D2 being in beta. If anything, I remember months ago where D2 was recommended for new projects. So, now I'm not sure what I'm supposed to do. Start all over again from scratch? I really like my design, so I guess I'll have to wait till it gets fixed. Sorry you got that impression. The fact is, as long as you are using the non-broken features, D2 is pretty useful, even downright awesome :) The issue is, if you hit one of those broken ones. Unfortunately, the release of TDPL didn't make all those features magically appear fully implemented. So since TDPL is promoted as the offical language spec, D2 suddenly jumped way back in the release cycle, since many of its unimplemented/not-fully-implemented features became official. I'd highly recommend *NOT* to use D2 for new projects unless you are willing to redesign your code to work around those issues, or wait for them to be fixed. I truly wish this wasn't the case, but I don't see how anyone can confidently recommend D2 for professional or non-toy projects. This may sound like an anti-endorsement, but I assure you it is not. I think D2 is going to be absolutely killer when it's finished. I just would not use it for professional development *right now*, where deadlines and budgets are under consideration. If you can afford to put it down when it breaks and wait for a fix, then I think it will be worth the wait. -Steve Both the d1 and d2 homepage states the following: There are two versions of the language: 1. D version 1 which is in maintenance mode. 2. D version 2 which is recommended for new projects. Should it mention that d2 is beta and phobos alpha? Or are you alone in thinking that?
Re: incompatible types!
What's strange is that auto r3 = r1 + r2; works. Bug indeed...
Re: incompatible types!
On Tue, 05 Apr 2011 15:48:36 -0400, Caligo iteronve...@gmail.com wrote: I searched the bugzilla and there are 'alias this' related bugs. Some of them are 2 years old and have not been fixed. There are many bugs in that category. inout I think is a prime example. I don't really know what to say to appease your expectations, except to have patience or try learning the comipler code. If I had time and was compiler-savvy I might fix some bugs, but I don't and I'm not. Walter and Don seem to do a lot of good bug fixes, and usually these are critical issues. I think it won't be long before Walter or Don can start working on half-implemented features. I know of no timeline though. I've heard bugs get fixed rather quickly if something is posted on reddit about them. I wouldn't push this avenue too much, if it is true, it's likely to become not true quite quickly if abused. I think it's more that bugs posted on reddit from people outside the D community look like outward-facing warts, and Walter and Andrei have a compulsive urge to make sure those are covered up quickly. I personally don't see why it's important, as long as progress is being made on *something*. Clearly the most visible wart was lack of 64-bit support, and that is almost resolved. But progress *is* being made. I think that's what's important right now. D2 is still very much beta, and Phobos 2 is very much alpha. -Steve
Re: incompatible types!
It's just frustrating, that's all. Writing thousands of lines of code and having everything stop because of a compiler bug is just frustrating. I know progress is being made, and all that is appreciated. But, I don't remember ever hearing anything about D2 being in beta. If anything, I remember months ago where D2 was recommended for new projects. So, now I'm not sure what I'm supposed to do. Start all over again from scratch? I really like my design, so I guess I'll have to wait till it gets fixed.
Re: incompatible types!
On Tue, 05 Apr 2011 19:37:15 -0400, Caligo iteronve...@gmail.com wrote: It's just frustrating, that's all. Writing thousands of lines of code and having everything stop because of a compiler bug is just frustrating. I completely understand. It's why I have to periodically stop using D. Dcollections sat idle for over a year while I waited for a compiler bug to be fixed. I know progress is being made, and all that is appreciated. But, I don't remember ever hearing anything about D2 being in beta. If anything, I remember months ago where D2 was recommended for new projects. So, now I'm not sure what I'm supposed to do. Start all over again from scratch? I really like my design, so I guess I'll have to wait till it gets fixed. Sorry you got that impression. The fact is, as long as you are using the non-broken features, D2 is pretty useful, even downright awesome :) The issue is, if you hit one of those broken ones. Unfortunately, the release of TDPL didn't make all those features magically appear fully implemented. So since TDPL is promoted as the offical language spec, D2 suddenly jumped way back in the release cycle, since many of its unimplemented/not-fully-implemented features became official. I'd highly recommend *NOT* to use D2 for new projects unless you are willing to redesign your code to work around those issues, or wait for them to be fixed. I truly wish this wasn't the case, but I don't see how anyone can confidently recommend D2 for professional or non-toy projects. This may sound like an anti-endorsement, but I assure you it is not. I think D2 is going to be absolutely killer when it's finished. I just would not use it for professional development *right now*, where deadlines and budgets are under consideration. If you can afford to put it down when it breaks and wait for a fix, then I think it will be worth the wait. -Steve
Re: incompatible types!
On Tue, 05 Apr 2011 19:37:15 -0400, Caligo iteronve...@gmail.com wrote: It's just frustrating, that's all. Writing thousands of lines of code and having everything stop because of a compiler bug is just frustrating. I completely understand. It's why I have to periodically stop using D. Dcollections sat idle for over a year while I waited for a compiler bug to be fixed. I know progress is being made, and all that is appreciated. But, I don't remember ever hearing anything about D2 being in beta. If anything, I remember months ago where D2 was recommended for new projects. So, now I'm not sure what I'm supposed to do. Start all over again from scratch? I really like my design, so I guess I'll have to wait till it gets fixed. Sorry you got that impression. The fact is, as long as you are using the non-broken features, D2 is pretty useful, even downright awesome :) The issue is, if you hit one of those broken ones. Unfortunately, the release of TDPL didn't make all those features magically appear fully implemented. So since TDPL is promoted as the offical language spec, D2 suddenly jumped way back in the release cycle, since many of its unimplemented/not-fully-implemented features became official. I'd highly recommend *NOT* to use D2 for new projects unless you are willing to redesign your code to work around those issues, or wait for them to be fixed. I truly wish this wasn't the case, but I don't see how anyone can confidently recommend D2 for professional or non-toy projects. This may sound like an anti-endorsement, but I assure you it is not. I think D2 is going to be absolutely killer when it's finished. I just would not use it for professional development *right now*, where deadlines and budgets are under consideration. If you can afford to put it down when it breaks and wait for a fix, then I think it will be worth the wait. IIRC, Adam Ruppe uses D2 for professional development, and he discusses it from time to time on the main d newsgroup, but he specifically avoids some of the newer features. He rarely runs into problems with compiler. On the other hand, folks who consistently try and use the newer features in their code - especially when they try and mix them - run into problems all too frequently. I ran into a number of major issues while creating std.datetime. A number of them have been fixed now. Others remain unfixed and still affect affect std.datetime to some degree (e.g. it's impossible to create an immutable SysTime). But std.datetime uses some of the newer features quite heavily (though alias this isn't one of them). So, if you restrict what you do with D2 to an older subset of the language, you're likely to be fine. But if you try and use a lot of the newer features, you _will_ run into bugs. And alias this is definitely one of the areas with problems. Personally, I only use D2 for my personal stuff, but as much as I'd like to use it at work, I wouldn't even attempt to yet. The language is stabilizing, and the compiler and libraries are definitely improving, but if you expect rock-solid stability, you're going to be dissapointed. We're getting there, but we're not there yet. - Jonathan M Davis
