Re: AliasSeq in UDA

2019-03-10 Thread Basile B. via Digitalmars-d-learn

On Sunday, 10 March 2019 at 17:04:20 UTC, Sebastiaan Koppe wrote:

On Sunday, 10 March 2019 at 16:46:43 UTC, Basile B. wrote:
Yes I see. I've refined a bit the test case and maybe I'll 
took a look this week.


Cool. Is it normal to create a testcase that doesn't depend on 
phobos? I suppose it is needed for it to be included in dmd's 
testcases.


Yes.


Re: AliasSeq in UDA

2019-03-10 Thread Sebastiaan Koppe via Digitalmars-d-learn

On Sunday, 10 March 2019 at 16:46:43 UTC, Basile B. wrote:
Yes I see. I've refined a bit the test case and maybe I'll took 
a look this week.


Cool. Is it normal to create a testcase that doesn't depend on 
phobos? I suppose it is needed for it to be included in dmd's 
testcases.




Re: AliasSeq in UDA

2019-03-10 Thread Basile B. via Digitalmars-d-learn

On Sunday, 10 March 2019 at 16:05:19 UTC, Sebastiaan Koppe wrote:

On Sunday, 10 March 2019 at 13:41:32 UTC, Basile B. wrote:

It looks like a bug, a "reject-valid" one.
Try the same code with

enum A = 0;

and it work, despite of B being still opaque. The problem may 
be related to the fact the enum A in the orginal code is 
opaque and has not type.


Thanks. The example I posted was a reduced case, but I can 
still use your trick to fool the compiler.


The following is more real:

---

import std.meta;

enum A; enum B; enum Dummy = 0; // <- Dummy needs to be 0

struct Param(alias T) {}

@AliasSeq!(Dummy,Param!A,Param!B) // <- Here Dummy is needed
struct Foo {}

pragma(msg, __traits(getAttributes, Foo));

void main() {}

---

I have created an issue: 
https://issues.dlang.org/show_bug.cgi?id=19728


Yes I see. I've refined a bit the test case and maybe I'll took a 
look this week.


Re: this is null

2019-03-10 Thread ANtlord via Digitalmars-d-learn

On Sunday, 10 March 2019 at 14:25:56 UTC, spir wrote:


There is a typo in this instruction:

T* ptr = this.list.getFisrtFreeOrAdd(memViewLen).getPtr!T();
^^
rs
(may this explain your null? the compiler should complain)

diniz


Good catch! But I have the same typo within the definition of the 
method. I believe DMD screams about undefined method if it 
happens.


Re: AliasSeq in UDA

2019-03-10 Thread Sebastiaan Koppe via Digitalmars-d-learn

On Sunday, 10 March 2019 at 13:41:32 UTC, Basile B. wrote:

It looks like a bug, a "reject-valid" one.
Try the same code with

enum A = 0;

and it work, despite of B being still opaque. The problem may 
be related to the fact the enum A in the orginal code is opaque 
and has not type.


Thanks. The example I posted was a reduced case, but I can still 
use your trick to fool the compiler.


The following is more real:

---

import std.meta;

enum A; enum B; enum Dummy = 0; // <- Dummy needs to be 0

struct Param(alias T) {}

@AliasSeq!(Dummy,Param!A,Param!B) // <- Here Dummy is needed
struct Foo {}

pragma(msg, __traits(getAttributes, Foo));

void main() {}

---

I have created an issue: 
https://issues.dlang.org/show_bug.cgi?id=19728


Re: Distinguish float and integer types from string

2019-03-10 Thread spir via Digitalmars-d-learn

On 09/03/2019 19:11, Jacob Shtokolov via Digitalmars-d-learn wrote:

The thing is that in PHP, for example, I would do


The thing is php needs to be able to "lexify" raw input data at runtime, while 
in D this is done at compile-time. The ompiler has the lexer to do that.


But I agree that, for user input, it would be cool to have such a feature 
available. However, this would quickly become complex because of (the reciprocal 
of) localisation, or even personalisation. Eg I like to write decimals like:

-1'234'457,098

diniz



Re: this is null

2019-03-10 Thread spir via Digitalmars-d-learn

On 09/03/2019 21:10, ANtlord via Digitalmars-d-learn wrote:

On Saturday, 9 March 2019 at 20:04:53 UTC, Paul Backus wrote:


You can end up with a null `this` reference if you dereference a null pointer 
to a struct and then call a method on the result. For example:




I can but my reference is not null before calling. Take a look at the line of 
code [0]. There is a check before the line.


https://github.com/ANtlord/deadmemory/blob/master/src/deadmemory/mem.d#L20 [0]


There is a typo in this instruction:

T* ptr = this.list.getFisrtFreeOrAdd(memViewLen).getPtr!T();
^^
rs
(may this explain your null? the compiler should complain)

diniz




Re: AliasSeq in UDA

2019-03-10 Thread Basile B. via Digitalmars-d-learn

On Sunday, 10 March 2019 at 13:20:12 UTC, Sebastiaan Koppe wrote:
The compiler complains about `cannot form tuple of tuples` 
whenever I try to put an AliasSeq in a UDA and try to use it.


You would expect the compiler to expand it. Is this a bug?

---

import std.meta;

enum A; enum B;

@AliasSeq!(A,B) // <-- Error: cannot form tuple of tuples
struct Foo {}

pragma(msg, __traits(getAttributes, Foo)); // <- must be 
present (error happens only when queried)


void main() {}

---

link to run.dlang.io: 
https://run.dlang.io/gist/cd5cd94d8ce5327e8a7d5ad77f1d15b8


It looks like a bug, a "reject-valid" one.
Try the same code with

enum A = 0;

and it work, despite of B being still opaque. The problem may be 
related to the fact the enum A in the orginal code is opaque and 
has not type.


I've seen a related issue lately.



Re: AliasSeq in UDA

2019-03-10 Thread Basile B. via Digitalmars-d-learn

On Sunday, 10 March 2019 at 13:41:32 UTC, Basile B. wrote:
On Sunday, 10 March 2019 at 13:20:12 UTC, Sebastiaan Koppe 
wrote:
The compiler complains about `cannot form tuple of tuples` 
whenever I try to put an AliasSeq in a UDA and try to use it.


You would expect the compiler to expand it. Is this a bug?

---

import std.meta;

enum A; enum B;

@AliasSeq!(A,B) // <-- Error: cannot form tuple of tuples
struct Foo {}

pragma(msg, __traits(getAttributes, Foo)); // <- must be 
present (error happens only when queried)


void main() {}

---

link to run.dlang.io: 
https://run.dlang.io/gist/cd5cd94d8ce5327e8a7d5ad77f1d15b8


It looks like a bug, a "reject-valid" one.
Try the same code with

enum A = 0;

and it work, despite of B being still opaque. The problem may 
be related to the fact the enum A in the orginal code is opaque 
and has not type.


I've seen a related issue lately.


It was 19605. But the relationship is not so obvious...


AliasSeq in UDA

2019-03-10 Thread Sebastiaan Koppe via Digitalmars-d-learn
The compiler complains about `cannot form tuple of tuples` 
whenever I try to put an AliasSeq in a UDA and try to use it.


You would expect the compiler to expand it. Is this a bug?

---

import std.meta;

enum A; enum B;

@AliasSeq!(A,B) // <-- Error: cannot form tuple of tuples
struct Foo {}

pragma(msg, __traits(getAttributes, Foo)); // <- must be present 
(error happens only when queried)


void main() {}

---

link to run.dlang.io: 
https://run.dlang.io/gist/cd5cd94d8ce5327e8a7d5ad77f1d15b8


Re: Aliasing a mixin (or alternative ways to profile a scope)

2019-03-10 Thread Simon via Digitalmars-d-learn

On Saturday, 9 March 2019 at 09:12:13 UTC, Dennis wrote:

On Friday, 8 March 2019 at 11:42:11 UTC, Simon wrote:
Thanks, this works flawlessly. Out of interest: what is the 
"enum" doing there? I had the exact same behaviour in a 
function before, that I only called at compile-time, so why 
did it complain then? Can I somehow tell the compiler that a 
function should only be available at compile-time?


The enum (which in D is not only for enumerations, but also for 
"manifest constants") ensures it is evaluated at compile-time, 
since things are only evaluated at compile-time if they have to.

See also Adam D. Ruppe's post in this thread:
https://forum.dlang.org/post/blaawtdhljjantvga...@forum.dlang.org


Thanks!


Re: Phobos in BetterC

2019-03-10 Thread Seb via Digitalmars-d-learn

On Friday, 8 March 2019 at 09:24:25 UTC, Vasyl Teliman wrote:
I've tried to use Mallocator in BetterC but it seems it's not 
available there:


https://run.dlang.io/is/pp3HDq

This produces a linker error.

I'm wondering why Mallocator is not available in this mode (it 
would be intuitive to assume that it's working). Also I would 
like to know what parts of Phobos are available there (e.g. 
std.traits, std.typecons...).


Thanks in advance.


Just for reference there's also a few number of tests in Phobos 
annotated with @betterC. As expected, they are tested with 
-betterC. However, at the moment this annotated subset is pretty 
small and not exposed to the documentation. Though it shouldn't 
be too hard to increase the subset and mark the annotated 
function in the documentation.


Re: Applying a function each respective 2 elements of an array

2019-03-10 Thread kerdemdemir via Digitalmars-d-learn

On Sunday, 10 March 2019 at 09:43:59 UTC, Dennis wrote:

On Sunday, 10 March 2019 at 08:59:59 UTC, kerdemdemir wrote:
Can I avoid for loops and solve my problem with std algorithms 
or ranges ?


Try slide: https://dlang.org/phobos/std_range.html#slide
And then use map.


I think that will work that is exactly what I am looking for 
thanks


Erdem


Re: Applying a function each respective 2 elements of an array

2019-03-10 Thread Dennis via Digitalmars-d-learn

On Sunday, 10 March 2019 at 08:59:59 UTC, kerdemdemir wrote:
Can I avoid for loops and solve my problem with std algorithms 
or ranges ?


Try slide: https://dlang.org/phobos/std_range.html#slide
And then use map.


Applying a function each respective 2 elements of an array

2019-03-10 Thread kerdemdemir via Digitalmars-d-learn
I have an array like(In my real problem my data structs is more 
complex ) :


auto a = [2,3,4,5,6,7];


I want to apply a operation in a fashion like :

 [ 2 , 3 ]  --> apply foo and get return result -1
 [ 3 , 4 ]  ---> -1
 [ 4 , 5 ] ---> -1
  and so on...

operation might be :

int foo ( int a, int b)
{
   return a - b;
}

So my expected result is [-1,-1,-1,-1,-1]

I tried fold but fold add up the result of the last operation.
Range utilities like "chunks" does not help because "chunks" 
transforms the array into a range like [2,3],[4,5],[6,7].


Can I avoid for loops and solve my problem with std algorithms or 
ranges ?