Re: Running unit tests from DUB single file packages

2020-12-22 Thread drug via Digitalmars-d-learn
On 12/22/20 8:32 PM, jmh530 wrote: On Tuesday, 22 December 2020 at 15:06:09 UTC, drug wrote: [snip] 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

Re: Why is (int[int] s = int[int].init) not allowed

2020-12-22 Thread Daniel Kozak via Digitalmars-d-learn
Dne st 23. 12. 2020 1:00 uživatel Steven Schveighoffer via Digitalmars-d-learn napsal: > On 12/22/20 5:44 PM, Daniel Kozak wrote: > > On Tue, Dec 22, 2020 at 10:15 PM Andre Pany via Digitalmars-d-learn > > > > wrote: > > > > Hi, > > > > I am

Re: Slice allocation after appending

2020-12-22 Thread Ali Çehreli via Digitalmars-d-learn
On 12/22/20 2:12 PM, Rekel wrote: > Now I'm unsure how to check this, I tried to a bit using the online > editor and a bit of pointer usage which seemed to confirm my suspicion, > but does this mean that taking a (small) slice at the end of a > (possibly) very large dynamic array can lead to

Re: Can I output strings using core.stdc.stdio?

2020-12-22 Thread Paul Backus via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 21:26:37 UTC, Godnyx wrote: On Tuesday, 22 December 2020 at 21:10:59 UTC, Godnyx wrote: Is there a way? If not then how std.stdio does it? I should mention that I want to use it in a variable that can't be read at compile time so .toStringz is not working for

Re: Slice allocation after appending

2020-12-22 Thread Basile B. via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 22:12:29 UTC, Rekel wrote: According to the D slice article (https://dlang.org/articles/d-array-article.html), slices do not care where they start, only where they end, when checking whether expanding in place is permitable, or at least that is what I

Re: Why is (int[int] s = int[int].init) not allowed

2020-12-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 12/22/20 5:44 PM, Daniel Kozak wrote: On Tue, Dec 22, 2020 at 10:15 PM Andre Pany via Digitalmars-d-learn > wrote: Hi, I am really confused, why is this valid: void sample(string[string] s = string[string].init){} while this causes

Re: Getting started with graphqld

2020-12-22 Thread aberba via Digitalmars-d-learn
On Friday, 18 December 2020 at 03:36:05 UTC, Trustee wrote: On Thursday, 17 December 2020 at 14:49:42 UTC, evilrat wrote: On Tuesday, 15 December 2020 at 16:25:29 UTC, Trustee wrote: connect a basic vibe-d app to a graphql backend. umm, what? Did you mean write graphql backend using

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Ali Çehreli via Digitalmars-d-learn
On 12/22/20 10:53 AM, Rekel wrote:> On Tuesday, 22 December 2020 at 16:56:18 UTC, Ali Çehreli wrote: >> >[4]Foo b; /* an array of four Foos */ >> >> [4] already has a meaning. ;) > > It does in that context? Do tell, I'm unaware. An array literal with a single int element 4: pragma(msg,

Re: Why is (int[int] s = int[int].init) not allowed

2020-12-22 Thread Daniel Kozak via Digitalmars-d-learn
On Tue, Dec 22, 2020 at 10:15 PM Andre Pany via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > Hi, > > I am really confused, why is this valid: > void sample(string[string] s = string[string].init){} > > while this causes syntax errors? > > void sample_invalid1(double[string] s

Slice allocation after appending

2020-12-22 Thread Rekel via Digitalmars-d-learn
According to the D slice article (https://dlang.org/articles/d-array-article.html), slices do not care where they start, only where they end, when checking whether expanding in place is permitable, or at least that is what I understood regarding it. Now I'm unsure how to check this, I tried

Re: Why is (int[int] s = int[int].init) not allowed

2020-12-22 Thread Andre Pany via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 22:02:54 UTC, ag0aep6g wrote: On Tuesday, 22 December 2020 at 21:11:12 UTC, Andre Pany wrote: [...] Looks like an oddity in the grammar. `string` is an alias, meaning it's an identifier. And an identifier is a valid expression to the grammar. So

Re: Why is (int[int] s = int[int].init) not allowed

2020-12-22 Thread ag0aep6g via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 21:11:12 UTC, Andre Pany wrote: I am really confused, why is this valid: void sample(string[string] s = string[string].init){} while this causes syntax errors? void sample_invalid1(double[string] s = double[string].init){} void sample_invalid2(int[int] s =

Re: Can I output strings using core.stdc.stdio?

2020-12-22 Thread Dave P. via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 21:37:23 UTC, Godnyx wrote: On Tuesday, 22 December 2020 at 21:28:10 UTC, Dave P. wrote: On Tuesday, 22 December 2020 at 21:10:59 UTC, Godnyx wrote: [...] Lol. Actually I just don't want to use Phobos and trying to stay on core. Unfortunately, my variable

Re: Can I output strings using core.stdc.stdio?

2020-12-22 Thread Godnyx via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 21:28:10 UTC, Dave P. wrote: On Tuesday, 22 December 2020 at 21:10:59 UTC, Godnyx wrote: Is there a way? If not then how std.stdio does it? I assume you’re asking this because you don’t have access to std.stdio (such as using betterC). The way to do it is to

Re: Can I output strings using core.stdc.stdio?

2020-12-22 Thread Dave P. via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 21:10:59 UTC, Godnyx wrote: Is there a way? If not then how std.stdio does it? I assume you’re asking this because you don’t have access to std.stdio (such as using betterC). The way to do it is to use the %.*s specifier in printf. For example: void

Re: Can I output strings using core.stdc.stdio?

2020-12-22 Thread Godnyx via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 21:10:59 UTC, Godnyx wrote: Is there a way? If not then how std.stdio does it? I should mention that I want to use it in a variable that can't be read at compile time so .toStringz is not working for me.

Why is (int[int] s = int[int].init) not allowed

2020-12-22 Thread Andre Pany via Digitalmars-d-learn
Hi, I am really confused, why is this valid: void sample(string[string] s = string[string].init){} while this causes syntax errors? void sample_invalid1(double[string] s = double[string].init){} void sample_invalid2(int[int] s = int[int].init){} Kind regards André

Can I output strings using core.stdc.stdio?

2020-12-22 Thread Godnyx via Digitalmars-d-learn
Is there a way? If not then how std.stdio does it?

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Rekel via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 16:55:40 UTC, Mike Parker wrote: On Tuesday, 22 December 2020 at 15:31:06 UTC, Rekel wrote: Don't take that as a defence of changing pointer syntax by the way, just noting I think the argument pointers and arrays should be defined using a similar syntax is

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Rekel via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 16:56:18 UTC, Ali Çehreli wrote: >[4]Foo b; /* an array of four Foos */ [4] already has a meaning. ;) It does in that context? Do tell, I'm unaware. Also, is it possible to move entire thread to a different forum group?  This feels more like a

Re: Floating point values in structs.

2020-12-22 Thread Dave P. via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 18:10:22 UTC, Dukc wrote: On Friday, 18 December 2020 at 16:18:12 UTC, Dave P. wrote: [...] Honestly, I just want all bits zero. I don’t work with any platforms where null is not 0 and all-zero-bits aggregates can be efficiently represented in static storage.

Re: Floating point values in structs.

2020-12-22 Thread Dukc via Digitalmars-d-learn
On Friday, 18 December 2020 at 16:18:12 UTC, Dave P. wrote: If the compiler is going to introduce the overhead of initializing all the variables anyway, why set it to nan when integer types get set to the useful default of 0? Consider default value of `int*`. It is `null`, not a pointer to a

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread ag0aep6g via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 16:56:18 UTC, Ali Çehreli wrote: On 12/22/20 6:35 AM, ag0aep6g wrote: > Flip the pointer syntax, too: > > *Foo a; /* a pointer to a Foo */ I am not a language expert but I think that would make D's parsing complicated (like C++'s < token) because * already

Re: Running unit tests from DUB single file packages

2020-12-22 Thread jmh530 via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 15:06:09 UTC, drug wrote: [snip] 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

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Ali Çehreli via Digitalmars-d-learn
On 12/22/20 8:56 AM, Ali Çehreli wrote: > * already means "derefence" "dereference" > > But now we're no longer C-like, I guess.x That x seems to be due to my fat Emacs fingers. Ali

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Ali Çehreli via Digitalmars-d-learn
On 12/22/20 6:35 AM, ag0aep6g wrote: > Flip the pointer syntax, too: > > *Foo a; /* a pointer to a Foo */ I am not a language expert but I think that would make D's parsing complicated (like C++'s < token) because * already means "derefence" in that position. So, the parser would see

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Mike Parker via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 15:31:06 UTC, Rekel wrote: Don't take that as a defence of changing pointer syntax by the way, just noting I think the argument pointers and arrays should be defined using a similar syntax is not consistent when thinking about indexing & dereferencing.

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Rekel via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 15:24:04 UTC, Rekel wrote: The way C syntax handles pointers isn't very consistent to begin with imo. It's strange & and * are prepended to pointer variables for example, while indexing is postpended. Leads to stuff like; (*array_of_pointers_to_arrays[2])[1] vs

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Rekel via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 14:15:12 UTC, Mike Parker wrote: [][4]Foo is completely backwards from and inconsistent with the pointer declaration syntax. We shouldn't want to intentionally introduce inconsistencies. The way C syntax handles pointers isn't very consistent to begin with

Re: Running unit tests from DUB single file packages

2020-12-22 Thread drug via Digitalmars-d-learn
On 12/22/20 10:52 AM, drug wrote: 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

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread ag0aep6g via Digitalmars-d-learn
On 22.12.20 15:15, Mike Parker wrote: On Tuesday, 22 December 2020 at 13:59:54 UTC, Rekel wrote: I am curious by the way, what do you think of the [][4]Row suggestion I gave? In a way you'd have your  & could eat it too, i think ^^ (Still a strange saying to me) Currently, D's variable

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Mike Parker via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 13:59:54 UTC, Rekel wrote: I am curious by the way, what do you think of the [][4]Row suggestion I gave? In a way you'd have your  & could eat it too, i think ^^ (Still a strange saying to me) Currently, D's variable declaration syntax is consistent and,

Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Rekel via Digitalmars-d-learn
On Tuesday, 22 December 2020 at 07:19:49 UTC, Ali Çehreli wrote: Let me try the history example: Row[4][] history; Row array (of 4) array. Fully disagreed: D's array syntax makes me happy; designed right. :) I think i see your point, strange how a change of words makes some things