[Issue 16358] New: the most basic program leaks 88 bytes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16358

  Issue ID: 16358
   Summary: the most basic program leaks 88 bytes
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

a.d:


void main()
{
}

compile & run (dmd v2.071.2-b1):
°°°

dmd a.d
valgrind --leak-check=full -v ./basic:

output:
°°°

==10527== HEAP SUMMARY:
==10527== in use at exit: 88 bytes in 2 blocks
==10527==   total heap usage: 27 allocs, 25 frees, 43,904 bytes allocated
==10527== 
==10527== Searching for pointers to 2 not-freed blocks
==10527== Checked 148,376 bytes
==10527== 
==10527== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2
==10527==at 0x4C291A0: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10527==by 0x446CCB: _D2rt5tlsgc4initFZPv (in /tmp/a)
==10527==by 0x441CC8: thread_attachThis (in /tmp/a)
==10527==by 0x441B8D: thread_init (in /tmp/a)
==10527==by 0x436D76: gc_init (in /tmp/a)
==10527==by 0x4296DE: rt_init (in /tmp/a)
==10527==by 0x426369: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv (in
/tmp/a)
==10527==by 0x426314:
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv (in /tmp/a)
==10527==by 0x426285: _d_run_main (in /tmp/a)
==10527==by 0x425EBD: main (in /tmp/a)
==10527== 
==10527== 72 bytes in 1 blocks are definitely lost in loss record 2 of 2
==10527==at 0x4C2B290: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10527==by 0x446AAC:
_D2rt8monitor_13ensureMonitorFNbC6ObjectZPOS2rt8monitor_7Monitor (in /tmp/a)
==10527==by 0x446A02: _d_monitorenter (in /tmp/a)
==10527==by 0x4418C0: _D4core6thread6Thread8isDaemonMFNdZb (in /tmp/a)
==10527==by 0x42E8C7: thread_joinAll (in /tmp/a)
==10527==by 0x429779: rt_term (in /tmp/a)
==10527==by 0x426394: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv (in
/tmp/a)
==10527==by 0x426314:
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv (in /tmp/a)
==10527==by 0x426285: _d_run_main (in /tmp/a)
==10527==by 0x425EBD: main (in /tmp/a)
==10527== 
==10527== LEAK SUMMARY:
==10527==definitely lost: 88 bytes in 2 blocks
==10527==indirectly lost: 0 bytes in 0 blocks
==10527==  possibly lost: 0 bytes in 0 blocks
==10527==still reachable: 0 bytes in 0 blocks
==10527== suppressed: 0 bytes in 0 blocks

--

[Issue 16357] New: cast(T[])[x] casts x to T instead of [x] to T[]

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16357

  Issue ID: 16357
   Summary: cast(T[])[x] casts x to T instead of [x] to T[]
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

// test.d //
void main()
{
uint x;
ubyte[] data = cast(ubyte[])[x];
assert(data.length == 4);
}


This is surprising, because if the expression is split up into:

auto arr = [x];
ubyte[] data = cast(ubyte[])arr;

then the result is as expected (an array with 4 elements).

--

[Issue 16349] better curl retry for install.sh script

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16349

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #5 from greensunn...@gmail.com ---
> Our binaries are already hosted on S3 (that's where Github Releases come from 
> as well).

Oh, but for Github Releases traffic is _free_, whereas if I am not mistaken you
have to pay quite a lot to AWS. A simple estimate goes like this:

25 (size of release in MB, depends of course) * 10_000 (number of monthly
downloads, I hope it's higher, see below)  / 1_000 (convert to GB) * 0.09
(transfer costs to internet, per GB)

and thus yields:

10K monthly downloads: 25 * 1 / 1000 * 0.09 = 22.5$
30K: 67.5$
50K: 112.5$
100K monthly downloads: 225$

According to http://erdani.com/d/downloads.daily.png, there are currently at
about 1400 downloads per day (=42K /month), which means it's about 1.1K$ a
year.
I estimate the bill to be 30-40% less, because the Linux archives are better
compressed and it's mostly those that are constantly downloaded for CI. It's
still quite a lot of money (if I am not mistaken with my estimate).

--

[Issue 16356] cdouble is broken

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16356

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com

--

[Issue 16356] cdouble is broken

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16356

--- Comment #2 from Kazuki Komatsu  ---
(In reply to greensunny12 from comment #1)
> I hardly believe that this is going to be fixed as builtin complex types are
> rarely used and have been scheduled for deprecation (see
> https://dlang.org/deprecate.html). Btw @other why is there no schedule date
> for complex types?
>
> Do you experience a similar behavior with std.complex?
> (https://dlang.org/phobos/std_complex.html)

I test std.complex.Complex by same code, but it　has no　strange behavior.

--

[Issue 16356] cdouble is broken

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16356

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from greensunn...@gmail.com ---
I hardly believe that this is going to be fixed as builtin complex types are
rarely used and have been scheduled for deprecation (see
https://dlang.org/deprecate.html). Btw @other why is there no schedule date for
complex types?

Do you experience a similar behavior with std.complex?
(https://dlang.org/phobos/std_complex.html)

--

[Issue 16356] New: cdouble is broken

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16356

  Issue ID: 16356
   Summary: cdouble is broken
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: enjouzensyou.bo...@gmail.com

OK:

import std.stdio;

/*
0+0i
1+1i
2+2i
3+3i
*/
void main()
{
cfloat c = 1f + 1fi;
foreach(x; 0 .. 4)
writeln(c * x);
}


NG:

import std.stdio;

/*
0+1i
1+1i
2+1i
3+1i
*/
void main()
{
cdouble c = 1 + 1i;
foreach(x; 0 .. 4)
writeln(c * x);
}


dmd: 2.071.1

--

[Issue 16349] better curl retry for install.sh script

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16349

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/installer

https://github.com/dlang/installer/commit/2f1ec46aaae444f3b0a10dde18517d7e98145ee7
fix Issue 16349 - better curl retry for install.sh script

- curl's --retry option isn't really helpful b/c no timeouts are
  activated by default
- use a retry loop with increasing sleep times instead
- enable connection (5s) and download (<1KB/s for 30s) timeouts
  (using --max-time is too tricky b/c of the unknown download sizes)

https://github.com/dlang/installer/commit/c777a91b353cc3e2daed2460a43e16420005bbd2
Merge pull request #187 from MartinNowak/fix16349

fix Issue 16349 - better curl retry for install.sh script

--

[Issue 16349] better curl retry for install.sh script

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16349

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #3 from Martin Nowak  ---
Would you want to review this?
https://github.com/dlang/installer/pull/187

--

[Issue 16349] better curl retry for install.sh script

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16349

--- Comment #2 from Martin Nowak  ---
(In reply to greenify from comment #1)
> It's definitely good if the installation gets more robust, but maybe we can 
> also
> dig into the root cause of the random network failures. I never experienced
> such  constant problems with other providers, do you know anything what
> could cause this? Should we consider to provide a more stable distribution
> way like e.g. Github Releases?

Network failures are normal, everyone has to properly deal w/ them.
Our binaries are already hosted on S3 (that's where Github Releases come from
as well).

--

[Issue 14855] -cov should ignore assert(0)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14855

--- Comment #3 from Jonathan M Davis  ---
(In reply to Walter Bright from comment #2)
> Being concerned about assert(0)'s not being executed is placing too
> much emphasis on the metric.

Perhaps, but if you're trying to make sure that you tested every line that
you're supposed to test, assert(0) is not on the list of lines that should ever
be run. In fact, if the code is correct, it shouldn't even be testable, because
it shouldn't be reachable. So, if the point of the code coverage metric is to
show whether your tests actually run every reachable line of code, then
including assert(0) in the total is incorrect and counterproductive. It's
certainly not the end of the world, but I don't see why there is any value in
counting assert(0) in the coverage, and there's definitely value in not
counting it.

--

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16352

--- Comment #2 from Martin Nowak  ---
They do, thanks. There is not much information in the log other than it did
hang at the commit hashes.

--