Re: abs and minimum values
On Thursday, 28 October 2021 at 21:23:15 UTC, kyle wrote:
```
void main()
{
import std.math : abs, sgn;
alias n_type = short; //or int, long, byte, whatever
assert(n_type.min == abs(n_type.min));
assert(sgn(abs(n_type.min)) == -1);
}
```
I stumbled into this fun today. I understand why abs yields a
negative value here with overflow and no promotion. I just want
to know if it should. Should abs ever return a negative number?
Thanks.
Okay I checked the phobos docs and it does say "Limitations
Does not work correctly for signed intergal types and value
Num.min." Should have looked there first, I know. Still seems
pretty silly.
abs and minimum values
```
void main()
{
import std.math : abs, sgn;
alias n_type = short; //or int, long, byte, whatever
assert(n_type.min == abs(n_type.min));
assert(sgn(abs(n_type.min)) == -1);
}
```
I stumbled into this fun today. I understand why abs yields a
negative value here with overflow and no promotion. I just want
to know if it should. Should abs ever return a negative number?
Thanks.
Re: SumType
On Thursday, 28 October 2021 at 13:30:53 UTC, Paul Backus wrote:
On Thursday, 28 October 2021 at 09:02:52 UTC, JG wrote:
I am heavily using SumType (which I like very much). The
problem I am having is that is seems to be causing slow
compile times (as can be observed by profiling during the
compile). The problem seems to be with match (which is
extremely convenient to use). I looked at the code and it does
the only reasonable thing too do which is to test each handler
against each type. The slow compile time makes development
slower and less pleasant, so I am thinking of replacing
SumType with my own tagged union and writing out the switches
by hand. However, I really don't like this idea since it makes
the code less readable and more prone to errors. Any
suggestions?
Hi, I'm the author of `SumType`. Thanks for bringing this to my
attention. The good news is, I have not put a lot of effort so
far into micro-optimizing the compile-time performance of
`match`, so there is almost certainly room for improvement.
If you have an example of the kind of code you are seeing poor
compile-time performance for, I'd be happy to use it as a
benchmark/profiling target. Any profiling data you've collected
would also be helpful.
I've created issues for this on Bugzilla and the sumtype Github
repository:
https://issues.dlang.org/show_bug.cgi?id=22447
https://github.com/pbackus/sumtype/issues/76
Thank you so much for your response (and thanks for the hard work
that went into SumType). Here is a rather contrived example which
compiles in around 9 seconds on my machine.
import std;
struct A1 {int val; }
struct A2 {int val; }
struct A3 {int val; }
struct A4 {int val; }
struct A5 {int val; }
struct A6 {int val; }
struct A7 {int val; }
struct A8 {int val; }
struct A9 {int val; }
struct A10 {int val; }
struct A11 {int val; }
struct A12 {int val; }
struct A13 {int val; }
struct A14 {int val; }
alias A =
SumType!(A1,A2,A3,A4,A5,A6,A7,A8,A9,A10,A11,A12,A13,A14);
T asserter(T)() { assert(0); }
auto op(A1 x, A1 y, A1 z) { return x.val + y.val + z.val; }
auto op(A2 x, A2 y, A2 z) { return x.val + y.val - z.val; }
auto op(A3 x, A3 y, A3 z) { return x.val + y.val * z.val; }
auto op(A4 x, A4 y, A4 z) { return x.val + y.val & z.val; }
auto op(A5 x, A5 y, A5 z) { return x.val - y.val + z.val; }
auto op(A6 x, A6 y, A6 z) { return x.val - y.val - z.val; }
auto op(A7 x, A7 y, A7 z) { return x.val - y.val * z.val; }
auto op(A8 x, A8 y, A8 z) { return x.val - y.val & z.val; }
auto op(A9 x, A9 y, A9 z) { return x.val * y.val + z.val; }
auto op(A10 x, A10 y, A10 z) { return x.val * y.val - z.val; }
auto op(A11 x, A11 y, A11 z) { return x.val * y.val * z.val; }
auto op(A12 x, A12 y, A12 z) { return x.val * y.val & z.val; }
auto op(A13 x, A13 y, A13 z) { return x.val & y.val + z.val; }
auto op(A14 x, A14 y, A14 z) { return x.val & y.val - z.val; }
auto op(A a, A b, A c) {
return a.match!(
x=>b.match!(
y=>c.match!(z=>op(x,y,z),
_=>asserter!int),
_=>asserter!int));
}
auto op2(A a, A b, A c) {
alias doMatch = match!(
(x, y, z) => op(x,y,z),
(_1, _2, _3) => asserter!int
);
return doMatch(a, b, c);
}
void main()
{
A a = A1(12);
A b = A1(13);
A c = A1(14);
assert(op(a,b,c)==39);
assert(op2(a,b,c)==39);
}
Re: Vibe.d tutorial
On Thursday, 28 October 2021 at 13:30:36 UTC, Rey Valeza wrote: On Friday, 2 April 2021 at 22:29:20 UTC, Imperatorn wrote: On Thursday, 4 March 2021 at 13:47:11 UTC, Imperatorn wrote: On Monday, 1 March 2021 at 22:25:39 UTC, Rey Valeza wrote: [...] https://github.com/reyvaleza/vibed/blob/main/Build%20Web%20Apps%20in%20Vibe.pdf New link: https://raw.githubusercontent.com/reyvaleza/vibed/main/BuildWebAppsinVibe.pdf I know this is very, very late, but thank you! No, thank *you*
Re: Vibe.d tutorial
On Wednesday, 7 April 2021 at 09:00:29 UTC, M.M. wrote: On Friday, 2 April 2021 at 22:29:20 UTC, Imperatorn wrote: On Thursday, 4 March 2021 at 13:47:11 UTC, Imperatorn wrote: On Monday, 1 March 2021 at 22:25:39 UTC, Rey Valeza wrote: Hi, I wrote a tutorial on Vibe.d while trying to re-learn Vibe.d. I find that most of Kai Nacke's book need updating, so I wrote a tutorial while trying to re-learn it. Here it is. https://github.com/reyvaleza/vibed/commit/27ec3678f25d1dd414fae1390677397a7bc57721 I would be glad if you can give me some feedback so I can improve it. Thanks! https://github.com/reyvaleza/vibed/blob/main/Build%20Web%20Apps%20in%20Vibe.pdf New link: https://raw.githubusercontent.com/reyvaleza/vibed/main/BuildWebAppsinVibe.pdf Looks like a really lot of work. Updating books/notes as the language/software advances is a tedious work which often gets forgotten... So cudos to you. I think you could also post to "Announcement" section of the dlang forum for a much better visibility. Thanks! I just did!
Re: SumType
On Thursday, 28 October 2021 at 09:02:52 UTC, JG wrote: I am heavily using SumType (which I like very much). The problem I am having is that is seems to be causing slow compile times (as can be observed by profiling during the compile). The problem seems to be with match (which is extremely convenient to use). I looked at the code and it does the only reasonable thing too do which is to test each handler against each type. The slow compile time makes development slower and less pleasant, so I am thinking of replacing SumType with my own tagged union and writing out the switches by hand. However, I really don't like this idea since it makes the code less readable and more prone to errors. Any suggestions? Hi, I'm the author of `SumType`. Thanks for bringing this to my attention. The good news is, I have not put a lot of effort so far into micro-optimizing the compile-time performance of `match`, so there is almost certainly room for improvement. If you have an example of the kind of code you are seeing poor compile-time performance for, I'd be happy to use it as a benchmark/profiling target. Any profiling data you've collected would also be helpful. I've created issues for this on Bugzilla and the sumtype Github repository: https://issues.dlang.org/show_bug.cgi?id=22447 https://github.com/pbackus/sumtype/issues/76
Re: Vibe.d tutorial
On Friday, 2 April 2021 at 22:29:20 UTC, Imperatorn wrote: On Thursday, 4 March 2021 at 13:47:11 UTC, Imperatorn wrote: On Monday, 1 March 2021 at 22:25:39 UTC, Rey Valeza wrote: Hi, I wrote a tutorial on Vibe.d while trying to re-learn Vibe.d. I find that most of Kai Nacke's book need updating, so I wrote a tutorial while trying to re-learn it. Here it is. https://github.com/reyvaleza/vibed/commit/27ec3678f25d1dd414fae1390677397a7bc57721 I would be glad if you can give me some feedback so I can improve it. Thanks! https://github.com/reyvaleza/vibed/blob/main/Build%20Web%20Apps%20in%20Vibe.pdf New link: https://raw.githubusercontent.com/reyvaleza/vibed/main/BuildWebAppsinVibe.pdf I know this is very, very late, but thank you!
Re: What is D's "__debugbreak()" equivalent?
On Wednesday, 27 October 2021 at 16:54:49 UTC, Simon wrote:
What is the equivalent in D?
With LDC, you have:
```D
import ldc.intrinsics: llvm_debugtrap;
```
Combining that with previous answers, you can make something like
this:
```D
void debugbreak() nothrow @nogc @trusted {
version(D_InlineAsm_X86_64) {
asm nothrow @nogc {
int 3;
}
} else version(LDC) {
import ldc.intrinsics: llvm_debugtrap;
llvm_debugtrap();
} else {
assert(0); // No `breakPoint` for this compiler configuration
}
}
```
SumType
I am heavily using SumType (which I like very much). The problem I am having is that is seems to be causing slow compile times (as can be observed by profiling during the compile). The problem seems to be with match (which is extremely convenient to use). I looked at the code and it does the only reasonable thing too do which is to test each handler against each type. The slow compile time makes development slower and less pleasant, so I am thinking of replacing SumType with my own tagged union and writing out the switches by hand. However, I really don't like this idea since it makes the code less readable and more prone to errors. Any suggestions?
Re: Bitfileds Error: no identifier for declarator
On Thursday, 28 October 2021 at 05:51:27 UTC, Imperatorn wrote: Try renaming debug to something else Many thanks guys. I should have spotted that one!
