basic sepia questions
Joe Brenner
I've got some basic Sepia questions. Are there any Sepia uses in
the house (Rolf?) that can give me something like a SYNOPSIS of a
typical session in using Sepia?
The "Getting Started" section of:
http://cpansearch.perl.org/src/SEANO/Sepia-0.97/Sepia.html
Stops at sepia-repl (which brings up a sepia prompt), and I don't
even see how you point sepia to look at your own code.
LanX
promising anyway...
I only was recently curious to use the perldoc functions because they
make use of w3m if installed and realized that I have to upgrade to
the newest version for it. ;-)
There are now many packages out there to enhance perl on emacs but I'm
still looking for the best testing strategy.
Joe Brenner
LanX <lanx...@googlemail.com> wrote:
> <do...@kzsu.stanford.edu> wrote:
> > I've got some basic Sepia questions. Are there any Sepia uses in
> > the house (Rolf?) that can give me something like a SYNOPSIS of a
> > typical session in using Sepia?
> >
> > The "Getting Started" section of:
> >
> > http://cpansearch.perl.org/src/SEANO/Sepia-0.97/Sepia.html
> >
> > Stops at sepia-repl (which brings up a sepia prompt), and I don't
> > even see how you point sepia to look at your own code.
> Sorry till now I only used the REPL, but the other features look
> promising anyway...
Okay. What do you REPL for, then? Testing code snippets?
I tend to just use the perldebugger for that (M-x perldb), but
then, I see that sepia-repl can deal with multi-line code.
By the way, my idea of using mmm-mode to do syntax highlighting
at the repl prompt will almost certainly have problems. If I
understand the way mmm-mode works, you can use regexps to tell
it to treat the chunk after the prompt as perl code, but it's going
to look at that chunk in isolation, it's not going to understand
multi-line code very well.
> There are now many packages out there to enhance perl on emacs but I'm
> still looking for the best testing strategy.
Exactly. Which means there's an endless supply of things to talk
about here.
LanX
> > promising anyway...
>
> Okay. What do you REPL for, then? Testing code snippets?
lacks.
see http://www.perlmonks.org/?node_id=731680
The debugger forces you to prepend *manually* p or x to see the result
of something like "10/5", but sepia handles it with clever DWIM.
> then, I see that sepia-repl can deal with multi-line code.
and of the line, which cripples any cut and paste...
Please compare:
----------------------------------------------perl -de0
DB<1> for $i (@x) {
Missing right curly or square bracket at (eval 5)[/usr/share/perl/5.10/
perl5db.pl:638] line 4, at end of line
syntax error at (eval 5)[/usr/share/perl/5.10/perl5db.pl:638] line 4,
at EOF
DB<2> for $i (@x) {\
cont:
----------------------------------------------sepia
main @> for $i (@x) {
>>
---------------------------------------------
> By the way, my idea of using mmm-mode to do syntax highlighting
> at the repl prompt will almost certainly have problems. If I
> understand the way mmm-mode works, you can use regexps to tell
> it to treat the chunk after the prompt as perl code, but it's going
> to look at that chunk in isolation, it's not going to understand
> multi-line code very well.
parsing.
Theoretically it should be possible to copy this lispcode and extend
the rexexes such that
'main @>' at the beginning of the line is interpreted as semicolon
and the PRINT-part
is interpreted as comment. (I'm not sure about multiline '>>'
though...)
so this
----------------
main @> @x=1..5
1 2 3 4 5
---------------
should be seen as
---------------
; @x=1..5
# 1 2 3 4 5
---------------
which is perfect perl-code!
> I tend to just use the perldebugger for that (M-x perldb),
(Am I ignorant not to know this or is it just another example of
"learn emacs in 100 years" ???)
http://emacslife.blogspot.com/2009/07/learn-emacs-in-100-years.html .
I have to admit I'm one of these "only use print" for debugging guys,
but putting a cursor in the line of the currently executed code is
very NICE!!!
I remeber discussing with Gabor that Perl-IDEs lack a decent "in
source debugging" feature which is very common in other languages ...
*fg*
Cheers
Rolf
Joe Brenner
LanX <lanx...@googlemail.com> wrote:
> > > Sorry till now I only used the REPL, but the other features look
> > > promising anyway...
> >
> > Okay. What do you use REPL for, then? Testing code snippets?
>
> exactly, I wanted a real REPL including the *P*rint part which perldb
> lacks.
>
> see http://www.perlmonks.org/?node_id=731680
>
> The debugger forces you to prepend *manually* p or x to see the result
> of something like "10/5", but sepia handles it with clever DWIM.
Ah, yeah I see what you've mean. It's true that "edebug" (the
elisp debugger) is more convienient in that respect - it
constantly echoes the result of every expression it evaluates
to the status bar.
But I see that tye says if you start the debugger with the x
option, then you get the REPL-effect (I wonder how this would work
with perldb...):
http://www.perlmonks.org/?node_id=598127
Anyway that (http://www.perlmonks.org/?node_id=731680) is not a
bad perlmonks thread...
It's one of the central questions I'm interested in, combining (as
well as comparing and contrasting) ecb, cperl, sepia, perlysense,
pde... not to mention cedet. And some smaller stuff (like my own
perlnow.el, that Fred just mentioned).
> > then, I see that sepia-repl can deal with multi-line code.
>
> In the debugger multilinecode can only be done with backspaces at the
> and of the line, which cripples any cut and paste...
Yes, exactly. If you want to type in complex perl expressions,
perldb would be annoying to use.
But then, I've got another trick: there's a perlnow feature,
where a single command creates a new perl script from a template
that you've defined. When I really need to experiment with a
chunk of perl code, I put it in it's own script...
Consequently, as a side-effect I've got my own private perl
cookbook, a collection of hundreds of small scripts that demo
techniques I've used before ("what's a good way of adding hashes
together? I know I've figured that out before...").
> > By the way, my idea of using mmm-mode to do syntax highlighting
> > at the repl prompt will almost certainly have problems. If I
> > understand the way mmm-mode works, you can use regexps to tell
> > it to treat the chunk after the prompt as perl code, but it's going
> > to look at that chunk in isolation, it's not going to understand
> > multi-line code very well.
> cperl makes use of the font-lock mechanisms to define regexes for
> parsing. Theoretically it should be possible to copy this lispcode
> and extend the rexexes such that 'main @>' at the beginning of the
> line is interpreted as semicolon and the PRINT-part is interpreted as
> comment.
That's an interesting thought...
> (I'm not sure about multiline '>>' though...)
Right, that's probably a harder one: '>>' looks like it's part of a heredoc.
> > I tend to just use the perldebugger for that (M-x perldb),
>
> thank you very much 8)
>
> (Am I ignorant not to know this or is it just another example of
> "learn emacs in 100 years" ???)
> http://emacslife.blogspot.com/2009/07/learn-emacs-in-100-years.html .
Well, there's always going to be something you haven't run across,
yet. The emacs interface is not known for it's "discoverability".
> I have to admit I'm one of these "only use print" for debugging guys,
> but putting a cursor in the line of the currently executed code is
> very NICE!!!
Yes, definitely. I think it might be worth learning emacs just to
use it as a perl debugger front-end (but then, there are other
front-ends out there that have their virtues-- perltk is always on
my list of things to look at... you can apparently use it with
mod_perl code without restarting apache with the single-process
option).
Anyway, certainly embedded print statements are a useful debugging
technique, but it's also a good idea to know how to thread through
the code with the debugger. In the debugger you can can change
your mind on the fly about what values you're interested in spying
on, or what parts of the code you need to focus your attention on.
After a certain point, adding embedded print statements to your
code starts to clutter it up and make it hard to see what's going
on with it.
> I remember discussing with Gabor that Perl-IDEs lack a decent "in
> source debugging" feature which is very common in other languages ...
> *fg*
I'm not usually familiar with other languages enough to know what
we perl might be missing... typically I wait for other perl
programmer's to steal the ideas and import them.
LanX
> But I see that tye says if you start the debugger with the x
> option, then you get the REPL-effect (I wonder how this would work
> with perldb...):
>
> http://www.perlmonks.org/?node_id=598127
replying
than in reading the question, if you know what I mean...
Sure one could try to upgrade perldb to a feature which automatically
prepends "x",
but I was told that the source is more suitable for an obfuscation
contest... ;)
> Consequently, as a side-effect I've got my own private perl
> cookbook, a collection of hundreds of small scripts that demo
> techniques I've used before ("what's a good way of adding hashes
> together? I know I've figured that out before...").
> That's an interesting thought...
>
> > (I'm not sure about multiline '>>' though...)
>
> Right, that's probably a harder one: '>>' looks like it's part of a heredoc.
as
perfect as in cperl, 90% is just enough.
> Well, there's always going to be something you haven't run across,
> yet. The emacs interface is not known for it's "discoverability".
> > I have to admit I'm one of these "only use print" for debugging guys,
> > but putting a cursor in the line of the currently executed code is
> > very NICE!!!
>
> Yes, definitely. I think it might be worth learning emacs just to
> use it as a perl debugger front-end
purpose.
A lot like 'info' works...
> (but then, there are other
> front-ends out there that have their virtues-- perltk is always on
> my list of things to look at... you can apparently use it with
> mod_perl code without restarting apache with the single-process
> option).
> I'm not usually familiar with other languages enough to know what
> we perl might be missing... typically I wait for other perl
> programmer's to steal the ideas and import them.
see what Eclipse
(IMHO the role model for IDEs) actually offers...
I just started a thread to try breaking down this hole IDE-discussion
into measurable terms.
http://perlmonks.org/?node_id=788619
(plz excuse typos, no spellchecker yet in opera)
Joe Brenner
LanX <lanx...@googlemail.com> wrote:
> > Yes, definitely. I think it might be worth learning emacs just to
> > use it as a perl debugger front-end
>
> One could even directly start emacs in batch mode just for this
> purpose.
> A lot like 'info' works...
I don't think you quite mean "batch", I think you mean "standalone".
> > (but then, there are other
> > front-ends out there that have their virtues-- perltk is always on
> > my list of things to look at... you can apparently use it with
> > mod_perl code without restarting apache with the single-process
> > option).
>
> perltk and modperl??? do you have a link?
The name is ptkdb:
http://search.cpan.org/~vkon/TclTk-0.75/demos/tcltkdb.pm
http://ptkdb.sourceforge.net/
I've seen it demoed, but haven't used it myself (though really, I
should've tried it recently... I had some forking code that I needed
to debug, but forgot that ptkdb might be the solution).
> Yeah, but I'm seriously considering starting a Java project just to
> see what Eclipse
> (IMHO the role model for IDEs) actually offers...
Actually there are people who use Eclipse with perl (you might get
a better feel for all of it's features with Java though).