How to Use eclipse to debug Perl applications

How to Use eclipse to debug a Perl application before 11:30:36

This tutorial will introduce the debugging functions provided by the eclipse epic plug-in. This plug-in provides a rich debugging environment that can be used in the epic Perl development environment and integrated with this development environment. This tutorial assumes that you understand the eclipse environment and have experience using Perl.

About this tutorial

Epic combines two systems that help with the Perl application test process: Regexp and debugger. Regexp is an interface for testing Perl regular expressions. Regular Expressions are the main component of many Perl applications, but it is very complicated to ensure the correctness of expressions. Using the epic Regexp view, you can test and modify the regular expression based on the check results of known data.

The epic Perl debugger is a traditional tool that is fully integrated into the eclipse environment. In addition to testing local scripts, the epic debugger can also be used to debug the web and remotely execute Perl scripts. Therefore, it is an ideal tool in multiple environments.

This tutorial describes how to import and move large applications and how to simplify the application view to make the code easier to understand and debug. In addition, we will introduce the epic debugging environment, which is completely inside eclipse and provides a complete debugging environment for standard scripts, CGI scripts, and regular expressions.

Prerequisites

To start using epic, you must meet the following prerequisites:

Eclipse v3.1 or 3.0

Java v1.3, 1.4, or later

Perl v5.8.6 or later. Most Unix and Linux installations and Mac OS X contain Perl. ActivePerl is used on Windows.

Eclipse epic plug-in

Padwalker Perl module. The ActiveState version is also supported.

Traditional Perl debugging technology

Before introducing epic, Let's first look at the traditional debugging technologies used by Perl, which are available at any time and indeed have some advantages. But they also have their own limitations. Understanding the limitations helps you understand why a better debugging environment is needed.

Introduction to debugging in Perl

If you ask a typical Perl programmer how to debug his application, he will mostly tell you that he only uses simple output statements to dump information during program execution. For example, you can add a simple statement to the loop to output the value you are calculating or processing, as shown in Listing 1.

Listing 1. debug with output statements
 
my $sth = $dbh->prepare($query); 
 
$sth->execute(); 
 
while(my $row = $sth->fetchrow_hashref()) 
{ 
  print STDERR Dumper($row); 
 
  printf('%s, %s (%s)<br/>', 
      $row->{album}, 
      $row->{artist}, 
      $row->{genre}); 
} 
$sth->finish(); 

In this case, you have output a row dump that is loaded from the database (MySQL) to stderr. Stderr is very convenient to use, because on a unix host, you can relocate the stderr output to the log file, while allowing other outputs to be located to the standard output as usual.

The dumper () function in the example will actually output the structure of any variable, including embedded and nested arrays, hashes, and other content. The output format is the same as the structure you manually generated. This function (part of the data: dumper module) is very useful and can be used as a method to output variables in a format suitable for human reading or to write a readable structure, you can use eval () to create a new variable.

Post-event debugging

When an application is running, the output function of the output information is used as an example for subsequent debugging. At this time, you do not actually monitor the execution of the application, nor try to find out the problem during the application running process, but instead dump the information and wait until the execution is completed.

This special debugging method is very popular when interactive debugging is difficult to implement. For example, real-time debugging of CGI applications is basically impossible because the application is executed on a remote server and is executed by a second application (Web Server. It is impossible to monitor script execution in real time.

Therefore, post-event debugging is useful, but it also has some obvious limitations. For example, you cannot monitor any variables without changing the code. Once the code is changed, you must run the program again to get the expected output.

Similarly, you cannot execute a single-step debugging program line by line. The entire application must be running unless you forcibly stop it. To track function calls and sequences, you need to add output statements to display the decisions made and the sequence and sequence. In addition, there is no other way to monitor or obtain information.

Real-time debugging

There are multiple real-time debugging systems (one of the built-in debuggers in Perl). You can start with the-D command line option (see Listing 2 ). This command line option starts an interactive session through which you can perform one-step debugging, skip code segments, monitoring variables and values, and even modify values during execution.

Listing 2. Using the Perl Debugger
 
$ perl -d -e 0 
 
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::(-e:1):  0 

In this example, the text interface is very clear, but it is still difficult to understand what happened, what information is displayed, and where the current execution is in a specific part of the code.

Some guis are available for the Perl debugger, but the functions available through these interfaces are still limited. Most importantly, it is very difficult to debug Web applications through such an interface.

In either case, the main limitation of the above debugging systems is that they are all other tools that you must add to the programming toolbox. However, none of them provide an integrated solution for your development environment.

This is precisely the case where the eclipse/epic Perl debugger has played a huge advantage. It is built into the eclipse system, so that you can develop, edit, and debug the same application at the same time.

Import and process existing projects in epic

The traditional Perl debugging technology has been introduced above, and now it is time for epic to appear. The following describes the traversal methods in the project-for code execution and debugging, this is a crucial technique. To study the best way to achieve this goal, you need to use a large project as an example. To enable the project to enter eclipse, you will use the import system to add files to the new project.

Run Import

To learn how to debug an application, you must first import the developed application to your system. This will lay a good foundation for you and give you the opportunity to understand how to traverse in a large project-this is a required skill when using the debugger interface.

Follow these steps to import a group of existing files:

If necessary, create a new project (if you want to add files to your own project, you can also use an existing project ).

Select import from the File menu.

Select File System from the list of available import sources. See figure 1.

Figure 1. Select Import Source

Click Next.

In the next panel, Click Browse and select the source folder for the import operation. The folder is displayed in the left-side pane. Other folders in the source folder are displayed in the tree structure in this list. The files in the selected folder are displayed on the right panel.

Click the check box next to the displayed folder. You can also select multiple independent files and folders based on the same mechanism.

You can select this to complete, but sometimes you may not want to import other files in this folder. Manual file selection is complex. You can use the filter to automatically select a file for import:

If you want to select only Perl files (usually the files ending with. pl -- that is, scripts and. PM -- that is, the files ending with the module), click filter types.

You will see a list of possible file types prompt (see figure 2 ). The camel icon is next to all perl file types. Click the check box next to the file type you want to import.

Figure 2. Select the file type to import

If you use a non-standard extension for a perl file, you can use the other extensions text box to add your extension.

After confirming the final extension list, click OK.

It is best to check which file has been selected. Check boxes should exist next to each file selected from the source folder. Figure 3 shows an example of the filtered file.

Figure 3. view the file/folder to be imported

View the source image (large image)

If you confirm that the selected import file/folder is correct, click the Browse button next to the into folder text box. The system requires you to select the target project folder for the import file.

Click Finish.

The project has been imported successfully. The following describes how to traverse the project.

Traverse large projects

You can use either of the following methods to traverse a project. You can use the navigator view to browse the entire project. You can see one or more independent folders and files that open the project. Figure 4 provides an example.

Figure 4. Navigator View

After you select a specific file to be viewed in the editor, the Outline View displays the modules in the imported file and all child routines defined in the file. The two are combined to make the file layout and functions easier to understand. To skip a specific subroutine, double-click its name in the Outline View. Figure 5 shows an Outline View window example.

Figure 5. Outline View

Limitations on epic autoloader

It is worth noting that some popular Perl structures and technologies are not available in epic/eclipse. There is such a restriction in the autoloader system. The system provides a flexible and efficient way to split modules into smaller files and automatically load them during execution.

The autoloader system works by placing all Code except the stub auto-loader into the text part of the file. This text is usually used to store script data rather than external files. Therefore, it is safe to ignore it. Unfortunately, this also means that eclipse will completely ignore this code.

Code folding

Readability makes the code easy to understand and is of great benefit to debugging the code. The tools provided by the epic plug-in first make the code in a good format, which is more readable and easier to hide child routines and components that are no longer needed or desired.

Code folding allows you to hide the definition of a given subroutine. Except that the sub-routine declaration stub is still displayed, other parts of the sub-routine code definition can be hidden.

If you view the RSS feeder script in the editor window, you will see a short line mark in the left column of each subroutine, as shown in 6.

Figure 6. Child routines in the code before collapse

View the source image (large image)

If you click the Short-line mark next to parse_items_to_text (), the definition of the entire subroutine is hidden. For examples of the Child routine definition after collapse, see Figure 7.

Figure 7. Collapsed child routines

After being folded, the original short-line mark is changed to the plus sign (emphasizing that the code has been folded ). Click the plus sign to expand the code and display the definition again.

Run the Perl Application

Now, you should have a good understanding of how to use epic to easily traverse projects. Before debugging an application, you must first understand how to run the application. To run the application, you must create a new running configuration.

RSS feeder Application

The basics of RSS feeder applications have been introduced in the "build Perl applications with Eclipse" tutorial. For convenience, listing 3 shows the scripts that will be used later in this tutorial.

Listing 3. RSS feeder script
 
use strict; 
use warnings; 
use XML::RSS; 
use LWP::UserAgent; 
my $ua = LWP::UserAgent->new(); 
my $feeds = { "MCslp" => 'http://www.mcslp.com/wp-rss2.php' }; 
foreach my $feed ( sort keys %{$feeds} ) 
{ 
  my ($rss) = parse_rss_fromurl( $feeds, $ua, $feed ); 
  parse_items_to_text($rss);   
} 
 
sub parse_rss_fromurl 
{ 
  my $feeds  = shift; 
  my $ua    = shift; 
  my $feed   = shift; 
  my $response = $ua->get( $feeds->{$feed} ); 
  my $rss; 
  if ( $response->is_success ) 
  { 
    $rss = XML::RSS->new(); 
    $rss->parse( $response->{_content} ); 
  } 
  return ($rss); 
} 
 
sub parse_items_to_text 
{ 
  my ($feed) = @_; 
  foreach my $i ( @{ $feed->{items} } ) 
  { 
    next unless defined($i); 
    my $len = length( $i->{"title"} ); 
    print($i->{"title"}, 
       "/n", 
       ( '=' x $len ), 
       "/n", 
       $i->{"description"}, 
       "/n/n", 
       $i->{"link"}, 
       "/n/n" ); 
  } 
} 

This script consists of a basic loop for processing hashes. First, download the RSS Feed Source (using lwp) and then parse the source (using XML: RSS ). The obtained object is used to output a simple text representation of the RSS feed.

Configure the application for execution

Before introducing the debugging details, you should first understand the basic knowledge of running the applications developed in eclipse. This section describes the RSS feeder Application generated in the tutorials for developing Perl applications in eclipse. I have used the technology described earlier in this tutorial to import files of this application to the system.

Follow these steps to configure the scripts in the project to be executed:

Select Run from the run menu. You will see a dialog box shown in Figure 8:

Figure 8. Set the default run Configuration

View the source image (large image)

Select the Perl local item and configure the perspective used when debugging or running a local Perl script (non-remote or cgi. When you run the script, your perspective will automatically switch to the perspective configured for this location.

Make sure that Perl local is selected and new is selected in the configuration list on the left side of the dialog box. The dialog box for creating a new run configuration is displayed, as shown in figure 9.

Figure 9. Add a new run Configuration

View the source image (large image)

Configure the name of the project and script you want to execute. Note that you can also add any command line options to the script. Remember to add the configuration name. Note that this configuration is specific to this script in this project.

You can also set specific options through the conmon Panel, such as where to send the output, whether to add the available scripts to the run menu for execution, and whether to enable the console (see figure 10 ).

Figure 10. Common configuration panel

View the source image (large image)

Click Apply, and then click Close to save the configuration.

After activating the configuration, you can run your script at any time.

Run your application

Now that you have obtained the run configuration of the activity, you can execute your script and determine whether it works as expected.

When running the script you configured for the first time, you need to manually select the configuration. However, this manual selection only takes one time. Then, you can select it as a "History" project in the run menu and run it again. You can edit the run configuration option to explicitly add the script to the run menu.

When you first run your configuration, follow these steps:

Select Run from the run menu.

Select a configuration from the configuration list on the left.

Select Run.

Your script will be executed and its output will be sent to the eclipse console.

If you have not opened the console view in eclipse, you can select the console view in the window menu to open it.

Figure 11 shows some output examples of this RSS feeder script.

Figure 11. Console output of RSS feeder script

View the source image (large image)

You may not want to simply run the application without monitoring or processing the application in some way. Here we will introduce it.

Interaction with your application

Eclipse's console view is sufficient for basic text scripts or applications that implement most interactions through standard input/output. Of course, the interaction that can be achieved through this interface is limited. You may want to increase the size of the console view to make it easier to use.

If you create a CGI running configuration, the execution model is slightly different. The reason is that the temporary CGI interface created by the epic to the script and CGI output is provided through the built-in Web client or third-party client, such as Internet Explorer, Safari, or Firefox.

When you debug an application, instead of simply executing the application, the full interaction of the CGI script interface is more meaningful. Debugging usually requires a lot of interaction, so next we will introduce the script execution details during the debugging process.

Debug standard applications

Now that you have understood how to use epic to traverse the project and run the application, the following describes how to debug the standard application.

All you need to do is change the configuration of the standard run environment to the debugging configuration. Eclipse then provides a debugging perspective that supports standard debugging tools (such as breakpoints) and allows you to view variables during execution.

Configure the application for debugging

Follow these steps to configure the script to be debugged in the project:

Select debug from the run menu. The dialog box 12 is displayed.

Figure 12. debug Configuration

View the source image (large image)

Select the Perl local item and configure the perspective used when debugging a local Perl script (not remote or cgi. When you run the script, your view will automatically switch to the perspective configured for this location. Because you are configuring for debugging, select the eclipse debug perspective.

You can choose to create a new configuration or use the existing configuration. To create a new configuration, select Perl local from the configuration list on the left side of this dialog box, and then click newy. The dialog box for creating a new debug configuration is displayed, as shown in Figure 13.

Figure 13. Add new debug Configuration

View the source image (large image)

Configure the name of the project and script to be executed. Note that you can also add any command line options to the script. Remember to add the configuration name. Note that this configuration is specific to this script in this project.

Click Apply, and then click Close to save the configuration.

After activating the configuration, You can debug your script at any time. Click debug to start the debugging process.

Eclipse debugging Interface

The debugging perspective of eclipse is shared and used by most debugging systems in eclipse, including debugging C/C ++ and Java applications. Figure 14 shows an example of the debugging perspective.

Figure 14. debugging perspective

View the source image (large image)

The debugging perspective consists of multiple default views, including:

Debug view this view shows the running scripts, including multiple threads in a separate script. Figure 15 shows a close-up of this view. The view displays the running scripts (main thread) and Perl debugger threads (interfaces used to run scripts ). Note that the row where the script is paused is also displayed in the figure. If you select this option from the view, the corresponding lines in the source code will be displayed. Variables view this view can be used to display variable values. Its output is similar to the output produced by the dumper () function mentioned in the traditional debugging method described earlier in this tutorial. The following describes how to configure the variables to be viewed in detail. Breakpoints view this view displays the breakpoints configured for the debugged application. We will introduce the configuration of breakpoints in more detail later.

You should be familiar with other views, such as the editor view, project outline view, and console view.

After you start to debug the application, you want to start executing the code line in a single step and monitor the output. The debugger stops automatically in the first line of executable code (after all modules are imported ).

Run the debugged application in one step

One-step execution of the debugged application enables you to monitor script execution row by row and function call. With one-step execution, you can trace and execute functions, test statements, and monitor variable values during code execution.

Eclipse supports five step modes, but in most cases, the EPCI plug-in only supports the first three. You can use the step button on the toolbar (the last five buttons on the right of the toolbar panel ):

Step into -- enter the function, loop, or other statements. If the function is available, the debugger displays the source code and allows you to execute the source code in one step.

Step over -- skip a statement and switch to the next statement in the code.

Step return -- if you have entered the function, execute all the code in the function, including its return statement.

You can click the "play" button (which is your VCR play button) to start execution again until the pre-configured breakpoint or script end-based on the conditions met first-stops, use the pause button similar to VCR to pause and use the stop button to stop the execution completely.

If you stop the execution and want to restart the debugging process on the same script, right-click the process and select relaunch from the menu.

Add/delete breakpoints

Sometimes you want to pause or stop the execution during script execution. the breakpoint is the row where the execution is paused or stopped in the code. It is conceivable that the breakpoint function is interrupted at this point.

To configure breakpoints, right-click the border next to the line to which you want to add breakpoints in the source code.

You will see a prompt menu that allows you to add breakpoints in the code. When you set a breakpoint, you will find it useful to enable the row number (via the same prompt menu ).

After a breakpoint is added, a breakpoint icon appears next to the code line, as shown in Figure 15. The breakpoint icon is displayed next to line 1 of the source code.

Figure 15. Code with breakpoints

View the source image (large image)

You can also use the breakpoints view to access the list of configured breakpoints (16), which lists the types, files, and line numbers of all configured breakpoints in the project.

Figure 16. breakpoints View

To delete a breakpoint, right-click the corresponding line of the source code and select Remove breakpoint. You can also select the breakpoint to be deleted from the breakpoint list, right-click it, and delete it in the same way. You can also enable and disable breakpoints. This function is convenient if you want to monitor the same code but do not need to monitor it at the same time.

Monitoring Variables

After a running thread is selected, all the variables in the current range are listed in the variables view. Figure 17 shows an example of the variables view.

Figure 17. Debugger Variables

For most debuggers, variables are only displayed after you explicitly add the variables to the list of variables to be monitored. Unlike this, the epic debugger automatically displays all variables in the current range. As you can see, all the details of the variables are shown here. You can use the tree interface to review the values of complex structures such as nested arrays and hashes in the script. Note that the local variable has an icon containing "L", and all other variables use the standard variable icon.

Variables that have changed since the last execution are highlighted in red. This makes it easy to find the changed variables when executing the application in one step.

In addition to the variables defined in your script (including the global and local variables of the current block), the variable view displays some of the global variables indirectly used in the script by default. For example, it displays the values of special stdin, stdout, and stderr variables.

You can also select to display internal Perl variables (such as $ and % env ). Click the View menu and select Show Perl internal variables. Figure 18 shows a variable view with this feature enabled.

Figure 18. Display standard internal variables

Remember that the variable view only displays variables or global variables in the current range. It does not display the available variables in the current range (functions, loops, blocks, or even modules or packages.

Debug the perl cgi application

So far, you have learned the benefits of using epic to debug Perl applications. What is the situation for per CGI applications? CGI applications are executed by web servers and usually output their information through a web browser. Therefore, debugging is very difficult unless you use the post-event debugging technology mentioned at the beginning of this tutorial. However, epic provides a unique solution for this type of problem.

Configure CGI debugging sessions

To debug the perl cgi script, you must have a working and available web service environment, such as Apache or IIS, and be able to write information to the IIS directory. The CGI application debugging method of epic is to act as a proxy between the Web server and the client. This allows it to control and monitor script execution, even technically, scripts are accessed through web servers.

Follow these steps to configure the CGI debugging session:

Select debug from the run menu to open the debug Configuration window.

Select the perl cgi configuration from the list of available configuration types.

Click new to create a new configuration.

On the configuration Panel (19), select the project to debug. You can select a CGI script by extension on the Web server panel.

Figure 19. Configuration panel

View the source image (large image)

On the web server control panel (20 shown), configure the HTML and CGI directories for the configured web server. You need to copy the script to this directory (you can use the export function of eclipse ). You also need to configure the name of the "Start" file to be used during debugging. This file will be returned when you access the Web server for the first time. It should contain a link to the script or a form using the script.

Figure 20. Web server panel

View the source image (large image)

To set custom CGI Environment Variables, you can use the CGI Environment panel to set these variables and their values.

On the browser panel, select the browser you want to use to debug the script. I found that built-in browsers are often the best choice.

Click Apply.

Click debug to start the debugging process.

Debug the perl cgi script

After running the perl cgi script, you can execute all the functions executed when debugging the standard script. You can also perform one step, monitor variables, and set breakpoints to interrupt execution.

Figure 21 shows the execution example of the RSS feeder application in the perl cgi script format.

Figure 21. debug the perl cgi script

View the source image (large image)

After learning how eclipse works as a proxy between scripts and the actual web server, you can control the execution. You can even easily monitor and control the individual HTML output in the script. When you debug a CGI script in this way, it usually takes a long time. Some browsers may encounter problems in this case. Therefore, we recommend that you use a built-in Web browser that can better accommodate the impact of CGI debugging.

Debug Regular Expressions

The difficulty of debugging regular expressions is well known. Regular Expressions are usually built during debugging and executed based on different scripts. By using interactive regular expressions to test the system, you can speed up the entire process. The epic plug-in is such a system.

If you add a regular expression View to the eclipse perspective (during development or debugging), you can enter and test a separate regular expression based on known values without creating a script for it. Figure 22 shows the Regexp view at work.

Figure 22. use regular expression View

When using this method, enter a regular expression in the top text box, and enter the text as the test basis in the match text box. You can also add options, such as case-insensitive and multi-line string matching. You only need to select the appropriate check box.

If the regular expression is correct, you will see a green indicator. The incorrect expression is red, and the unverified expression is black.

The button on the right of the view is used to perform the following operations (from left to right ):

Stop execution: stop the execution of regular expressions. In a regular expression with multiple elements (for example, multiple groups), step backward moves backward along the matching element. The matching elements in the matching text are highlighted accordingly. For example, in the regular expression and matching text shown in Figure 22, the first match is a number, followed by a name. Step forwardstep forward traverses matching elements in the regular expression forward. Run runs a regular expression on the entire text block. Successfully running blocks are highlighted in different colors, as shown in Figure 23.

Figure 23. Run the entire regular expression

 

When debugging a standard script, the regular expression debugger/tester view becomes available. You can even set a special regular expression breakpoint.

Now you have learned how to use epic to debug your Perl CGI application.

Conclusion

This tutorial describes how to debug a Perl script. Start with the methods used in the traditional Perl development environment. In general, there are two ways to use the print () function and monitor the output or use the debugger provided by Perl. Both methods have some limitations.

You can use the epic-Eclipse Perl Development Environment plug-in to debug Perl scripts and perl cgi applications. You want all the functions of a debugger to be available through epic, including single-step processing, variable monitoring, breakpoint setting, and script execution monitoring. You can also debug the CGI script through Eclipse/epic, run the script in eclipse, and directly output the script to the Web browser (including the built-in Web browser provided by ECLIPSE) in this way. Finally, we also introduced the method for debugging regular expressions in the script-in particular, such debugging can be implemented during the development process.

This tutorial introduces the features provided by epic and the features described in the "build Perl applications with Eclipse" tutorial. You can understand that this plug-in provides a complete environment, enables you to develop and test Perl applications in eclipse.