why starts the avr plugin quite every time when i change a setting commands like these?
find /home/ -path /ATmega16.xml
find /usr/local/ -path /ATmega16.xml
have you ever worked on a real linux system? ;)
/home/ and /usr/local/ are very very big file-systems.
find need several minutes...
can i forbid this?
thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Short answer: Open the preferences, go to AVR -> Paths and enable the "Disable search for system paths at startup" option and ensure that all paths are valid (except for the last one 'Atmel Part Description Files', which is currently unused).
Actually, starting with version 2.3 of the plugin this option should be enabled by default on Linux systems. If this option is enabled on your system and the plugin is still executing the 'find' command then there might be a bug in the plugin.
Background:
Determining the paths to the various required AVR toolchain components is a convenience feature for users that don't know or don't care where these components are located on the filesystem.
On Windows systems this requires just a quick registry lookup that is quick enough to be executed on every startup.
On non-Windows systems the situation is much more complex, because the toolchain components can be just about anywhere in the filesystem, depending on distribution, toolchain packages or D-I-Y builds.
The only solution I could think of to implement automatic determination of these paths was to call 'find' on the most commonly used paths and looking for some key files (looking for ATmega16.xml is for finding the path to the Atmel part description files)
Because this search can be slow on loaded systems the default was changed to disable the search on non-Windows systems.
brgds,
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was facing the suspicious find today. Generally the idea to lookup the toolchain components is very good support and if it takes several minutes it should not be a problem.
But what if you have mounted network shares? The unix 'find' generally does not distinct between those and local mounts.
I was spending the whole day to find out why my NAS gets loaded so heavily. The thing was I had installed the plugin (AVR Eclipse Plugin 2.4.0.201203041437 de.innot.avreclipse.feature.group avr-eclipse.sourceforge.net) on Kepler, but did not set up the toolcahin. On eclipse start up my local disk and my NAS got loaded and I did not understand why.
The first start up took 2 hours which of course depends on the sizes of the lokal and remote disks and its containing files.
Once eclipse started up, every turn to change something in the properties turned out to load my disks again for another 2 hours.
I figured out the process in question by the 'top' command and tried to kill it, which indeed was 'find'. But it is really resistive. It starts again and again by itself until you kill the whole eclipse environment.
After installing the toolchain it looked good.
I came to this thread and tried the suggestion >>enable the "Disable search for system paths at startup"<< but I am still not able to do so because I am waiting again for a long time.
Wouldn't it be a good thing to generally omit network shares when executing find?
Thanks for reading this post
cheers, woodz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi!
why starts the avr plugin quite every time when i change a setting commands like these?
find /home/ -path /ATmega16.xml
find /usr/local/ -path /ATmega16.xml
have you ever worked on a real linux system? ;)
/home/ and /usr/local/ are very very big file-systems.
find need several minutes...
can i forbid this?
thanks.
Hello Richard,
sorry for the late reply, but I was on vacation.
Short answer: Open the preferences, go to AVR -> Paths and enable the "Disable search for system paths at startup" option and ensure that all paths are valid (except for the last one 'Atmel Part Description Files', which is currently unused).
Actually, starting with version 2.3 of the plugin this option should be enabled by default on Linux systems. If this option is enabled on your system and the plugin is still executing the 'find' command then there might be a bug in the plugin.
Background:
Determining the paths to the various required AVR toolchain components is a convenience feature for users that don't know or don't care where these components are located on the filesystem.
On Windows systems this requires just a quick registry lookup that is quick enough to be executed on every startup.
On non-Windows systems the situation is much more complex, because the toolchain components can be just about anywhere in the filesystem, depending on distribution, toolchain packages or D-I-Y builds.
The only solution I could think of to implement automatic determination of these paths was to call 'find' on the most commonly used paths and looking for some key files (looking for ATmega16.xml is for finding the path to the Atmel part description files)
Because this search can be slow on loaded systems the default was changed to disable the search on non-Windows systems.
brgds,
Thomas
Aloha,
I was facing the suspicious find today. Generally the idea to lookup the toolchain components is very good support and if it takes several minutes it should not be a problem.
But what if you have mounted network shares? The unix 'find' generally does not distinct between those and local mounts.
I was spending the whole day to find out why my NAS gets loaded so heavily. The thing was I had installed the plugin (AVR Eclipse Plugin 2.4.0.201203041437 de.innot.avreclipse.feature.group avr-eclipse.sourceforge.net) on Kepler, but did not set up the toolcahin. On eclipse start up my local disk and my NAS got loaded and I did not understand why.
The first start up took 2 hours which of course depends on the sizes of the lokal and remote disks and its containing files.
Once eclipse started up, every turn to change something in the properties turned out to load my disks again for another 2 hours.
I figured out the process in question by the 'top' command and tried to kill it, which indeed was 'find'. But it is really resistive. It starts again and again by itself until you kill the whole eclipse environment.
After installing the toolchain it looked good.
I came to this thread and tried the suggestion >>enable the "Disable search for system paths at startup"<< but I am still not able to do so because I am waiting again for a long time.
Wouldn't it be a good thing to generally omit network shares when executing find?
Thanks for reading this post
cheers, woodz