Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#377 No stop on breakpoints EPIC 0.5.31

v0.5.x
closed-fixed
Jan Ploski
Debugger (177)
5
2007-05-27
2007-03-02
ziobombo
No

Hi,
I use EPIC to develop and debug pl and cgi scripts.
Neither in pl debugging nor in cgi debugging it stops on breakpoints that are in secondary files.
For exemple:
- main.pl that use lib.pm;
- breakpoint in lib.pm;
- start debug on main.pl;
- debugger doesn't break on breakpoints in lib.pm.

I've activated the debug console (perl -d): I attach the error file.

My machine is i386, my system Centos 4.4, my eclipse is 3.1.1 from jpackage.org and my epic is 0.3.51

Discussion

  • ziobombo
    ziobombo
    2007-03-02

    debug console output

     
    Attachments
  • Logged In: NO

    Hi ziobombo,

    I have the same problem. I can't use de debuger with epic and eclipse. Now, I must use another IDE (komodo) to debug my project. It's not fun.

    If anybody can help us :)

    Thank you

    Arnaud

     
  • ziobombo
    ziobombo
    2007-03-05

    • assigned_to: stephan_ruehl --> jploski
     
  • Jan Ploski
    Jan Ploski
    2007-03-05

    Logged In: YES
    user_id=86907
    Originator: NO

    Are your modules located in exactly the same directory as your Perl scripts?

    Then check out this thread for a possible workaround:
    http://sourceforge.net/forum/forum.php?thread_id=1682847&forum_id=258688

    (which will be incorporated into 0.5.32)

     
  • Jan Ploski
    Jan Ploski
    2007-03-05

    Logged In: YES
    user_id=86907
    Originator: NO

    Another factor: how exactly do you use your modules in your scripts?

    For example, in script bin/test.pl:

    use SomeModule;

    should be ok if the project's include path is set up properly (so that SomeModule.pm can be found).

    However,

    require "../lib/SomeModule.pm"

    will cause breakpoints to be ignored because "perl -d" will refer to the file literally as "../lib/SomeModule.pm" while EPIC will attempt to set a breakpoint on "/home/somewhere/lib/SomeModule.pm". "perl -d" is silly enough to not understand that both paths refer to the same entity and it will not break when "../lib/SomeModule.pm" is loaded (so EPIC won't be able to set line breakpoints in that file).

     
  • ziobombo
    ziobombo
    2007-03-06

    Logged In: YES
    user_id=1640376
    Originator: YES

    Hi,
    I tried the workaround (Project->Properties->Perl Include Path->${project_loc}) and it works.
    All my project is full of require "../lib/SomeModule.pm" and not of require "/absolute/path/Module.pm". My project has more than 100 files, organised in 10 folders and sub-folders.
    So, i have cross references through different folders... No way of replacing relative paths with absolute paths...

    Anyway, I've also tried cgi debugging, but the problem is not solved.

    Thanks a lot for your fast answer and of course thanks for EPIC.

     
  • ziobombo
    ziobombo
    2007-03-06

    Logged In: YES
    user_id=1640376
    Originator: YES

    False alarm, in fact the workaround doesn't work: same error.

     
  • ziobombo
    ziobombo
    2007-03-06

    Logged In: YES
    user_id=1640376
    Originator: YES

    I think the problem is somewhere else. I've tried this:

    cd /myhome/myproject/bin
    perl -d test.pl

    f /myhome/myproject/lib/test.pm

    No file matching `/myhome/myproject/lib/test.pm' is loaded.

    f ../lib/test.pm

    No file matching `../lib/test.pm' is loaded.

    Any idea?

     
  • ziobombo
    ziobombo
    2007-03-06

    Logged In: YES
    user_id=1640376
    Originator: YES

    Ok, I think I've understood: it is a conceptual error.
    I sometimes call my libraries with require, not with use. More than that, sometimes i call a library that calls a library that calls a library, etc.
    So, not all the libraries are loaded at the beginning.
    On the contrary the command "f library.pm" is executed at the beginning of the debugging: it is for that reason that it returns an error.
    I hope i have targetted the error and that it could be of help for you.

     
  • Jan Ploski
    Jan Ploski
    2007-03-06

    Logged In: YES
    user_id=86907
    Originator: NO

    You are right that not all libraries are loaded at the beginning. You are also right that "f library.pm" is attempted at the beginning, this is expected behavior. EPIC realizes when it fails and then sends "b load library.pm" to make the Perl debugger (perl5db.pl) notify it as soon as the file is actually loaded. This is where things go wrong - the "loaded" notification is never delivered to EPIC.

    Maybe you misunderstood my suggesting about relative vs. absolute paths. What I am suggesting is that you organize your project as follows:

    1. Scripts (*.pl) go into any directory you like.
    2. Modules (*.pm) go into a directory subtree rooted at lib.
    3. You define exactly one package per module.
    4. Module file location corresponds to the package name (or vice versa). For example if you have a package named A::B::C, then it should be defined in file lib/A/B/C.pm. If you have a module lib/X/Y.pm, then it contains package X::Y.
    5. You just add lib to the @INC path in project properties. You can even enter a project-relative path to lib there for portability across machines.
    6. To get access to modules in scripts (or other modules), "use A::B::C;" There is no need for "requires" whatsoever, unless you are generating the filename to be included at run time (i.e. "require $str;")

    With the above project layout, the debugger does not cause trouble by skipping breakpoints - it then uses absolute paths to refer to files internally, just like EPIC does. I know that if you have lots of legacy code, bringing it in order may mean a big effort. Yet I think it is worth trying, not just because of the current bug, but because of the resulting improved project structure.

    The current behavior of the debugger is certainly not ok, but it is hard to fix. The root of the problem is in perl5db.pl, the implementation of the client-side pieces of the Perl debugger, which does not belong to EPIC. The command "b load <path>" is supposed to set a breakpoint which will be activated upon loading the file described by <path> (this loading occurs immediately when you "use", or when executing the "require" line). It is nowhere specified what exact form the <path> passed to this command should have. EPIC always uses absolute paths of files there. However, when you "require ../../something.pm", then perl5db.pl seems to check this exact string "../../something.pm" against the list of strings previously registered with "b load <path>" - it does NOT compare file identities (I think it should normalize the paths before comparison, but there may be deeper issues that I don't understand here).

    Solutions that I presently see:

    1. Fix perl5db.pl. Out of scope of EPIC - report to Perl developers? Even if they treat it as bug and fix it, most of the existing systems will still suffer from this problem for a good while.

    2. Hack perl5db.pl. With enough determination, you could hack it yourself and make it work in your environment. The code out there is not particularly easy to grasp and references to filenames appear all over it. The subroutine which actually does the dreaded comparison which causes load breakpoints to be ignored is named 'postponed'. You may try to patch it as follows:

    # original lines:
    my $filename = $dbline;
    $filename =~ s/^_<//;
    # added lines to normalize the filename:
    use Cwd 'abs_path';
    $filename = abs_path($filename);
    # original lines again
    local $\ = '';
    $signal = 1, print $OUT "'$filename' loaded...\n"
    if $break_on_load{$filename};

    3. Get rid of the dependence on perl5db.pl in EPIC altogether. That is, implement an own rudimentary Perl debugger frontend instead of interfacing with the existing one. This solution would obviously require very much effort.

     
  • ziobombo
    ziobombo
    2007-03-07

    Logged In: YES
    user_id=1640376
    Originator: YES

    Hi. Thanks a lot for your time.
    Changing the directory tree of my project is a huge project and is not feasible for now. It is a shame that it doesn't exists a specification or at least recommendations for the directory structure of a perl project.

    Anyway, I've tried your "Hack perl5db.pl" solution and for now it works.

    Since I bought a complete version of Komodo, I was planning to use Komodo's debugger. In fact the Komodo distro include a custom version of perl5db.pl with some extra features.
    I have to figure out how to use it. Is there a way to use a custom version of the perl debugger in epic?

    Thanks again.
    Riccardo

     
  • Jan Ploski
    Jan Ploski
    2007-03-08

    Logged In: YES
    user_id=86907
    Originator: NO

    In theory, setting the environment variable PERL5DB to something like 'require "mydebugger.pl"' should replace the default debugger with a custom one. It works fine with simple examples (man perldebguts). However, it does not work if you substitute the path to perl5db.pl for mydebugger.pl, so I guess a better way would be to just overwrite perl5db.pl with the custom version.

     
  • Daniel Kasak
    Daniel Kasak
    2007-03-13

    Logged In: YES
    user_id=1276360
    Originator: NO

    I've got the same problem exactly. I have the following layout for my projects:

    - a main.pl in the top-level directory
    - a 'forms' directory with individual pm files for individual modules
    - a 'reports' directory with individual pm files for individual modules
    - a 'glade' directory with glade files

    The above layout is all inside an APPNAME folder, which is in the users' home directory. It gets started thus:

    APPNAME/main.pl

    I tried moving the 'forms' and 'reports' directory under a 'lib' directory as suggested above, but then nothing works:

    dan@dkasak ~ $ .client_services/main.pl -u 20
    Can't locate forms/splash.pm in @INC (@INC contains: /home/dan/.client_services/ /etc/perl /usr/lib/perl5/vendor_perl/5.8.8/i686-linux /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.7/i686-linux /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.8.8/i686-linux /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/5.8.8/i686-linux /usr/lib/perl5/5.8.8 /usr/local/lib/site_perl .) at .client_services/main.pl line 49.
    BEGIN failed--compilation aborted at .client_services/main.pl line 49.
    dan@dkasak ~ $

    Unfortunately, I'm in the same boat as other people here. If I can't get debugging working quickly, I'll have to go back to Komodo ( and I need another license, hence me checking out EPIC at the moment ). I'm prepared to put foward at least as much money as a Komodo license would cost me if someone thinks they can get the issues with the Perl debugger fixed.

     
  • Jan Ploski
    Jan Ploski
    2007-03-13

    Logged In: YES
    user_id=86907
    Originator: NO

    You do not need to have a lib directory, it's just important that
    1) you 'use' modules rather than 'require' them by specifying relative paths - this is the most important point; if you must have requires with relative paths, then the only solution is to hack perl5db.pl as mentioned earlier
    2) the *.pm files are not located in the same directory as *.pl
    3) the @INC of your project is set up correctly

    In your case, I suppose that you have project_dir/forms/splash.pm and that splash.pm contains "package splash;" To make things work, it should suffice to edit project properties and add the string 'forms' as an entry in the project's @INC path there. Similarly, add an entry 'reports'. The resulting @INC path will contain absolute paths to the 'forms' and 'reports' directory.

    If you want to see why breakpoints are skipped, turn on the debug console in EPIC properties. This will result in an additional entry in the Debug view, and the Console view will show you the communication between EPIC and perl -d when you click on this entry. From the output you will see how EPIC is setting file breakpoints (the "b load <some path>" commands). Next, set a breakpoint in a .pl script file on the line where you invoke something from a module (this breakpoint should work) and Step Into the module. The debug console will then show you what pathname Perl is using to refer to that module. In a working configuration, the path from "b load <some path>" and the path used by Perl match. In a broken setup they are different, probably because Perl refers to the module by some sort of relative path.

     
  • Daniel Kasak
    Daniel Kasak
    2007-03-14

    Logged In: YES
    user_id=1276360
    Originator: NO

    Thanks for the quick response. I've tried these suggestions, but unfortunately it's not working.

    I have added 2 entries to the project's include path:
    forms
    reports

    I also have the full path to the top-level application folder in the path ( I've tried both with this and without it ).

    With the debug console turned on, I get this on startup:

    ---

    Loading DB routines from perl5db.pl version 1.28
    Editor support available.

    Enter h or `h h' for help, or `man perldebug' for more help.

    main::(/home/dan/.client_services/main.pl:20):
    20: $| = 1;
    DB<1> printf $DB::OUT "%vd", $^V;
    5.8.8
    DB<2> f /home/dan/.client_services/forms/management_confirmed_savings.pm
    No file matching `/home/dan/.client_services/forms/management_confirmed_savings.pm' is loaded.
    DB<3> b load /home/dan/.client_services/forms/management_confirmed_savings.pm
    Will stop on load of `/home/dan/.client_services/forms/management_confirmed_savings.pm'.
    DB<4> .
    main::(/home/dan/.client_services/main.pl:20):
    20: $| = 1;
    DB<4> T
    DB<4> .
    main::(/home/dan/.client_services/main.pl:20):
    20: $| = 1;
    DB<4>

    ---

    However when I run code in forms::management_confirmed_savings the breakpoints are ignored. Is this the problem:

    No file matching `/home/dan/.client_services/forms/management_confirmed_savings.pm' is loaded.

    ... because that file does exist:

    dan@dkasak ~ $ ls -l /home/dan/.client_services/forms/management_confirmed_savings.pm
    -rw-r--r-- 1 dan users 63093 Mar 14 10:19 /home/dan/.client_services/forms/management_confirmed_savings.pm
    dan@dkasak

     
  • Jan Ploski
    Jan Ploski
    2007-03-14

    Logged In: YES
    user_id=86907
    Originator: NO

    The "No file matching" message is normal, nothing to worry about.

    In the debug console output you pasted, you can see this line:

    main::(/home/dan/.client_services/main.pl:20):

    This means that perl -d refers to main.pl by the absolute path "/home/dan/.client_services/main.pl", which is good. What I would like to see is a similar line from the debug console containing the file name "management_confirmed_savings.pm". To produce it, you have to set a breakpoint in main.pl at a line where something from management_confirmed_savings is invoked. The debugger will hold there. Then click on "Step Into" to enter the module. On this event the interesting line will be appended to the debug console. Paste it here.

    Also please answer these questions:
    1. Do you rely on 'require's or 'use's in main.pl?
    2. Does management_confirmed_savings.pm contain a package named 'management_confirmed_savings'?

     
  • Daniel Kasak
    Daniel Kasak
    2007-03-15

    Logged In: YES
    user_id=1276360
    Originator: NO

    Thanks again for the quick reply :)

    Instead of targetting the management_confirmed_savings.pm file, I'll use the 1st form I call from the startup script, which is forms::tab_form. It lives in the 'forms' directory. It's called tab_form.pm, and has the line:

    package forms::tab_form;

    at the top. The management_confirmed_savings.pm file is called from the tab_form.pm file, but I'd have to step through thousands of lines of Perl code to get to it ...

    So, here is the output when I step into the line that called forms::tab_form:

    ---

    main::load_tab_form(/home/dan/.client_services/main.pl:346):
    346: if ( $forms->{tab_form}->{form} ) {
    DB<6> .
    main::load_tab_form(/home/dan/.client_services/main.pl:346):
    346: if ( $forms->{tab_form}->{form} ) {
    DB<6> .
    main::load_tab_form(/home/dan/.client_services/main.pl:346):
    346: if ( $forms->{tab_form}->{form} ) {
    DB<6> T
    . = main::load_tab_form() called from file `.client_services/forms/splash.pm' line 116
    $ = forms::splash::splash_timeout() called from file `/home/dan/.client_services/main.pl' line 400
    $ = eval {...} called from file `/home/dan/.client_services/main.pl' line 400
    DB<6> .
    main::load_tab_form(/home/dan/.client_services/main.pl:346):
    346: if ( $forms->{tab_form}->{form} ) {
    DB<6> .
    main::load_tab_form(/home/dan/.client_services/main.pl:346):
    346: if ( $forms->{tab_form}->{form} ) {
    DB<6> s
    main::load_tab_form(/home/dan/.client_services/main.pl:349):
    349: $forms->{tab_form} = forms::tab_form->new( $globals );
    DB<6> .
    main::load_tab_form(/home/dan/.client_services/main.pl:349):
    349: $forms->{tab_form} = forms::tab_form->new( $globals );
    DB<6> .
    main::load_tab_form(/home/dan/.client_services/main.pl:349):
    349: $forms->{tab_form} = forms::tab_form->new( $globals );
    DB<6> T
    . = main::load_tab_form() called from file `.client_services/forms/splash.pm' line 116
    $ = forms::splash::splash_timeout() called from file `/home/dan/.client_services/main.pl' line 400
    $ = eval {...} called from file `/home/dan/.client_services/main.pl' line 400
    DB<6> .
    main::load_tab_form(/home/dan/.client_services/main.pl:349):
    349: $forms->{tab_form} = forms::tab_form->new( $globals );
    DB<6> .
    main::load_tab_form(/home/dan/.client_services/main.pl:349):
    349: $forms->{tab_form} = forms::tab_form->new( $globals );
    DB<6> s
    forms::tab_form::new(.client_services/forms/tab_form.pm:14):
    14: my ( $class, $globals ) = @_;
    DB<6> .
    forms::tab_form::new(.client_services/forms/tab_form.pm:14):
    14: my ( $class, $globals ) = @_;
    DB<6> .
    forms::tab_form::new(.client_services/forms/tab_form.pm:14):
    14: my ( $class, $globals ) = @_;
    DB<6> T
    $ = forms::tab_form::new('forms::tab_form', ref(HASH)) called from file `/home/dan/.client_services/main.pl' line 349
    . = main::load_tab_form() called from file `.client_services/forms/splash.pm' line 116
    $ = forms::splash::splash_timeout() called from file `/home/dan/.client_services/main.pl' line 400
    $ = eval {...} called from file `/home/dan/.client_services/main.pl' line 400
    DB<6> .
    forms::tab_form::new(.client_services/forms/tab_form.pm:14):
    14: my ( $class, $globals ) = @_;
    DB<6> .
    forms::tab_form::new(.client_services/forms/tab_form.pm:14):
    14: my ( $class, $globals ) = @_;
    DB<6> s
    forms::tab_form::new(.client_services/forms/tab_form.pm:16):
    16: my $self;
    DB<6> .
    forms::tab_form::new(.client_services/forms/tab_form.pm:16):
    16: my $self;
    DB<6> .
    forms::tab_form::new(.client_services/forms/tab_form.pm:16):
    16: my $self;
    DB<6> T
    $ = forms::tab_form::new('forms::tab_form', ref(HASH)) called from file `/home/dan/.client_services/main.pl' line 349
    . = main::load_tab_form() called from file `.client_services/forms/splash.pm' line 116
    $ = forms::splash::splash_timeout() called from file `/home/dan/.client_services/main.pl' line 400
    $ = eval {...} called from file `/home/dan/.client_services/main.pl' line 400
    DB<6> .
    forms::tab_form::new(.client_services/forms/tab_form.pm:16):
    16: my $self;
    DB<6> q

    ---

    Here is the code that calls is:

    ---

    sub load_tab_form {

    if ( $forms->{tab_form}->{form} ) {
    $forms->{tab_form}->{form}->get_widget( "TabForm" )->present;
    } else {
    $forms->{tab_form} = forms::tab_form->new( $globals );
    }

    }

    ---

    A couple of things to note at this point ...

    The debugger doesn't switch the focus into the tab_form.pm file. It allows me to step through code in the debugger, but even if I select the file, the current position in the file isn't tracked with the horizontal bar.

    Each line I step through produces an error:

    ---

    Warning
    Thu Mar 15 10:11:14 GMT+10:00 2007
    An unexpected exception occurred while creating a link to .client_services/forms/tab_form.pm

    org.eclipse.core.internal.resources.ResourceException: .client_services/forms is not a valid location. The location is relative to undefined workspace path variable ".client_services".
    at org.eclipse.core.internal.resources.Resource.assertLinkRequirements(Resource.java:154)
    at org.eclipse.core.internal.resources.Resource.createLink(Resource.java:588)
    at org.eclipse.core.internal.resources.Resource.createLink(Resource.java:570)
    at org.epic.core.util.FileUtilities.createFolderLink(FileUtilities.java:90)
    at org.epic.core.util.FileUtilities.getFileEditorInput(FileUtilities.java:27)
    at org.epic.debug.ui.DebugModelPresentation.getEditorInput(DebugModelPresentation.java:167)
    at org.eclipse.debug.internal.ui.LazyModelPresentation.getEditorInput(LazyModelPresentation.java:212)
    at org.eclipse.debug.internal.ui.sourcelookup.SourceLookupFacility.lookup(SourceLookupFacility.java:174)
    at org.eclipse.debug.ui.DebugUITools.lookupSource(DebugUITools.java:689)
    at org.eclipse.debug.internal.ui.elements.adapters.StackFrameSourceDisplayAdapter$SourceLookupJob.run(StackFrameSourceDisplayAdapter.java:101)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)

    ---

    At one point I tried to set up a project called '.client_services', but it disappeared. Maybe it's talking about this? I don't know. The *current* project is called 'Client Services', and I've manually set it's path to '/home/dan/.client_services'. It's a bit strange that EPIC says it can't 'see' tab_form, because it's in the project explorer under the 'Client Services' project.

    There is also this in the debug log:

    ---

    Info
    Thu Mar 15 10:11:00 GMT+10:00 2007
    Starting Perl debugger:
    Command line:
    perl
    -I/home/dan/.client_services/forms
    -I/home/dan/.client_services/reports
    -I/home/dan/workspace/.metadata/.plugins/org.epic.debug
    -d
    -w
    -Mautoflush_epic
    -w
    /home/dan/.client_services/main.pl
    -u
    20
    -e
    1
    Working directory: /home/dan
    Environment:
    CONFIG_PROTECT_MASK=/etc/java-config/vms/ /etc/env.d/java/ /etc/gconf /etc/terminfo /etc/texmf/web2c /etc/revdep-rebuild /etc/splash
    GUILE_LOAD_PATH=/usr/share/guile/1.6
    XAUTHORITY=/home/dan/.Xauthority
    CVS_RSH=ssh
    LESS=-R -M --shift 5
    GDK_USE_XFT=1
    LESSOPEN=|lesspipe.sh %s
    PWD=/home/dan
    USER=dan
    DISTCC_VERBOSE=0
    G_BROKEN_FILENAMES=1
    LOGNAME=dan
    KDE_MALLOC=1
    SHLVL=2
    OPENGL_PROFILE=xorg-x11
    DESKTOP=Enlightenment-0.17.0
    QMAKESPEC=linux-g++
    PATH=/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/local/compiz/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.2:/opt/stuffit/bin:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/qt/3/bin:/usr/games/bin:/opt/vmware/player/bin
    XPSERVERLIST=
    KDEDIRS=/usr
    GENERATION=2
    TERM=linux
    PAGER=/usr/bin/less
    SANE_CONFIG_DIR=/etc/sane.d
    DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-gJveIzUNUD,guid=ccff714664f568521eb8280045f76a42
    HOME=/home/dan
    JAVA_HOME=/etc/java-config-2/current-system-vm
    LD_LIBRARY_PATH=/opt/blackdown-jre-1.4.2.03/lib/i386/client:/opt/blackdown-jre-1.4.2.03/lib/i386:/opt/blackdown-jre-1.4.2.03/../lib/i386:/usr/lib/mozilla-thunderbird
    PKG_CONFIG_PATH=/usr/qt/3/lib/pkgconfig
    MANPATH=/usr/local/share/man:/usr/share/man:/usr/share/binutils-data/i686-pc-linux-gnu/2.17/man:/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man:/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man:/opt/blackdown-jdk-1.4.2.03/man:/etc/java-config/system-vm/man/:/usr/qt/3/doc/man:/opt/vmware/player/man
    DISPLAY=:0.0
    E_START=/usr/bin/enlightenment_start
    ANT_HOME=/usr/share/ant-core
    CONFIG_PROTECT=/usr/share/X11/xkb /usr/share/config
    MAIL=/var/mail/dan
    EDITOR=/bin/nano
    QTDIR=/usr/qt/3
    E_RESTART=1
    E_IPC_SOCKET=/tmp/enlightenment-dan/disp-:0.0-7716
    LADSPA_PATH=/usr/lib/ladspa
    MOZILLA_FIVE_HOME=/usr/lib/mozilla-thunderbird
    INFOPATH=/usr/share/info:/usr/share/binutils-data/i686-pc-linux-gnu/2.17/info:/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info:/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info
    VMHANDLE=blackdown-jdk-1.4.2
    PANTS=ON
    GCC_SPECS=
    DCCC_PATH=/usr/lib/distcc/bin
    DISTCC_LOG=
    PRELINK_PATH_MASK=/usr/lib/gstreamer-0.10:/usr/lib/gstreamer-0.8:/lib/modules:/usr/lib/locale:/usr/lib/wine:/usr/lib/valgrind:*.la:*.png:*.py:*.pl:*.pm:*.sh:*.xml:*.xslt:*.a:*.js:/usr/lib/klibc
    LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.pdf=00;32:*.ps=00;32:*.txt=00;32:*.patch=00;32:*.diff=00;32:*.log=00;32:*.tex=00;32:*.doc=00;32:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:
    JDK_HOME=/etc/java-config-2/current-system-vm
    SHELL=/bin/bash
    JAVAC=/etc/java-config-2/current-system-vm/bin/javac
    PYTHONPATH=/usr/lib/portage/pym
    HUSHLOGIN=FALSE
    CLASSPATH=.
    G_FILENAME_ENCODING=UTF-8
    E_START_TIME=1173842500.9
    PERLDB_OPTS=RemotePort=10.146.1.25:5000 DumpReused ReadLine=0

    ---

    This seems to indicate it's got the full paths to the @INC stuff I want.

    Answers to other questions:

    1) I *only* use 'use' lines ... no 'require' lines.

    2) /home/dan/.client_services/forms/tab_form.pm contains a package named forms::tab_form
    This is how I've set up all my modules.

     
  • Jan Ploski
    Jan Ploski
    2007-03-15

    Logged In: YES
    user_id=86907
    Originator: NO

    Thanks for the extensive information. The "disappeared" project is probably just filtered out. Edit Filters... in the pop-up menu of the Navigator view to make it appear. Clean up your workspace so that you don't have two projects referring to the same disk location. This may be causing the exception.

    As you can see, the Perl interpreter is referring to your module file by a relative path:

    forms::tab_form::new(.client_services/forms/tab_form.pm:14):

    I guess that the reason is that '.' is the first entry in the effective @INC which can be used to resolve the package name into that module.
    What we'd like it to use is:

    forms::tab_form::new(/home/dan/.client_services/forms/tab_form.pm:14):

    Solution #1:
    Add "/home/dan/.client_services" to the include path in project properties. It will become prepended before '.', affecting the filename resolution as we wish. It works for me. If it does not for you, also try

    Solution #2:
    Make a new directory /home/dan/.client_services/lib
    Move /home/dan/.client_services/forms under that directory, so that you have /home/dan/.client_services/lib/forms
    Add 'lib' to the include path in project properties

    This should result in forms::tab_form::new(/home/dan/.client_services/lib/forms/tab_form.pm:14): being used by perl -d.
    You have already tried it earlier, sort of, but forgot to add 'lib' to @INC in your command line:

    dan@dkasak ~ $ .client_services/main.pl -u 20

    should have been

    dan@dkasak ~ $ perl -I .client_services/lib .client_services/main.pl -u 20

    or if it's too clumsy for you to specify it each time
    - you could set the environment variable PERL5LIB=/home/dan/.client_services/lib
    - you could write a little wrapper shell script with that invocation

    When you run the script from EPIC it does not matter because it passes -I options according to the project's configured include path.

     
  • Daniel Kasak
    Daniel Kasak
    2007-03-15

    Logged In: YES
    user_id=1276360
    Originator: NO

    Thankyou VERY much :)

    Removing an include line from my startup script, adding /home/dan/.client_services ( and subdirectories ) to the project's INC path, and changing people's launcher to:

    perl -I ~/.client_services .client_services.pl

    has fixed things. I really can't thank you enough.

     
  • Jan Ploski
    Jan Ploski
    2007-03-16

    Logged In: YES
    user_id=86907
    Originator: NO

    'til next bug... ;-)

     
  • Uri Sh.
    Uri Sh.
    2007-03-29

    Logged In: YES
    user_id=1336768
    Originator: NO

    Working with both "use" and "require"

    1) "Disable" and then "Enable" the breakpoint AFTER the "require" line - debugger does stop
    2) Set breakpoint in secondary file AFTER the "require" line - debugger does stop

    Other case - debugger doesn't break on breakpoints in secondary file

    Working on Win32 complex environment, so playing with INC path variable is little inconvenience.

     
  • Jan Ploski
    Jan Ploski
    2007-05-27

    • status: open --> closed-fixed
     
  • Jan Ploski
    Jan Ploski
    2007-05-27

    Logged In: YES
    user_id=86907
    Originator: NO

    Fixed in 0.6.5. With this version, it should no longer matter whether 'require' or 'use' is used. It should also work with both absolute and relative paths in 'require's.