[devrope]

Thanks, we’ll consider it.
But will the floating license prevent use even if the Internet goes down for a few minutes or hours?
That does happen sometimes, you know, and then we wouldn’t be able to work 🙁

[devrope]

Why doesn’t the button “Revert to trial” deactivates on your servers so we can move our activations ourselves?
Now in Corona times we work from home sometimes and not always remoting to the office computer, for obvious reasons (hardware needed).
So I need my perfectly valid and purchased license on my home computer temporarily.

[devrope]

Thanks, build 3784 solved it!

[devrope]

The setting is still “Regular VS Build Output Window”.
Setting stickiness to 0 doesn’t help either.

• This reply was modified 4 years, 2 months ago by devrope.

[devrope]

Sorry, the issue is still there in build 3779.
It worked fine in build 3769.

[devrope]

We have fixed the problem in the following build: VisualGDB-5.5.8.3774.msi

I tried this build, not having the issue in this thread, but there’s another issue with it.
The “VisualGDB Build” window keeps popping up every time I build, even though I’ve redirected all output to the standard output window.
It doesn’t respect that I close it either, and when starting a debug session it pops up in the upper left corner as a small window.

[devrope]

Please see attached. It get so sluggish that the VS window shows “not responding” for a while.

Attachments:

You must be logged in to view attached files.

[devrope]

I mentioned that I use the regular Output (see attached), same as last time I had issues.
It happens all the time, any VGDB embedded project, any amount in the output.

It seems that all gcc-rows in the output are colored white, even though I disabled coloring.
And then when I scroll in the Output and the white rows are shown, everything in VS gets sluggish.

Attachments:

You must be logged in to view attached files.

[devrope]

Attached is the build log.
This time it’s not so much a slow build, but after the build, VS is sluggish/not responding for a while.
When I try to scroll in the Output window it hangs. Also the Output window is coloring some rows white even though I disabled all Advanced build things, and redirected it to the normal Output.

Attachments:

You must be logged in to view attached files.

[devrope]

Looks like the new logic for analyzing linker messages was working slower than expected for long build command lines.

This bug seems to be back again in v5.5.7.3679 (and also in the offical preview 7).
Build is slow, and after build the studio is sluggish for a while.
I also disabled all coloring in the settings, but I’m still getting some white rows.
BTW: I’ve set it to output only to the normal output window.

[devrope]

Sorry, but the 3470 installer is corrupt, see attached picture.
Not knowing if there was a later build, I tried changing the url to 3471, and there was!
This time the installation went fine, and… it’s building fast again! 🙂
And the new mem report is really nice.

Used FLASH_SOFTDEVICE: 0 bytes out of 152KB (0%)
Used FLASH: 53KB out of 324KB (16%)
Used SRAM_SOFTDEVICE: 0 bytes out of 30KB (0%)
Used RAM: 4840 bytes out of 33KB (14%)

Thanks for the fast bugfix, now back to coding!

Attachments:

You must be logged in to view attached files.

[devrope]

1. The build logs are the same essentially, please see attached. Every compile row takes ~6 seconds when using VGDB 5.5 and it’s devenv.exe process that takes ~25% CPU.
2. Same thing, still slow. Every compile row takes ~6 seconds when using VGDB 5.5 and it’s VisualGDB.exe process that takes ~20% CPU.
3. Builds fast! 🙂 But makes VisualGDB kind of redundant… and no mem utilization report, of course 🙁

Attachments:

You must be logged in to view attached files.

[devrope]

After installing 3458 (the official Preview 3) I can confirm that it still builds very slow (11 min instead of 45 secs).
I tried “disabling the advanced build output (Tools->Options->VisualGDB->Advanced Build->Show build output from VisualGDB = Regular VS Output Window) and restarting Visual Studio”, but it didn’t help.
No code/project changes at all between tries.

Will revert to 5.4 once again 🙁

[devrope]

Before reverting yesterday I tried to disable the new “advanced build output” but it didn’t help.
The one thing I didn’t do was restarting Viusal Studio.

After reverting to 5.4 the build took 45 seconds, so disabling AV seems pointless.
The project is using GNU Make.

Regarding the mem utilization fix: is it fixed in the real preview 3 (3458)? Because I tried 3457 and it was still wrong there.

[devrope]

I’m having the same issue, after upgrading to VisualGDB 5.5 Preview 2 (also tried preview 3 build 3457).
I wanted to try the new “Memory utilization report from Linker script” and made no changes at all to my code, except enabling the new option.
My project is nRF52832 generated from VGDB with make file (not msbuild) and in v5.4r12 it builds fast.

Also, the new mem utilization isn’t correct, so there’s that too 🙁
My linker script is the one you provide, with reserved space for SoftDevice (nRF52832_XXAA_S132_reserve.lds), and the report states:

——————- Memory utilization report ——————-
Used FLASH_SOFTDEVICE: 57KB out of 152KB (37%)
Used FLASH: 876 bytes out of 324KB (0%)
Used SRAM_SOFTDEVICE: 612 bytes out of 30KB (1%)
Used RAM: 4580 bytes out of 33KB (13%)

That’s not correct, right?

Will revert to 5.4r12 for now, as it takes 11 minutes to build (used to take ~1 minute).

• This reply was modified 4 years, 9 months ago by devrope.

[Author]

Posts