Too much time launching a scenario : Refreshing workspace

[jime]

Hi,
When using the existing scenarios, i.e. unmodified C++ files, launching a scenario takes very little time almost a second or two. While launching a scenario that involves a modified C++ file, it takes a really long time. from the console it seems that the operation:
"Refreshing workspace (Blocked:the user operation is waiting for background work to complete.))" is the one which is consuming most of the time.

Is there any configuration fix for that?

Thanks.

[Michael Kirsche]

Are you using the Windows or Linux version of OMNeT?

Are you launching a simulation via the green button under the main menu or via (e.g.) omnetpp.ini -> left+click -> run as -> OMNeT simulation??

[jime]

Oh, I got it now. running the scenario by clicking the green button compiles the project and takes the changes in C++ files. While running the scenario using "run as OMNet" simulation does not compile the changes. I completely missed that.

Thanks.

[jime]

However, something annoying is happening all the time. When I make changes to INET files, then build INET. I don't want to set idle so I try to work on other projects referencing INET in the same workspace. But I get a "User operation is waiting" pop up window which blocks me from doing anything. so much waste of time on each change. I have to wait for build operation to finish each time to continue my last action!!

[Michael Kirsche]

Well as you've said: "some project referencing INET".
What do you expect? When you build INET, other projects that reference it depend on INET's files and build results (the library). If you would continue to work with files that are currently touched/processed, you might get duplicates, conflicts, errors and so on... that's why Eclipse is blocking your referenced project as long as INET is build.

[jime]

Is there a way/configuration that I can inhibit the referencing project from being blocked hence it depends on INET, but INET does not depend on it ?!

[Rudolf Hornig]

This is how the eclipse build system is working. Once you indicate that you depend on an other project, that project is considered as part of your working set and once that project is actually under build all the rest of the operation is blocked to avoid inconsistency.

The only way to properly solve this would be if there would be a 'read-only' dependency in eclipse. i.e. you could refer to an other project the same way as you use a system library (i.e. your own project would assume that INET is not changing while you are working).

Obviously you would see strange things and mysterious errors if this is not the case. I'm not saying it's an unsolvable issue, but this is definitely not the way the eclipse build system and workspace was designed. Some workarounds for this:

- Hit the build button for INET in the IDE and then work the other projects outside of the IDE (obviously this is a bad solution)

- When you want to build INET, go to the consol and build INET from there (i.e. outside of the IDE). with

make -j8 

so it will do parallel build. This way the IDE would not know whether INET build is in progress and you can keep continue to work on your related projects (obviously you should NOT build them as they depend and link against INET which is being build in the background).

I've added a reminder for this in the bugtracker: http://dev.omnetpp.org/bugs/view.php?id=762

Rudolf

[jime]

Is it normal that INET folder size exceeding 2 GB. Most specifically in the src folder I have the following files each with size of 256754 KB :
.tmplib3264 , .tmplib1836 , ..... (total of six files)

[Alfonso Ariza Quintana]

 

You can delete the tmp* files, there are temporary files that omnet creates in the linker time and it should delete them after a successful build

--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.