Mu: test_microbit hangs for quite a while

[tjguk]

Running the full test suite without a microbit attached. test_microbit hangs for some while (more than 30s I think). Need to run in verbose mode to see what's sticking

[ntoll]

This is likely a Windows only issue since it works fine for me on Linux.

[tjguk]

Well it seems to be machine-specific as well: another Windows machine doesn't exhibit the same hang. The "offending" test seems to be test_flash_with_attached_device_and_custom_runtime.

[tjguk]

Ok; I should have guessed. It's the logic in uflash.py:find_microbit which is trying to scan drive letters to find the MICROBIT drive. In this case, I'm on a work laptop which is off its usual network, so several of the drive letters are attached to network shares which are no longer accessible.

It's not a general showstopper, although I could see it being a problem in a school or other setting where there are network drives. I'll park it for now, but I should be able to come up with something a bit more refined so we don't attempt to scan network paths.

[ntoll]

Aha... that makes sense. +1 on your assessment of parking for now.

Thank you.

[ntoll]

I'm going to close the issue since there's lack of movement. That it's been flagged by @tjguk will mean it'll appear in any Google search if anyone else encounters such a problem.

[carlosperate]

@ntoll maybe this one is better left open or transfered to uFlash? It's only been 2-3 months, it's still a pending task or significant improvements for a subset of users (network drives are common, and slow flashing is very annoying), and it is something that could still be looked by somebody else if they are curious and want to contribute to the project.

From my point of view closed issues are usually seen as "done" or "won't fix", I assume most people will see it the same way?

[tjguk]

I'd forgotten about this. I think it's worth fixing and it should just need a call to GetDriveType to detect removable drives before trying for the volume name.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa364939(v=vs.85).aspx

I'm not sure if this should be a PR against this repo or another, as the uflash code is in the contrib folder?

[ntoll]

OK... I was closing as an implied "won't fix" since there hadn't been any movement (and I also thought that if people imagined it valuable they'd say so, just like you've done @carlosperate). ;-)

@tjguk I believe this should actually be fixed in the upstream uflash repos (https://github.com/ntoll/uflash). Once done I'll re-release uflash and update the version in contrib.

[tjguk]

I've submitted a PR to uflash upstream https://github.com/ntoll/uflash/pull/47

[ntoll]

Fixed by https://github.com/ntoll/uflash/pull/47 in uflash.