• Andrei Alexandrescu (3/3) May 01 2021 The second longest unittest is like 1.5 seconds.
• Vladimir Panteleev (9/12) May 01 2021 ~/work/extern/D/phobos/std » dmd -main -unittest
• Andrei Alexandrescu (3/18) May 01 2021 A special dedicated test mode should be for that. Routine unittests
• Vladimir Panteleev (21/23) May 01 2021 There already is something like that: `debug=std_socket` (and
• Vladimir Panteleev (4/6) May 01 2021 It would be good to test that theory. Could you please attach a

Andrei Alexandrescu <andrei erdani.com> writes:

The second longest unittest is like 1.5 seconds.

I assume it goes outbound and initiates actual connections. A 
unittest should not connect to other hosts than localhost.

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Saturday, 1 May 2021 at 15:01:31 UTC, Andrei Alexandrescu 
wrote:
 The second longest unittest is like 1.5 seconds.

~/work/extern/D/phobos/std » dmd -main -unittest 
-version=StdUnittest socket.d && time ./socket
1 modules passed unittests
./socket  0.05s user 0.15s system 92% cpu 0.211 total

Between this and your AUTO_BOOTSTRAP woes, my most likely guess 
is that there is something wrong with your computer.

 I assume it goes outbound and initiates actual connections. A 
 unittest should not connect to other hosts than localhost.

Unfortunately that's not possible for things like testing DNS.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 5/1/21 11:30 AM, Vladimir Panteleev wrote:
 On Saturday, 1 May 2021 at 15:01:31 UTC, Andrei Alexandrescu wrote:
 The second longest unittest is like 1.5 seconds.

 
 ~/work/extern/D/phobos/std » dmd -main -unittest -version=StdUnittest 
 socket.d && time ./socket
 1 modules passed unittests
 ./socket  0.05s user 0.15s system 92% cpu 0.211 total
 
 Between this and your AUTO_BOOTSTRAP woes, my most likely guess is that 
 there is something wrong with your computer.
 
 I assume it goes outbound and initiates actual connections. A unittest 
 should not connect to other hosts than localhost.

 
 Unfortunately that's not possible for things like testing DNS.

A special dedicated test mode should be for that. Routine unittests 
should not connect to the network.

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Saturday, 1 May 2021 at 18:14:33 UTC, Andrei Alexandrescu 
wrote:
 A special dedicated test mode should be for that.

There already is something like that: `debug=std_socket` (and 
used via `softUnittest`).

 Routine unittests should not connect to the network.

Currently, an absence of Internet connection (without 
`debug=std_socket`) will not cause a failure.

However, the absence of an Internet connection should still not 
result in a very long test duration. I don't know for sure what 
causes this in your case. My first guess would be that the 
computer thinks it's connected to the Internet whereas it 
actually has no connectivity (e.g. it's connected to a network 
which advertises a gateway but all packets sent to it are 
actually dropped).

BTW, if this is still in WSL, I think that should be mentioned 
explicitly. I don't think we currently officially support that 
environment, and I'm not sure if we should expend much effort in 
doing so, considering that it's occasionally buggy and rapidly 
evolving. (I got bug reports that turned out to be due to 
filesystems in WSL behaving mysteriously and incorrectly, e.g. 
inability to rename a directory even with no processes accessing 
it.)

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Saturday, 1 May 2021 at 15:01:31 UTC, Andrei Alexandrescu 
wrote:
 The second longest unittest is like 1.5 seconds.

 I assume it goes outbound and initiates actual connections.

It would be good to test that theory. Could you please attach a 
debugger and check the stack trace?