Re: Running unit tests from DUB single file packages

2020-12-21 Thread drug via Digitalmars-d-learn

On 12/21/20 7:31 PM, jmh530 wrote:

On Monday, 21 December 2020 at 11:31:49 UTC, drug wrote:

[snip]
Unfortunately I'm very busy. But I check it again and it turns out 
that the fix does not resolve the problem completely. This PR just 
remove the single file from testing so currently dub does not run unit 
tests in the single file package at all. The first variant 
(https://github.com/dlang/dub/pull/2050) fixes the issue indeed. I 
need to reevaluate these PRs and close the issue. I'll do it later.


Thanks for taking a look.


Not at all.

But what do you mean exactly by "work with dependency"? As I understand, 
`dub test` does not run unit tests in dependencies and single file 
packages work with dependencies in general. Do you mean something else? 
I'm finishing the new PR to fix #2051 finally and I'd like to know if 
there is something else I should include in it.


Re: Trying to understand multidimensional arrays in D

2020-12-21 Thread Ali Çehreli via Digitalmars-d-learn

On 12/21/20 8:47 PM, Rekel wrote:

> On Monday, 30 January 2017 at 07:33:34 UTC, Ali Çehreli wrote:
>> As others have said, D's array definition is natural because unlike
>> C's inside-out (or is that outside-in?) syntax, it follows from the
>> alias syntax. Replacing History inside main with Matrix[], etc.:
>>
>> History history;// is the same as:
>> Matrix[] history;   // is the same as:
>> Row[4][] history;   // is the same as:
>> int[4][4][] history;
>>
>> Ali
>
> Defending array-notation by giving an example of explicitly not using
> declared aliases makes no sense to me.

Reading 3-year younger Ali's message, I still agree with him. The 
aliases were not given to defend D's array syntax. They were just an 
additional information which I do use occasionally to simplify my code.


> When I define 2d arrays, or index them, I think in row -> column terms

Everybody have their own mental model. Because C, C++, D, three 
languages that I am quite familiar with, don't have 2d arrays, 
personally, I never felt comfortable with that mental model. I don't 
think C's array syntax is left-to-right or right-to-left, it's either 
inside-out or outside-in. As soon as I learned about D's array syntax I 
felt happy. Consistent...


> (often math notation for matrix size being; 'rows x columns'), or more
> generally in big -> small terms, which is clear when using the
> consistent left->right notation, big picture first followed by detail,
> honestly the whole concept of encapsulation;
>
>> History history;
>> Matrix[] history;

Ok.

>> Row[][4] history; // collection of rows, stored in a dynamic array

But that's not consistent. If array syntax is "type followed by square 
bracketed stuff", then your history must be


  Row[4][] history;

  Row[4] -> Four rows

Now, if we call that T, a history of those is

  T[]

Replacing T with Row[4]

  Row[4][] history;

That's what understand from consistency. What other consistent mental 
model is there to accept int[] as an array of ints but when it comes to 
an array of Row[4]s we should write Row[][4]? It's not logical nor 
consistent. It's a remnant of C, where the creator decided to make the 
definition and the use the same (or similar). Well, that did not work 
for me. And the creator agreed in a interview (which I am not motivated 
to search for now) that he might find a better syntax for C array but it 
was too late then.


> At heart however, this declaration design leads to inconsistency.

I disagree and I don't even understand.

>>int[1][2] history; // 1 columm, 2 rows
> vs
>>int last_element = history[1][0] // row 1, column 0
>
> This makes no sense to anyone used to reading left to right, or even
> right to left.

You seem to expect the language to parse history[1][0] as a whole. (?) 
However, history[1] is an expression by itself. There is one thing that 
history[1] returns and that is the second element of that array. [0] is 
and should be applied to whatever history[1] expression produces. Now, 
that's consistent.


> Honestly, reversing reading-order when indexing & declaring is the worst
> idea I could imagine if consistency and readability were your goal.

I argue the complete opposite for the same reason: consistency and 
readability.


> It
> doesn't make more sense because you're reading 'outward', that would
> mean I would have to read both left to right _and_ right to left.

I always read from left to right: T[]. That is the array syntax. And 
arr[i]; that is the array element access syntax. Everything else falls 
into place with those definitions.


> The argument Jonathan M Davis gives in this regard hold no water for me.

Neither to me. I am simple person. Definition: T[], use: arr[i]. Done. :)

>> Like in C/C++, types are mostly read outward from the variable name in
>> D. In both C/C++ and D,

Perhaps because I'm not a native speaker, I have never ever read any 
definition from right-to-left or inside out or outside in.


>> int* foo;
>>
>> is a pointer to an int.

To me, it has always been an "int pointer".

> It's read outward from the variable name, so
>> you get the pointer and then what it points to. Similarly,
>>
>> int** foo;
>>
>> is a pointer to a pointer to an int.

No: "int pointer pointer". :)

> Feel free to read them the way you want, but personally, I read int* foo
> as 'integer pointer', which is not 'outward'.

Thank you! Me too! :)

Let me try the history example:

  Row[4][] history;

Row array (of 4) array.

> just noticed this is how D handles multidimensional arrays

I think that's the source of the disagreements: D does not have 
multidimensional arrays. C and C++ don't have multidimensional arrays 
either.


> It saddens me quite a bit, as I see it as a big design flaw and quite a
> turn-off

Fully disagreed: D's array syntax makes me happy; designed right. :)

> , "unfortunately one that can't be fixed" as Profile Analysis
> put it.

Phew! :)

>> Have a nice & safe christmas!

Same to you! <3


Re: Trying to understand multidimensional arrays in D

2020-12-21 Thread H. S. Teoh via Digitalmars-d-learn
On Tue, Dec 22, 2020 at 04:47:13AM +, Rekel via Digitalmars-d-learn wrote:
[...]
> Defending array-notation by giving an example of explicitly not using
> declared aliases makes no sense to me.
> When I define 2d arrays, or index them, I think in row -> column terms
> (often math notation for matrix size being; 'rows x columns'), or more
> generally in big -> small terms, which is clear when using the
> consistent left->right notation, big picture first followed by detail,
> honestly the whole concept of encapsulation;

If you really want multidimensional arrays, i.e., arrays that logically
range over an n-dimensional space of indices, not just arrays of arrays
(which is what the array[][]... syntax gives you), I highly recommend
designing your own array type using D's multidimensional array overload
mechanism:

https://dlang.org/spec/operatoroverloading.html#array-ops

This link gives only a 2D example, but it can be generalized to
arbitrary dimensions.  With the proper overloads, you can do
vertical/horizontal slices, subarrays, etc., all with a consistent
syntax:

arr[1, x..y]
arr[i..j, 5]
arr[2..3, 4..6]

See the ndslice package in the mir library for an actual such
implementation.


T

-- 
Why did the mathematician reinvent the square wheel?
Because he wanted to drive smoothly over an inverted catenary road.


Re: Trying to understand multidimensional arrays in D

2020-12-21 Thread Rekel via Digitalmars-d-learn

Small addition, not out of jest;
If plug and play consistency given aliases is required (which 
seems pointless, as they exit to be used), the best solution, 
which would avoid indexing inconsistency given regular reading 
order, would be the following;


alias Row = [3]int;
[1][2][3]int history;
int last_element = history[0][1][2];
[1][2]Row history;
int last_element = history[0][1][2];
Row last_row = history[0][1];

This would be consistent, and readable.


Re: Trying to understand multidimensional arrays in D

2020-12-21 Thread Rekel via Digitalmars-d-learn

On Monday, 30 January 2017 at 07:33:34 UTC, Ali Çehreli wrote:
As others have said, D's array definition is natural because 
unlike C's inside-out (or is that outside-in?) syntax, it 
follows from the alias syntax. Replacing History inside main 
with Matrix[], etc.:


History history;// is the same as:
Matrix[] history;   // is the same as:
Row[4][] history;   // is the same as:
int[4][4][] history;

Ali


Defending array-notation by giving an example of explicitly not 
using declared aliases makes no sense to me.
When I define 2d arrays, or index them, I think in row -> column 
terms (often math notation for matrix size being; 'rows x 
columns'), or more generally in big -> small terms, which is 
clear when using the consistent left->right notation, big picture 
first followed by detail, honestly the whole concept of 
encapsulation;



History history;
Matrix[] history;
Row[][4] history; // collection of rows, stored in a dynamic 
array (top level), each containing 4 (in detail).
int[][4][4] history; // collection of integers, stored in a 
dynamic array (top level), containing 4 rows (->middle level->) 
of 4 columns (in detail),


Of course, one can also prefer storing in columns, instead of 
rows, even glsl uses column-major order, just change 'Row' to 
'Column' and you're set.
My argument here of course rests on outside->in thinking, which 
one can reverse consistently. I would be fine with that.


At heart however, this declaration design leads to inconsistency.


   int[1][2] history; // 1 columm, 2 rows

vs

   int last_element = history[1][0] // row 1, column 0


This makes no sense to anyone used to reading left to right, or 
even right to left.
Honestly, reversing reading-order when indexing & declaring is 
the worst idea I could imagine if consistency and readability 
were your goal. It doesn't make more sense because you're reading 
'outward', that would mean I would have to read both left to 
right _and_ right to left.


The argument Jonathan M Davis gives in this regard hold no water 
for me.
Like in C/C++, types are mostly read outward from the variable 
name in D. In both C/C++ and D,


int* foo;

is a pointer to an int. It's read outward from the variable 
name, so you get the pointer and then what it points to. 
Similarly,


int** foo;

is a pointer to a pointer to an int.


Feel free to read them the way you want, but personally, I read 
int* foo as 'integer pointer', which is not 'outward'. Your 
argument is only based on personal reading preference, but with 
it you remove indexing consistency & introduce boustrophedon.


You don't even always have the variable name;

... = new int[1][2]

vs

... = new int[][](2, 1)


If you were to ask someone with no prior coding experience how to 
access a predefined declaration, given a onedimensional 
explanation, I'm certain they would default to standard western 
reading order, no matter the presence of a variable name.


I'm surprised this thread is 3 years old by the way, sorry for 
that, just noticed this is how D handles multidimensional arrays 
(I may add a note about this to the tour suggestions).
It saddens me quite a bit, as I see it as a big design flaw and 
quite a turn-off, "unfortunately one that can't be fixed" as 
Profile Analysis put it.



Have a nice & safe christmas!
- Rekel, the disproportionally active forum . . . person (sorry)


Re: Visual Studio with gtkD

2020-12-21 Thread RedshiftVelocities via Digitalmars-d-learn

That appears to have worked. Thanks!


Re: Visual Studio with gtkD

2020-12-21 Thread frame via Digitalmars-d-learn
On Monday, 21 December 2020 at 17:34:45 UTC, RedshiftVelocities 
wrote:
I'm trying to compile a gtkD program with VisualD. I've been 
following this guide 
(https://github.com/gtkd-developers/GtkD/wiki/Installing-on-Windows) and I can compile just fine directly from the command line. However, in VS, I get numerous errors in the form of "Error: module `Main` is in file 'gtk\Main.d' which cannot be read". I can compile non-gtk D programs just fine in VS. Any advice? Thanks!


You need to add source files and gtkd.lib to your project 
settings:


In your project properties select your [DMD/LDC-compiler > 
General] and add your generated\gtkd path to "Import Paths".


In [Linker -> Input -> Additional Dependencies] just add gtkd.lib 
to the rest.


These are my settings:

Import Paths => E:\Sources\GtkD\generated\gtkd;%(ImportPaths)
Additional Dependencies => gtkd.lib;%(AdditionalDependencies)

That's it.


Visual Studio with gtkD

2020-12-21 Thread RedshiftVelocities via Digitalmars-d-learn
I'm trying to compile a gtkD program with VisualD. I've been 
following this guide 
(https://github.com/gtkd-developers/GtkD/wiki/Installing-on-Windows) and I can compile just fine directly from the command line. However, in VS, I get numerous errors in the form of "Error: module `Main` is in file 'gtk\Main.d' which cannot be read". I can compile non-gtk D programs just fine in VS. Any advice? Thanks!


Re: Running unit tests from DUB single file packages

2020-12-21 Thread jmh530 via Digitalmars-d-learn

On Monday, 21 December 2020 at 11:31:49 UTC, drug wrote:

[snip]
Unfortunately I'm very busy. But I check it again and it turns 
out that the fix does not resolve the problem completely. This 
PR just remove the single file from testing so currently dub 
does not run unit tests in the single file package at all. The 
first variant (https://github.com/dlang/dub/pull/2050) fixes 
the issue indeed. I need to reevaluate these PRs and close the 
issue. I'll do it later.


Thanks for taking a look.


Re: Running unit tests from DUB single file packages

2020-12-21 Thread drug via Digitalmars-d-learn

On 12/20/20 9:31 PM, jmh530 wrote:

On Wednesday, 2 December 2020 at 12:51:11 UTC, drug wrote:

[snip]


Thanks! Let's see if it gets merged or if a slightly more involved
solution is needed.



Remake it - https://github.com/dlang/dub/pull/2052
This has more chances to be merged


Looks like this got merged and will be part of the newest version, which 
is great news. Have you checked that it works with dependencies?


Unfortunately I'm very busy. But I check it again and it turns out that 
the fix does not resolve the problem completely. This PR just remove the 
single file from testing so currently dub does not run unit tests in the 
single file package at all. The first variant 
(https://github.com/dlang/dub/pull/2050) fixes the issue indeed. I need 
to reevaluate these PRs and close the issue. I'll do it later.