Beta30 codeeditor delay

stopwatch says 8 seconds to startup the codeEditor for one plugin. currently i work on 3 plugins working together, that makes 24 seconds for the codeditor alone to have the project up and running.

pretty annoying if one wants to make quick edits like i intended to do.

and does vvvv has to freeze completely when its doing what its doing ? it feels like vvvv just crashed.

edit: ctrl+s in CE freezes everything as well
sorry to say but this renders this release completely unusable for me

deleted all old “-1630302878.dynamic.6.dll” files in bin by hand, that fixed the “open editor” issue.

CTRL-S still freezes everything to the point of forcing win7 to ask me if vvvv should be closed…v4 recovers after a few seconds.

as stated in the change log opening the editor for the first time should take some time, but not for the second or third time. never experienced this. this change was also done right after node13, so was in alpha for quite some time… still sad to hear that it doesn’t work for you as expected. would it be possible to zip your dynamic plugins and send them to me via mail? for debugging. see if i’ve the same issues with your plugins.

regarding ctrl+s: either something is completely messed up or your plugins contain much much code which simply takes time to compile. nevertheless, compilation should be done in background. will have to look into it why it’s not. but like i said before, something to reproduce what you describe would be good.

hi elias

i send you the plugins.
there is definetely a big difference in startup time compared to 29.2. as i said before, this can be fixed when i delete all the dll’s generated by 29.2

CTRL+S compilation is still very slow and no, there is not much code involved.

long loading time and freeze on save has luckily nothing todo with lazy parsing / background compiling, it’s simply the sheer amount of warnings you get from all the Input/Output/Import attributes above private fields in conjunction with a super slow table viewer - redrawing itself foreach warning/error it gets to display.

so simple workarounds for now:

  • change the visibility of your fields to protected or public

  • surround your imports (Input/Output/Import) with a

    • pragma warning disable 0649
      Input ISpread …
      Import ILogger …
    • pragma warning restore 0649

thank you for the tipp.
but all this didnt happen with the old vvvv version. maybe there is a way to disable warnings by default or an easier way to disable all warnings ?

well that was a feature request to display the warnings. they’re quite useful in many cases and shouldn’t be ignored in general. but i agree some kind of control to disable a few of them wouldn’t hurt.

yep, i usually turn off warnings in visual studio.

if the tableviewer is so slow then i’d say this new feature should be optional and not default.

i’ll keep working with the old beta for now.

it probably makes sense working on the ISpread warnings in general. compiling the SDK, one can see some of them too.
this hickup is in the end not just the fault of the tableview nor user inflicted.

the line

  • pragma warning disable 0649
    only disables the input / output error messages but i still get a message from ILogger FLogger; , which code disables this one ?

and while at it, where can i see the warning code ?

- pragma warning disable

could be part of every template to avoid starting with 2 warnings

the other warningn is 169:^code:

  • pragma warning disable 649, 169
  • pragma warning restore
    ^

in sharpdevelop the codes come up at the end of the warning messages something like (CS0169)

ok, should be visible in vvvv too, doesnt it ?
danks.

error/warning number will be included in upcoming release.

and a button to turn them off ? bitte bitte