Re: cannot alias array ;/
On Thursday, 19 January 2017 at 08:06:04 UTC, ketmar wrote:
alias is not a macro, it is alias to *symbol*. only symbol, not
any arbitrary expression.
In fact, it can nowadays be. You just have to mark it so, with a
lambda:
void main()
{ import std.stdio;
auto myArray = [2, 3, 5, 6];
int k = 2;
alias a = () => myArray[k];
writeln(a());
k = 3;
writeln(a());
}
//result:
//5
//6
The downside with this (and function pointers and delegates)
compared to defining functions is that you cannot call it without
parenthesis.
Re: @nogc and opengl errors check
On Friday, 20 January 2017 at 22:47:17 UTC, Xavier Bigand wrote: Hi, I am writing some code with opengl commands that I want to check in debug, so I am using the function checkgl (from glamour lib). The issue is that checkgl throw exception and can't be @nogc, I had try to use std.experimental.logger in place of exceptions, but it doesn't work either. I mostly want to be able to check the opengl errors only in debug in a way that can make the debugger breaks. On an other part as I will certainly have to log some events (even in release) I would appreciate that the logger be able to be used in @nogc functions, maybe with allocators? Don't use checkgl, it just bloats you code and there's an actual debug feature in OpenGL now. It provides more information than just an enum as well. So when a function has multiple errors that use the same enum, you can actually know what the error was rather than guessing. https://www.khronos.org/opengl/wiki/Debug_Output
Profiling calls to small functions
Let's say I want to create an array of random numbers and do some
operations on them:
void main() {
import std.random;
//Generate array of random numbers
int arrSize = 1;
double[] arr = new double[](arrSize);
foreach (i; 0..arrSize)
arr[i] = uniform01();
//Call funcA on array elements
foreach (i; 1..arr.length-1)
funcA(arr,i);
}
void funcA(double[] arr, size_t i) {
arr[i+1] = arr[i-1]+arr[i];
funcB(arr,i);
}
void funcB(double[] arr, size_t i) {
arr[i-1]= arr[i] + arr[i+1];
arr[i] = arr[i-1] + arr[i+1];
arr[i+1]= arr[i-1] + arr[i];
}
Now I dmd -profile it and look at the performance of funcA with
d-profile-viewer. Inside funcA, only 20% of time is spend in
funcB, but the rest 80% is self-time of funcA. How is it
possible, when funcB has three times the calculations of funcA?
It appears that the call to funcB itself is very expensive.
Re: Profiling calls to small functions
On Saturday, 21 January 2017 at 12:33:57 UTC, albert-j wrote: Now I dmd -profile it and look at the performance of funcA with d-profile-viewer. Inside funcA, only 20% of time is spend in funcB, but the rest 80% is self-time of funcA. How is it possible, when funcB has three times the calculations of funcA? It appears that the call to funcB itself is very expensive. I'm not sure if it's what happening in this case but, in code as simple as this, function calls can sometimes be the bottleneck. You should see how compiling with/without -O affects performance, and adding `pragma(inline)` to funcB.
Re: Profiling calls to small functions
I'm not sure if it's what happening in this case but, in code as simple as this, function calls can sometimes be the bottleneck. You should see how compiling with/without -O affects performance, and adding `pragma(inline)` to funcB. When compiled with -inline, the profiler does not report the performance of funcA and funcB individually, and this is what I want to measure.
Re: @nogc and opengl errors check
Le 21/01/2017 à 13:24, Jerry a écrit : On Friday, 20 January 2017 at 22:47:17 UTC, Xavier Bigand wrote: Hi, I am writing some code with opengl commands that I want to check in debug, so I am using the function checkgl (from glamour lib). The issue is that checkgl throw exception and can't be @nogc, I had try to use std.experimental.logger in place of exceptions, but it doesn't work either. I mostly want to be able to check the opengl errors only in debug in a way that can make the debugger breaks. On an other part as I will certainly have to log some events (even in release) I would appreciate that the logger be able to be used in @nogc functions, maybe with allocators? Don't use checkgl, it just bloats you code and there's an actual debug feature in OpenGL now. It provides more information than just an enum as well. So when a function has multiple errors that use the same enum, you can actually know what the error was rather than guessing. https://www.khronos.org/opengl/wiki/Debug_Output I had never use these API as it is doesn't work on older devices, but I'll may try to use it when available instead of glGetError. Thank you to remember me these API.
Re: iterating through members of bitfields
Thank you both!
Compile to C?
Hi friends, Is there a way to "compile" d code to C, similar to what nim does? That would be cool for greater portability.
Re: Compile to C?
On Saturday, 21 January 2017 at 18:38:22 UTC, Nestor wrote: Hi friends, Is there a way to "compile" d code to C, similar to what nim does? That would be cool for greater portability. The wiki says there was a dmd fork that attempted this 5 years ago, don't know how far he got: https://wiki.dlang.org/Compilers https://github.com/yebblies/dmd/tree/microd
Re: Compile to C?
On Saturday, 21 January 2017 at 18:38:22 UTC, Nestor wrote: That would be cool for greater portability. The hard part in porting to a new platform is rarely the code generation - gdc and ldc have diverse backends already (indeed, they tend to work for D as well as C there). But you still have to port runtime library requirements where compiling to C wouldn't help at all.
Re: Compile to C?
On Saturday, 21 January 2017 at 18:38:22 UTC, Nestor wrote: Hi friends, Is there a way to "compile" d code to C, similar to what nim does? That would be cool for greater portability. No, and this is actually a terrible idea. See https://forum.dlang.org/post/n1vbos$11ov$1...@digitalmars.com
Calls `this(this)` extra with delegate stuff in the code
Compile this and see, (it's crazy!):
import std.stdio;
struct Widget {
private int[] array;
this(uint length) {
array = new int[length];
}
this(this) {
writeln( "this(this) called" );
array = array.dup;
}
int get(size_t offset) { return array[offset]; }
void set(size_t offset, int value) { array[offset] = value; }
auto getArray() {
return array;
}
}
void main() {
auto w1 = Widget(10);
auto w2 = Widget(10);
w1.set(5, 100);
w2.set(5, 42);
assert(w1.get(5) == 100);
auto wd1 = Widget(3);
Widget wd2 = Widget(3);
wd1.set(0, 1);
wd1.set(1, 2);
wd1.set(2, 3);
assert( wd1.getArray == [1,2,3] );
assert( wd2.getArray == [0,0,0] );
void update(string message) {
writeln(message, " wd1 = ", wd1, ", wd2 = ", wd2);
}
void delegate(string) print = &update;
print("before");
wd2 = wd1;
print("after");
assert( wd2.getArray == [1,2,3] );
}
Re: Calls `this(this)` extra with delegate stuff in the code
Simplified:
import std.stdio;
struct Widget {
private int[] array;
this(uint length) {
array = new int[length];
writefln("ctor called : %s", array.ptr);
}
this(this) {
writef( "this(this) called: %s", array.ptr );
array = array.dup;
writefln(" -> %s", array.ptr);
}
}
void main() {
auto w1 = Widget(10);
writeln(w1);
}
It's due to the copies that are made when calling writeln and other
functions that it calls.
Ali
Re: Calls `this(this)` extra with delegate stuff in the code
On 01/21/2017 03:19 PM, Ali Çehreli wrote:
this(this) {
TIL! Change the signature and it works without copies:
this(const(this)) {
// ...
}
How did I miss this for so long?
Ali
Re: Calls `this(this)` extra with delegate stuff in the code
On 01/21/2017 03:36 PM, Ali Çehreli wrote:
> Change the signature and it works without copies:
>
> this(const(this)) {
> // ...
> }
Ugh... :( It's not a post-blit. Then what is it?
Ali
Re: Calls `this(this)` extra with delegate stuff in the code
On Sunday, 22 January 2017 at 00:31:38 UTC, Ali Çehreli wrote:
On 01/21/2017 03:36 PM, Ali Çehreli wrote:
> Change the signature and it works without copies:
>
> this(const(this)) {
> // ...
> }
Ugh... :( It's not a post-blit. Then what is it?
Ali
This is a __ctor that takes another instance as param. The param
name is not specified, i.e
struct Foo
{
this(const(this)){}
}
is the same as
struct Foo
{
this(const(this) param){}
}
since __PRETTY__FUNCTION__ in the function returns
"Foo Foo.this(const(Foo) _param_0) ref"
That's strange.
Isn't it mentioned somewhere in the specification that within a
function declaration, "this" resolves to the type of the current
aggregate ?
Re: Calls `this(this)` extra with delegate stuff in the code
On 01/21/2017 07:22 PM, Basile B. wrote:
On Sunday, 22 January 2017 at 00:31:38 UTC, Ali Çehreli wrote:
On 01/21/2017 03:36 PM, Ali Çehreli wrote:
> Change the signature and it works without copies:
>
> this(const(this)) {
> // ...
> }
Ugh... :( It's not a post-blit. Then what is it?
Ali
This is a __ctor that takes another instance as param. The param name is
not specified, i.e
struct Foo
{
this(const(this)){}
}
is the same as
struct Foo
{
this(const(this) param){}
}
since __PRETTY__FUNCTION__ in the function returns
"Foo Foo.this(const(Foo) _param_0) ref"
That's strange.
Isn't it mentioned somewhere in the specification that within a function
declaration, "this" resolves to the type of the current aggregate ?
Wow! Thanks.
I know about 'alias this' but this (pun!) is new to me. TIL indeed and
WAT (four exclamation marks is right in this case. :o) )
import std.stdio;
struct S {
void foo(this a = () {
static assert(is(this)); // 'this' is a type
return S();
}()) {
static assert(is(typeof(this))); // 'this' is an expression
writeln("foo called for ", this);
}
// WAT
}
void main() {
auto s = S();
s.foo(s);
}
Ali
Re: Calls `this(this)` extra with delegate stuff in the code
On Sunday, 22 January 2017 at 03:42:21 UTC, Ali Çehreli wrote:
On 01/21/2017 07:22 PM, Basile B. wrote:
[...]
Wow! Thanks.
I know about 'alias this' but this (pun!) is new to me. TIL
indeed and WAT (four exclamation marks is right in this
case. :o) )
import std.stdio;
struct S {
void foo(this a = () {
static assert(is(this)); // 'this' is a type
return S();
}()) {
static assert(is(typeof(this))); // 'this' is an
expression
writeln("foo called for ", this);
}
// WAT
}
void main() {
auto s = S();
s.foo(s);
}
Ali
Same mood. I'm quite astonished to see that something like that
still can be discovered, years after the language creation.
