
I'm trying to mofify a small PERL program that was written for me. Since I have no previous experience of using this language I wonder how I can debug it. PERL seems to be aninterpreter more than a debugger ... thanks a lot, MEM

Maura Edelweiss Monville wrote:
I'm trying to mofify a small PERL program that was written for me. Since I have no previous experience of using this language I wonder how I can debug it. PERL seems to be aninterpreter more than a debugger ...
thanks a lot, MEM
The first basics: If something strange has gone wrong with your program and you're not sure where you should look for help, try the -w switch first. It will often point out exactly where the trouble is. -w for warnings I am an experienced perl programmer, but I have switched to C++. I've never used the debugger. Normally no interpreted language needs a debugger. Only compiled and linked does. Hovewer, post your problem. I wanna see some good perl code. ;-) best regards Morten Gulbrandsen

Normally no interpreted language needs a debugger.
Only compiled and linked does.
Interesting statement. Would you care to expand on why you think that? -- --- Derek Fountain, on the web here : <a href="http://www.derekfountain.org">Derek Fountain</a>

Derek Fountain wrote:
Normally no interpreted language needs a debugger.
Only compiled and linked does.
Interesting statement. Would you care to expand on why you think that?
Sure, I had a discussion with other programmers what the difference between a compiled and an interpreted language was. At that time I were coding in PERL, I read that it existed a version of PERL, which actually could compile and link PERL source code. The other programmer said that the difference between an interpreter and a debugger lies solely in the language. He had the honest opinion that an interpreted Language like PERL was impossible to compile. An it could never exist any interpreter for C. End_Of_Statement. This I did investigate and I actually managed to find an interpreter for C sourcecode. And a compiler for Perl. which means, -> PERL can be compiled can be linked loaded can be executed all under control of the programmer with the options and environment he wants. I also took a closer look at the interpreted C language, which was a subset of K&R C. It was nearly like Maple, I then investigated what exactly a debugger was. best example: visual studio, I got the conclusion that a debugger was a very complex environment, that simulated the whole compile, link, load and execute process. I also got the feeling, that any interpreter did the same. I also took a look at what was required to make a good c compiler, and found that making a debugger was a lot more that making a compiler. Maybe I am wrong, but a debugger is a simulator. Someone could make a PERL compiler, When I use PERL, Python or PHP as interpreted languages, all kinds of assertions stops whenever it is required, gives the same information as any debugger. and In my eyes replaces a debugger. The levels of warnings usually set in a compiler before initial compilation takes place. is set at the beginning of a PERL script. I have some old PERL books and could recall what thay wrote about building a PERL compiler, linker and loader, IIRC, If I remember correctly. It was simply a discussion between another programmer and me that triggered the definition of an interpreter and a compiler. That showed me, a language like c could be interpreted, A language like PERL, could be compiled. The environment that parses, compiles and does what a debugger like visual studio did, is nearly the same as any PERL. PHP and Python interpreter does. ==> hence Debugger == Interpreter for me. This is only my initial idea. I'm only trying to help, I can be wrong, I'm not Knuth, nor Dijkstra. Please correct me, here is my proposition Compiler + debugger => Interpreter. Interpreter => simulation of compilation and debugging at the same time. under control by the programmer. I can be very wrong. But I also believe this is true for any language. if you like, I can fetch my PERL books and find out what Larry Wall has to tell, If I remember correctly. fell free to tell me your opinion. I have to append, at that time PERL was not object oriented. best regards Morten Gulbrandsen "If we all think exactly the same, then it must be someone who is not thinking at all"

On Monday 14 March 2005 08:02, Morten Gulbrandsen wrote:
Derek Fountain wrote:
Normally no interpreted language needs a debugger.
Only compiled and linked does.
Interesting statement. Would you care to expand on why you think that?
Sure,
I had a discussion with other programmers what the difference between a compiled and an interpreted language was.
At that time I were coding in PERL, I read that it existed a version of PERL, which actually could compile and link PERL source code.
The other programmer said that the difference between an interpreter and a debugger lies solely in the language.
He had the honest opinion that an interpreted Language like PERL was impossible to compile. An it could never exist any interpreter for C.
End_Of_Statement.
This I did investigate and I actually managed to find an interpreter for C sourcecode. And a compiler for Perl.
which means, -> PERL can be compiled can be linked loaded can be executed
all under control of the programmer with the options and environment he wants.
I also took a closer look at the interpreted C language, which was a subset of K&R C.
It was nearly like Maple,
I then investigated what exactly a debugger was.
best example: visual studio,
I got the conclusion that a debugger was a very complex environment, that simulated the whole compile, link, load and execute process.
I also got the feeling, that any interpreter did the same.
I also took a look at what was required to make a good c compiler,
and found that making a debugger was a lot more that making a compiler.
Maybe I am wrong, but a debugger is a simulator.
Someone could make a PERL compiler,
When I use PERL, Python or PHP as interpreted languages,
all kinds of assertions stops whenever it is required,
gives the same information as any debugger. and In my eyes replaces a debugger.
The levels of warnings usually set in a compiler before initial compilation takes place.
is set at the beginning of a PERL script.
I have some old PERL books and could recall what thay wrote about building a PERL compiler, linker and loader,
IIRC, If I remember correctly.
It was simply a discussion between another programmer and me that triggered the definition of an interpreter and a compiler.
That showed me, a language like c could be interpreted,
A language like PERL, could be compiled.
The environment that parses, compiles and does what a debugger like visual studio did, is nearly the same as any PERL. PHP and Python interpreter does.
==> hence Debugger == Interpreter for me.
This is only my initial idea.
I'm only trying to help, I can be wrong,
I'm not Knuth, nor Dijkstra.
Please correct me, here is my proposition
Compiler + debugger => Interpreter.
Interpreter => simulation of compilation and debugging at the same time. under control by the programmer.
I can be very wrong.
But I also believe this is true for any language.
if you like, I can fetch my PERL books and find out what Larry Wall has to tell, If I remember correctly.
fell free to tell me your opinion.
I have to append, at that time PERL was not object oriented.
best regards
Morten Gulbrandsen
"If we all think exactly the same, then it must be someone who is not thinking at all"
Okay Morten... Your thoughts are logical, but your assumptions are incorrect. In my book, a "Debugger" is a program/environment that allows you to execute a program step by step, and inspect the state of the program between each step. This can be done for Scripts as well as Compiled code. Download activestate komodo Trial and look at it as an example. Additionally, your discussions on "Compilers" is rather misleading. The definition of "what a compiler is", is blurry enough now-a-days that the discussion is not really worth carrying on, and leads to Flame wars about "compiled vs interpreted", "binary vs P-Code", and other such fine distinctions. Jerry

On Monday 14 March 2005 15:02, Morten Gulbrandsen wrote: <snip!> You seem confused about a lot of things. Here are a few facts to consider: 'C' can indeed be interpreted. I used a 'C' interpreter once and it was a quite horrible experience. It was marketed as an education tool, but to totally transform the nature of a language like that made it so far from reality it was worthless in my opinion. Perl is actually a compiled language. Really. The Perl code gets compiled into something a lot closer to a CPU's machine code than the Perl source really is. When you run a Perl program the first phase is compilation. If you run a really big Perl program you will notice a delay while this happens - with small Perl programs it's too quick to notice. There would be nothing to stop someone writing an alternative compiler which takes Perl code and writes out CPU-specific machine code, much like a normal 'C' compiler does. Java compilers traditionally compile Java code to Java Byte Code for the JVM to run, but there are compilers which compile Java to CPU machine code. Such issues are more a matter of market requirements than language or compiler technicalities. Visual Studio is not a debugger, it's an integrated development environment, which contains an editor, compiler, linker, debugger, profiler, and lots of other tools. But yes, it's complicated. :) A debugger is, as Jerry said, a "program/environment that allows you to execute a program step by step, and inspect the state of the program between each step." It doesn't simulate anything. It allows you to control the way the program runs and the environment it runs in. Because interpreted languages need a special environment to run in (i.e. the interpreter) as opposed to just having their machine code instructions dropped straight onto the CPU, there is a certain amount of control and runtime information which that environment can give. This is often called "introspection" - which means "looking into" something. Python in particular is very good at this. But introspection isn't as useful as a debugger - you can't use introspection to stop a program at a certain point, examine the runtime data, change it, then resume the program. So, in short, a debugger is useful in virtually all languages, regardless of how they actually get executed. Perl has one built in. Most other languages have one suppiled as an extra. --- Derek Fountain, on the web here : <a href="http://www.derekfountain.org">Derek Fountain</a>

Derek Fountain wrote:
On Monday 14 March 2005 15:02, Morten Gulbrandsen wrote: <snip!>
You seem confused about a lot of things. Here are a few facts to consider:
'C' can indeed be interpreted. I used a 'C' interpreter once and it was a quite horrible experience. It was marketed as an education tool, but to totally transform the nature of a language like that made it so far from reality it was worthless in my opinion.
So, in short, a debugger is useful in virtually all languages, regardless of how they actually get executed. Perl has one built in. Most other languages have one suppiled as an extra.
Thank you for the information, I knew it would be possible to make "C" an interpreted language. Could we say that a debugger is a visual interpreter ? executing in debug mode is nearly the same as running an interpreter? I still think so. To be honest. When I code in C/C++ I also find =>Rational Purify Plus, or => solaris DTrace for detecting memory leaks very good. certain kinds of crashes are impossible to find without Purify Plus, In visual studio I used the debugger extensively. In fact my problem here lies in the assumption: Some of the 'best' programmers I have ever met. Claimed something like: => only stupid beginners needs a debugger. => Good programmers uses printf(); End_Of_Statement I hope we can agree that is is foolish to say things like that, in fact we all need a debugger. with different warning levels. But certain kinds of errors can occure in C, Can memory leak occure in PERL? here again I think => NO, due to some garbage collection mechanism. certain languages can never experience memory leaks. Ideally a debugger gives output of also the expressions, the identifiers, and should enable some backsteps. To reconstruct the software situation just before the critical code. here under this URL http://www.activestate.com/Products/Download/Download.plex?id=ASPNPerl&conta... I found the software you use, To be honest I simply love PERL, It was the first programming language I simply mastered. In later years, I have been working with php. python, delphi and C++. Here I run solaris 9 x86, which perl /usr/bin/perl bash-2.05$ perl -v This is perl, v5.6.1 built for i86pc-solaris-64int (with 48 registered patches, see perl -V for more detail) Copyright 1987-2001, Larry Wall the trial does only run for solaris sparc. I can give it a go under Linux. Sun has perl as part of all solaris distributions. So it would be nice with a perl debugger for solaris x86. One last question, some years ago PERL was not object oriented. what is the situation now. can PERL offer the same object oriented software construction as Java, or C++ ? best regards Morten Gulbrandsen

On Monday 14 March 2005 11:31 am, Morten Gulbrandsen wrote:
When I code in C/C++ I also find =>Rational Purify Plus, or => solaris DTrace
for detecting memory leaks very good.
certain kinds of crashes are impossible to find without Purify Plus, I can't have more praise for Purify Plus. I was on the team that ported Purify Plus to Tru64 Unix, and I know it very well. This product has the technology to trace every byte of memory used in a program, including that used by the libraries. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Saturday 12 March 2005 19:19, Maura Edelweiss Monville wrote:
I'm trying to mofify a small PERL program that was written for me. Since I have no previous experience of using this language I wonder how I can debug it. PERL seems to be aninterpreter more than a debugger ...
thanks a lot, MEM
I use Komodo from www.activestate.com I use the profesional version (payware), I don't really remember if there is a free version. Jerry

Am Samstag, 12. März 2005 19:19 schrieb Maura Edelweiss Monville:
I'm trying to mofify a small PERL program that was written for me. Since I have no previous experience of using this language I wonder how I can debug it. PERL seems to be aninterpreter more than a debugger ...
Perl comes with a builtin debugger. Try to start the perl script using: perl -d script [arguments] For a graphical interface try ddd (http://www.gnu.org/software/ddd): ddd -perl script [arguments] Jan -- Linux-Quickies: http://www.jan-trippler.de PingoS: http://www.pingos.org
participants (7)
-
Derek Fountain
-
Jan Trippler
-
Jerry Feldman
-
Jerry Westrick
-
Maura Edelweiss Monville
-
Morten Gulbrandsen
-
Morten Gulbrandsen