Re: Hex constant method starts from ".a": 0xCCCCCC.argb
On Monday, 14 December 2020 at 05:37:21 UTC, Paul Backus wrote: On Monday, 14 December 2020 at 05:27:40 UTC, Виталий Фадеев wrote: ".rgb" Compiled fine. ".argb" Compilation error. Source: https://run.dlang.io/is/ULQ4kh It's parsing the `.a` in `.argb` as part of the number: auto color = 0x00AABBCC.a rgb; // what the compiler sees You can fix it with parentheses: auto color = (0x00AABBCC).argb; Thanks! It is not perfect, but also beauty!
Re: Hex constant method starts from ".a": 0xCCCCCC.argb
On Monday, 14 December 2020 at 05:27:40 UTC, Виталий Фадеев wrote: ".rgb" Compiled fine. ".argb" Compilation error. Source: https://run.dlang.io/is/ULQ4kh It's parsing the `.a` in `.argb` as part of the number: auto color = 0x00AABBCC.a rgb; // what the compiler sees You can fix it with parentheses: auto color = (0x00AABBCC).argb;
Re: Hex constant method starts from ".a": 0xCCCCCC.argb
On Monday, 14 December 2020 at 05:24:39 UTC, Виталий Фадеев wrote:
... msg ...
But...:
Color rgb( uint color )
{
return
Color( cast( uint ) (
( ( color & 0x00FF ) << 16 ) |
( ( color & 0xFF00 ) ) |
( ( color & 0x00FF ) >> 16 )
) );
}
unittest
{
auto color2 = 0x00AABBCC.rgb;
}
".rgb" Compiled fine.
".argb" Compilation error.
Source:
https://run.dlang.io/is/ULQ4kh
Hex constant method starts from ".a": 0xCCCCCC.argb
We have:
static import winapi=core.sys.windows.windows;
struct Color
{
union
{
winapi.COLORREF native;
struct
{
ubyte r;
ubyte g;
ubyte b;
}
}
ubyte a = 0xFF;
}
Color argb( uint color )
{
Color c;
c.native =
cast( uint ) (
( ( color & 0x00FF ) << 16 ) |
( ( color & 0xFF00 ) ) |
( ( color & 0x00FF ) >> 16 )
);
c.a = ( color & 0xFF00 ) >> 24;
return c;
}
Goal:
auto color = 0x00AABBCC.argb;
Has error:
Error: exponent required for hex float
( at 0x00AABBCC.argb )
What is it ?
How to implement beauty code like the: #CC.rgb ?
Re: Can I use dub to generate docs?
On Monday, 14 December 2020 at 02:54:12 UTC, Jack wrote: like dmd's -D flag? dub build --build=docs
Can I use dub to generate docs?
like dmd's -D flag?
Re: presence of function template prevents diagnostic
On Monday, 16 November 2020 at 18:34:14 UTC, Max Haughton wrote: [...] Probably should be a bug. filed as Issue 21481
Re: uncaught exceptions: stack trace truncated at NUL char
On Sunday, 13 December 2020 at 22:40:53 UTC, Paul Backus wrote: This is definitely a bug. filed as Issue 21480
Re: uncaught exceptions: stack trace truncated at NUL char
On Sunday, 13 December 2020 at 21:22:16 UTC, kdevel wrote: On Sunday, 13 December 2020 at 20:58:42 UTC, rikki cattermole wrote: [...] String literals are null terminated by the compiler. It is very useful for communicating with C. Sure, but in the example given there is an embedded NUL which as part of an exception msg. If caught everything works as expected, but if the stack is unwound the information is lost due to truncation. This is definitely a bug. The problem is that the D runtime uses `fprintf` to print the exception's error message, when it should be using `fwrite`: https://github.com/dlang/druntime/blob/v2.094.2/src/rt/dmain2.d#L733
Re: uncaught exceptions: stack trace truncated at NUL char
On Sunday, 13 December 2020 at 20:58:42 UTC, rikki cattermole wrote: [...] String literals are null terminated by the compiler. It is very useful for communicating with C. Sure, but in the example given there is an embedded NUL which as part of an exception msg. If caught everything works as expected, but if the stack is unwound the information is lost due to truncation.
Re: uncaught exceptions: stack trace truncated at NUL char
On 14/12/2020 9:56 AM, kdevel wrote: On Sunday, 13 December 2020 at 20:25:06 UTC, KapyoniK wrote: Is it really a bug ? \0 truncates the string, as mentionned on this page : https://en.wikipedia.org/wiki/Null-terminated_string I thought the D runtime is written in D (with D strings)?!? String literals are null terminated by the compiler. It is very useful for communicating with C.
Re: uncaught exceptions: stack trace truncated at NUL char
On Sunday, 13 December 2020 at 20:25:06 UTC, KapyoniK wrote: Is it really a bug ? \0 truncates the string, as mentionned on this page : https://en.wikipedia.org/wiki/Null-terminated_string I thought the D runtime is written in D (with D strings)?!?
Re: uncaught exceptions: stack trace truncated at NUL char
On Sunday, 13 December 2020 at 11:51:19 UTC, kdevel wrote:
~~~char2.d
void main ()
{
import std.stdio;
import std.conv;
char [2] win = [0, 'X'];
auto ne = new Exception ("A " ~ win.to!string ~ " B");
try throw ne;
catch (Exception e)
writeln ("exception caught: e.msg = <", e.msg, ">");
throw ne;
}
~~~
[...]
Is it really a bug ? \0 truncates the string, as mentionned on
this page :
https://en.wikipedia.org/wiki/Null-terminated_string
Re: How to check that function gets ref parameter?
On Sunday, 13 December 2020 at 16:41:06 UTC, Andrey Zherikov
wrote:
I'm trying to check that function has 'ref' parameter. The only
way I found so far is to use std.traits.Parameters.
Here is the code I have:
void f(int) {}
void g(ref int) {}
void main()
{
writeln(Parameters!f[0].stringof);
writeln(__traits(isRef, Parameters!f[0]));
writeln(Parameters!g.stringof);
writeln(Parameters!g[0].stringof);
writeln(__traits(isRef, Parameters!g[0]));
}
The output is:
int
false
(ref int)
int
false
"Parameters!g[0]" strips off 'ref' qualifier as you can see.
How can I make it work?
You use the wrong traits, try ParameterStorageClassTuple instead:
void f(int) {}
void g(ref int) {}
import std.traits : ParameterStorageClass,
ParameterStorageClassTuple;
static assert(ParameterStorageClassTuple!g[0] ==
ParameterStorageClass.ref_);
static assert(ParameterStorageClassTuple!f[0] !=
ParameterStorageClass.ref_);
Re: UFCS functions with both pointers and refs
On Sunday, 13 December 2020 at 18:44:20 UTC, Mike Parker wrote: On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote: Do I have to write both and have one forward to the other for more complicated functions? For free functions, yes. Is there any way to write the function as a template that is generic over a parameter being a pointer or a reference, but does not allow passing a copy?
Re: UFCS functions with both pointers and refs
On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote:
If I define a method on a type, then I can call it both through
a pointer and
through a reference and the compiler does the right thing. Eg:
struct Foo {
int x;
void fooey(){
x++;
}
void report(){
printf("%d\n", x);
}
}
int main(){
Foo f;
f.fooey;
Foo* pf =
pf.fooey;
f.report; // prints 2
return 0;
}
However, if I define it as a free function and try to invoke it
via UFCS,
it seems like I have to define it twice.
struct Foo {
int x;
void report(){
printf("%d\n", x);
}
}
void fooey(Foo* f){
f.x++;
}
void fooey(ref Foo f){
f.x++;
}
int main(){
Foo f;
f.fooey;
Foo* pf =
pf.fooey;
f.report; // prints 2
return 0;
}
Am I missing something or is this just how it has to work
generally?
These are two very different concepts.
Member functions have a hidden 'this' parameter as the first
function parameter. For structs, it's a reference to the
instance. Whether you call it through a pointer or a reference,
that never changes: there's only one implementation of the
function, the first parameter is always a reference to the
instance.
Free functions do not belong to any type (hence the "free"). UFCS
doesn't change that. UFCS is simply a convenience that rewrites
`foo.func` as `func(foo)`. You aren't calling "through" a pointer
or a reference. So if the first parameter is a pointer, you can't
give it a reference, and vice versa.
Do I have to write both and have one forward to the other for
more
complicated functions?
For free functions, yes.
UFCS functions with both pointers and refs
If I define a method on a type, then I can call it both through a
pointer and
through a reference and the compiler does the right thing. Eg:
struct Foo {
int x;
void fooey(){
x++;
}
void report(){
printf("%d\n", x);
}
}
int main(){
Foo f;
f.fooey;
Foo* pf =
pf.fooey;
f.report; // prints 2
return 0;
}
However, if I define it as a free function and try to invoke it
via UFCS,
it seems like I have to define it twice.
struct Foo {
int x;
void report(){
printf("%d\n", x);
}
}
void fooey(Foo* f){
f.x++;
}
void fooey(ref Foo f){
f.x++;
}
int main(){
Foo f;
f.fooey;
Foo* pf =
pf.fooey;
f.report; // prints 2
return 0;
}
Am I missing something or is this just how it has to work
generally?
Do I have to write both and have one forward to the other for more
complicated functions?
Re: MonoTimeImpl!(ClockType.normal) failed to get the frequency of the system's monotonic clock.
On Sunday, 13 December 2020 at 17:34:26 UTC, rikki cattermole
wrote:
Did you initialize the D runtime before you called the D code?
(assuming C main).
wow, thanks for such quck response. That's exactly what I missing
in this function:
version(Posix)
{
import core.runtime : rt_init, rt_term;
rt_init();
scope(exit) rt_term();
}
thanks!
Re: MonoTimeImpl!(ClockType.normal) failed to get the frequency of the system's monotonic clock.
Did you initialize the D runtime before you called the D code? (assuming C main).
MonoTimeImpl!(ClockType.normal) failed to get the frequency of the system's monotonic clock.
I have this D code base that when I compile to executable, it ran fine, but when I call the very same function from C, I get this error: Aborting from src/core/time.d(2113) MonoTimeImpl!(ClockType.normal) failed to get the frequency of the system's monotonic clock. from source code[1] I see ticksPerSecond failed to get a value but how don't know why and how can I fix that? can I track the line of code calling that function that end up with abort() call? my OS is openSUSE Leap 15.0, DMD64 D Compiler v2.094.2, DUB version 1.23.0, built on Nov 20 2020 [1]:https://github.com/dlang/druntime/blob/fd5f4e2dded204b01d977c695c3ff910a699bc52/src/core/time.d#2113
How to check that function gets ref parameter?
I'm trying to check that function has 'ref' parameter. The only
way I found so far is to use std.traits.Parameters.
Here is the code I have:
void f(int) {}
void g(ref int) {}
void main()
{
writeln(Parameters!f[0].stringof);
writeln(__traits(isRef, Parameters!f[0]));
writeln(Parameters!g.stringof);
writeln(Parameters!g[0].stringof);
writeln(__traits(isRef, Parameters!g[0]));
}
The output is:
int
false
(ref int)
int
false
"Parameters!g[0]" strips off 'ref' qualifier as you can see. How
can I make it work?
uncaught exceptions: stack trace truncated at NUL char
~~~char2.d
void main ()
{
import std.stdio;
import std.conv;
char [2] win = [0, 'X'];
auto ne = new Exception ("A " ~ win.to!string ~ " B");
try throw ne;
catch (Exception e)
writeln ("exception caught: e.msg = <", e.msg, ">");
throw ne;
}
~~~
Output:
exception caught: e.msg =
object.Exception@char2.d(6): A <--- truncated at \0
[...]
$ ./char2 | hexdump -c
000 e x c e p t i o n c a u g
h t
010 : e . m s g = < A \0
X
020 B > \n
$ ./char2 2>&1 1>/dev/null |hexdump -c
000 o b j e c t . E x c e p t i
o n
010 @ c h a r 2 . d ( 6 ) : A
\n
020 - - - - - - - - - - - - - -
- -
[...]
Shall I file a bug?
