SlickEdit 2008 (trial version): "Message List" feature problems...

[Lee]

I'll look into it, I've tested this with examples similar to what you describe, and it works correctly on my end.  Any more info or reproducible samples you can post/send will be helpful.  Were you still using any of the previous workarounds or have any advanced settings enabled for the build tool?  What output are you seeing in the Build window?   As a test, does it start working again if you restart the editor? 

[mrothman]

Well, on top of everything else, I'm having a lot of trouble posting a response to Lee's help.  I get an http 501 error every time, from several machines at work, and my home machine.  Sigh... I'm going to try to post it in several pieces.

Thanks for checking into this Lee.  It worked for a while again this morning, but now it has stopped working again.  The only thing I can remember doing in the interim is re-ordering the error parsing expressions in the "Error Regular Expressions" dialog.  That caused it to use the wrong expression to parse my errors until I figured out what was going on, but I turned off the offending expression and now it's using mine again.  Yes, I have restarted SlickEdit since then (several times).

 Here's some more information:
1) I was not using any of the workarounds, as I didn't upgrade to 13 until 13.0.1 was available.  Nothing special in the build tool - I have enabled capture output, output to build window and clear build window.  I have NOT enabled build first, command is slick-c macro or run in x terminal.  Verbose output and beep on completion are grayed out and not selected.
2) Here are my error regular expression, the macro function that I am running to find the file name, and the output from a sample run of the tool.

Here's the error expression:
^:p\:{#1:i}\:{#3?+}$

A clarification: you will note in the error output (next post) that the tool actually DOES print out the file name at the beginning of each line.  However, it does so in a way which is relative to it's own idea of where in the build tree it's processing from. So, there's no consistent way to figure out how to prepend the complete path to the file.  That's why I went with the solution of using a macro to search for the complete path, which the tool prints out just before processing each file.

[mrothman]

And here's the output:

[...src/services/io] /mathworks/home/mrothman/apps/slickedit/bin/vsbuild -command "sbcc -l /sandbox/mrothman/Amvm/matlab/src/services/io/MLStringSink.cpp"
VSLICKERRORPATH=/mathworks/devel/sandbox/mrothman/Amvm/matlab/src/services/io
sbcc -l /sandbox/mrothman/Amvm/matlab/src/services/io/MLStringSink.cpp
Configuring setmwe for sandbox, '/mathworks/devel/sandbox/mrothman/Amvm'
gmake: Entering directory `/mathworks/devel/sandbox/mrothman/Amvm/matlab/src/services'

sbcc-start: --- /sandbox/mrothman/Amvm/matlab/src/services/io/MLStringSink.cpp ---

io/MLStringSink.cpp: lint in RELEASE mode (tip: sbcc -lintmsg NUM)
FlexeLint for C/C++ (Unix)FlexeLint (Linux) Vers. 8.00w, Copyright Gimpel Software 1985-2007
--- Module:   io/MLStringSink.cpp (C++)
io/MLStringSink.cpp:26:<Note#1932> Base class 'MLSinkBase' is not abstract -- More Effective C++ #33
gmake: Leaving directory `/mathworks/devel/sandbox/mrothman/Amvm/matlab/src/services'

-- sbcc summary -----------
Total lint messages    : 1

Finally, I wanted to post the macro, but for some reason that is what is giving the http server issues!  Instead, I'm attaching it as a file.

[Lee]

Something is failing in the setup for vsbuild, there should be -signal option in the command-line.  vsbuild and SlickEdit use a socket for inter-process communication on localhost (127.0.0.1) and port number 9009.  If the -signal option was left off, that means the SlickEdit wasn't able to open the socket.  This could be a platform issue or just something dumb in the macro code, I'll need to investigate this further to find out.  You could try changing the port number, Macro > Set Macro Variable or set-var on the command-line: def_vsbuild_signal_port.   I'm also curious if it starts working after rebooting your system.

I'm guessing from the output your a Linux user, what distro are you using?

[mrothman]

Changed the port number, now the -signal appears in the vsbuild line, and things are fine.  Of course, they were fine yesterday for a while also...  But I'm hopeful

I will check with our systems people to see if 9009 happens to be used for something in house.

As far as distro, I'm running Debian.  I'm no linux expert, but here's what cat /proc/version outputs:

Linux version 2.6.22.8-mw017 (root@bat1826glnxa64) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Tue Sep 25 13:15:57 EDT 2007

Thanks for your continuing help!  One more thing, since you are obviously the expert in this area.  I posted this question over on the slick c board, but I'll ask you too.  Is there someway to get the message list to be reparsed from what's in the build window?  I note that anytime I run ANYTHING in the build window, even "ls", the message list is de-populated, and the next-error stuff thinks there are no errors if I try to navigate to errors in the build window.  This means if I want to (for example) use our (sigh) in-house version control to check out a file to fix an error, I have to avoid using the build window command line.  Otherwise, in effect I lose all my error output.

Thanks!

P.S. One other thing occurs to me - I routinely do all my linux work by vnc-ing into my server.  Any chance that could be affecting the port issue?  (You can see I'm not a linux expert...)

[Lee]

Hoping that it's just a port conflict, that's easy enough to workaround.  I've definitely confirmed that the message list and error markers are being cleared when entering commands in the Build window, I have been asked to look into it.  In the command process_enter (in macros/stdcmds.e), there is an explicit call to reset_next_error.  That *probably* doesn't need to be there, unless you plan on calling grep or directly invoking your build tools in Build window.  But even then, there's no callback handler for re-parsing the message list in that case, so it's probably safe to remove.  It's on my task list when I get the chance, it does need to be addressed.  It's small enough that you can make the change on your own for now if you'd like, barring any future hotfixes to stdcmds.e in this release.

[mrothman]

A hero point for Lee!  Great stuff.

[hs2]

@Lee: When I'm saving stdcmds.e with 'strip traing spaces = ON' (my Files default) I get an error on loading another module which imports 'stdcmds.e':
error msg: illegal character
here:
stdcmds.e - _GetLanguageSetupOptions() [line 10398]:

Code: [Select]

      'WW='word_wrap_style ',' 'IWT='indent_with_tabs ','\
Weird, isn't it ?
This also happens with stock macro modules. Example: strip trailing spaces in stdcmds.e, modify cbrowser.e and try to reload it.
Strange enough stdcmds.e itself loads w/o error (as it should).
If I leave all trailing spaces untouched and just apply your patch it works.

Could you please clarify what's going on here ?
HS2

[chrisant]

I noticed this a month or two ago (I think 13.0.0, but it might have even been 12.0.3, I don't remember for sure).

It happened to me after I added about 20 lines of code to stdcmds.e.  Then compiling other macros that #import it caused stdcmds.e to get an "invalid character" error in the middle of a statement concatenating a long string together (same one hs2 is seeing, I think).  I reduced the total number of characters that I had added to stdcmds.e and eventually it started working.  I assumed that there is some kind of size limit that's being hit and leading to the "invalid character" error, but it was only a guess and I didn't have a solid repro so I didn't report it.

For comparison, I do not have 'strip trailing spaces' on.  But I do have a macro that strips trailing spaces only from modified lines (I work in large codebases with lots of people, and we do not want to perturb the sources unnecessarily, especially since it leads to unnecessary merge conflicts).

[hs2]

Seems an '#import' specific problem... However, it's really annoying since modifying a module (also my own while migrating or later on) may lead to this unexpected and misleading error. No chance to find the problem in a systematic way

@chrisant: Besides that everybody should be forced to use spaces, strip the trailing ones and to use a decent diff/merge tool capable to ignore 'unimportant changes' - could you please share your 'strip_trailing_spaces_from_modified_lines_only()' macro ? I afraid I need it in a new project due to various reasons and I don't want to reinvent the wheel. Thanks !

HS2

[chrisant]

Here's the trouble with having the merge tool ignore the spaces...  I was personally involved in finding that flaw in three major source control systems.  One of them was obsolete, another realized the underlying math flaw in ignoring spaces during a merge and immediately hotfixed it, and the other source control system I was in charge of so of course we immediately hotfixed it too. 

When merging Base + Theirs + Yours the merge computes diffs between Base vs Theirs and between Base vs Yours.  It then aligns the two sets of diffs.  Where they intersect it is considered a conflict.  Where they do not intersect an automatic choice is made whether to keep the set of modified lines in Theirs or in Yours.

But if spaces are ignored then there are two problems that occur.

1.  A cosmetic problem:  by ignoring spaces, the merge will not merge changes that occur in spaces.  So for example, suppose the Theirs copy has indented a chunk of lines, but the Yours file has made a non-space functional change.  If spaces are ignored, then it appears that Theirs has no changes.  So, the result of the merge will either lose the indentation completely, or it will preserve the indentation on most lines but lose the indentation on the lines modified in the Yours file.  The natural reaction is to look for heuristic band-aids to apply to "nudge" the merge results to be what we desire for certain specific scenarios.  The risk in doing so is that each heuristic can have a ripple effect to cause some seemingly unrelated other scenario to begin to go awry.  It's dangerous to apply heuristics (case in point, ignoring spaces has at least two ripple effects).

2.  Silent removal/duplication of code:  ignoring spaces can perturb the Longest Common Subsequence (LCS) found between Base vs Theirs and between Base vs Yours.  The LCS's may be perturbed in such a way that two changes that would otherwise be in conflict do not get interpreted as intersecting.  This can then lead to silent removal or duplication of changes.  I use words like "can" and "may" because it does not always happen, but it can/may/does happen sometimes.  It's silent.

There are probably merge papers on the interwebs that go into more detail about these types of issues, but that's the basic idea.  I would say that hypothetically it should be possible to build a set of heuristics that check and balance and influence each other to arrive at consistently desirable results.  The hitch is that it's not safe to see an issue and devise a heuristic for that specific issue alone -- there are too many unseen scenarios that are easily perturbed by ripple effects.  It's a field that could use some intense academic research.

Anyways:

Here is a link to where I posted the macro.

[hs2]

Thanks for the interesting background information chrisant !
As usual things are sometimes much more complicated behind the scenes...
I was only aware of a few of the more obvious issues. I thought that at least ignoring trailing whitespaces should be save to do. Leading whitespaces can't be always ignored e.g. when dealing with makefiles. And of course I don't ignore whitespaces within code lines. However, thanks for re-sharing the macro I knew that there was already a discussion about that...

@SlickTeam: Do you think that it's a useful feature to add a 3rd value for 'strip trailing spaces' == 'restrict to new/modified lines' ?

HS2