Family Historian User Group

I've seen some odd effects at times with setting debugger breakpoints, where they do not seem to be working as anticipated. I've finally managed to capture evidence in a script that seems to be both repeatable and reproducible.

Consider the screengrabs below. Plugin execution pauses at the breakpoint at line 2. Clicking on Go, it correctly bypasses the breakpoint set at line 5, but pauses again at what should be the unreachable breakpoint at line 8. There is a flashing insertion point at line 7, which appears to indicate where the "true" breakpoint is. Each conditional test seems to knock the breakpoint out by one line. In this script, the first Message Box is not displayed until after the second program pause at line 16! My plugins are synced via OneDrive and Directory Junctions, and the identical file generates the same error on both my desktop (even after several reboots), and on the laptop. It runs normally on my old FH6 test installation on a third PC.

I haven't fully sorted out exactly what it needs to generate the error, but table declarations, the table size function, and conditional statements all seem to play a role. I have made minor changes to similar scripts in the past and the error has disappeared, but this one seems persistent so far.

I'll try the same script tomorrow after leaving the PC off and unpowered overnight, but has anybody else either seen this sort of thing before or able to reproduce the error with a similar script?

This is the exact plugin script used for the final screengrab.

It is doing it for me as well. Probably best to raise a ticket, I have not come across it myself, but I don't if then else on a single line. It might be a garbage collection as you are using a local named variable perhaps the parser is casting out the lines some how.

I would send the script over to Calico to see if they can spot the problem.

Thanks Jane. Good to see that it is reproducible. I'll raise a ticket and send them the script.

The problem is rogue Carriage Return characters ( i.e. Lua "\r" ).
I've had similar problems with misplaced breakpoints in Plugins since 2014.
So I produced the 'Prune Twin CR From Plugin' plugin which usually fixes the problem, but not in your case.

In this case the line break sequence at the end of the 'if then' lines is "\n\r\n".
They become visible when the script is viewed in a plain text editor such as Windows Notepad.

However, my plugin does not cope with that particular sequence because it is only looking for "\r\r".
So I have adapted it to look for "\r\n" as well as "\r\r" and is attached below.

P.S.
The problem was originally raised during FH v6.0 Beta testing under the Subject:
FHUG > Forums > Beta > Resolved > "Extra CR in Plugin Script Upsets Debug"
It was thought resolved by plugin 'Prune Twin CR From Plugin'.
So no further action was taken.

Thanks Mike - long experience and memories are very useful!

My best guess is that the root cause is down to a confusion between Unix and Windows line endings, and the debugger is sometimes inserting both! CP ought to fix it at source though, rather than rely on a plugin fix. I don't know if the debugger is something they have written themselves, or whether it is an off-the-shelf product from a third party.

If you view the plugin script in Notepad++ and simply convert the line endings from Windows to Unix and back again, that also fixes the problem.

I've gone through my Ancestry sync script in Notepad++. There are about 20 or so line ending errors in about 1400 lines of code, so they are rather common . Sometimes it's a double Unix/Windows ending, sometimes just a Unix LF on its own (will the plugin see that?). My NAS is Linux, and I do use Linux Mint occasionally, but the plugin script has never been edited or even opened in Linux.

I'll review my other plugins later to see how widespread the problem is.

I have a quick and dirty plugin that simply counts how many of each line ending there are in a file, and my Ancestry sync plugin does contain quite a few Unix style endings. I suspect that I have copied and adapted malformed lines without spotting the error, which is not visible in the FH debugger. I checked my other plugins, and I did find one double <CR>, but that was all.

The easiest fix is definitely in Notepad++, particularly as I use it already for code proof reading (if only FH had its features...). fhLoadTextFile()/fhSaveTextFile() fixes it as well, presumably as whatever it is calling behind the scenes does the correction automatically.

The simplest and most generally applicable plugin solution is probably to just delete all the <CR> characters, then convert <LF> to <CR><LF>.

I do wonder where my rogue <CR> have ever come from since I don't use Unix?

Unfortunately, fhLoadTextFile()/fhSaveTextFile() are only in FH v7.0 so don't offer a solution for earlier versions.

I suspect you are correct that the universal solution is to delete all <CR> and then replace all <LF> with <CR><LF>.
The attached plugin uses that technique but only writes the file back if the original file differs from the processed file in order to avoid altering the Modified Date unnecessarily.

My assumption is that there is stuff in the internal plumbing that originated in Unix/Linux and hasn't been fully/properly converted, but that's only a wild guess from somebody who knows very little about the nitty-gritty details of building a programming language and all its support files, libraries, etc, etc...