On Friday, 9 May 2025 at 10:56:00 UTC, Bastiaan Veelo wrote:
On Wednesday, 7 May 2025 at 00:40:04 UTC, Pete Padil wrote:
Why is std.int128 not listed when using the top Phobos Doc
page (link "Documentation>Library Reference")?
I can find it if I expand the "Library"
On Wednesday, 7 May 2025 at 01:40:33 UTC, Jonathan M Davis wrote:
On Tuesday, May 6, 2025 3:19:29 PM Mountain Daylight Time Pete
Padil via Digitalmars-d-learn wrote:
[...]
strip removes the requested elements from the ends (whereas
stripLeft does it from the front of the range, and
Why is std.int128 not listed when using the top Phobos Doc page
(link "Documentation>Library Reference")?
I can find it if I expand the "Library" link at the top of the
Phobos page. Just thought I mention it.
Regards
On Tuesday, 6 May 2025 at 21:54:31 UTC, monkyyy wrote:
On Tuesday, 6 May 2025 at 21:19:29 UTC, Pete Padil wrote:
I compiled and ran the following test program:
```d
import std.stdio, std.algorithm;
void main()
{
long[] a = [1, 2, 3, 15, 4];
auto b = a[].strip(15);
writeln(a
I compiled and ran the following test program:
```d
import std.stdio, std.algorithm;
void main()
{
long[] a = [1, 2, 3, 15, 4];
auto b = a[].strip(15);
writeln(a);
writeln(b);
}
```
I get:
[1, 2, 3, 15, 4]
[1, 2, 3, 15, 4]
It did not remove 15, it does work if 15 is at the beginning o
On Tuesday, 6 May 2025 at 06:50:36 UTC, Ferhat Kurtulmuş wrote:
Rbtree has a range interface of d. Its memory layout is similar
to a linked list, where the data is not contiguous. So, you
have to copy the elements manually. But it is always a nice
practice to use library functions, doing it for
Was wondering if there is a way to get the data inside an rbtree
as a simple array or a std.array, besides manually copying?
Apologies if the answer is obvious and I missed it.
I noticed this on an Intel Core 2. I skipped the pentium 4 generation :)
Ok, i've done some more investigating and it appears that in DMD2 a float NaN is
0x7FE0 (in dword format) but when it initialises a float 'out' parameter it
initialises it with 0x7FA0H. This causes an FPU trap which is where the time
is going. This looks like a bug to me. Can anyone confirm
//If you initialise f to 0 before calling func then it all works quickly again
Actually I think this is a red herring. I don't think initialising f helps
at 'ff' is being written to
twice. And the strange seemingly redundant push of EAX.
Has anyone else come across this and if so is it a bug? I'm also interested in
people's thoughts on the strange code gen.
My D2 version is now running faster than the old D1 version by the way :)
Regards,
Pete.
11 matches
Mail list logo
