Welcome to the Monastery and the wider Perl world, oldB51. You've made a great start already.

It is likely that my debug tactic will be to print variables at various stages until the problem is found. This is usually easier than a formal debugger anyway.

I too am an advocate of liberal print/warn statements while debugging. However you may be unaware that Perl has its own built-in debugger which can you use at any time should you so wish. It is explained extensively in perldebug. See also the FAQ How do I debug my Perl programs?

I think I’m right in saying neither will in fact install on 64bit Macs. But - if this is the case - why does the installation begin. Surely cpanm knows what system it is trying to install into and should stop the process immediately with a polite message.

It does know the architecture but it doesn't necessarily know that any given module won't install there. That is in the gift of the module author and they may not know either. Many modules were originally written before 64-bit architectures were widely available, for example, and some have not kept pace with such developments. It might also be the case that it's just a bug and needs to be fixed.

Contrarily many modules will bail out early if it is attempted to install them on a platform which is known to be unsuitable. This is most often seen when a non-Perl pre-requisite is missing (a compiler, a system libarary, a third-party tool, etc.). You will probably come across one of these eventually.

Thanks hippo for the useful background information. The two debug links are now on my…ever growing..list. Many thanks.

I suspect I will soon be seeking advice from Perl Monks - so many thanks in advance.

Welcome to the Monastery!

Feel free to ask all the questions you want. There are many, many Perl folk here who love to help, several with decades of experience.

Cheers, and have fun!

-stevieb

Padre development stagnated about a decade ago sadly. I've found Atom to be a good editor so far, but its corporate sponsor (Microsoft/Github) is abandoning it, so its future is a little uncertain at the moment. I do hear good things about vscode though.

Welcome to the site!

I've gotten the most use out of Log::Any. I wrote my own minimalist adapter for it Log::Any::Adapter::Daemontools which can change the log level on the fly in response to SIGUSR1 and SIGUSR2. And then I have written in-house Plack middleware that can change the log level depending on a browser cookie. (I might get that published some day) The end result is that I can set that secret cookie on my browser and then perform actions on the production system and see the full trace output even while other users are hitting the same server and generating minimal log output. (The log output stays in the server logs, so there isn't any security risk in this cookie as there would be if it pushed the logs to the browser.)

The other thing Perl has that kills the need for a debugger is nice easy unit testing. See Test::More or Test2. If you structure your program as a collection of small mostly-independent modules, you can wrap each of them with unit tests and work out all the bugs before you assemble them into anything complicated. It's amazing how few bugs I end up having in the main program if I've fully tested each of the components first. And there's always "perl -d" for debugging the unit tests, if the log wasn't enough.

I second your sentiment about print/log debugging plus testing.

For me personally is the debugger only helpful when dealing with badly documented foreign code, to figure out WHERE and HOW things happen, not necessarily what goes WRONG.

I.e. tests and logging are missing, and I can't figure out the flow by looking at the code.

(I also use the Perl-debugger as kind-of REPL to test code snippets, but that's not debugging)

To my chagrin are most of my colleagues trained from early on to develop with the debugger, because our tool of choice - Komodo - makes it very easy to set a breakpoint at the fringe of the actual code and step thru and see watch expressions.

Furthermore is F5 set to run inside the debugger, it's F6 for an independent run.

It's so interwoven, that they don't even know how to use perl -d and its commands. The keep talking about "Komodo's debugger", literally as if Active-State hacked an independent solution.

This, plus continuous automatic perl -c in the background with underlining of compilation errors (mostly forgotten my declarations) leads to a kind of "try and error" programming mentality.

Before I started for that client, newbies were told to copy-paste a "working" script and adapt it to their needs, Komodo would just help them underlining problems and help "debugging".

It's quite hard to convince them that the proactive use of test-suites and logging leads to better results.

It's basically a question of return of investment...

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

you can find interesting this recent thread: Workflow / Setup Questions where perl IDE are discussed.

See also RFC: Perl Learning Plan where I mention Modern Perl Book: worth to read even if not for beginners.

I loved a lot the ancient Perl Cookbook which can offer you a wide panorama about how many things Perl is good at (remember is an old book but many approaches presented here are basically still valid).

Pay attention to links posted by eyepopslikeamosquito: our best link collector :) (I try to mimicry them in my chaotic bibliotheca)

L*

Thanks for the response . Modern Perl is on my list. The IDE link is very useful…I had already tried BBEdit…an excellent text editor…but I decided on vscode.

However, I have seen several references to IntelliJ IDEA and decided to take the plunge. It is fantastic. I have some experience with its sister product CLion so didn’t require much convincing.

I have some experience with its sister product CLion so didn’t require much convincing.

Yeah, their other products are almost identical. I use CLion for several projects as well (and Rider etc, etc). The awesome thing about their products is that they all allow you to install the same plugins. For example, CLion is what I use for C/C++ development, but it also allows the Perl plugin be installed, so I can work on my projects that include both C and Perl (such as this one) without having to have two IDEs open.

I've been a user of their software for a very long time now. Best part is, is that they have an Open Source License, so if you've got a viable Open Source project(s) published, you can apply for said license, and that allows you to use every single one of their products for free.

Some more probably useful stuff:

• Still a good read
• Yet another good editor on the Mac
• Worth to consider
• Emacs replacement on the Mac

Best regards and have fun, Karl

Many thanks for these suggestions karlgoethebier.

What is TikTok?