SlickEdit Community

SlickEdit Product Discussion => SlickEdit® => Topic started by: rjpontefract on February 09, 2021, 01:51:43 am

Title: Support for older versions
Post by: rjpontefract on February 09, 2021, 01:51:43 am
I've been trying to adopt SE 25.0.1 but ongoing issues with context tagging have kept moving me back to 24.0.2.  I've tried many things to resolve the issues in 25.0.1 including clean configurations, re-importing visual studio solutions and opening support cases, but it still continues to have tagging issues.  There are symbols highlighted as undefined when they clearly have a definition.  Occasionally, pretty much all symbols will turn red (undefined) for no clear reason.

As I'm currently stuck on SE 24.0.2 until a version of SE comes along to resolve the tagging issues I'm curious as to whether 24.0.2 will see any more updates or hot fixes or is all of the attention now on 25.0.1?
Title: Re: Support for older versions
Post by: Dennis on February 09, 2021, 05:13:51 pm
We do not plan any more updates to 24.0.2, but if you have a reproducible case, please share the details and I'll see what can be done.  Otherwise, you may want to stick with 24 until 25.0.2 comes out.  The preprocessing fixes I put in for handling WxWidgets source should be in there.
Title: Re: Support for older versions
Post by: jporkkahtc on February 09, 2021, 06:57:28 pm
With a clean configuration you may loose any custom C/C++ Preprocessing settings you had.
Look in Tools > Options > Languages > Application Languages > C/C++ > C/C++ Preprocessing
Check this on Slick 24 and compare to Slick 25.

This macros are in your slickedit config, "usercpp.h"
Title: Re: Support for older versions
Post by: rjpontefract on February 09, 2021, 08:12:13 pm
Thanks for replying, it's appreciated.

My main problem is that the source code that is causing problems with tagging is proprietary and quite large so I can't share any examples from there.  I've been trying to recreate the issues with short examples that I can share, but while I have been successful for some of the issues, there are others that I just can't reproduce outside of the main code base. I'll keep trying and hopefully I'll get somewhere or, even better, 25.0.2 will improve things for me.
I know it must be nearly impossible to work out what's going on without an example and I wish there was a better way I could help.

@jporkkahtc, thanks for the suggestion, I've checked and made sure that my pre-processor definitions are the same for both versions. 
Title: Re: Support for older versions
Post by: jporkkahtc on February 09, 2021, 08:21:04 pm
In the past I've had a similar problem with sharing code.
I hacked together a python script to obfuscate the code.
I could share it, but it isn't exactly user friendly.
I've had to customize it for a couple of different cases.

The basic idea though is that it identifies a token, adds it to a hash table along with a random string (of the same length).
It then replaces all the tokens using this hash table.
Resulting text is obscured, but not totally random either.

This would be hard to make work on a large code base (and complex C/C++ code) -- works better for smaller samples.

Maybe there is a more polished tool to do the same available somewhere?
Title: Re: Support for older versions
Post by: rjpontefract on February 10, 2021, 04:07:54 am
I just wish I understood what was going on.  A simple example is a typedef like:

typedef int Tbool;
typedef long Ttimestamp;

typedef Tbool (Tsimple_callback)(const Ttimestamp timestamp);


Why is timestamp highlighted in red as an undefined symbol?  Shouldn't it be tagged as a parameter?  What's worse is that SE goes looking for symbols with the same name in the tag files and sometimes such parameters are resolved as some random symbol with the same name. 

Maybe the C parser needs an improvement to handle this case.
Title: Re: Support for older versions
Post by: Dennis on February 10, 2021, 03:38:52 pm
I tested that simple case with 24.0.2, 25.0.0, and 25.0.1.  Only 24.0.2 failed.  I did improve some of the parser's handling of function pointer declarations in version 25.0.0 and further improved it in 25.0.1, so that is no surprise.
Title: Re: Support for older versions
Post by: rjpontefract on February 10, 2021, 05:11:28 pm
Hi Dennis

That's not my experience, that example fails for me in both 24.0.2 and 25.0.1 so I wonder what I'm doing wrong.


Title: Re: Support for older versions
Post by: Dennis on February 10, 2021, 05:16:38 pm
From the SlickEdit command line, run the command "tag-dump-context" for that test file.  You'll get a bunch of debug output in the SlickEdit debug window, click there and hit Ctrl+X to cut it to clipboard, and paste it here.

The place the cursor on "timestamp" and run the command "tag-dump-locals" and do the same with those results.
Title: Re: Support for older versions
Post by: rjpontefract on February 10, 2021, 05:20:54 pm
Here's the output from tag-dump-context:

Code: [Select]
tag_dump_context: =======================================================
//=================================================================
// Browse info from CONTEXT[1]
//=================================================================
cm.member_name=Tbool
cm.class_name=
cm.type_name=typedef
cm.flags=no_comment
cm.file_name=
cm.line_no=1
cm.seekpos=0
cm.name_line_no=1
cm.name_seekpos=12
cm.scope_line_no=1
cm.scope_seekpos=18
cm.end_line_no=1
cm.end_seekpos=18
cm.language=c
cm.return_type=int
//=================================================================
// Browse info from CONTEXT[2]
//=================================================================
cm.member_name=Ttimestamp
cm.class_name=
cm.type_name=typedef
cm.flags=no_comment
cm.file_name=
cm.line_no=2
cm.seekpos=20
cm.name_line_no=2
cm.name_seekpos=33
cm.scope_line_no=2
cm.scope_seekpos=44
cm.end_line_no=2
cm.end_seekpos=44
cm.language=c
cm.return_type=long
//=================================================================
// Browse info from CONTEXT[3]
//=================================================================
cm.member_name=Tsimple_callback
cm.class_name=
cm.type_name=typedef
cm.flags=no_comment
cm.file_name=
cm.line_no=4
cm.seekpos=48
cm.name_line_no=4
cm.name_seekpos=63
cm.scope_line_no=4
cm.scope_seekpos=110
cm.end_line_no=4
cm.end_seekpos=110
cm.language=c
cm.return_type=Tbool(Tsimple_callback)()
cm.arguments=const Ttimestamp timestamp

And from tag-dump-locals:
Code: [Select]
tag_dump_locals: =======================================================
Title: Re: Support for older versions
Post by: Dennis on February 10, 2021, 06:20:49 pm
OK, retrying, and I can reproduce the issue when I start in a default configuration.  My previous tests were in a configuration where I had a tag file that must have defined a global var named timestamp, my bad.  I will check and see if I can do something about this one for 25.0.2.
Title: Re: Support for older versions
Post by: rjpontefract on February 10, 2021, 06:22:48 pm
Thanks Dennis, it's appreciated.
Title: Re: Support for older versions
Post by: Dennis on February 10, 2021, 08:29:04 pm
This specific case will be fixed in 25.0.2.  Keep them coming if you find more like this.
Title: Re: Support for older versions
Post by: Dennis on February 10, 2021, 09:26:09 pm
@jporkkahtc:  Here is your algorithm codified in Slick-C.  It only works on a single file.  I'll leave it as a student exercise to apply it to multiple files (the only real trick would be to pass along the hash table for each file), and maybe have a progress GUI.  Oh, yeah, and ironically, it completely botches Python.
Title: Re: Support for older versions
Post by: jporkkahtc on February 10, 2021, 10:54:15 pm
Nice!
My python script isn't language sensitive, so this is much better.

WRT hashing: If you have a 1-way hash available in script (like md5, sha, etc), then you don't need to share a hash table between files - it can be calculated on the fly.


Unfortunately, for this to work in in general, especially for C/C++, you would want to not obfuscate any library symbols either (unless you also obfuscate the entire library-  like windows.h).
But, it is good for obfuscating code to use as repro cases sending to Slickedit support.