I have a perl script, if i run it normally, it doesn't work right.
But if i run it with the debugger and set a breakpoint at a very specific line, then the script operates correctly.
What side effects can the, breakpoints of the ptkdb module, have?
Loading of any perl debugger has quite significant impact on all environment -- for an idea look into perldebguts. While the debuggers try hardly to minimize its effects, there are additional packages loaded, some special variable has different contents, timing of runtime changes, etc. Without more detail it is hard to say what difference is affecting you.
I would recommend to debug using logger (I found easy mode of Log::Log4perl very handy for this). Also many useful hints on debugging art is in perldebtut.
Related
Is it possible to disable WARNINGS (text in red) for the Output window, and only allow it to report errors?
I try a bit with the settings, and according to other posts I set Quiet for the Ant, and option -q for Maven, but it has no effect whatsoever.
So can anyone tell if it can be done at all, and if so, how, please?
From what I see the warnings are generated by the program you execute (or maybe by a library used by your program).
Ant or Maven are build tools to generate your program, that's why changing their verbosity level won't impact the program output.
You should check if your program accepts some command-line options, there might be one to adjust the verbosity level.
EDIT: just had a look at "aparapi", I see that it's a library, so you should check the library API if you can configure the verbosity level, or if you can redirect log messages to a file.
Typically, when running an application from the command line, I get a nicely printed trace when things go wrong. But, since I happen to be working on an Ncurses application, the trace gets mixed in with the interface that was running, and the output gets all jumbled. Like so:
Specifically, I'm working on this project: todo-curses.
I'm running the app as a Rake task, so I figured the --trace option would help me, but I just can't seem to figure it out. Is there a good way to log the output of the app to a file or something and not include the Ncurses interface with it?
It depends on the application: curses writes to the standard output by default. If you (as the developer of the curses application) use newterm for initializing the library rather than initscr, then you can tell it to write the screen interface to the standard error.
But developers of bindings for curses from other languages typically leave out newterm as an alternative, just to make things simple. For instance, the Ruby curses shown on github has this deficiency. Perhaps a bug report is due.
Recently, I found that my emacs starts slowly. Sometimes the startup process takes 30 seconds, sometimes 3 seconds. I guess this is related to network enviroment. However, emacs -q can always start up quickly.
This question is like asking "How long is a piece of string". You have not provided anywhere near enough information. Start with telling us which version of emacs and what platform you running on.
You mention that emacs -q starts quickly, so we can assume the slowness is due to your init file. There are a lot of possibilities and no way for us to tell for sure without analysing your init file. However, there are a few things you can do to help identify possible causes.
#Drew's comment about bisecting your init file is a very useful trick to identify the source of a problem in your init file, particularly when trying to track down an error. It can be useful in identifying major contributors to load time when those contributors can be linked to a specific config option or package load etc. It is less useful when the problem is an overly long inefficient init file with too many packages.
Using a profiler as suggested by #legoscia can help identify areas to focus on, but it will still be necessary to interpret and understand what the profiler is telling you.
My suggestions would be to
Additional Packages. Since the introduction of package.el and the emacs package archives, I've observed a tendency for some users to get a little carried away and install lots of packages just in case. run C-h p and go through the packages you have installed. If you don't use any or you see ones there which you no longer want or use, remove them. Each additional package (depending on how they are loaded - see below) will increase your startup time by some amount as each package will need to be loaded. Loading packages you don't need or want will slow down startup time.
Stuff you don't need or understand. Over time, our init file can grow with stuff and we don't remember why we added it or it can be stuff we have copied from others which we thought we might need and forgot about. Every few months (depending on how often you modify your init - maybe more frequently if you make frequent changes, less if you don't) go through your init file and comment out anything you don't need, don't understand or don't rmember why you added it. Just comment it out, don't delete it. Re-start restart emacs and see if it starts faster and whether features or configuration settings you want/need have gone. If there are, look through the stuff you have commented out and see if anything looks relevant. When you find possible candidates, try to work out what the code is doing (look in the emacs manual, use C-h f and C-h v or C-h m etc to try and work it out. If it relates to a specific package, try M-x customize-package and see if there is built in customization which might give you what you want. Even if you prefer to customize things by hand rather than use emacs' built in customization system, M-x customize-group is a great way to find out what customizations are supported by a package and verify you have variable names correct etc.
Learn emacs autoloads. Emacs has this very useful feature called autoload. There are two main ways of loading packages into emacs. The first is to just do a basic 'require'. This will look for an emacs library with the appropriate name and will read it in and evaluate it (it is like adding the file to your init file, so more lines to evaluate, which means increased load time for your init). The good thing about require is that it just loads the whole file and you know that everything gets evaluated. the bad things is that it can in turn require other files, which can require other files and can result in a much longer init time. To try and address this problem, emacs has the autoload facility. Basically, with autoload, you tell emacs that if it tries to execute a command with the name 'foo', it must first load (require) a specific file which you define in the autoload definition. The advantage here is that emacs doesn't try to load the library until you first try to use it, so there is no increase in load time. The disadvantage is that it can mean there is a delay the first time you use a command and it won't work if other parts of your init use the command (well, it will work, but will have no impact on improving load time).
Switch to use-pckage. There is a very useful package called use-package which can help address all of the issues I've mentioned. It helps compartmentalise your configuraiton, simplifies some common configuration tasks and has support for either setting up a package with autoloads or deferring the loading of a package until emacs is idle. It can help speed up your init time considerably provided you use it correctly. Highly recommend giving it a go. See https://github.com/jwiegley/use-package
I am using Eclipse Kepler Service Release 2 , EPIC 0.5.46 and Strawberry Perl 5 version 18 for perl programming. For debugging I am using Eclipse debugger and PadWalker .
I have an interactive perl program that writes to files based on answers provided by the users to multiple prompts. While debugging , every time i change a single line of code I have to rerun the whole program again and provide inputs to every prompt , which is really time consuming.
Is there a way to make changes to the code in a sub routine , in the middle of debugging session such that the instruction pointer resets itself to the first line of that sub routine. This way i do not have to restart the session to recompile the new code.
Appreciate your inputs and suggestions. Thank You!!!
What you want to do can be done, and I've done it many times in Perl myself. For example, see this.
However although what you describe may work (and is a bit dangerous), the way it is generally done a bit different and safer.
First one has to assume a regular kind of command structure like a command processor, or say a web server.
In a command processor or web server, you read a command (or get a web request), perform an action, then read another command, perform another action and so on. From your description, it sounds like you have such a structure.
In my case, I have each debugger command stored as in Perl file. This is helpful not only for facilitating this task, but also for understanding, testing and changing the code.
Given this kind of program structure, instead of trying to change the program counter, you complete the command and at the level where you are about to read a new command, you make the change and then reload the file which changes the code.
The specific Perl construct to do this is called do. Don't use require or use which will load in a Perl file only if that file or module hasn't been previously loaded. In your situation, you want to reload even if it has been loaded before.
So now how do you get to be able to issue a do command? As you suggest, you could do it through a debugger. Assuming you have this overall program stucture as described above, you put the breakpoint somewhere a common point in the caller which loops over things to process, rather than try to change things in indvidual commands.
And you don't even need a debugger to do this! Many web frameworks like Ruby on Rails, have a "development" mode where they save timestamps on files that implement functionality. If the file has changed they issue the "do" command before running the request.
I am using a web form I created as an interface to query a MySQL database. I have written some
perl CGI scripts to process the queries. But I am not getting the desired output, so I need to
debug the scripts. How do I do that? I mostly use Eclipse for debugging perl, but now I have the
web form parameters (checkboxes, listboxes) as input to the script. Is there any way I can pass
in the inputs from the web page and then debug the script in Eclipse? Or is there any other way
of debugging in this case? Hope I have made myself clear. Thanks.
I use this Perl module for CGI debugging. It lets you capture all data sent to a CGI script, when running from a normal browser. It then lets you "replay" the script from anywhere (command line, within a debugger) using the captured data.
CGI::Inspect looks promising, though I haven't tried it yet myself.
Using Devel::DumpTrace during a normal CGI session (with the data being logged to a file, via DUMPTRACE_FH) is a way to do in-depth debugging, without using an actual debugger.
Yes, of course you can use Apaches error log to do debugging; which a very lazy but efficient way to work.
You mention you use Eclipse so I assume you also use the EPIC plug-in for Perl development. Check out this chapter on how to configure Eclipse/EPIC for debugging CGI:
http://www.epic-ide.org/guide/ch06s02.php
I would hope Eclipse has a way to simulate CGI.
I use ActiveState's Komodo IDE, and it can simulate CGI (including input params), so I can recommend that as a good tool for this purpose. The IDE is NOT free, though, but consider this an investment if you're going to be doing this a lot. (I'm NOT affiliated with ActiveState - just a happy customer.)
It's not clear what exactly you want to debug, but a few tips:
When running under Apache, warnings go to the error.log, so you could follow your variables there.
The CGI.pm module allows you to run CGI scripts from the command-line (with parameters).
if you have a hypothetical CGI program written in perl, called webawesome.pl and you want to pass it two parameters: name and age, you can use a shell command like this:
prompt> perl -d webawesome.pl name=sifl age=21
Now you're in the perl debugger and you can step through your program, and the key/value pairs from the command line will be loaded as form parameters by CGI.pm
Setting these command line switches in Eclipse is left as an exercise to the reader, as I am an unabashed vi user, and haven't use eclipse in two or three years. I know there's dialogs to set run/debug options.
You can use Firebug or Fiddler to watch your requests made from the form, to ensure you are sending exactly what you think you are. You can also open a file open(fh,">>debug.txt") and print out the sql calls that you are making to a log file. I would also suggest learning about Data::Dumper which will print out objects prettily so you can see their structure.