Re: ugly and/or useless features in the language.
On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:
Which parts in dlang don't you use and why?
There is one feature (actually a mix of features) I'd be happy
not to use, but it is not possible: I call it autoreals, because
it resembles somewhat the idea behind autodecoding - in both
cases the compiler (or Phobos) does something automatically that
you cannot avoid and sometimes causes real headache, but which
you could do easily yourself if it were not done automatically):
What I'm talking about is
- reals being differently implemented on different computers
- reals being internally used for computation and intermediate
storage
- reals being automatically used in CTFE (and reals in CTFE might
differ from the reals at runtime)
All together this ends in generic code (for example in libraries)
behaving more or less like a random generator; at least it feels
like this.
I would be able to cope with the first point by either not using
reals at all or `static if` to generate separate code for every
version. But together with the other two "features" reals cannot
be ignored anymore. You cannot even assume a function with return
type double to return a double. So to be sure to have a double,
when a double is needed you need to do stuff like
```
double d = some_fun();
ulong tmp = *cast(ulong*)
tmp ^= 12543;
/* maybe here some more ugly stuff that doesn't change the value
until it is enough to trick the optimizer */
tmp ^= 12543;
d = *cast(double*)
```
Even worse with CTFE, where you get values that are neither NaN,
nor infinity but larger then `.max`. And you cannot even
use `static if` to find out which reals are used in CTFE, because
CTFE might use different reals or reals on an other platform or
whatever. So to be able to find out which real you use, you need
to add more ugly code like
```
if (__ctfe)
{
if (real.max + 1 != real.infinity && real.max + 10 - 20 <
real.max)
{
...
}
else
{
}
}
```
Finally you end up writing several hundred lines of code for
something that would have fitted in one line without autoreals;
probably you would prefer to write a library (using heavy amount
of `asm` parts) with types `Float` and `Double` that is just
doing what float and double are normally supposed to do.
What I really dislike about this is, that you have no means to
escape from it, while the other way round it would be easy: If
you really want to use reals instead of double, you could just
use reals...
Re: Any suggestions on dmd error message formatting?
On Saturday, 15 May 2021 at 04:54:15 UTC, Chris Piker wrote: As always, your advice is much appreciated I'm usually piping the results through hexdump. ;-) No, in earnest, I often would have liked to have better formatted messages. The only thing I can say: Sometimes it helps to increase the size of the window (>300 columns or so). Without line breaking, sometimes you can spot patterns you didn't before...
Re: Is inc function part of the library ?
On Thursday, 13 May 2021 at 11:21:58 UTC, Alain De Vos wrote: [...] how can I do an extensive search in the library to functions when i know more or less their name , but don't know their exact place as module or package. An alternative to the official documentation is [dpldocs](http://dpldocs.info/experimental-docs/dpldocs.home.html) from Adam. It is inofficial (and sometimes a little bit outdated), but it has a different search algorithm and often points you to places, you may have missed using the official documentation.
Re: Issue with small floating point numbers
On Thursday, 13 May 2021 at 03:03:37 UTC, Tim wrote:
```
unittest{
auto p = rotate2D([0.0, 10.0], PI_2);
assert(p == [-10.0, 0.0]);
}
```
I suggest
```
unittest
{
auto p = rotate2D([0.0, 10.0], PI_2);
assert(isClose(p[0], -10.0));
assert(isClose(p[1], 0.0, 0.0, 1e-6));
}
```
In the second test, the value is compared against zero, which is
somewhat special - you need to specify an acceptable distance
from zero to get it right.
You could also improve your result by making the `phi` a `double`
value. In this case you can replace the `1e-6` above by `1e-15`
which is much closer to zero.
Re: Near-simplest route to learn D
On Wednesday, 12 May 2021 at 18:37:55 UTC, NonNull wrote: Some documents/books seem to be out of date. If an intuitive person competent in several other programming languages and in abstract reasoning wanted to take the fastest route to learn pretty much the whole of D as it stands now, having already learned and used a core of the language, what is the best way to proceed? And how long would this likely take? Even if it is a few years old, I would still use the book from Ali. Most is still valid and maybe, the online version is even updated, but I'm not sure on this. A completely other approach is to try to help fixing bugs. I learned a lot about D, when I started doing so. I don't know, if that is, what you wanted to hear, but I thought, it wont hurt telling you. :-)
Re: question on map
On Wednesday, 12 May 2021 at 09:52:52 UTC, Alain De Vos wrote:
As oppposed to what i expect code below prints nothing nothing
on the screen. What is wrong and how to fix it ?
```
import std.stdio;
import std.range:iota;
import std.algorithm:map;
bool mywriteln(int x){
writeln(x);
return true;
}
void main(){
5.iota.map!mywriteln;
}
```
You've got a *lazy* range here. Try `5.iota.map!mywriteln.array`
(you need to import std.array). With that it is not lazy anymore
and will print.
The way, I'm thinking about lazy ranges is in terms of vouchers,
like you sometimes have to buy vouchers on sport festivals to get
sausages. Now you go to the stand with the sausages and hand in
that voucher, you get the sausage. But if you throw the voucher
in a waste paper basket, you'll get no sausages, they are not
even roasted, as long as you do not query them.
What you do above is to buy that voucher and throw it away.
That's why nothing happens.
So in more detail, `5.iota` gives you a voucher (A) for the 5
numbers from 0 to 4. You hand that voucher (A) to `map` together
with a function `mywriteln` and get back a new voucher (B), this
time for applying the numbers to your function. And that voucher
(B) is discarded, because it is never used.
If you would write `5.iota.map!mywriteln.front`, you would say
something like: "Hey `map`, here is my voucher (B), please give
me the first element you promised to me. `map` now takes the
voucher (A) you gave it earlier and does the same, it asks
`iota`: "Hey `iota`, here is my voucher (A), please give me the
first element." And iota hands `0` to `map`, which now calls
`mywriteln(0)`. `mywriteln` now prints the expected `0` and hands
a `true` to `map` and then `map` gives you that `true` (which you
still discard).
Hope, this analogy helps.
Re: Remove own post from forum
On Monday, 10 May 2021 at 10:00:11 UTC, Виталий Фадеев wrote: Say, please, how to remove own post from this forum ? There's currently no way to remove or edit an existing post. ok In my opinion it is a violation of the GDPR, which gives you the right to remove such posts. GDPR applies here, because this forum addresses Europeans (among others)... (I don't mind much about that, but IMHO the people, who are responsible, should at least know it.)
Re: Thoughts on Structure
On Friday, 30 April 2021 at 17:33:19 UTC, Alain De Vos wrote: An active maintainer is a living person, with a first name a last name and an email adress, who looks into issues and tries to fix them. Now go look to this page ... https://code.dlang.org/ Feel free to elaborate ... I don't get your point...
Re: dlang vs crystal-language
On Thursday, 29 April 2021 at 05:41:45 UTC, Imperatorn wrote: Crystal has no installer for Windows Is this a strength or a weakness? (SCNR)
What are virtual functions?
I'm trying to understand, what virtual functions are. I found the [specs](https://dlang.org/spec/function.html#virtual-functions), but I can't make head or tail of it. - What is a `vtbl[]`? Obviously a function pointer table. But where to find this? The examples don't use it. Maybe something inside of the compiler? - Which of the eight functions in the example are virtual and and which not? OK B.abc is said to be virtual, as the comment states. But it seems never to be used. And why is it considered to be virtual? - There is also the term "covariant function", which is not explained. What is this? I'm asking, because I'm currently writing new docs for `std.format`. The [current (stable) docs of `formatValue`](https://dlang.org/phobos/std_format.html#formatValue) tell, that some `toString` versions are discouraged, but not for virtual functions. I would like to understand the reason for that, so I can put that properly into the new docs. The reasons, why it's better to not use these versions in normal functions is explained in the [changelog](https://dlang.org/changelog/2.079.0.html#toString). But I miss the reason, why virtual functions should still use them; probably, because I did not understand, what that is. Can you help me?
Re: weird formattedRead
On Friday, 9 April 2021 at 16:11:26 UTC, Oleg B wrote: valid '1/1/1': 0001-Jan-01 00:00:00 <<< see here [...] Is space a special char for `formattedRead` and it simple stop parse without throwing exception if not found space (that represented in fmt string)? Have `formattedRead` any other special chars? Or it's bug? It's a (at least to me) known bug (I haven't taken the time to report it yet; found it a few days ago, when I reworked the docs). `formattedRead` treats space sometimes special and sometimes not, which (obviously) may lead to strange behavior, like it does here. If you like, you can [report this one](https://issues.dlang.org/enter_bug.cgi); I'll probably will care about it in a few weeks/months (I first want to fix the `formattedWrite` bugs and finish implementing formatting floating point numbers without calling `snprintf`.) On Friday, 9 April 2021 at 16:39:30 UTC, Ali Çehreli wrote: P.S. I can't check whether the D standard library documentation includes that information because the documentation looks very different and very skimpy to me at this time. There is nothing on format characters on formattedRead's documentation. (?) When using the `stable` docs you still should get, what you are used to. But I guess, you used the `master` docs and looked at `formattedWrite` where the information used to be. Since about three weeks I'm on reworking completely the docs of `std.format`. Before that, the module has been split in several submodules (package, read, write, specs). Meanwhile I moved the docs you know from `formattedWrite` to [package](https://dlang.org/phobos-prerelease/std_format.html) (but yet not reworked completely, because the review process takes some time and I try to verify everything I state in the new docs in the source code). For [`formattedRead`](https://dlang.org/phobos-prerelease/std_format_read.html#.formattedRead) and [reading in general](https://dlang.org/phobos-prerelease/std_format_read.html), the new docs are already finished. Feedback is welcome.
Re: Is this bug ? format %(%)
On Wednesday, 7 April 2021 at 17:31:09 UTC, Paul Backus wrote: It's not your fault--this is a pretty obscure feature, and it's not documented very well. Even after you've found the correct page in the documentation (the page for `formattedWrite` [1]), you have to scroll down past multiple examples to find the text that explains it. [1] https://dlang.org/phobos/std_format.html#formattedWrite The docs of `std.format` are currently under strong revision, about 90% is already done, but that "feature" is among the other 10%. I hope to get that ready till the end of the month, so the next stable release will have better docs. Unfortunately it's much more difficult to change that strange behavior without breaking code. Currently I hope for Phobos 2.0 coming soon and meanwhile try to prepare `std.format` for that change.
Re: what exactly is string length?
On Friday, 2 April 2021 at 15:01:07 UTC, mw wrote: BTW, shall I log a writeln() improvement bug ? It's really confusing, e.g as debug print or logs. In my opinion this isn't a bug. The nulls are actually printed: ``` $> rdmd test.d | hd 61 62 63 00 00 00 36 0a 68 65 61 64 2d 61 62 63 |abc...6.head-abc| 0010 00 00 00 2d 74 61 69 6c 31 36 0a |...-tail16.| 001b ``` It's just, that you can't see them, because it's an invisible character. If you want to get `\0` for nulls, you could write ``` writefln!"%(%s%)"(only(t)); ``` With this, `t` is printed as a string literal: ``` "head-abc\0\0\0-tail" ```
Re: Need for speed
On Thursday, 1 April 2021 at 16:52:17 UTC, Nestor wrote: I was hoping to beat my dear Python and get similar results to Go, but that is not the case neither using rdmd nor running the executable generated by dmd. I am getting values between 350-380 ms, and 81ms in Python. Try using ldc2 instead of dmd: ``` ldc2 -O3 -release -boundscheck=off -flto=full -defaultlib=phobos2-ldc-lto,druntime-ldc-lto speed.d ``` should produce much better results.
Re: list of all defined items in a D file
On Friday, 24 January 2020 at 12:22:49 UTC, Dennis wrote: You can pass the -X flag to dmd, which makes it generate a .json file describing the compiled file. Great, that's what I was looking for - although it's also good to know the __traits approach! Thanks!
list of all defined items in a D file
I'd like to get a list of all items (public, package, private) that are defined in a D file. Is there a simple way, to get them?
template instantiation problems
I'm trying to understand issue 17441 [1]. I reduced it (including
Phobos) to the following (and added some message to point out the
problem):
test.d:
---
alias parentOf(alias sym) = __traits(parent, sym);
template packageName(alias T)
{
pragma(msg, "IN: ", T.stringof);
static if (__traits(compiles, parentOf!T))
enum parent = packageName!(parentOf!T);
else
enum string parent = null;
static if (T.stringof[0..8] == "package ")
enum packageName = (parent? parent ~ '.' : "") ~
T.stringof[8 .. $];
else
enum packageName = parent;
}
void main()
{
import mod0 = foo.baz;
import mod1 = foo;
pragma(msg, "mod0: ",mod0.stringof);
pragma(msg, "mod1: ",mod1.stringof);
pragma(msg, "A");
enum a = packageName!mod0;
pragma(msg, "B");
enum b = packageName!mod1;
pragma(msg, "C");
static assert(a == "foo");
static assert(b == ""); // Error: static assert: "foo"
== "" is false
}
---
foo/baz.d:
---
module foo.baz;
---
foo/package.d:
---
module foo;
---
When compiling with
$> dmd test.d
I get:
---
mod0: module baz
mod1: module foo
A
IN: module baz
IN: package foo
B
C
test.d(32): Error: static assert: "foo" == "" is false
---
This clearly shows, that packageName is only instatiated once at
top level although mod0 and mod1 are two different things (at
least their stringof produces different results) and therefore
should be instantiated twice.
Now I don't know if this is a bug in DMD or I should know
something I do not know... Can you help me?
[1] https://issues.dlang.org/show_bug.cgi?id=17441
Re: linkererrors when reducion phobos with dustmite
On Wednesday, 8 January 2020 at 19:55:57 UTC, H. S. Teoh wrote: Use dmd -i should solve the problem. Oh, thanks, now it works... (Have been using rdmd too long, so I always forget about other modules to be included.)
linkererrors when reducion phobos with dustmite
As mentioned on the dustmite website [1] I copied the folder std from Phobos in a separate folder and renamed it to mystd. The I changed all occurences of std by mystd in all files. That works most of the time, but sometimes I get hundreds of linker errors I do not understand: $> dmd -main -unittest -g -run mystd/variant.d /usr/bin/ld: variant.o:(.data.rel.ro+0x68): undefined reference to `_D5mystd4meta12__ModuleInfoZ' /usr/bin/ld: variant.o:(.data.rel.ro+0x70): undefined reference to `_D5mystd6traits12__ModuleInfoZ' /usr/bin/ld: variant.o:(.data.rel.ro+0x78): undefined reference to `_D5mystd8typecons12__ModuleInfoZ' ... Does anyone know, what's the problem here and how to get arround this? [1] https://github.com/CyberShadow/DustMite/wiki#minimizing-the-standard-library
Re: What kind of Editor, IDE you are using and which one do you like for D language?
On Sunday, 22 December 2019 at 17:20:51 UTC, BoQsc wrote: What kind of editor/IDE are you using and which one do you like the most? I'm using sed... - no, just joking. Actually I use jed (because I did for 20 years now) with emacs keybindings in C mode, but I cannot recommend it for D. There are several limitations, for example jed can only handle two different types of comments, let alone nested comments. I always think, I should change to something better, but as I'm so used to it, it would be a rather big deal. I also thought about porting jed to d (than it's de(a)d?), but this sounds like one of those life long projects, I'm not sure I want to start that.
Re: Problem with public example in Phobos
On Wednesday, 18 December 2019 at 17:57:15 UTC, Steven Schveighoffer wrote: style checker has nothing to do with buildable code. It just enforces the style follows the guidelines. It also checks, that the public unittests can be used on it's own. (Target publictests in the makefile. Didn't know that too until yesterday.) This comes from the fact that unless you are declaring a template with `template`, you are using the eponymous template trick under the hood. Aaaah. It's so common, that one forgets about it. Thanks for reminding. :-) Note, putting unittests inside templates duplicates the unit test for every instantiation. Using an instantiation other than the template itself is going to result in a lot of duplicated tests. Unfortunately, there is no mechanism to have a documented unittest that isn't part of the instantiation. I know about that problem. Would be good, to have some such mechanism. Until we have, I'll resort to moving them after the template and adding a link to the docs, see below. This might be a bug. I don't know how this is built, so I'm not sure. But it looks like the compiler isn't including some instantiation of FormatSpec when linking. I moved the unittest outside the template, just to find out, that there is allready one, which is almost identical. I merged the two and added a link to the docs, so people can find the example. Thanks a lot!
Problem with public example in Phobos
I thought it's a fast fix, just adding some documentation and a
unittest. But when running the style checker I got into trouble.
A shortend version of the problem:
I added the following public unittest to writeUpToNextSpec in
std.format:
///
@safe unittest
{
import std.array;
auto w = appender!(char[])();
auto f = FormatSpec("input: %10d output: %s");
assert(f.writeUpToNextSpec(w) == true);
assert(w.data == "input: ");
assert(f.spec == 'd');
assert(f.width == 10);
// [...]
}
While it works with the normal unittest test routines (make -f
posix.mak unittest) the stylechecker complains (make -f posix.mak
style).
I meanwhile found out, that I have to add the template parameter
dchar to FormatSpec, although I don't understand why. (I know,
that these tests should work, when they are put into a separate
file. But I do not understand why the original version doesn't
work there.)
But more problematic: When I add this templete parameter, I still
get an error from the style checker, this time it's a linker
problem, and I'm completely lost here. The error does not occure
when checking std.format, but when checking std.package:
parsing std/package.d
/usr/bin/ld: std_package.o: in function
`_D3std6format__T10FormatSpecTaZQp22__unittest_L1237_C11_1FNaNfZv':
__main.d:(.text._D3std6format__T10FormatSpecTaZQp22__unittest_L1237_C11_1FNaNfZv[_D3std6format__T10FormatSpecTaZQp22__unittest_L1237_C11_1FNaNfZv]+0x17):
undefined reference to `_D3std6format__T10FormatSpecTwZQp6__initZ'
/usr/bin/ld:
__main.d:(.text._D3std6format__T10FormatSpecTaZQp22__unittest_L1237_C11_1FNaNfZv[_D3std6format__T10FormatSpecTaZQp22__unittest_L1237_C11_1FNaNfZv]+0x38): undefined reference to `_D3std6format__T10FormatSpecTwZQp6__ctorMFNaNbNcNiNfxAwZSQCdQCc__TQByTwZQCe'
/usr/bin/ld: std_package.o: in function
`_D3std6format__T10FormatSpecTwZQp__T17writeUpToNextSpecTSQCd5array__T8AppenderTAaZQnZQBxMFNaNlNfKQBpZb':
__main.d:(.text._D3std6format__T10FormatSpecTwZQp__T17writeUpToNextSpecTSQCd5array__T8AppenderTAaZQnZQBxMFNaNlNfKQBpZb[_D3std6format__T10FormatSpecTwZQp__T17writeUpToNextSpecTSQCd5array__T8AppenderTAaZQnZQBxMFNaNlNfKQBpZb]+0x15a):
undefined reference to `_D3std6format__T10FormatSpecTwZQp6fillUpMFNaNlNfZv'
What do I miss?
Re: Bug or Feature: unsigned integer overflow
On Saturday, 14 December 2019 at 09:33:13 UTC, Tobias Pankrath wrote: See: https://dlang.org/spec/lex.html#integerliteral What I am aiming at: Is the spec wrong or am I misunderstanding it and did this change recently? You are right. The implementation does not do what the specs tell here. I filed a bug report: https://issues.dlang.org/show_bug.cgi?id=20449
Re: Bug or Feature: unsigned integer overflow
On Saturday, 14 December 2019 at 07:09:30 UTC, Tobias Pankrath
wrote:
void main()
{
auto x = 9223372036854775808; // long.max + 1
}
You need to tell, that this is an unsigned long literal, else the
compiler treats it as an int:
void main()
{
auto x = 9223372036854775808UL; // long.max + 1
}
Re: Mapping float to ulong in CTFE
Yeah, it worked (at least for %a): static assert(format!"%.3a"(1.0f) == "0x1.000p+0");
Re: Mapping float to ulong in CTFE
On Thursday, 12 December 2019 at 19:39:16 UTC, Petar Kirov
[ZombineDev] wrote:
You can use a C-style pointer reinterpret cast like this:
uint test(float f) { return *cast(uint*) }
Make sure that source and destination types have the same size.
Hey, great! :-)
Mapping float to ulong in CTFE
Is it possible to get to the bits of a float in CTFE? I tried the
following, but this doesn't work:
```
import std.stdio;
union FloatBits
{
float floatValue;
ulong ulongValue;
}
ulong test(float f)
{
FloatBits fb;
fb.floatValue = f;
return fb.ulongValue;
}
void main()
{
static assert(test(3.0) == 1077936128);
}
```
test.d(13): Error: reinterpretation through overlapped field
ulongValue is not allowed in CTFE
test.d(18):called from here: test(3.0F)
test.d(18):while evaluating: static assert(test(3.0F)
== 1077936128LU)
opCmp with and without const
In std.typecons, in Tuple there are two opCmp functions, that are
almost identical; they only differ by one being const and the
other not:
int opCmp(R)(R rhs)
if (areCompatibleTuples!(typeof(this), R, "<"))
{
static foreach (i; 0 .. Types.length)
{
if (field[i] != rhs.field[i])
{
return field[i] < rhs.field[i] ? -1 : 1;
}
}
return 0;
}
int opCmp(R)(R rhs) const
if (areCompatibleTuples!(typeof(this), R, "<"))
{
static foreach (i; 0 .. Types.length)
{
if (field[i] != rhs.field[i])
{
return field[i] < rhs.field[i] ? -1 : 1;
}
}
return 0;
}
What is the reason for having this? (I guess, that it's because
the function may indirectly call opCmp of other types which may
or may not be const.)
My real question is: Can this code duplication be avoided
somehow? (I ask, because I've got a PR running, which increases
the size of these functions and it doesn't feel good to have two
long, almost identical functions.)
Re: Confusion Concerning Numerical Equation
On Saturday, 16 November 2019 at 10:01:25 UTC, Avery Stupidman wrote: assert(angleDeg(sqrt(3.0)/2.0, 1.5) == 60.0); // Fails On my computer the results are very close, that is: import std.math: nextUp; assert(nextUp(angleDeg(sqrt(3.0)/2.0, 1.5)) == 60.0); // OK On Saturday, 16 November 2019 at 10:17:12 UTC, drug wrote: you can use something like approxEqual https://dlang.org/library/std/math/approx_equal.html With approxEqual, one needs to be very carefull. The default parameters allow for very odd results, accepting values to be equal, which are actually far apart considering the precision available; this is especially true, when using double or real. For example, here are about 12 significant fractional digits involved, which are completely ignored: assert(approxEqual(100.0,101.0)); // OK I wrote a replacement with better handling of the default parameters [1], but it looks like no one wants to take the burden to review it, probably because that would involve to make a decision. (Or maybe it has some other reasons I do not see.) [1] https://github.com/dlang/phobos/pull/7241
Re: Should I stop being interested in D language if I don't like to see template instantiation in my code?
On Wednesday, 13 November 2019 at 14:23:40 UTC, mipri wrote:
3. it's very clear what's a compile-time vs. a runtime
parameter to the template.
At least, if one understands the difference. I remember that I
was not aware of this, when I started learning D and was a lot
confused by the use of templates in Phobos. And maybe for BoQsc
it's the same. Therefore: Take the second example: This could
also be written as
s.formattedRead("%s!%s:%s", a, b, c);
Now you've got no ! anymore. The disadvantage of this is, that
parsing "%s!%s:%s" happens at runtime, meaning it is done
everytime, the function is executed. If there are lots of such
reads, the code can get considerably slower. The alternative is
s.formattedRead!("%s!%s:%s")(a, b, c);
I put the parenthesis around "%s!%s:%s" to make it more clear,
that this is also some sort of function argument, like a, b and
c. But this time, the compiler allready parses "%s!%s:%s" at
compiletime, which means, when running the program it allready
knows, that there are no errors in that string and maybe (I don't
know the details) also, which parameter to put where and so on.
That's faster. :-)
Believe me: It's worth to learn about templates!
Distinguishing a pointer to a function and a closure
While debugging phobos I came across some stuff I don't
understand. A small example:
void foo(void* p)
{
Object o = cast(Object) p;
ClassInfo oc = typeid(o);
}
class Bar
{
void some_func(int i) {}
void do_something(void delegate(int) d)
{
// is it possible to check here, if d.ptr can be passed
to foo?
foo(d.ptr);
}
}
void main()
{
auto b = new Bar();
b.do_something(_func); // OK
b.do_something(i => b.some_func(i)); // crashes
}
While the first call to do_something succeeds, the second one
crashes. That's probably, because a closure is not an 'Object'
and the cast in foo should never happen (a normal delegate seems
to be an Object somehow, though). Is there any chance to notice
this in "do_something" and emergency-exit there (e.g. with some
assert call)?
Background of the question: Issue 9603 [1] reports some crashes
when using std.signals. I meanwhile found out, that the crash
happens inside "_d_toObject", which is a function in the runtime
[2]. The documentation tells, that this function crashes if the
pointer does not point to a class, an interface or is the null
pointer. It would be nice to avoid the crash by some check before
the call to _d_toObject.
[1] https://issues.dlang.org/show_bug.cgi?id=9603
[2] https://dlang.org/library/rt/cast_/_d_to_object.html
Re: Documentation: is it intentional that template constraints are displayed after the signature?
On Thursday, 31 October 2019 at 13:34:35 UTC, Tobias Pankrath wrote: I was confused at first by the trailing if (!is(T == struct) && !is(T == interface) && !is(T == class) && !__traits(isStaticArray, T)); I understood your question different from what Dennis answered. At least I was confused by similar lines, when I was a beginner and did not know much about template constraints. What I would have needed to know at that time is, that template constraints limit the situations, where the template can be used. Here for example, this destroy template can only be used, when the type T is neither struct, interface nor class (these three have separate instances, probably because they need different treatment) and it's also not a static array, for unknown reasons. What I don't understand is the 4th version with two extra parameters. Here the documentation lacks an explanation, what this is good for.
Re: Accuracy of floating point calculations
On Tuesday, 29 October 2019 at 20:15:13 UTC, kinke wrote: Note that there's at least one bugzilla for these float/double math overloads already. For a start, one could simply wrap the corresponding C functions. I guess, that this issue: https://issues.dlang.org/show_bug.cgi?id=20206 boils down to the same problem. I allready found out, that it's high likely that the bug is not to be found inside std.complex but probably the log function.
Re: ddox build locally failed
On Saturday, 26 October 2019 at 17:54:44 UTC, Mitacha wrote: sudo apt-get install libssl-dev That's it. Thanks. :-)
ddox build locally failed
I tried to build ddox documentation locally with the command (in dlang.org): make -j3 -f posix.mak apidocs-prerelease After a while I get the message "Linking..." followed by a call of dmd with lots of parameters, among them -L-lssl and -L-lcrypto. This ends in: /usr/bin/ld: cannot find -lssl /usr/bin/ld: cannot find -lcrypto I'm using debian stable. There are probably some packages missing or maybe a path needs to be set. Any ideas?
Re: Printing floating point numbers
On Friday, 25 October 2019 at 14:51:33 UTC, Yui Hosaka wrote: The outputs for your program are as follows: [...] Thanks for the output. I added it to the bug report. The internal representation of the value is correct in all versions. While the result of the direct call of snprintf always gives the wrong answer. Therefore I think, the bug is to be found in this function. Resently Robert Schadek noted, that it would be nice, to have this function be rewritten in D anyway. I'll have a look if I can do this in the next weeks but do not want to promise anything yet. With "-m64" or "-m64 -O": --- 0.02 3b df 4f 8d 97 6e 12 83 f9 3f 0.00 --- The "0.00" is strange.
Re: Can not understand this code.
On Friday, 25 October 2019 at 06:40:19 UTC, lili wrote:
Hi:
What is the alias Min = xxx mean? why need defined a alias Min
in Min template?
```
template Min(alias pred, Args...)
if (Args.length > 0 && __traits(isTemplate, pred))
{
static if (Args.length == 1)
{
alias Min = Alias!(Args[0]);
}
else static if (isLess!(pred, Args[1], Args[0]))
{
alias Min = Min!(pred, Args[1], Args[2 .. $]);
}
else
{
alias Min = Min!(pred, Args[0], Args[2 .. $]);
}
}
```
I can't explain in detail, but I know, this is called an
eponymous template.
See
https://dlang.org/spec/template.html#implicit_template_properties
Re: Printing floating point numbers
On Thursday, 24 October 2019 at 20:48:02 UTC, Yui Hosaka wrote:
Do you have any idea for this issue?
I added a bug report:
https://issues.dlang.org/show_bug.cgi?id=20320
Internally the conversation from the binary representation of the
value to the printed one is done by a call to a C function called
snprintf. Probably the error is inside of this function call. But
it could also happen before. Maybe the internal representation of
0.016 is allready wrong.
It would be helpful if you could run the following program and
post the output:
import std.stdio;
import std.format;
void main()
{
real b = 0.016;
writefln!"%.2f"(b);
foreach (c;format("%r",b)) writef("%x ",c);
writeln();
char[6] sprintfSpec = "%*.*Lf";
char[512] buf = void;
import core.stdc.stdio : snprintf;
immutable n = snprintf(buf.ptr, buf.length, sprintfSpec.ptr,
0, 2, b);
writeln(buf[0..n]);
}
Re: formatting a float or double in a string with all significant digits kept
On Tuesday, 8 October 2019 at 20:37:03 UTC, dan wrote:
But i would like to be able to do this without knowing the
expansion of pi, or writing too much code, especially if
there's some d function like writeAllDigits or something
similar.
You can use the property .dig to get the number of significant
digits of a number:
writeln(PI.dig); // => 18
You still need to account for the numbers before the dot. If
you're happy with scientific notation you can do:
auto t = format("%.*e", PI.dig, PI);
writeln("PI = ",t);
(By the way, you can shortcut that with writefln!"PI =
%.*e"(PI.dig, PI);)
If you don't want to use scientific notation, you probably need
to do some calculations to find out about the number of digits
before the dot (you need abs to make it work for negative numbers
too):
import std.conv: to;
auto x = to!int(log10(abs(PI)));
writefln!"%*.*f"(x,PI.dig-x,PI);
