fujie wrote on Tue Jul 18 00:23:14 MEST 2006:
Hello, I was wondering about the syntax checker. It seems a bit buggy, but it could just be me. I will explain my problem with an example. Let's say I have two modules A.pm and B.pm, and module A has "use B" statement. This statement will report an Error due to "so called" existing errors in module B. So I go check the errors in module B and fix them (or find that there are none). And now I go back to module A and the "use B" statement still reports an error, even though I have fixed B.pm to NOT report any errors. (I have done numerous "Clean Projects"). This is very odd. Because sometimes I will open and close an erroneous module and that will "magically" fix the error (I don't know why). Does anyone else have similar problems? Are there still bugs being worked out with the syntax checker? Thanks Fuji
pacanukeha wrote on Tue Jul 18 01:09:58 MEST 2006:
Yeah, I get this problem. perl -c on the commandline shows no problems. Program executed in context generates no problems. Project|Clean sometimes fixes it, sometimes doesn't.
jploski wrote on Thu Jul 20 21:57:24 MEST 2006:
Currently, syntax checking is done on a per-file basis using "perl -c". When you open/save a file, the syntax check is performed on it automatically in the background. This syntax check begins by removing all error markers from the checked file. After that, the error markers are added to all files about which "perl -c" is complaining (which might as well be other files than the checked file). This algorithm's intent is to assign markers to files on which errors are reported rather than the files whose checking reports errors. However, it is imperfect because in some cases it leads to disappearing of error markers. You can have a situation in which you have a script foo.pl using module Bar.pm, and when you run "perl -c" on foo.pl you get the interpreter complaining about errors in Bar.pm, but when you run "perl -c" on Bar.pm, it says the file itself is ok. In this situation, reopening Bar.pm in EPIC will clear the markers which should stay because they were actually contributed by a check of foo.pl. On the other hand, if you delete foo.pl from the project, its contributed markers on Bar.pm should disappear (unless other scripts are also contributing them). This dependency tracking between error markers and source files which caused their appearance is not implemented. It would require major work to get it done right. I can imagine that the problems also occurs upon "Project/Clean" sometimes because the order in which the files are checked plays a role, but it is not constrained by EPIC. I would be interested in concrete (small) examples of projects in which this is happening because implementing some ordering heuristics might be feasible. In general, these problems will happen if you have missing modules in the @INC path (e.g., some modules reference other modules which themselves reference non-existing modules). After you have sorted out the @INC path, the problems should no longer occur. At this time, running perl -c manually on all your files is a recommended way of sorting out this puzzle. (I hope you are using epic-devel; the handling of @INC path in 'stable'/'testing' is buggy).
Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.