Re: How can I make DMD stop on the first fatal error? (-Wfatal-errors)

2020-07-07 Thread Jacob Carlborg via Digitalmars-d-learn

On Wednesday, 8 July 2020 at 00:54:40 UTC, Marcone wrote:
How can I make DMD stop on the first fatal error like 
-Wfatal-errors on C++?


With the `-verrors=1` flag. You can specify exactly how many 
errors the compiler should emit before halting the compilation. 
Specify `0` for unlimited.


--
/Jacob Carlborg


Re: Construct an used-defined hash table container type from an AA-literal expression

2020-07-07 Thread Jacob Carlborg via Digitalmars-d-learn

On Tuesday, 7 July 2020 at 12:41:23 UTC, Per Nordlöw wrote:

What about construction and assignment from a static array of 
`Pair`'s? Wouldn't that be easier on the compiler?


I you refer to it wouldn't be using templates, then yes, I guess 
so.


--
/Jacob Carlborg



Re: constructing labels for static foreach inside switch inside foreach

2020-07-07 Thread bauss via Digitalmars-d-learn
On Wednesday, 8 July 2020 at 02:06:01 UTC, Steven Schveighoffer 
wrote:
OK, so I have a situation where I'm foreaching over a 
compile-time list of types. Inside the loop, I'm using a second 
loop over a set of input.


Inside that loop, I'm using a switch on the input, and inside 
the switch, I'm foreaching over the type's members, to 
construct a switch that can handle member names (this is for 
serialization).


If I encounter a certain name, then I want to break out of the 
inner loop (it's a while loop)


So naturally, I have to use break statements with labels like:

innerloop:
while(haveMoreData)
   switchstmt:
   switch(nextDataElement) {
  static foreach(name; __traits(allMembers, T)) {
  case name:
 ... // handle it
 break switchstmt;
  }
  case "STOP":
 break innerloop;
   }

Seems simple enough, except that this inner portion is 
unrolled, and if I have more than one type to run this on, I 
already have an "innerloop" label defined.


Is there a way to define a label using a mixin or something? or 
do I have to wrap this in a function?


Is there another way to approach this?

-Steve


Unfortunately mixin does not support labels so I don't think you 
can do what you want to do.


Kind of surprised me tbh


constructing labels for static foreach inside switch inside foreach

2020-07-07 Thread Steven Schveighoffer via Digitalmars-d-learn
OK, so I have a situation where I'm foreaching over a compile-time list 
of types. Inside the loop, I'm using a second loop over a set of input.


Inside that loop, I'm using a switch on the input, and inside the 
switch, I'm foreaching over the type's members, to construct a switch 
that can handle member names (this is for serialization).


If I encounter a certain name, then I want to break out of the inner 
loop (it's a while loop)


So naturally, I have to use break statements with labels like:

innerloop:
while(haveMoreData)
   switchstmt:
   switch(nextDataElement) {
  static foreach(name; __traits(allMembers, T)) {
  case name:
 ... // handle it
 break switchstmt;
  }
  case "STOP":
 break innerloop;
   }

Seems simple enough, except that this inner portion is unrolled, and if 
I have more than one type to run this on, I already have an "innerloop" 
label defined.


Is there a way to define a label using a mixin or something? or do I 
have to wrap this in a function?


Is there another way to approach this?

-Steve


How can I make DMD stop on the first fatal error? (-Wfatal-errors)

2020-07-07 Thread Marcone via Digitalmars-d-learn
How can I make DMD stop on the first fatal error like 
-Wfatal-errors on C++?


Re: Template function specialization doesn't work

2020-07-07 Thread Ali Çehreli via Digitalmars-d-learn

On 7/7/20 12:53 PM, IGotD- wrote:


ubyte[3] ar = [ 1, 2, 3 ];
ubyte[] arSlice = ar;

overloadedFunction(arSlice);

The first function will be used. Shouldn't the template argument (T : 
T[]) make the compiler pick the second one?


There is also template constraints which may be useful:

import std.traits;

void overloadedFunction(T)(ref T val)
if (!isArray!T) {
  writeln("general");
}

void overloadedFunction(T)(ref T s)
if (isArray!T) {
  writeln("T[]");
}

Ali




Re: Template function specialization doesn't work

2020-07-07 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/7/20 4:21 PM, IGotD- wrote:

On Tuesday, 7 July 2020 at 20:14:19 UTC, IGotD- wrote:


Thank you, that worked and now it picked the correct overloaded 
function. I don't understand why and it is a bit counter intuitive. 
Why two template arguments as I'm not even us using U?


If you look at the article

https://dlang.org/articles/templates-revisited.html#specialization

Then it mentioned that (T : T*) would work. Intuitively, then you 
would think (T : T[]) would work.


Here (T : T[]) is even the example with the correct double[] type as a 
correct example as well.


https://dlang.org/spec/template.html#parameters_specialization

I'm confused.


That's not IFTI, that's template instantiation.

I bet if you did:

overloadedFunction!(ubyte[])(arSlice)

it would pick the second one.

there is some extra magic going on for IFTI, and I'm not sure how it 
figures out what to do. I would agree with you that if explicit 
templates use that rule, so should IFTI. But perhaps there's a good 
reason why it can't be done.


So possibly:

overloadedFunction(arSlice) => Pattern match `ref T[]` to `ubyte[]` => T 
is ubyte => Check ubyte for T : T[], no match.


-Steve


Re: opApply and attributes

2020-07-07 Thread Ali Çehreli via Digitalmars-d-learn
On 7/6/20 5:20 PM, solidstate1991 wrote:> See implementation of data 
structure here:
> 
https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/treemap.d#L565 


>
>
> If I try to compile this code, it'll fail, limiting it's usecase:
>
> @safe pure unittest {
>  alias IntMap = TreeMap!(int, int, false);
>  IntMap test;
>  test[5] = 5;
>  test[7] = 7;
>  test[3] = 3;
>  foreach(elem, key; test) {
>  assert(elem == key);
>  }
> }

I am not sure whether I understand it correctly but there has been a 
request for opApply() to gain the attributes of the delegate (or the 
range?). In other words, "transfer the attributes to opApply". This is 
needed because I want opApply() to work with any foreach body, 
attributes of which opApply() cannot know.


I am sure I created an issue on Dlang bug tracker for Weka on this topic 
but I can't find it now. (Aside: The search boxes on the bug tracker are 
inferior to the automatic search feature that works when creating a 
bug.) Anyway, this one seems related:


  https://issues.dlang.org/show_bug.cgi?id=7543

Ali



Re: opApply and attributes

2020-07-07 Thread solidstate1991 via Digitalmars-d-learn

On Tuesday, 7 July 2020 at 13:33:41 UTC, Paul Backus wrote:


You can make opApply a template:

int opApply(Dg)(Dg dg)
if (is(Dg : scope int delegate(ref E)))
{
// etc.
}

Because `scope int delegate(ref E) @safe` implicitly converts 
to `scope int delegate(ref E)`, this version will accept both 
@safe and non-@safe delegates. (And likewise for the other 
function attributes.)


Unfortunately this doesn't really work, even with explicitly 
defined foreach arguments.


Re: Template function specialization doesn't work

2020-07-07 Thread IGotD- via Digitalmars-d-learn

On Tuesday, 7 July 2020 at 20:14:19 UTC, IGotD- wrote:


Thank you, that worked and now it picked the correct overloaded 
function. I don't understand why and it is a bit counter 
intuitive. Why two template arguments as I'm not even us using 
U?


If you look at the article

https://dlang.org/articles/templates-revisited.html#specialization

Then it mentioned that (T : T*) would work. Intuitively, then 
you would think (T : T[]) would work.


Here (T : T[]) is even the example with the correct double[] type 
as a correct example as well.


https://dlang.org/spec/template.html#parameters_specialization

I'm confused.


Re: Template function specialization doesn't work

2020-07-07 Thread IGotD- via Digitalmars-d-learn
On Tuesday, 7 July 2020 at 20:05:37 UTC, Steven Schveighoffer 
wrote:

On 7/7/20 4:04 PM, Steven Schveighoffer wrote:


Have you tried (T: U[], U)(ref T[] s) ?


Ugh... (T: U[], U)(ref T s)

-Steve


Thank you, that worked and now it picked the correct overloaded 
function. I don't understand why and it is a bit counter 
intuitive. Why two template arguments as I'm not even us using U?


If you look at the article

https://dlang.org/articles/templates-revisited.html#specialization

Then it mentioned that (T : T*) would work. Intuitively, then you 
would think (T : T[]) would work.


Re: Template function specialization doesn't work

2020-07-07 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/7/20 4:04 PM, Steven Schveighoffer wrote:


Have you tried (T: U[], U)(ref T[] s) ?


Ugh... (T: U[], U)(ref T s)

-Steve


Re: Template function specialization doesn't work

2020-07-07 Thread IGotD- via Digitalmars-d-learn

On Tuesday, 7 July 2020 at 19:53:30 UTC, IGotD- wrote:


...



I also forgot to mention that the overloadedFunction is used in a 
variadic template function.


void processAll(T...)(ref T t)
{
foreach(ref v; t)
{
overloadedFunction(v);
}
}





Re: Template function specialization doesn't work

2020-07-07 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/7/20 3:53 PM, IGotD- wrote:

I have two template functions

void overloadedFunction(T)(ref T val)
{

}


void overloadedFunction(T : T[])(ref T[] s)
{

}

Obviously the second should be used when the parameter is a slice of any 
type, and the first should be used in other cases. However this doesn't 
happen, the compiler always picks the first function regardless if the 
parameter is a slice or not.


So

ubyte[3] ar = [ 1, 2, 3 ];
ubyte[] arSlice = ar;

overloadedFunction(arSlice);

The first function will be used. Shouldn't the template argument (T : 
T[]) make the compiler pick the second one?




That specialization is... odd. It's basically saying, is T an array of T.

I know I've seen this before, so I think it's valid. But maybe not?

Have you tried (T: U[], U)(ref T[] s) ?

-Steve


Template function specialization doesn't work

2020-07-07 Thread IGotD- via Digitalmars-d-learn

I have two template functions

void overloadedFunction(T)(ref T val)
{
...
}


void overloadedFunction(T : T[])(ref T[] s)
{
...
}

Obviously the second should be used when the parameter is a slice 
of any type, and the first should be used in other cases. However 
this doesn't happen, the compiler always picks the first function 
regardless if the parameter is a slice or not.


So

ubyte[3] ar = [ 1, 2, 3 ];
ubyte[] arSlice = ar;

overloadedFunction(arSlice);

The first function will be used. Shouldn't the template argument 
(T : T[]) make the compiler pick the second one?




Re: How to specify a version from dub build command

2020-07-07 Thread mw via Digitalmars-d-learn

On Tuesday, 7 July 2020 at 06:34:15 UTC, adnan338 wrote:
I have a separate version for flatpak builds in my app. Let's 
say I have a large project that builds with dub that goes like 
this:


import std.stdio;

void main()
{
version (flatpak) {
writeln(`Flatpak build`);
} else {
writeln("Edit source/app.d to start your project.");
}
}

Now if I try `dub build --version=flatpak` it's not recognized 
by the compiler. How can I set the version __from command 
line__ before building my project? I cannot depend on dflags 
inside dub.json because dub.json has no idea whether if it's 
being parsed in a flatpak version build or a regular build.


try dub Configurations?

https://dub.pm/package-format-json.html#configurations




Re: opApply and attributes

2020-07-07 Thread Stanislav Blinov via Digitalmars-d-learn

On Tuesday, 7 July 2020 at 13:33:41 UTC, Paul Backus wrote:


You can make opApply a template:

int opApply(Dg)(Dg dg)
if (is(Dg : scope int delegate(ref E)))
{
// etc.
}

Because `scope int delegate(ref E) @safe` implicitly converts 
to `scope int delegate(ref E)`, this version will accept both 
@safe and non-@safe delegates. (And likewise for the other 
function attributes.)


Yeah, but unfortunately then this won't work:


foreach(elem; test) {
assert(elem == key);
}


you'd have to spell out the types for `elem`.


Re: Catching OS Exceptions in Windows using LDC

2020-07-07 Thread realhet via Digitalmars-d-learn

On Saturday, 4 July 2020 at 14:44:06 UTC, Kagamin wrote:
try 
https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-setunhandledexceptionfilter


Thank You, this was the winner for me.
Not just I can catch the OS Exceptions, I can check and alter the 
CPU state and decide to continue execution from an optionally 
modified cpu state, or just stop and show the error.


It needed some work, but this seems the best way for LDC2 Win64.


Re: opApply and attributes

2020-07-07 Thread Paul Backus via Digitalmars-d-learn

On Tuesday, 7 July 2020 at 00:20:40 UTC, solidstate1991 wrote:
See implementation of data structure here: 
https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/treemap.d#L565


If I try to compile this code, it'll fail, limiting it's 
usecase:


@safe pure unittest {
alias IntMap = TreeMap!(int, int, false);
IntMap test;
test[5] = 5;
test[7] = 7;
test[3] = 3;
foreach(elem, key; test) {
assert(elem == key);
}
}


You can make opApply a template:

int opApply(Dg)(Dg dg)
if (is(Dg : scope int delegate(ref E)))
{
// etc.
}

Because `scope int delegate(ref E) @safe` implicitly converts to 
`scope int delegate(ref E)`, this version will accept both @safe 
and non-@safe delegates. (And likewise for the other function 
attributes.)


Re: BetterC Bug? Intended Behavior? Asking Here As Unsure

2020-07-07 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/7/20 8:26 AM, Steven Schveighoffer wrote:

On 7/6/20 5:09 PM, kinke wrote:

On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote:
Though, admittedly I'm kind of used to seeing this error message 
since it appears any time you try and do something that relies on 
type info in betterC, intentionally or not. A notable example is 
forgetting to supply an arrange length when declaring a stack array, 
or it'll try to create a runtime-allocated array.


Similar case here; the 'varargs' end up in a GC-allocated array. I've 
recently changed `scope` slice params, so that array literal arguments 
are allocated on the caller's stack instead; so adding `scope` for 
these variadics *should* probably do the same:


void tester(Test test, scope Test[] tests...);


Note that without the initial parameter, or without the destructor, they 
do NOT end up on the heap.


I think this is a bug, and not a "feature". I can't see any reason why 
in those two cases it can construct it on the stack, and in this case it 
cannot.


I should clarify:
1. Removing the destructor, but leaving the initial parameter => stack 
allocated
2. Removing the initial parameter, but leaving the destructor => stack 
allocated


This is why I think it's at least inconsistent. A bug might be too far, 
since the spec clearly gives leeway to implementations to allocate on 
the heap.


But I would love to see the spec changed to require stack allocation.

-Steve


Re: Construct an used-defined hash table container type from an AA-literal expression

2020-07-07 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 6 July 2020 at 12:04:11 UTC, Jacob Carlborg wrote:

void main() @nogc
{
auto a = tuple(Pair("foo", 1), Pair("bar", 2));
}

--
/Jacob Carlborg


Thanks.

What about construction and assignment from a static array of 
`Pair`'s? Wouldn't that be easier on the compiler?


Re: BetterC Bug? Intended Behavior? Asking Here As Unsure

2020-07-07 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/6/20 5:09 PM, kinke wrote:

On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote:
Though, admittedly I'm kind of used to seeing this error message since 
it appears any time you try and do something that relies on type info 
in betterC, intentionally or not. A notable example is forgetting to 
supply an arrange length when declaring a stack array, or it'll try to 
create a runtime-allocated array.


Similar case here; the 'varargs' end up in a GC-allocated array. I've 
recently changed `scope` slice params, so that array literal arguments 
are allocated on the caller's stack instead; so adding `scope` for these 
variadics *should* probably do the same:


void tester(Test test, scope Test[] tests...);


Note that without the initial parameter, or without the destructor, they 
do NOT end up on the heap.


I think this is a bug, and not a "feature". I can't see any reason why 
in those two cases it can construct it on the stack, and in this case it 
cannot.


Note that I was under the impression that a Typesafe Variadic would 
always be on the stack. Reading the spec, it says it "may" put it on the 
stack, which makes me like those types of functions a lot less. Is there 
any reason a Typesafe Variadic function called with individual values 
cannot be required to put the values on the stack?


-Steve


Re: Associative array on the heap

2020-07-07 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/7/20 3:08 AM, mw wrote:

On Tuesday, 19 May 2015 at 12:21:48 UTC, Steven Schveighoffer wrote:

On 5/18/15 7:55 PM, Freddy wrote:

How do you allocate an associative array on the heap?

void main(){
 alias A=int[string];
 auto b=new A;
}

$ rdmd test
test.d(4): Error: new can only create structs, dynamic arrays or class
objects, not int[string]'s
Failed: ["dmd", "-v", "-o-", "test.d", "-I."]


As others have said, I don't know why you would want to do this, since 
AA is already simply a wrapper for a pointer to a


AA is a wrapper for a pointer (e.g a struct with some extra info beyond 
the plain pointer), or AA is just the plain pointer (nothing extra)?


AA is a pImpl type wrapper. Yes, it's just a pointer inside.

But it's not simply a pointer because things like indexing can change 
the pointer (i.e. if the pointer is null, it will allocate a new AA impl).


If it were just a pointer, then using it without initializing would be a 
segfault.


-Steve


Re: dub build=ddox, where the are the docs?

2020-07-07 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/6/20 5:04 PM, claptrap wrote:
Ok yeah it starts up a server and opens a webpage, great, but where are 
the docs? Cant find any info on command line switches for dub or ddox on 
how to get it to just dump the docs in a folder.





dub --build=ddox

makes a server and runs it so you can serve live documentation.

dub build --build=ddox

builds a docs folder that has all the generated HTML and associated files.

I admit, that's a poor interface...

-Steve


Re: I need an Easy example to understand Alias This

2020-07-07 Thread Ferhat Kurtulmuş via Digitalmars-d-learn

On Tuesday, 7 July 2020 at 00:35:38 UTC, Marcone wrote:
Hi, I study Dlang for one year, and I can't understand alias 
this. I need an Easy example to understand Alias This.


I used it for widget inheritance in my experimental code here,

https://github.com/aferust/noobgui/blob/master/source/widget.d


Re: I need an Easy example to understand Alias This

2020-07-07 Thread Cym13 via Digitalmars-d-learn

On Tuesday, 7 July 2020 at 00:44:32 UTC, Marcone wrote:

On Tuesday, 7 July 2020 at 00:42:40 UTC, Ali Çehreli wrote:

On 7/6/20 5:35 PM, Marcone wrote:
Hi, I study Dlang for one year, and I can't understand alias 
this. I need an Easy example to understand Alias This.


Is the following example useful?

  http://ddili.org/ders/d.en/alias_this.html

Ali


I can't undestand it. I need a simple example.


This only scrapes the surface, but it should give an idea of the 
core mechanics and why it's regarded as an important concept.



import std.stdio;

struct Fruit {
string name;
}

struct ColoredFruit {
Fruit _fruit;
alias _fruit this;

string color;
}

void printColoredFruit(ColoredFruit f) {
writeln(f.color, " ", f.name);
}

void printGeneralFruit(Fruit f) {
writeln(f.name);
}

void main(string[] args) {
ColoredFruit banana;
banana.color = "yellow"; // It's a normal struct for its 
non-alias members
banana.name  = "banana"; // We can interact with internal 
fields directly


// This function accepts a ColoredFruit so the whole banana 
is passed.

printColoredFruit(banana);
// > yellow banana

// This function only doesn't accept a ColoredFruit, but it 
does accept a
// Fruit and we have a Fruit alias this so the internal 
_fruit is passed.

printGeneralFruit(banana);
// > banana
}



Re: Associative array on the heap

2020-07-07 Thread mw via Digitalmars-d-learn
On Tuesday, 19 May 2015 at 12:21:48 UTC, Steven Schveighoffer 
wrote:

On 5/18/15 7:55 PM, Freddy wrote:

How do you allocate an associative array on the heap?

void main(){
 alias A=int[string];
 auto b=new A;
}

$ rdmd test
test.d(4): Error: new can only create structs, dynamic arrays 
or class

objects, not int[string]'s
Failed: ["dmd", "-v", "-o-", "test.d", "-I."]


As others have said, I don't know why you would want to do 
this, since AA is already simply a wrapper for a pointer to a


AA is a wrapper for a pointer (e.g a struct with some extra info 
beyond the plain pointer), or AA is just the plain pointer 
(nothing extra)?


I tried this:

  class Foo {}
  Foo[string] foos;
  writeln(foos.sizeof);  // print 8

looks like it's just a plain pointer?


The usage pattern to have AA on the heap is, e.g:

class Class {
  StudentInfo[string] students;  // dict-by-name
  // many other fields
}

suppose in a multi-threaded app, the Class object is shared, and 
one thread will perform a lengthy updates on all the students. To 
ensure data consistency among all the students object, instead of 
updating each student's info of the original AA in a loop (with 
lengthy locking period), it can be achieved by heap-alloc a new 
AA, update the new AA, and atomic-set:


  new_students = new StudentInfo[string];  // heap-alloc a new AA
  // length update on each of new_students
  atomicStore(theClass.students, new_students);