Can you provide a little explanation of how to use this?

[joshcsmith13]

How does this compare or relate to Gerald Richter's Perl extension? I want to debug on my Windows 10 machine, but after installing this extension, and adding a configuration entry to my launch.json, it will pause on the first line of code and then goes away/stops/dies.

[Nihilus118]

Gerald Richter's extension is based on a Perl module he wrote, while this debugger aims to work just by invoking perl -d. So the features aren't as advanced, but it should be way simpler to set up on most environments. Compared to Gerald's extension, it should also work on Windows 10 and 11. I test on both OSs myself while developing. If you set "trace": true inside your launch.json, the debug adapter will log every single request and response, which should help to find the issue. If you provide me with a code snippet to recreate the problem, I can start testing on my machine as well. In the past, there have been some issues with the debugger crashing when debug.inlineValues is set to on inside the VSCode settings. You could try to disable it and see if the issue resolves that way.

[Nihilus118]

@joshcsmith13 I just released a new version of the debugger with enhanced error handling when parsing variables. Please give it a try to see if it fixes your problem.

[joshcsmith13]

Sorry @Nihilus118 , it's been a while since I worked on this. I saw you note about the trace flag and just tried again. It does indeed stop on entry, and I can actually set a breakpoint (before the program/debugger crashes). However, as the first few lines that set variables are stepped it says "$=undef" for each line, and nothing shows in the "My" variables debug navigator.

I may or may not have tweaked the following a tad bit (like changing the "program" in launch and moving the editor line into the "[perl]" attribute of the settings).

This is what my project launch.json (for perl) looks like: { "type": "perl", "name": "Perl-Debug", "request": "launch", "program": "${file}", "stopOnEntry": true, "debug": true, "trace": true } This is what appears to be the relevant sections of global settings.json: "[perl]": { "editor.defaultFormatter": "nihilus118.perl-debugger", }, "perl.perlInc": [ "C:\\berrybrew\\instance\\5.38.0_64\\perl\\bin" ], "perl.showLocalVars": true, "perl.pathMap": null

It is confusing why the python files are being listed in the debug console.

launch.json settings.json perl-debug-trace.txt

I can't tell you how useful this would be, to be able to run this on my laptop when testing, instead of remoting into a production server.

Thanks, Josh

[Nihilus118]

Hi @joshcsmith13, your settings.json suggests that you have installed this Perl Extension at the same time. It seems to interfere with mine, as both register a debugger for Perl. I recommend disabling it and trying to debug again.

If this fixes your problem and you want additional LSP capabilities for Perl, I highly recommend this LSP, which works out of the box as well.

If this does not fix your problem, could you `please provide me with a minimal code example which I can try to debug myself? I have a Windows machine at hand and will install berrybrew to test the compatibility with the debugger.

[joshcsmith13]

Thanks again for the response. I installed the extension, along with Perl Navigator, into a separate [older (Version: 1.85.2)] instance of VS Code that I have for Remote Debugging and stripped the code down to something very simplistic. I still get the "$variable = undef" indicators, but for some reason the $epoch_time variable actually shows up in the Variables>My section, while the others do not. I verified that PadWalker is installed in Perl. PS C:\git\src\WhatThePerl> perl -MPadWalker -e 'print $PadWalker::VERSION'
2.5

settings.json WhatThePerl.zip

[Nihilus118]

I just installed berrybrew on my Windows 11 machine and installed the same Perl version you are using. I found that the error occurs when trying to parse variables, as the version of Data::Dumper bundled with it is too old and does not support the call to ->Trailingcomma(1), which is necessary for variable parsing to work properly. I fixed this by updating Data::Dumper using cpanm as follows:

After that, all unit tests passed with this version of Perl, and the debug adapter behaves correctly in VSCode as well:

Would it be possible for you to update your version of Data::Dumper to a more recent one? Removing the call to ->Trailingcomma(1) breaks the parsing of arrays and hashes, and a complete refactor would take additional time.

[Nihilus118]

@joshcsmith13 I just released a new version that should be compatible with older versions of Data::Dumper. Please give it a try.