I often work with IBM/Rational's Clearquest product writing scripts. Clearquest uses a specialized version of Perl called cqperl (Don't ask - I don't like it but am stuck with it). I'd like to use EPIC to develop and debug cqperl scripts. cqperl is an ActiveState based perl that uses some special libraries.
When I attempt to use the debugger I get an error stating:
Error displaying local variables
Install PadWalker and restart Eclipse or disable display of local variables.
I also see:
Bareword found where operator expected at D:/Profiles/p6258c/workspace/.metadata/.plugins/org.epic.debug/epic_breakpoints.pm line 49, near "$DB::OUT _abs_path"
(Missing operator before _abs_path?)
Default die handler restored.
Trouble is I don't have PadWalker nor do I have ppm with which to install it. IBM/Rational gives you an ActiveState based, specialize Perl called cqperl but does not give you tools to install additional Perl CPAN modules into it's perl.
Is there a way to get ppm and PadWalker to install into this beast or am i just out of luck?
You can build PadWalker in your area and add it in the include path. Go to cpan.org. download the latest PadWalker and build it. If you are in Windows environment then you will need to install "cmake" and its dependencies first. When you build PadWalker it will create objects in blib directory, copy the objects under 'arch' and 'lib' directory to some directory and add that directory in your include path.
Or if you have install/Admin permission use "make install" to install it to the perl lib installation location.
This is Windows - not Unix. I can't make, even cmake, because that involves gcc, which doesn't exist on Windows AFAIK. You mention installing cmake and it's dependencies. Where do I get cmake? How do I figure out "it's dependencies"?
These links will help you to build.
Ugh. On to the world of building packages for Windows and Activestate...
Well I didn't get that far. First off, I don't really need Unix utilities as I have Cygwin. But I know that Cygwin will build things with POSIX paths and that'll probably not be good so I downloaded UnxUtils and unpacked it. What am I supposed to do with it then?
I also downloaded the nmake thing but it says to install it into your C:\Perl\bin directory. I don't have a C:\Perl\bin directory because I don't have ActiveState Perl. I have Rational's cqperl which is a derivative of ActiveState Perl so I put nmake into C:\Program Files\Rational\Clearquest - where cqperl.exe resides...
Moving onward, I download PadWalker and unpacked it then did cqperl Makefile.PL and got:
Perl v5.8.2 required--this is only v5.6.1, stopped at Makefile.PL line 4.
That means you are running older version of perl Distribution. I'm not sure if PadWalker supported there or not. Try commenting out "require 5.008002;" in MakeFile.PL.
Yes cqperl is older. But it's not like I have a say so in the matter...
I will try to comment out the require...
Ain't hacking fun!
However I still don't how nmake and this UnxUtils thing is supposed to be used together. There was no instructions for what to do with UnxUtils.zip save unzip it. How does cqperl Makefile.PL utilize any of th UnxUtils files? How does it locate them? And after using it do I have effectively a Perl module that has a dependency on UnxUtils in some way?
Well I removed the require and tried a cqperl Makefile.PL again and received:
Checking if your kit is complete...
'NO_META' is not a known MakeMaker parameter name.
Error: Unable to locate installed Perl libraries or Perl source code.
It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.
(You get this message, because MakeMaker could not find "\public\rational\common
Again, i don't know how to use UnxUtils nor nmake to build this. I assume I need to use cqperl and keep Windows style paths and the like. I mean I could try building this under Cygwin but that would probably embed POSIX paths which would not work with cqperl, which is decidedly Windows like and will not like POSIX paths...
If cqperl is based on 5.6.x, the debugger backend it is not compatible with the EPIC frontend, so don't try to use them together unless you are ready to modify Java code. If it is based on 5.8.x or 5.10.x, then it may be worth trying to copy the binary PadWalker files from a matching ActiveState Perl distribution to their expected locations:
What sort of Java could would I be modifying? I ask because cqperl isn't gonna be going to 5.8 nor 5.10 probably never. Could you give me at least a rough sketch of what would be involved in getting EPIC to support cqperl?
EPIC communicates with the perl5db.pl debugger back-end extracted from your Perl installation and patched with one line to interface with the "epic_breakpoints.pm" module. EPIC retrieves the back-end's current state, adds/removes breakpoints (dynamically, when source files are loaded by the back-end) and obtains values of variables on each suspend. It basically emulates what the user would type in the command-line debugger and parses the output. You can see this communication if you enable the "debugger console" in EPIC preferences. It is likely that some commands and/or output strings have changed since 5.6. The helper modules that rely on PadWalker or introspection to display values may need to be understood and updated also.
If you are interested, follow the instructions at http://www.epic-ide.org/devguide.php to create a development environment. Then, install breakpoints at interesting locations in the org.epic.debug plug-in (particularly the DebuggerInterface class and friends). Also, print-to-file logging statements in the *.pm files contained in that plug-in are useful to understand how they work. There is also javadoc on the Java side and POD regarding the variable dump syntax.
It's hard to tell to what extent the current (that is, 'testing', CVS HEAD) front-end is incompatible with 5.6. It just hasn't been tried yet, could be anything from changing a few constants to hacking PadWalker.
Thanks for the pointers. It actually all makes sense to me! Yes 5.6 debugger commands are indeed different and that's probably exactly the source of the problem and the solution. Now to only find more time to dedicate to fixing this. It is something I should do because I'll probably be working with cqperl for the foreseeable future... :-(