where is the "check syntax cache"?

rschumm wrote on Wed Sep 28 16:14:21 MEST 2005:

I have a very big Perl-Project that gets very long to "clean build" oder
"check syntax". Sometimes check syntax gets corrupted. There must be a cache
somewhere with this information, but I cannot find it (.metadata etc.) 
Can somebody help? 

jploski wrote on Wed Sep 28 20:25:37 MEST 2005:

There is no cache maintained by EPIC. The problem markers are a platform
feature of Eclipse. EPIC uses Eclipse API calls to add and remove markers;
how they are stored internally is beyond our concern.

I do not think it is a good idea to mess with .metadata files anyway. Doesn't
the "Project/Clean" action resolve your problem? What sort of "corrupting"
do you observe exactly?

There is a known limitation related to problem markers inserted into module
files while checking scripts that use these modules. When you open the module
file with a problem marker inserted in this manner and check its syntax,
the markers might disappear because the problem is only reported while syntax-checking
a script. EPIC does not yet track the dependency between the source (detection)
and target (annotation) site for problem markers.

dacypher wrote on Thu Sep 29 15:21:00 MEST 2005:

I had a similar problem where I had errors that I didn't need/want.  I believe
I was using some Perl code that used some platform specific modules (something
in the Sys package I think).  Since I was running Eclipse in Windows and
the Perl module was Unix specific the module was not only not found, but
a bunch of thing that depended on the module gave errors as well.  I ended
up commenting a bunch of stuff out and rebuilt the project to remove the
errors.  I then had to disable the Perl compiling altogether (removed any
reference to the Perl interpreter in the preferences).  At this point I
was able to use Eclipse essentially as a syntax highlighting text editor,
obviously the debugger wouldn't work, but it was better than nothing.  Not
sure if this helps any...

rschumm wrote on Thu Sep 29 17:34:55 MEST 2005:

I don't know exactly if something gets corrupted or not. 
Clean build definitively helps, but sometimes "Checking Perl Syntax" takes
hours (10min per file or so). And sometimes the whole project is checked
very fast. 
So I thought it might be good to flush the cache (maybe after an eclipse
crash) - but apparently it's exacly what "clean build" does. 

jploski wrote on Thu Sep 29 21:20:02 MEST 2005:

When you do a "clean build" all files are checked again (as you can see
in the Progress view). According to my measurements over 90% of the checking
time is spent in the Perl interpreter, so it appears that little can be
improved on the EPIC side.

The checking duration should not vary from case to case if you are referring
to clean builds. If it does, maybe your scripts contain some nasty code
in BEGIN or END blocks. These blocks are executed by the Perl interpreter
even when it is invoked with the -c option (for syntax checking) and can
also generate some crazy error messages. So if you put a sleep(20); into
a BEGIN block, your build will take at least 20 seconds. 

Try figuring out whether particular files take a long time or if the time
is split evenly among a great number of files (as it is in my project, alas).

rschumm wrote on Fri Sep 30 17:43:28 MEST 2005:

ok, I will figure out in which files "clean build" hangs. I didn't see any
BEGIN-END blocks, but there certainly could be, as the project is huge.

as I see in "top", most of the time there is no "perl" process, but just
the "java" process of eclipse. when "perl" is working, syntax-checking goes
forward fastly. 

jploski wrote on Fri Sep 30 19:42:51 MEST 2005:

"top" might not be very reliable because the "perl" process is spawned over
and over again (once for each file), while the java process keeps running.
You might get the impression that only java hogs the CPU.

In my case I see the perl process appearing and disappearing all the time,
while java's used CPU time accumulates. The 90% mark I mentioned earlier
had been collected by profiling the build loop in EPIC (org.epic.core.builders.PerlBuilderJob).
Let me know if you notice anything strange in your project.