Re: Dub platform probes

2020-05-26 Thread Tim via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 09:17:52 UTC, Andre Pany wrote:

Hi,
What version of dub do you use? I am not 100 % sure but thought 
platform probes do not longer write files with recent dub 
version.

Do you use DMD or LDC or GDC?

Kind regards
Andre


Hi there

I'm using Dub 1.19.0-1build2 with dmd

Thanks


Re: Mir Slice Column or Row Major

2020-05-26 Thread data pulverizer via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 01:31:23 UTC, data pulverizer wrote:

Hi,

I have started running Kernel benchmarks calculations using Mir 
NDSlice, and I'm getting times that are much slower than 
expected.


I've swapped the calculation to row major and it's running as 
expected.





Re: How to target ldc compiler only in dub

2020-05-26 Thread data pulverizer via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 02:09:48 UTC, Mike Parker wrote:
Thanks. Is there anyway to verify that the flags I am passing 
to the compiler are being used?


dub -v

It shows you the full compiler command line.


Ah, I forgot to force the rebuild. Thanks.



Re: How to target ldc compiler only in dub

2020-05-26 Thread Mathias LANG via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 22:28:14 UTC, data pulverizer wrote:

Hi,

I am trying to build a package to target LDC compiler only. I 
have both dmd and ldc2 (1.18.0) installed on my system. The dub 
file is:


```
{
"authors": [
"Me"
],
"copyright": "Copyright © 2020, Me",
"dependencies": {
"mir-algorithm": "~>3.8.12",
"mir-random": "~>2.2.14"
},
"description": "Some Cool Stuff",
"license": "MIT",
"name": "myPackage",
"dflags": [
"-O", "--release", "--boundscheck=off",
"--ffast-math", "-mcpu=native"],
"toolchainRequirements": {
"dmd": "no",
"gdc": "no",
"ldc": ">=1.18.0"
},
"targetType": "executable"
}
```

I get the message:

```
Installed dmd 2.090.1 is not supported by myPackage. Supported 
compiler(s):

  - ldc: >=1.18.0
```

Thanks


Add a `dub.settings.json` with:
```
{
"defaultCompiler": "ldc2"
}
```

Like we did: 
https://github.com/bpfkorea/agora/blob/38b2c33cc56acdeeabce8158bf3231a1f51eb5b1/dub.settings.json


Re: How to target ldc compiler only in dub

2020-05-26 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 01:41:47 UTC, data pulverizer wrote:

On Wednesday, 27 May 2020 at 01:06:48 UTC, mw wrote:

And you can use option

dub -v

to verify it's calling the correct compiler cmd.


Thanks. Is there anyway to verify that the flags I am passing 
to the compiler are being used?


dub -v

It shows you the full compiler command line.


Re: Distinguish between a null array and an empty array

2020-05-26 Thread Dukc via Digitalmars-d-learn

On Sunday, 24 May 2020 at 12:29:23 UTC, bauss wrote:
Dang, that sucks there is no proper way and I would say that's 
a big flaw of D.


Because what I need it for is for some data serialization but 
if the value is an empty array then it should be present and if 
it's null then it should not be present.


Since null is used to say "ignore this" in the data 
serialization.


Oh well.


If you want to avoid the memory cost of `Nullable`, I think you 
could still have a special value for "no data". But I wouldn't 
use D `null` for it, because it's so common for it to be used for 
empty values. Instead, I'd define a small data section somewhere. 
You test whether the array points to it (`[0] == 
[0]`), and if, it means no data.


Re: How to target ldc compiler only in dub

2020-05-26 Thread data pulverizer via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 01:06:48 UTC, mw wrote:

And you can use option

dub -v

to verify it's calling the correct compiler cmd.


Thanks. Is there anyway to verify that the flags I am passing to 
the compiler are being used?




Re: m32mscoff with lld-link causes SEH errors

2020-05-26 Thread Daniel C via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 15:56:31 UTC, kinke wrote:

Using `-L/safeseh:no` should work around this.


It successfully made the executable, and it runs fine - until 
exit lol.  Must be more tweaks needed.


Edit source/app.d to start your project.
object.Error@(0): Access Violation

0x0045F058
0x0040139F
0x0040100D
0x00405879
0x00405710
0x00402A1E
0x00401030
0x75C6347D in BaseThreadInitThunk
0x77059852 in RtlInitializeExceptionChain
0x77059825 in RtlInitializeExceptionChain

 - CreateProcess Program Exit code: 1 -


Mir Slice Column or Row Major

2020-05-26 Thread data pulverizer via Digitalmars-d-learn

Hi,

I have started running Kernel benchmarks calculations using Mir 
NDSlice, and I'm getting times that are much slower than 
expected. To check that I'm not making an obvious mistake, below 
are samples of the code I am using. The way the selection happens 
is that the `calculateKernelMatrix` function assumes that the 
data under the slice object is column major, if it is row major 
the calculation will be slow which could account for the issues 
I'm seeing. Thanks


Dot product functor
```
struct DotProduct(T)
{
  public:
  this(T _nothing)
  {}
  T opCall(U...)(Slice!(T*, U) x, Slice!(T*, U) y) const
  {
T dist = 0;
auto m = x.length;
for(size_t i = 0; i < m; ++i)
{
  dist += x[i] * y[i];
}
return dist;
  }
}
```

Kernel Matrix function:
```
auto calculateKernelMatrix(alias K, T, U...)(K!(T) kernel, 
Slice!(T*, U) data)

{
  size_t n = data.length!1;
  auto mat = slice!(T)(n, n);

  foreach(j; taskPool.parallel(iota(n)))
  {
auto arrj = data[0..$, j];
foreach(size_t i; j..n)
{
  mat[i, j] = kernel(data[0..$, i], arrj);
  mat[j, i] = mat[i, j];
}
  }
  return mat;
}
```

Benchmark Function
```
auto bench(alias K, T)(K!(T) kernel, long[] n, bool verbose = 
true)

{
  auto times = new double[n.length];
  auto sw = StopWatch(AutoStart.no);
  foreach(i; 0..n.length)
  {
double[3] _times;
auto data = UniformVariable!T(0, 1).randomSlice(784L, n[i]);
foreach(ref t; _times[])
{
  sw.start();
  auto mat = calculateKernelMatrix!(K, T)(kernel, data);
  sw.stop();
  t = sw.peek.total!"nsecs"/1000_000_000.0;
  sw.reset();
}
times[i] = sum(_times[])/3.0;
if(verbose)
{
  writeln("Average time for n = ", n[i], ", ", times[i], " 
seconds.");

  writeln("Detailed times: ", _times, "\n");
}
  }
  return tuple(n, times);
}
```


Re: How to target ldc compiler only in dub

2020-05-26 Thread mw via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 00:54:45 UTC, data pulverizer wrote:

On Wednesday, 27 May 2020 at 00:52:55 UTC, mw wrote:

On Tuesday, 26 May 2020 at 22:28:14 UTC, data pulverizer wrote:

I am trying to build a package to target LDC compiler only. I


set env:

LDC=
DUB = $(LDC)/bin/dub

then, run this new dub:

$(DUB) build


Thanks. Building with `dub run --compiler=ldc2` works so I 
think I'll do that instead.


And you can use option

dub -v

to verify it's calling the correct compiler cmd.


Re: How to target ldc compiler only in dub

2020-05-26 Thread mw via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 22:28:14 UTC, data pulverizer wrote:

I am trying to build a package to target LDC compiler only. I


set env:

LDC=
DUB = $(LDC)/bin/dub

then, run this new dub:

$(DUB) build




Re: How to target ldc compiler only in dub

2020-05-26 Thread data pulverizer via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 00:52:55 UTC, mw wrote:

On Tuesday, 26 May 2020 at 22:28:14 UTC, data pulverizer wrote:

I am trying to build a package to target LDC compiler only. I


set env:

LDC=
DUB = $(LDC)/bin/dub

then, run this new dub:

$(DUB) build


Thanks. Building with `dub run --compiler=ldc2` works so I think 
I'll do that instead.


How to target ldc compiler only in dub

2020-05-26 Thread data pulverizer via Digitalmars-d-learn

Hi,

I am trying to build a package to target LDC compiler only. I 
have both dmd and ldc2 (1.18.0) installed on my system. The dub 
file is:


```
{
"authors": [
"Me"
],
"copyright": "Copyright © 2020, Me",
"dependencies": {
"mir-algorithm": "~>3.8.12",
"mir-random": "~>2.2.14"
},
"description": "Some Cool Stuff",
"license": "MIT",
"name": "myPackage",
"dflags": [
"-O", "--release", "--boundscheck=off",
"--ffast-math", "-mcpu=native"],
"toolchainRequirements": {
"dmd": "no",
"gdc": "no",
"ldc": ">=1.18.0"
},
"targetType": "executable"
}
```

I get the message:

```
Installed dmd 2.090.1 is not supported by myPackage. Supported 
compiler(s):

  - ldc: >=1.18.0
```

Thanks


Re: How to get the pointer of "this" ?

2020-05-26 Thread bauss via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 12:08:29 UTC, Johannes Loher wrote:

On Tuesday, 26 May 2020 at 11:44:58 UTC, Vinod K Chandran wrote:

On Monday, 25 May 2020 at 16:39:30 UTC, Mike Parker wrote:

On Monday, 25 May 2020 at 08:39:23 UTC, John Burton wrote:


I believe that in D *this* is a reference to the
object and not a pointer like in C++.
So I think that writing  might be what you need?


No. A class reference is a pointer under the hood. Getting 
its address will result in a pointer to the reference 
variable itself, not to the class instance. When passing a 
reference to a C API, casting it directly to the C type is 
correct.


Try this code. This will reproduce the same error.
import std.stdio : log = writeln;



void main() {
 log("Let's check whether 'this' is an lvalue or not.");
 Button btn = new Button("A button");
}

class Button {
this(string btntext){
mtext = btntext;
log("button created with the name , ", btntext);
log();
}
private:
string mt
}

It doesn't compile, the line

string mt

should be

string mtext;

instead. Indeed, we get a compiler error:

Error: this is not an lvalue and cannot be modified.

The problem is in line 11: You are trying to get the address of 
`this`. But `this` is an lvalue, so it does not have an address 
you could take. It becomes mir clear that this doesn’t work if 
you consider other lvalues, like literals:


int* = &1; // doesn’t compile, can’t take the address of an 
lvalue.


In this code example, the correct thing to do is to simply not 
take the address but pass `this` to `writeln`. That compiles 
and results in the following output:


Let's check whether 'this' is an lvalue or not.
button created with the name , A button
onlineapp.Button

(The module is onlineapp because I ran it in run.dlang.io)

I don't know what the correct thing would be in your original 
code though.

You can just do this to get around it:

 auto button = this;
 log();



Re: m32mscoff with lld-link causes SEH errors

2020-05-26 Thread Daniel C via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 15:56:31 UTC, kinke wrote:

On Monday, 25 May 2020 at 01:32:58 UTC, Daniel C wrote:
Is lld-link only for 64-bit compiles (-m64 is the only one 
that gives no errors)


Nope, but SafeSEH is a 32-bit-only feature. DMD doesn't emit 
SafeSEH compatible object files, and LLD seems to have a 
different default setting in that regard compared to MS 
link.exe. Using `-L/safeseh:no` should work around this.


Thank you!  One more thing to add to my compile/link notes =)


Re: How to get the pointer of "this" ?

2020-05-26 Thread Vinod K Chandran via Digitalmars-d-learn
On Tuesday, 26 May 2020 at 14:42:04 UTC, Steven Schveighoffer 
wrote:
On Tuesday, 26 May 2020 at 14:42:04 UTC, Steven Schveighoffer 
wrote:



Hm... According to run.dlang.io, this behavior changed in 2.072 
(prior to that it worked). In  2.067.1 to 2.071.2, changing the 
this reference was actually allowed, but deprecated.


Technically, you don't need to do this. Passing an address to a 
class reference isn't going to benefit anything, as a class 
reference already is a pointer. This is, of course, unless you 
want to CHANGE the class reference. Which is disallowed for 
`this`.


Technically speaking, `this` is simply a local parameter. It 
technically could be changed, but it is not allowed because of 
the bad code that would likely result.


-Steve


Hi,
Thanks for the reply. I've got the point.


Re: How to get the pointer of "this" ?

2020-05-26 Thread John Chapman via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 13:37:22 UTC, Vinod K Chandran wrote:

On Tuesday, 26 May 2020 at 12:41:20 UTC, John Chapman wrote:

On Monday, 25 May 2020 at 16:26:31 UTC, Vinod K Chandran wrote:

Here is my full code. Please take a look.
https://pastebin.com/av3nrvtT


Change line 124 to:

SetWindowSubclass(this.mHandle, SUBCLASSPROC(), 
UINT_PTR(subClsID), cast(DWORD_PTR)cast(void*)this);


That is, change `` to `cast(void*)this`.


Hi,
Thanks for the reply. That will work like charm but we need to 
change the code in subclassed button's WndProc  like this--

extern(Windows)
private LRESULT btnWndProc(HWND hWnd, UINT message, WPARAM 
wParam, LPARAM lParam, UINT_PTR scID, DWORD_PTR refData) {

try  {

Button thisBtn = cast(Button)cast(void*)refData;
 {
catch (Exception e) {}



Yes, that should work.


Re: Distinguish between a null array and an empty array

2020-05-26 Thread Steven Schveighoffer via Digitalmars-d-learn

On 5/24/20 8:12 AM, bauss wrote:

Is there a way to do that?

Since the following are both true:

int[] a = null;
int[] b = [];

assert(a is null);
assert(!a.length);

assert(b is null);
assert(!b.length);

What I would like is to tell that b is an empty array and a is a null 
array.


The issue is simply that [] is the same as null.

Try this:

T[] emptyArr(T)() @trusted
{
   T* p = null;
   return p[1 .. 1];
}


int[] b = emptyArr!int;

assert(b !is null);
assert(!b.length);

-Steve


Re: m32mscoff with lld-link causes SEH errors

2020-05-26 Thread kinke via Digitalmars-d-learn

On Monday, 25 May 2020 at 01:32:58 UTC, Daniel C wrote:
Is lld-link only for 64-bit compiles (-m64 is the only one that 
gives no errors)


Nope, but SafeSEH is a 32-bit-only feature. DMD doesn't emit 
SafeSEH compatible object files, and LLD seems to have a 
different default setting in that regard compared to MS link.exe. 
Using `-L/safeseh:no` should work around this.


Re: [GTK-D] dub run leads to lld-link: error: could not open libcmt.lib: no such file or directory

2020-05-26 Thread jmh530 via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 15:18:42 UTC, jmh530 wrote:

On Tuesday, 26 May 2020 at 15:16:25 UTC, jmh530 wrote:

[snip]
Another short-term fix might be to try compiling with the -m32 
dflag (need to put in your dub.sdl/json).




Sorry, easier is
dub test --arch=x86


You may also have to make sure that bin64 is in the path.

https://dlang.org/changelog/2.091.0.html#windows


Re: [GTK-D] dub run leads to lld-link: error: could not open libcmt.lib: no such file or directory

2020-05-26 Thread jmh530 via Digitalmars-d-learn

On Wednesday, 13 May 2020 at 15:26:48 UTC, BoQsc wrote:

[snip]

Linking...
lld-link: error: could not open libcmt.lib: no such file or 
directory
lld-link: error: could not open OLDNAMES.lib: no such file or 
directory

Error: linker exited with status 1
C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1.


I just ran into this issue as well. I haven't had a chance to fix 
it on my end, but this is what I've found.


This line
Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for 
x86_64.

means that it is compiling a 64bit program on Windows.

On Windows, if you are trying to compile a 64bit program, then it 
will try to link with lld if it cannot find a Microsoft linker 
[1]. The failure is likely due your Microsoft linker (or lld) 
either not being installed properly or wrong version or 
configured improperly. If you don't have Visual Studio Community 
installed, that might be a first step. Another short-term fix 
might be to try compiling with the -m32 dflag (need to put in 
your dub.sdl/json).


[1] https://dlang.org/dmd-windows.html#linking


Re: [GTK-D] dub run leads to lld-link: error: could not open libcmt.lib: no such file or directory

2020-05-26 Thread jmh530 via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 15:16:25 UTC, jmh530 wrote:

[snip]
Another short-term fix might be to try compiling with the -m32 
dflag (need to put in your dub.sdl/json).




Sorry, easier is
dub test --arch=x86



Re: How to get the pointer of "this" ?

2020-05-26 Thread Steven Schveighoffer via Digitalmars-d-learn

On 5/26/20 8:08 AM, Johannes Loher wrote:

On Tuesday, 26 May 2020 at 11:44:58 UTC, Vinod K Chandran wrote:

On Monday, 25 May 2020 at 16:39:30 UTC, Mike Parker wrote:

On Monday, 25 May 2020 at 08:39:23 UTC, John Burton wrote:


I believe that in D *this* is a reference to the
object and not a pointer like in C++.
So I think that writing  might be what you need?


No. A class reference is a pointer under the hood. Getting its 
address will result in a pointer to the reference variable itself, 
not to the class instance. When passing a reference to a C API, 
casting it directly to the C type is correct.


Try this code. This will reproduce the same error.
import std.stdio : log = writeln;



void main() {
 log("Let's check whether 'this' is an lvalue or not.");
 Button btn = new Button("A button");
}

class Button {
    this(string btntext)    {
    mtext = btntext;
    log("button created with the name , ", btntext);
    log();
    }
    private:
    string mt
}

It doesn't compile, the line

string mt

should be

string mtext;

instead. Indeed, we get a compiler error:

Error: this is not an lvalue and cannot be modified.

The problem is in line 11: You are trying to get the address of `this`. 
But `this` is an lvalue, so it does not have an address you could take. 
It becomes mir clear that this doesn’t work if you consider other 
lvalues, like literals:


int* = &1; // doesn’t compile, can’t take the address of an lvalue.

In this code example, the correct thing to do is to simply not take the 
address but pass `this` to `writeln`. That compiles and results in the 
following output:


Let's check whether 'this' is an lvalue or not.
button created with the name , A button
onlineapp.Button

(The module is onlineapp because I ran it in run.dlang.io)

I don't know what the correct thing would be in your original code though.




Hm... According to run.dlang.io, this behavior changed in 2.072 (prior 
to that it worked). In  2.067.1 to 2.071.2, changing the this reference 
was actually allowed, but deprecated.


Technically, you don't need to do this. Passing an address to a class 
reference isn't going to benefit anything, as a class reference already 
is a pointer. This is, of course, unless you want to CHANGE the class 
reference. Which is disallowed for `this`.


Technically speaking, `this` is simply a local parameter. It technically 
could be changed, but it is not allowed because of the bad code that 
would likely result.


-Steve


Re: Learning Vibe.d

2020-05-26 Thread Steven Schveighoffer via Digitalmars-d-learn

On 5/25/20 5:49 AM, Daniel Kozak wrote:

On Sun, May 24, 2020 at 10:06 AM Russel Winder via Digitalmars-d-learn
 wrote:


For my purposes switching to using SIGKILL rather than SIGTERM in my tests
seems to work with 1.9.1, so I'll go with that till 1.9.2 or 1.10.0 produces a
fix rather than revert to 1.8.1.



You can use VibeHighEventPriority version in your dub as a workaround
for now, there is no need to revert to 1.8.1



I'm thinking of actually reverting to something earlier or trying to get 
1.9.0 to work. I am getting tons of spurious errors in vibe-core (see 
[1]). The latest cost me about 2 days of tracking down an error, where 
occasionally (still not sure of the situation) the connection to the 
database is spuriously closed before the response can be fully read.


I was not getting these in an earlier version of the build.

-Steve

[1] https://github.com/vibe-d/vibe-core/issues/208


Flagging spam on forum.dlang.org

2020-05-26 Thread Steven Schveighoffer via Digitalmars-d-learn
Someone asked this question in response to SPAM, and I don't want to 
answer it there, because I'm expecting that entire subthread to be removed.


Yes, there is a flag button on forum.dlang.org. I'm not sure if you need 
permissions to access it, but it allows you to flag the maintainers to 
look at a specific message for spam or inappropriate text.


I did it for that post you responded to, Les De Rider. (and looks like 
it's already deleted)


-Steve


Re: How to get the pointer of "this" ?

2020-05-26 Thread Johannes Loher via Digitalmars-d-learn
Am 26.05.20 um 16:17 schrieb Vinod K Chandran:
> On Tuesday, 26 May 2020 at 13:48:52 UTC, ag0aep6g wrote:
>> On 26.05.20 15:43, Vinod K Chandran wrote:
>>> So far now, two solutions are very clear for this problem.
>>> 1. As per John Chapman's suggestion - use
>>> cast(DWORD_PTR)cast(void*)this).
>>> 2. Use another varibale to use as an lvalue. -
>>>   Button dummyBtn = this;
>>>   cast(DWORD_PTR)
>>> Among these two, i think 2nd option is good. Am i right ?
>>
>> No. Use option 1.
> 
> Could you please tell me why ?
With option 2, you will not actually get a pointer to the object but a
pointer to the local variable which is a reference to the object. `this`
and the local variable both are references to the object, so internally
they already are pointers. Their usage is just restricted in regular D
code. This is also why simply casting it to a pointer works. You need to
cast to void* in between because that's just the way to tell the
compiler to ignore the restrictions you usually have for references.


Re: How to get the pointer of "this" ?

2020-05-26 Thread Vinod K Chandran via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 13:48:52 UTC, ag0aep6g wrote:

On 26.05.20 15:43, Vinod K Chandran wrote:

So far now, two solutions are very clear for this problem.
1. As per John Chapman's suggestion - use 
cast(DWORD_PTR)cast(void*)this).

2. Use another varibale to use as an lvalue. -
  Button dummyBtn = this;
  cast(DWORD_PTR)
Among these two, i think 2nd option is good. Am i right ?


No. Use option 1.


Could you please tell me why ?


Re: Assign Range: layout = X, AlignRight;

2020-05-26 Thread Paul Backus via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 13:36:34 UTC, Виталий Фадеев wrote:

I want this:

layout = X, AlignRight;



Use case:
class Widget
{
struct Layout
{
ILayout[] _layouts;

void opAssign( args... )
{
foreach( a; args )
{
_layouts ~= a;
}
}


alias _layouts this;
}
}


in front-end code:

with( new Widget() )
{
layout = X, AlignRight;
}


I think the solution:
   void opAssign( args... ) { ... }



I want this feature in D!


You can do this by wrapping your argument list with the template 
`std.meta.AliasSeq`:


import std.stdio: writeln;
import std.meta: AliasSeq;

struct Example
{
void opAssign(Args...)(Args args)
{
writeln("called with ", Args.stringof);
}
}

void main()
{
Example e;
e = AliasSeq!(1, 2, "hello");
// prints: called with (int, int, string)
}

I believe there is a proposal in the works to make it possible to 
do this without AliasSeq, but I'm not sure how far along it is. 
For now, if you want to make the code prettier, I recommend using 
an alias to give AliasSeq a less ugly name. For example:


alias Args = AliasSeq;
e = Args!(1, 2, "hello");


Re: How to get the pointer of "this" ?

2020-05-26 Thread Vinod K Chandran via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 13:44:24 UTC, Adam D. Ruppe wrote:

On Tuesday, 26 May 2020 at 11:35:23 UTC, Vinod K Chandran wrote:

Okay, but uint is working perfectly.


It won't if you use -m64.


Okay. I got it.


Re: Assign Range: layout = X, AlignRight;

2020-05-26 Thread Виталий Фадеев via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 13:36:34 UTC, Виталий Фадеев wrote:

I want this:

layout = X, AlignRight;



Use case:
class Widget
{
struct Layout
{
ILayout[] _layouts;

void opAssign( args... )
{
foreach( a; args )
{
_layouts ~= a;
}
}


alias _layouts this;
}
}


in front-end code:

with( new Widget() )
{
layout = X, AlignRight;
}


I think the solution:
   void opAssign( args... ) { ... }



I want this feature in D!


Main goal is: Readable, clean, beauty code.



Re: Assign Range: layout = X, AlignRight;

2020-05-26 Thread WebFreak001 via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 13:36:34 UTC, Виталий Фадеев wrote:

[...]

I want this feature in D!


I think you are rather looking for tuples:

 void opAssign(Args...)(Tuple!Args args)
 {
 foreach( a; args )
 {
 _layouts ~= a;
 }
 }

which you can currently use like

layout = tuple(X, AlignRight);

which is probably going to be the best you can do with D right 
now. You can also make your own type like Tuple and/or a function 
like tuple if you want more type-safety




(and maybe some day in the distant future once the comma operator 
is completely removed and a DIP for tuple syntax goes through we 
might even be able to write layout = (X, AlignRight))


Re: Distinguish between a null array and an empty array

2020-05-26 Thread WebFreak001 via Digitalmars-d-learn

On Sunday, 24 May 2020 at 12:37:20 UTC, ag0aep6g wrote:

On 24.05.20 14:29, bauss wrote:
Dang, that sucks there is no proper way and I would say that's 
a big flaw of D.


Because what I need it for is for some data serialization but 
if the value is an empty array then it should be present and 
if it's null then it should not be present.


Since null is used to say "ignore this" in the data 
serialization.


You can use std.typecons.Nullable (or a similar wrapper) to add 
an extra "ignore this" value to a type.


and just in case you use vibe.d serialization (JSON, BSON or 
other custom ones), there is a new @embedNullable UDA which 
treats Nullable!T inside a map as a T or completely omits it if 
it's null ;)


Re: How to get the pointer of "this" ?

2020-05-26 Thread ag0aep6g via Digitalmars-d-learn

On 26.05.20 15:43, Vinod K Chandran wrote:

So far now, two solutions are very clear for this problem.
1. As per John Chapman's suggestion - use cast(DWORD_PTR)cast(void*)this).
2. Use another varibale to use as an lvalue. -
  Button dummyBtn = this;
  cast(DWORD_PTR)
Among these two, i think 2nd option is good. Am i right ?


No. Use option 1.


Re: How to get the pointer of "this" ?

2020-05-26 Thread Adam D. Ruppe via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 11:35:23 UTC, Vinod K Chandran wrote:

Okay, but uint is working perfectly.


It won't if you use -m64.


Re: How to get the pointer of "this" ?

2020-05-26 Thread Vinod K Chandran via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 13:37:22 UTC, Vinod K Chandran wrote:

On Tuesday, 26 May 2020 at 12:41:20 UTC, John Chapman wrote:

On Monday, 25 May 2020 at 16:26:31 UTC, Vinod K Chandran wrote:

Here is my full code. Please take a look.
https://pastebin.com/av3nrvtT


Change line 124 to:

SetWindowSubclass(this.mHandle, SUBCLASSPROC(), 
UINT_PTR(subClsID), cast(DWORD_PTR)cast(void*)this);


That is, change `` to `cast(void*)this`.


Hi,
Thanks for the reply. That will work like charm but we need to 
change the code in subclassed button's WndProc  like this--

extern(Windows)
private LRESULT btnWndProc(HWND hWnd, UINT message, WPARAM 
wParam, LPARAM lParam, UINT_PTR scID, DWORD_PTR refData) {

try  {

Button thisBtn = cast(Button)cast(void*)refData;
 {
catch (Exception e) {}



So far now, two solutions are very clear for this problem.
1. As per John Chapman's suggestion - use 
cast(DWORD_PTR)cast(void*)this).

2. Use another varibale to use as an lvalue. -
 Button dummyBtn = this;
 cast(DWORD_PTR)
Among these two, i think 2nd option is good. Am i right ?



Assign Range: layout = X, AlignRight;

2020-05-26 Thread Виталий Фадеев via Digitalmars-d-learn

I want this:

layout = X, AlignRight;



Use case:
class Widget
{
struct Layout
{
ILayout[] _layouts;

void opAssign( args... )
{
foreach( a; args )
{
_layouts ~= a;
}
}


alias _layouts this;
}
}


in front-end code:

with( new Widget() )
{
layout = X, AlignRight;
}


I think the solution:
   void opAssign( args... ) { ... }



I want this feature in D!



Re: How to get the pointer of "this" ?

2020-05-26 Thread Vinod K Chandran via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 12:08:29 UTC, Johannes Loher wrote:

On Tuesday, 26 May 2020 at 11:44:58 UTC, Vinod K Chandran wrote:

[...]



[...]

It doesn't compile, the line

string mt

[...]


Hi,
Sorry for the typos in my code.


Re: How to get the pointer of "this" ?

2020-05-26 Thread Vinod K Chandran via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 12:41:20 UTC, John Chapman wrote:

On Monday, 25 May 2020 at 16:26:31 UTC, Vinod K Chandran wrote:

Here is my full code. Please take a look.
https://pastebin.com/av3nrvtT


Change line 124 to:

SetWindowSubclass(this.mHandle, SUBCLASSPROC(), 
UINT_PTR(subClsID), cast(DWORD_PTR)cast(void*)this);


That is, change `` to `cast(void*)this`.


Hi,
Thanks for the reply. That will work like charm but we need to 
change the code in subclassed button's WndProc  like this--

extern(Windows)
private LRESULT btnWndProc(HWND hWnd, UINT message, WPARAM 
wParam, LPARAM lParam, UINT_PTR scID, DWORD_PTR refData) {

try  {

Button thisBtn = cast(Button)cast(void*)refData;
 {
catch (Exception e) {}



Re: How to get the pointer of "this" ?

2020-05-26 Thread John Chapman via Digitalmars-d-learn

On Monday, 25 May 2020 at 16:26:31 UTC, Vinod K Chandran wrote:

Here is my full code. Please take a look.
https://pastebin.com/av3nrvtT


Change line 124 to:

SetWindowSubclass(this.mHandle, SUBCLASSPROC(), 
UINT_PTR(subClsID), cast(DWORD_PTR)cast(void*)this);


That is, change `` to `cast(void*)this`.


Re: How to get the pointer of "this" ?

2020-05-26 Thread Johannes Loher via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 12:08:29 UTC, Johannes Loher wrote:

[...]


Small correction: I said that this is an lvalue and that you 
cannot take the address of lvalues. Of course that is incorrect, 
I meant to say that rvalues (this is an rvalue and you cannot 
take the address of rvalues).


Re: How to get the pointer of "this" ?

2020-05-26 Thread Johannes Loher via Digitalmars-d-learn

On Tuesday, 26 May 2020 at 11:44:58 UTC, Vinod K Chandran wrote:

On Monday, 25 May 2020 at 16:39:30 UTC, Mike Parker wrote:

On Monday, 25 May 2020 at 08:39:23 UTC, John Burton wrote:


I believe that in D *this* is a reference to the
object and not a pointer like in C++.
So I think that writing  might be what you need?


No. A class reference is a pointer under the hood. Getting its 
address will result in a pointer to the reference variable 
itself, not to the class instance. When passing a reference to 
a C API, casting it directly to the C type is correct.


Try this code. This will reproduce the same error.
import std.stdio : log = writeln;



void main() {
 log("Let's check whether 'this' is an lvalue or not.");
 Button btn = new Button("A button");
}

class Button {
this(string btntext){
mtext = btntext;
log("button created with the name , ", btntext);
log();
}
private:
string mt
}

It doesn't compile, the line

string mt

should be

string mtext;

instead. Indeed, we get a compiler error:

Error: this is not an lvalue and cannot be modified.

The problem is in line 11: You are trying to get the address of 
`this`. But `this` is an lvalue, so it does not have an address 
you could take. It becomes mir clear that this doesn’t work if 
you consider other lvalues, like literals:


int* = &1; // doesn’t compile, can’t take the address of an 
lvalue.


In this code example, the correct thing to do is to simply not 
take the address but pass `this` to `writeln`. That compiles and 
results in the following output:


Let's check whether 'this' is an lvalue or not.
button created with the name , A button
onlineapp.Button

(The module is onlineapp because I ran it in run.dlang.io)

I don't know what the correct thing would be in your original 
code though.




Re: How to get the pointer of "this" ?

2020-05-26 Thread Vinod K Chandran via Digitalmars-d-learn

On Monday, 25 May 2020 at 16:39:30 UTC, Mike Parker wrote:

On Monday, 25 May 2020 at 08:39:23 UTC, John Burton wrote:


I believe that in D *this* is a reference to the
object and not a pointer like in C++.
So I think that writing  might be what you need?


No. A class reference is a pointer under the hood. Getting its 
address will result in a pointer to the reference variable 
itself, not to the class instance. When passing a reference to 
a C API, casting it directly to the C type is correct.


Try this code. This will reproduce the same error.
import std.stdio : log = writeln;
void main() {
 log("Let's check whether 'this' is an lvalue or not.");
 Button btn = new Button("A button");
}

class Button {
this(string btntext){
mtext = btntext;
log("button created with the name , ", btntext);
log();
}
private:
string mt
}


Re: How to get the pointer of "this" ?

2020-05-26 Thread Vinod K Chandran via Digitalmars-d-learn

On Monday, 25 May 2020 at 18:42:33 UTC, bauss wrote:

On Monday, 25 May 2020 at 17:14:13 UTC, Vinod K Chandran wrote:

On Monday, 25 May 2020 at 16:54:11 UTC, Mike Parker wrote:

[...]


Hi @Mike Parker,
Thank you for your valuable suggestions. I will sure follow 
them. Well, the  exact line number where the error showing is 
the one with the "SetWindowSubclass" function.  In pastebin, 
the line number is 124.


Need to see the Control  class too.

I think the problem might be something you're referencing from 
there but need to be sure.


Here is some code to reproduce the error in your system.
https://pastebin.com/rgN3ug1e
'this' is not an lvalue.


Re: How to get the pointer of "this" ?

2020-05-26 Thread Vinod K Chandran via Digitalmars-d-learn

On Monday, 25 May 2020 at 22:54:32 UTC, Adam D. Ruppe wrote:

On Monday, 25 May 2020 at 22:31:00 UTC, Vinod K Chandran wrote:
A dword is an unsigned, 32-bit unit of data. We can use uint 
in D. I have tried that too, but no luck.


A DWORD_PTR is *not* the same as a uint. It is more like a 
size_t or void* depending on context.


Okay, but uint is working perfectly.


Re: ModuleInfo and -fno-moduleinfo option

2020-05-26 Thread kinke via Digitalmars-d-learn
ModuleInfos are essential for the module ctors and dtors (of used 
modules) to be run, incl. a dependency tree defining their order 
of execution. They're also needed for running the unittests.


Re: Dub platform probes

2020-05-26 Thread Andre Pany via Digitalmars-d-learn

On Monday, 25 May 2020 at 22:58:54 UTC, Tim wrote:

Hi all

I end up with a directory flooded with platform probes. How can 
I make sure that old ones are deleted automatically?


Thanks


Hi,
What version of dub do you use? I am not 100 % sure but thought 
platform probes do not longer write files with recent dub version.

Do you use DMD or LDC or GDC?

Kind regards
Andre