Re: Vibe-d issue with timer in separate thread on debug builds
On Thursday, 18 January 2018 at 10:03:57 UTC, drug wrote: 18.01.2018 08:45, Andres Clari пишет: I see, then although it works (or it may work) on release shouldn't that assert happen for release builds by default too? Or is the thought that you got the error running the debug build you should do it a different way on your own and skip the check all together? asserts are disabled in release mode, so you have no it. Better would be say it seems to be working in release mode. Ahh, that explains it. Indeed. Well I won't complain for now as it seems to be allowing me to do what I meant to do. :)
Re: __gshared as part of alias
On Wednesday, 17 January 2018 at 22:56:09 UTC, kinke wrote:
On Wednesday, 17 January 2018 at 22:01:57 UTC, Johan Engelen
wrote:
```
struct GSharedVariable(AddrSpace as, T)
{
static __gshared T val;
alias val this;
}
alias Global(T) = GSharedVariable!(AddrSpace.Global, T);
Global!float bar1; // __gshared
```
Only 1 value per T though. ;)
Ah, haha indeed, I meant without the "static", but __gshared is
always "static".
```
alias Global(T) = shared Variable!(AddrSpace.Global, T);
```
seems to work.
https://godbolt.org/g/iDbRX7
-Johan
Re: New integer promotion rules
On Thursday, 18 January 2018 at 18:00:51 UTC, rumbu wrote: On Thursday, 18 January 2018 at 17:54:59 UTC, rumbu wrote: On Thursday, 18 January 2018 at 12:51:48 UTC, Dominikus Dittes target = isNegative ? cast(Unsigned!T)(-c) : cast(Unsigned!T)c; That would have been better even before the change, because the operator '-' used on unsigned types is likely to produce unexpected results, if the behaviour is defined at all. I don't think so: ulong c = 128; bool isNegative = true; byte target = isNegative ? -cast(ubyte)c : cast(ubyte)c; Error Deprecation: integral promotion not done for `-cast(ubyte)c`, use '-transition=intpromote' switch or `-cast(int)(cast(ubyte)c)` My bad, it works. Thanks: ulong c = 128; bool isNegative = true; byte target = isNegative ? cast(ubyte)-c : cast(ubyte)c; But this doesn't: ushort c = 128; bool isNegative = true; byte target = isNegative ? cast(ubyte)-c : cast(ubyte)c; Error Deprecation: integral promotion not done for `-c`, use '-transition=intpromote' switch or `-cast(int)(c) This is starting to become truly crazy.
Re: New integer promotion rules
On Thursday, 18 January 2018 at 17:54:59 UTC, rumbu wrote: On Thursday, 18 January 2018 at 12:51:48 UTC, Dominikus Dittes target = isNegative ? cast(Unsigned!T)(-c) : cast(Unsigned!T)c; That would have been better even before the change, because the operator '-' used on unsigned types is likely to produce unexpected results, if the behaviour is defined at all. I don't think so: ulong c = 128; bool isNegative = true; byte target = isNegative ? -cast(ubyte)c : cast(ubyte)c; Error Deprecation: integral promotion not done for `-cast(ubyte)c`, use '-transition=intpromote' switch or `-cast(int)(cast(ubyte)c)` My bad, it works. Thanks: ulong c = 128; bool isNegative = true; byte target = isNegative ? cast(ubyte)-c : cast(ubyte)c;
Re: New integer promotion rules
On Thursday, 18 January 2018 at 12:51:48 UTC, Dominikus Dittes Scherkl wrote: On Thursday, 18 January 2018 at 06:05:08 UTC, rumbu wrote: On Thursday, 18 January 2018 at 02:30:17 UTC, Rubn wrote: On Wednesday, 17 January 2018 at 22:30:11 UTC, rumbu wrote: code like "m = n < 0 ? -n : n" doesn't worth a wrapper That code is worth a wrapper, it's called "abs"... m = abs(n); Well, since I'm in the learn forum and you seem to have a response to anything, can you help me translate this line under the new integer promotion rules? https://github.com/rumbu13/decimal/blob/master/src/decimal/decimal.d#L7804 Thanks. target = isNegative ? cast(Unsigned!T)(-c) : cast(Unsigned!T)c; That would have been better even before the change, because the operator '-' used on unsigned types is likely to produce unexpected results, if the behaviour is defined at all. I don't think so: ulong c = 128; bool isNegative = true; byte target = isNegative ? -cast(ubyte)c : cast(ubyte)c; Error Deprecation: integral promotion not done for `-cast(ubyte)c`, use '-transition=intpromote' switch or `-cast(int)(cast(ubyte)c)`
Re: cast ref pointer
On Thursday, 18 January 2018 at 16:26:54 UTC, Luís Marques wrote:
The actual function bar also receives by ref its pointer.
you might be better off receiving a pointer-to-pointer instead of
ref. Then it will be encoded in the type and thus you can cast
outer layers too and use intermediate more easily if you need.
void foo(void** f) {
bar(cast(int**) f);
}
int* a;
foo();
Re: Any sample how to use Sqlite-d?
On Wednesday, 17 January 2018 at 13:36:26 UTC, Marc wrote: I was looking for a library to use SQLite with D, found this (https://code.dlang.org/packages/sqlite-d) but it has no documentation or code example. I looked into files in the source code and wrote this: Database db = Database(name); auto table = db.table(tableName); auto rows = table.findRows!(format!"(id,date) => id == %s"(id)); (i'm aware of sql injection above) but it doesnt work, it seems the library has changed. If happen to that library author see this, would be very helpful. Also have a look at https://github.com/biozic/d2sqlite3 (documentation: http://biozic.github.io/d2sqlite3/d2sqlite3.html).
Re: New integer promotion rules
On 01/18/2018 05:22 PM, Steven Schveighoffer wrote: Sure, but what does the statement "Once deprecated this will become an error" mean? Will I have to use the -transition=intpromote switch forever to avoid an error? As you quoted before: "Once deprecated this will become an error, and then the C-like behavior will become the default." I'm interpreting that to mean that it will become an error for some time, but later it will be allowed again with the new behavior. And then you can throw away `-transition=intpromote`.
Re: cast ref pointer
On Thursday, 18 January 2018 at 16:14:18 UTC, ag0aep6g wrote: On 01/18/2018 04:25 PM, Luís Marques wrote: You need a reinterpret-style cast here to get an lvalue: foo(* cast(int**) ); Right, that's what I wanted. Ugh, for some reason I was totally confused about this :-) writeln(*cast(int*) *ptr); You're dereferencing twice here. Do it only once, after casting: That was just a typo. That way, `ptr` itself won't be updated by `foo`, of course. But `ptr` isn't a `ref` parameter, so this only affects the insides of `bar` anyway. Yeah, it was a bad example.
Re: cast ref pointer
On Thursday, 18 January 2018 at 16:20:35 UTC, Steven Schveighoffer wrote: Note, this, to me, seems odd. Of course this is not the full case, but you are not affecting anything except for the value of the local `ptr`. So I would be concerned this may not be what you want (if you are looking to affect something outside the callback). Yeah, I went overboard in reducing my scenario :( The actual function bar also receives by ref its pointer.
Re: New integer promotion rules
On 1/18/18 11:14 AM, ag0aep6g wrote: On 01/18/2018 03:30 PM, Steven Schveighoffer wrote: Is there going to be a point where casts aren't needed? Otherwise, this is pretty ugly. You don't need casts when you use `-transition=intpromote`. Sure, but what does the statement "Once deprecated this will become an error" mean? Will I have to use the -transition=intpromote switch forever to avoid an error? Thinking about the fact that the deprecation doesn't show an error for the -transition switch, makes me think possibly the changelog message is incorrect. -Steve
Re: cast ref pointer
On Thursday, 18 January 2018 at 16:08:32 UTC, Adam D. Ruppe wrote: Simply define an intermediate. int* tmp = cast(int*) that_void_pointer; foo(tmp); In my actual case bar also receives its pointer by ref, so you would have to do something like: int* tmp = cast(int*) that_void_pointer; foo(tmp); that_void_pointer = tmp; This is a bit more noisy than what I would prefers (a more care is needed to check if this is properly optimized away), that's why I was looking for a more direct route, like a cast.
Re: cast ref pointer
On 1/18/18 10:25 AM, Luís Marques wrote:
This works, obviously (i.e. it prints 42):
void foo(ref int* a)
{
static int j = 42;
a =
}
void bar(int* ptr)
{
foo(ptr);
writeln(*ptr);
}
Note, this, to me, seems odd. Of course this is not the full case, but
you are not affecting anything except for the value of the local `ptr`.
So I would be concerned this may not be what you want (if you are
looking to affect something outside the callback).
Other than that, the other responders are right, you just need to
reinterpret the pointer.
-Steve
Re: New integer promotion rules
On 01/18/2018 03:30 PM, Steven Schveighoffer wrote: Is there going to be a point where casts aren't needed? Otherwise, this is pretty ugly. You don't need casts when you use `-transition=intpromote`.
Re: cast ref pointer
On 01/18/2018 04:25 PM, Luís Marques wrote:
This works, obviously (i.e. it prints 42):
void foo(ref int* a)
{
static int j = 42;
a =
}
void bar(int* ptr)
{
foo(ptr);
writeln(*ptr);
}
void main()
{
int i = 7;
bar();
}
Unfortunately, if bar for some reason receives a void* pointer (e.g. C
callback) this doesn't work:
void bar(void* ptr)
{
foo(cast(int*) ptr); // error
You need a reinterpret-style cast here to get an lvalue:
foo(* cast(int**) );
The result has the same type (int*), but it refers to the very same
memory location as `` does. So it's not just a temporary value, and
it can be passed in a `ref` parameter.
writeln(*cast(int*) *ptr);
You're dereferencing twice here. Do it only once, after casting:
writeln(* cast(int*) ptr);
}
Alernatively, you can make a local variable for the casted pointer and
use that instead of the `ptr`:
int* casted_ptr = cast(int*) ptr;
foo(casted_ptr);
writeln(*casted_ptr);
That way, `ptr` itself won't be updated by `foo`, of course. But `ptr`
isn't a `ref` parameter, so this only affects the insides of `bar` anyway.
Re: cast ref pointer
On Thursday, 18 January 2018 at 15:25:38 UTC, Luís Marques wrote: I think the underlying idea is sound (use ptr as an lvalue, but with int* type), but since you can't cast(ref int*), I don't know how to express it in D code. Simply define an intermediate. int* tmp = cast(int*) that_void_pointer; foo(tmp);
cast ref pointer
This works, obviously (i.e. it prints 42):
void foo(ref int* a)
{
static int j = 42;
a =
}
void bar(int* ptr)
{
foo(ptr);
writeln(*ptr);
}
void main()
{
int i = 7;
bar();
}
Unfortunately, if bar for some reason receives a void* pointer
(e.g. C callback) this doesn't work:
void bar(void* ptr)
{
foo(cast(int*) ptr); // error
writeln(*cast(int*) *ptr);
}
I think the underlying idea is sound (use ptr as an lvalue, but
with int* type), but since you can't cast(ref int*), I don't know
how to express it in D code.
Re: New integer promotion rules
On 1/17/18 2:40 PM, rumbu wrote: This started in the last DMD version (2.078): byte b = -10; ulong u = b < 0 ? -b : b; //Deprecation: integral promotion not done for `-b`, use '-transition=intpromote' switch or `-cast(int)(b) Why do I need a to promote a byte to int to obtain an ulong? Even in the extreme case where b is byte.min, -byte.min as unsigned is exactly what i need: 128; This leads to more cases: ubyte u = cast(ubyte)-b; //Deprecation: integral promotion not done for `-b`, use '-transition=intpromote' switch or `-cast(int)(b)` Last time I checked, casting is somehow synonym with "I know what I'm doing", why do I need another cast to prove my sanity: ubyte u = cast(ubyte)-cast(int)b; I was going to respond with a helpful guide on what to do here, but I either misunderstand the docs, or I don't agree with the transition requirements. I thought that you could simply ignore this deprecation message if it doesn't affect you (i.e. you don't have the possibility of seeing the corner cases that are fixed), but looking at the changelog it says: "Once deprecated this will become an error, and then the C-like behavior will become the default." So this says, even if you aren't affected, you *still* have to add casts to avoid a future error? I thought it was going to be deprecated, and then after some number of versions it would just be switched to the new behavior. Is there going to be a point where casts aren't needed? Otherwise, this is pretty ugly. -Steve
Re: New integer promotion rules
On Thursday, 18 January 2018 at 06:05:08 UTC, rumbu wrote: On Thursday, 18 January 2018 at 02:30:17 UTC, Rubn wrote: On Wednesday, 17 January 2018 at 22:30:11 UTC, rumbu wrote: code like "m = n < 0 ? -n : n" doesn't worth a wrapper That code is worth a wrapper, it's called "abs"... m = abs(n); Well, since I'm in the learn forum and you seem to have a response to anything, can you help me translate this line under the new integer promotion rules? https://github.com/rumbu13/decimal/blob/master/src/decimal/decimal.d#L7804 Thanks. target = isNegative ? cast(Unsigned!T)(-c) : cast(Unsigned!T)c; That would have been better even before the change, because the operator '-' used on unsigned types is likely to produce unexpected results, if the behaviour is defined at all.
Re: Vibe-d issue with timer in separate thread on debug builds
18.01.2018 08:45, Andres Clari пишет: I see, then although it works (or it may work) on release shouldn't that assert happen for release builds by default too? Or is the thought that you got the error running the debug build you should do it a different way on your own and skip the check all together? asserts are disabled in release mode, so you have no it. Better would be say it seems to be working in release mode.
