bearslumber wrote on Tue Oct 14 21:52:12 MEST 2008:
Hi, Before I ramble on about the problem I encounter, I wish to thank all involved for all the work they have put in to EPIC. A fantastic product it is and always my first port of call to write/debug perl applications. So many many many many thanks... Unfortunately I am encountering the following problem: The debugger does not seem to stop at breakpoints in a multiple module/package application. I am implementing an OO application and defining each class in a separate package/file. I can't get the debugger to stop at breakpoints in any of the class files called from the main program. I can step through the code but since it is a wxPerl GUI I am limited to stepping through the class constructors. My environment is: Windows XP, Eclipse 3.3.2 EPIC Source Plug-in 0.6.25 Active Perl 5.10.0 Build 1003 PadWalker 1.7 I realised it is not limited to this multiple package environment because I have previously abandoned an attempt to play with the plug in (and hoping to add features) because the debug never seemed to stop at any breakpoints. I also realise I can add all my classes to a single file and that works fine, but defeats the object, and I suppose suppresses me from my ultimate aim to add features to my EPIC environment. Any help would be very greatly appreciated. Thanks in advance Regards Lucas Other EPIC plug-ins in case they help EPIC Perl Editor Plug-in 0.6.17 EPIC External Libs Plug-in 0.6.1 EPIC Regexp Plug-in 0.6.1 EPIC Docs Plug-in 0.6.1 EPIC Perl Debug Plug-in 0.6.1
jploski wrote on Tue Oct 14 22:04:56 MEST 2008:
What is your directory structure and include path configured for the project? Do the modules refer to each other by 'use' or 'require'? Do breakpoints work correctly when you start a new hello project with a 'lib' directory (added to project's include path), under which the directory structure reflect the package hierarchy, e.g. lib/Hello.pm <-- package Hello lib/Hello/SomeOther.pm <-- package Hello::SomeOther with scripts and modules referencing others by 'use'?
bearslumber wrote on Wed Oct 15 11:19:53 MEST 2008:
Hi Jan, Thank you for your quick response. I'd never stumbled across the project INC setting in the "Project/Properties" menu. I set this to the project folder (below) but it still did not work. I had read about the folders structure requirements for packages and embedded packages (Package::Embedded_Package => /Package/Embedded_Package) but never used it, so I feared that I needed to restructure my project and thus rename my packages to comply. But I could not believe that this restricted the writing of as many packages as you like in a local folder and calling them. After all the application worked fine this way. So I continued to dig further. My final thought was the letter casing in the file names did not match the letter casing of the packages they implemented so I changed these to match and also recreated the project in Eclipse, and Viola!!! This suggests case sensitivity in EPIC, but it could also be the recreating of the project. I recreated the project because I was getting Out of sync messages from Eclipse, and perhaps the feature would have worked just by changing the INC path, but all was tangled up and therefore EPIC couldn't work properly with a tangled up environment. Perhaps you can confirm to me Jan whether these features of EPIC are indeed case sensitive? Now I shall try debugging EPIC itself. Watch this space!!!! Many thanks again Lucas ......................................................... The Project name is Make_PPM. The Project directory is: Z:/Documents/Workspace/Make_PPM and I keep all packages (modules) in the same directory. The current project files are: Make_PPM.pl # The application Make_PPM_dlgAbout.pm # Package/Class Make_PPM_dlgAbout Make_PPM_MainFrame.pm # Package/Class Make_PPM_MainFrame
jploski wrote on Wed Oct 15 20:12:43 MEST 2008:
Regarding the correspondence of package names to directory hierarchy, there is no reason NOT to do that. This is how anything you install from CPAN is organized. Incidentally, this is also the same convention used by Java with respect to the fully-qualified class names and locations of .class files - with the difference that it is not optional in Java. It is also used in Python. It's used everywhere! Ignore it at your own peril. ;-) Regarding the lettercase problems - this rings a bell - I can vaguely remember a bug related to that under Windows. EPIC contains some path normalization abracadabra to deal with the sad fact that how the Perl debugger refers to source files is unspecified (internally, EPIC uses canonical absolute paths). Obviously, based on your report that seems not enough. Maybe you can debug it on your system. Hint: put epic_breakpoints.pm into the working directory of your script, so that it is found through @INC before EPIC's own version - then you can hack it and experiment etc. One thing to keep in mind is that this code is performance-sensitive. Doing path conversions in the wrong place can slow down debug-mode execution considerably.
bearslumber wrote on Thu Oct 16 21:11:45 MEST 2008:
Thanks Jan, Point well put about the correlation between package names and directory hierarchy. I should have taken heed, and now that you have spelt it, I shall be taking heed. Looks like Perl gives enough rope to either hang or to abseil. I know which I'd rather do, even though sometimes it is tempting to just hang. ;¬) Thanks also for the Hint and tips. I look forward to getting my claws dirty. Will report back with progress. Now likely to be in a couple of weeks time. Thanks again. Lucas
Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.