log parser issues

Hi

Couple of issues with the log parser.

First off, although the debugger help suggests that %S would match spaces, it doesn't (minor issue, I can just put a space instead)

Second, sometimes if I have a full filename in the log but there is another file earlier in the project that almost matches, the file that will be opened is the wrong one.

Eg log parser is "* %F %L"

Log line is
3 \\amachine\somepath\ip\ip.h 71

Double-clicking that line brings up a file from the project called aatestpspad\ip.h

It looks as though it's only searching for the last section matching?

Edited 2 time(s). Last edit at 2014-07-01 12:31 by gwinkless.

There is LOG parser debuger in the Highlighter settings / Compiler tab.
Maybe better is use log parser expression: %L %F in case 3 on the begin is line number

I don't know is is possible to open file: \\amachine\somepath\ip\ip.h
If PSpad isn't able to open file from the path, it search file in the project.

I am sorry. I was wrong. Project has higher priority than file on the disk.
I will change logic. If log parser will return file include path, PSPad will open this file if possible.

pspad:

I am sorry. I was wrong. Project has higher priority than file on the disk.
I will change logic. If log parser will return file include path, PSPad will open this file if possible.

That's great - will definitely help, thanks!

pspad:

I am sorry. I was wrong. Project has higher priority than file on the disk.
I will change logic. If log parser will return file include path, PSPad will open this file if possible.

On a different but related note, if I run a compile with log being %F:%L:* and get (from a remote compilation) eg

folder/wibble.c:185: warning: format '%d' expects type 'int', but argument 4 has type 'long int'

if I double click that line, pspad correctly maps "folder/wibble.c" to a file \\mymachine\src\folder\wibble.c in the project and opens it to the correct line; however if I already have \\mymachine\src\folder\wibble.c open in an editor window it sometimes doesn't take me to that editor window, it opens a new editor so I end up with two copies open (gets very confusing).

Is there a way to fix that too?

Edit: I can't yet figure out when it works and when it fails. I'll see if I can work it out...

Edited 2 time(s). Last edit at 2014-07-03 12:44 by gwinkless.

pspad:

I am sorry. I was wrong. Project has higher priority than file on the disk.
I will change logic. If log parser will return file include path, PSPad will open this file if possible.

Is there any way you could make it slightly more complex? My issue is that the compile is returning a relative path (not a full one), eg

mysubdir/network.c:482:4 error: expected ';'

but if there's another file earlier in the project (say anothersubdir/network.c ) it's _that_ file that opens when I double-click; I guess you're matching just the leaf name and stopping at that point?

Is there a way that you could parse the entire project for the "best match", if you like? So (in pseudocode) something like this:

bestMatchpos=len(logFileName)
bestMatchFN="notfound"
while (fn=getnextfilename()) {
// can we match the whole search string to the RHS of the project filename's path?
if (substr(fn, len(fn)-len(logFileName))==logFileName) {
return fn
}
// is it a better match than the last one?
matchPos=positionOfLastMatchingSlash(logFileName, fn)
if (matchPos < bestMatchPos) {
bestMatchFN=fn
bestMatchPos=noMatchPos
}
return bestMatchFN
}

function positionOfLastMatchingSlash(string s1, string s2) {
i=len(s1)
j=len(s2)
lastsl=i
while (i > 0 && j > 0) {
if (h[j]!=n[i] && !((h[j]==char(92) || h[j]=='/') && (n[i]==char(92) || n[i]=='/'))) {
// it's neither the same char nor a slash
break;
}
if (h[j]=='/' || h[j]==char(92))
// we've matched a slash, so we've matched up to this node
lastsl=i
}
i--;
j--;
}
// so now we should have the position of the last slash that matched
return lastsl;
}

Obviously it's not tested and apologies that indents don't come out, but hopefully it gives you the gist of what I mean.

gwinkless:

Is there a way that you could parse the entire project for the "best match", if you like? So (in pseudocode) something like this:
.... snip ...

Alternatively, could you add in a hook so that scripts can register their own log parser? I appreciate that my requirements don't match everybody's, but that would seem to be a good compromise

Thanks!

pspad:

I am sorry. I was wrong. Project has higher priority than file on the disk.
I will change logic. If log parser will return file include path, PSPad will open this file if possible.

Just a gentle reminder that this is still misbehaving, if it's still on your list of things to fix then fine, I can wait, I just wanted to flag it up again in case it got lost over time

Just to precis:

log returns full UNC path to error in file

\\myserver\share\b\filename.c

Double-clicking log name opens a\filename.c because it's earlier in the project than b\filename.c

Thanks!

Edited 4 time(s). Last edit at 2016-04-20 10:10 by gwinkless.

gwinkless:

log returns full UNC path to error in file

\\myserver\share\b\filename.c

Double-clicking log name opens a\filename.c because it's earlier in the project than b\filename.c

Are your files open with UNC path or from mapped disks? What do you see in the PSPad title?

Edited 1 time(s). Last edit at 2016-04-20 10:18 by pspad.

pspad:

gwinkless:

log returns full UNC path to error in file

\\myserver\share\b\filename.c

Double-clicking log name opens a\filename.c because it's earlier in the project than b\filename.c

Are your files open with UNC path or from mapped disks? What do you see in the PSPad title?

From UNC paths: I've modified the project compile command to output all the output through sed and map the server's local unix paths to UNC \\-style paths.

The title shows \\myserver\share\b\filename.c

If I switch the paths to use mapped drivenames and modify the compile output to match, double-clicking errors in the log seems to fail to work altogether :(

Thanks

Edited 1 time(s). Last edit at 2016-04-20 11:08 by gwinkless.