debug skips breakpoints in multi module app

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