On Sunday, 27 December 2020 at 13:27:49 UTC, oddp wrote:
foreach (group; readText("input").splitter("\n\n")) { ... }
Also, on other days, when the input is more uniform, there's
always https://dlang.org/library/std/file/slurp.html which
makes reading it in even easier, e.g. day02:
alias
It's more of a multi-part question,
I've been trying to read tuples using 'slurp', though later
realised one of the types was an enum, I'm guessing that's what
was the problem, which lead me down a whole rabbit hole.
- Can I directly read tuples using slurp? It doesnt seem to like
On Sunday, 27 December 2020 at 23:12:46 UTC, Rekel wrote:
Sidetangent, don't mean to bash the learning tour, as it's been
really useful for getting started, but I'm surprised stuff like
tuples and files arent mentioned there.
Update;
Any clue why there's both "std.file" and "std.io.File"?
I
On Wednesday, 23 December 2020 at 04:03:37 UTC, Ali Çehreli wrote:
It is valid. One can always copy the small array before
appending to it and the large array would be preserved.
Try the -profile command line switch when compiling your
program and it will show where memory allocations occur.
After reading most of the tour.dlang.org website, I was
completely surprised & confused encountering 'KeepTerminator', a
'Flag' used by the File.byLine function. With no examples
denoting how to use it.
Most confusing was the way the documentation (website &
in-editor) used;
1.
I found a lot of the Phobos documentation to contain template
arguments and if statements that made no sense to me, for example:
```
uint readf(alias format, A...) (
auto ref A args
)
if (isSomeString!(typeof(format)));
uint readf(A...) (
scope const(char)[] format,
auto ref A args
);
```
Thanks for all the help! This makes it make a lot more sense now,
I'm surprised it's not part of the dlang tour.
The template parameter serves to make Flag!"foo" a distinct
type from Flag!"bar".
Does this mean other flag yes's will not be accepted?
On Sunday, 20 December 2020 at 13:58:00 UTC, Max Haughton wrote:
The if is a template constraint.
Ah sorry! I must have missed that part of the dlang tour.
(https://tour.dlang.org/tour/en/gems/template-meta-programming)
Thanks a lot!
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;
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
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;//
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
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
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
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
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
On Sunday, 20 December 2020 at 15:04:29 UTC, Steven Schveighoffer
wrote:
On 12/20/20 9:07 AM, Rekel wrote:
Does this mean other flag yes's will not be accepted?
The long and short of it is that Flag is supposed to make you
NAME what your flag is for.
The idea is to prevent things like:
I'm trying to read a file with entries seperated by '\n\n' (empty
line), with entries containing '\n'. I thought the
File.readLine(KeepTerminator, Terminator) might work, as it seems
to accept strings as terminators, since there seems to have been
a thread regarding '\r\n' seperators.
I
On Sunday, 27 December 2020 at 02:41:12 UTC, Jesse Phillips wrote:
Unfortunately std.csv is character based and not string.
https://dlang.org/phobos/std_csv.html#.csvReader
But your use case sounds like splitter is more aligned with
your needs.
http://ddili.org/ders/d.en/index.html
This seems very promising :)
I doubt I'd still be considering D if it weren't for this awesome
learning forum, thanks for all the help!
On Tuesday, 29 December 2020 at 14:50:41 UTC, Steven
Schveighoffer wrote:
Are you on Windows? If so, your double newlines might be
\r\n\r\n, depending on what editor you used to create the
input. Use a hexdump program to see what the newlines are in
your input file.
I've tried \r\n\r\n as
On Tuesday, 29 December 2020 at 16:13:50 UTC, Imperatorn wrote:
https://ibb.co/syQRs9v
I hope I'm not the only one that thinks 'designers and std lib
writers unable to name anything correctly' is kind of ironic.
And don't get me started on documentation return values.
On Thursday, 31 December 2020 at 18:19:54 UTC, Ali Çehreli wrote:
Can you describe it with a piece of code? If the code shows
what the current undesired output is and what you want instead,
perhaps we can find a solution.
Regarding the enum part;
While trying to do this I noticed one cannot
And regarding the rest,
I'm curious about reading back user types, without defining a new
seperate method for it, such as structs, unions and tuples,
(although I'm unsure to what extent tuples are really a
user-defined-type).
The other thing just resolved itself;
I was wondering, as slurp
I seem to have hit a bit of a wall when comparing D enums to Java
enums.
Of course the latter is just a fancy class, though it'd be nice
to see partially equivalent usefulness regardless.
For example, as soon as non-integer, non-string values are given
to enums things get messy for me when
樂I'm either asking a stupid question, asking it in a wrong way,
or asking an important question. Clueless nontheless. . .
On Tuesday, 6 July 2021 at 14:27:35 UTC, Paul Backus wrote:
Instead of having the template evaluate to a `bool`, have it
evaluate to the type of the result:
```d
alias ResultType(Lhs, string op, Rhs) =
typeof(((Lhs lhs, Rhs rhs) => mixin("lhs", op, "rhs"))());
static
On Tuesday, 6 July 2021 at 15:00:24 UTC, Paul Backus wrote:
On Tuesday, 6 July 2021 at 14:43:26 UTC, Rekel wrote:
Is there any reason the function call in the alias is
acceptable? I would imagine the () part would actually require
2 parameters.
You're right, it does; that was a mistake on my
I recently found __traits(compiles, ...) can be used in template
constraints.
(I first used `is(mixin("T.init"~op~"T2.init"))` but this cause
problems related to nanF)
However I'm wondering if there is an easier way to do what I'm
currently doing, especially since using typeof inside the
Is there an easy way to remove elements from an array passed in
as a parameter?
Every example I find does something along the lines of:
```d
int[] a = ...
long index = countUntil(a, element);
a = a.remove(index);
But what do you do when you have?:
```d
void function(int[] a){
. . .
I'm not sure if this is the place to talk about it, but on the
same topic it's a little strange to me neither the Dlang Tour nor
the arrays spec page mention removing elements. Even though
basically everyone is going to use it sooner or later (most
likely sooner).
Is that because it's part
On Monday, 5 July 2021 at 14:22:24 UTC, jfondren wrote:
What use of long?
remove returns the same type of range as it gets:
My apology, I meant to say countUntil instead of remove in that
context.
Oh my, thank you both, that mostly cleared up my confusion, I had
no clue this was struct related.
I'll be reading the references you gave me & probably submitting
an issue
Ah, ref, thanks, I didn't know if that would work as I was
confused since arrays themselves are kind of already pointers.
On Monday, 5 July 2021 at 13:18:55 UTC, Mike Parker wrote:
In what situations do you need to manually change the length?
Where do you worry about copies? It's possible
I'm not sure why this is happening, but after simplifying my code
I traced it back to what the title may suggest. The original
cause of my issues being summarized by debug print statements
returning a union as:
Mat([nanf, nanF, . . . .], [[1.0F, 0.0F, . . . .])
Even though the nanF should
On Thursday, 22 April 2021 at 23:41:33 UTC, H. S. Teoh wrote:
On Thu, Apr 22, 2021 at 10:47:17PM +, Rekel via
Digitalmars-d-learn wrote:
I'm not sure why this is happening, but after simplifying my
code I traced it back to what the title may suggest.
Keep in mind that CTFE does
On Friday, 23 April 2021 at 00:55:50 UTC, H. S. Teoh wrote:
[...]
If you read the field during CTFE. I've never tested
initializing a union in CTFE then reading it at runtime,
though. Not sure exactly what would happen in that case.
T
I'm not referring to reading non-initial variables,
On Wednesday, 18 August 2021 at 13:35:07 UTC, Paul Backus wrote:
On Wednesday, 18 August 2021 at 11:10:49 UTC, Rekel wrote:
I tried looking into how isArray is defined. Like, does being
able to index mean it's an array, or are these only static
&/or dynamic arrays?
Did you read the
When using implicit function templates, identical specialization
yield different results.
Example:
```d
template TFoo(T){ void foo(){writeln("1");} } // #1
template TFoo(T : T[]) { void foo(){writeln("2");} } // #2
void foo(T)(){
writeln("1");
}
void foo(T : T[])(){
On Monday, 16 August 2021 at 22:01:21 UTC, russhy wrote:
remove the .dub folder and try again, as stated in other reply,
might be a cache issue, or something that picks an outdated
file in the cache
Thanks, I'll try that, sadly clear didn't seem to fix it.
On Tuesday, 17 August 2021 at 10:21:39 UTC, Mike Parker wrote:
We do have a paid Issue/Pull-Request manager now (Razvan Nitu),
and he's prioritizing issues for strike teams composed of
volunteers willing to fix them. If you find a specific bug that
is a blocker or a major headache, make a post
On Tuesday, 17 August 2021 at 10:14:07 UTC, Mike Parker wrote:
The error is in your code. Both of your `foo` templates are
implemented to print `"1"`. Change the second one to print "2"
and you will see the desired output.
I keep managing to disappoint myself greatly... this is absurd,
so
As my post was not the actual cause of my issue (my apology for
the mistake), I think I have found the actual reason I'm
currently having problems.
This seems to be related to a (seeming, I might be wrong)
inability to specialize over both 1d and 2d arrays separately.
(If constraining the
On Saturday, 14 August 2021 at 20:50:47 UTC, Carl Sturtivant
wrote:
```
struct S {
int x = 1234;
}
void main() {
import std.stdio;
S s;
//construction of a using &(s.x)
auto a = Ref!(int)();
writeln(a); //displays 1234
s.x += 1;
writeln(a); //displays 1235
a += 1;
On Tuesday, 17 August 2021 at 16:24:38 UTC, Steven Schveighoffer
wrote:
void foo(T:U[L], uint L)(T a){...}
This is an invalid specification, what is U? Did you mean:
Yes, sorry typo in the forum.
void foo(T: U[L], U, uint L)(T a) {...}
void foo(T:U[L][L], uint L)(T a){...} // Never
On Friday, 18 January 2019 at 18:49:23 UTC, Steven Schveighoffer
wrote:
As others have said, those are the rules D has for historical
reasons, you just have to deal with them.
Is that to ensure compatibility with C?
On Friday, 13 August 2021 at 09:10:18 UTC, Tejas wrote:
On Friday, 13 August 2021 at 08:25:33 UTC, JG wrote:
Suppose one has a pointer p of type T*.
Can on declare variable a of type T which is stored in the
location pointed to by p?
Umm is this what you want?
```d
import std.stdio;
struct S
I found a this thread about testing libraries:
https://forum.dlang.org/post/mailman.1807.1522279261.3374.digitalmars-d-le...@puremagic.com
But it's very old, yet I have the same issue today.
I want to build a unittest executable for the library I've made,
but given I'm trying to use the vscode
On Tuesday, 17 August 2021 at 18:27:21 UTC, Steven Schveighoffer
wrote:
According to my tests, it prefers the `T` version over the
static array version. Which leads me to believe that it prefers
a dynamic array over a static one. In fact, if I comment out
the `T` version, it doesn't compile.
On Tuesday, 17 August 2021 at 18:46:05 UTC, Ali Çehreli wrote:
I don't have such problems because I am not smart enough to
understand that syntax so I don't use it. :) I use template
constraints (which have other problems).
Yeah, they seem to be a bit more trustworthy to some extent.
If you
I am unsure where to mention this as I am utterly lost as to what
the issue is, which I can simply best describe with 2
screenshots. Though I'll first give a short description.
For some reason my debugger is "\" for
one of my variables in one of my unittests. This is however not
the case
Note you might need to open the screenshots externally, as they
are cut off by the forum.
On Monday, 2 August 2021 at 14:46:36 UTC, jfondren wrote:
C, C++, Rust, and Zig are all fine with this. Nim doesn't like
it.
I had no clue, never seen it used in any case. I've always
assumed one couldn't return void as it's not a value. I guess
intuitions aren't always universal . Good to
On Monday, 2 August 2021 at 14:51:07 UTC, H. S. Teoh wrote:
This is intentional, in order to make it easier to write
generic code without always having to special-case functions
that don't return anything.
Ooh that indeed seems useful. Thanks for the hint.
Also slightly off topic, but when
I recently found one can return function calls to void functions,
though I don't remember any documentation mentioning this even
though it doesn't seem trivial.
```d
void print(){
writeln("0");
}
void doSomething(int a){
if (a==0)
return print();
On Tuesday, 3 August 2021 at 00:53:43 UTC, user1234 wrote:
You got the answer in another reply but here is a bit of more
fun:
```d
void main() {
return cast(void) 1;
}
```
What does casting to void do? Does it just ignore whatever
follows it?
On Tuesday, 3 August 2021 at 07:23:34 UTC,
On Friday, 23 July 2021 at 14:41:41 UTC, Paul Backus wrote:
The first is to change the type of right from const R to const
T[L1], which removes the type specialization:
Thanks for suggesting that fix, removing R altogether is a very
simple solution I hadn't considered. :)
Unfortunately, the
After simplifying a part of my code I found the following code
cannot deduce the template arguments, but I have no clue why.
```d
void foo(L : T[L1][L2], uint L1, uint L2, T, R:
T[L1])(const L left, const R right) {
// Function
}
void bar(uint L)(float[L] l) {
58 matches
Mail list logo
