Recent Posts

Pages: [1] 2 3 ... 10
SlickEdit® / Re: v22 memory leak?
« Last post by Dennis on Today at 12:43:14 am »
OK.  I've spent about a half week on this.  Good news and bad news.

1 - Good news)  I've identified, found and fixed a few memory leaks.  These fixes will be incorporated into the next release.

2 - Bad news - or Jedi mind trick)  These are not the leaks you are looking for.  It is unlikely that what I found is what brought our SlickEdit memory footprint up to 2G.  They were small leaks.

3 - resizing and drawing)  Not leaks.  We have a fairly significant line drawing cache.  You are merely filling up the cache.  The test project has a bit over 6000 lines of code, the cache holds 20000 lines before it fills and purges.  This is just using memory, not leaking it.

4 - delete and undo)  I did not observe a significant memory increase here, and the memory leak tracking software did not identify anything as leaked as a result of this test.

5 - searching) same story, yes, first time use of a feature can uptick memory somewhat, when the form is loaded the first time, etc, but no definitive leaks identified.

6 - segmenting)  We have a our own memory allocator for speed.  Like any allocator, it can fall victim to some segmenting depending on usage patterns.  Some of the memory growth you see could be segmenting, well, it will appear as growth initially, but once there is enough memory in use, the growth will level off entirely.  Note, this can happen with the system malloc() too, so there is nothing particularly wrong with our allocator, it's just faster than malloc.

7 - scrolling) see (3)

8 - caches) we have a lot of caches.  Tagging especially has a lot of caching going on.  It is one of the few things that gives you some limited control over the caches, yet, even there, there are some caches that will just grow as needed.  You can't make a setting for everything.  I have suggested ways to cut back the tagging cache earlier in this thread.

9 - your config)  You were loading a mini-map tool that I did not have access to.  Hence, this did not factor into any of my testing.

Hope this helps.  I'm still digging around for leaks, as I work.  Maybe something will surface eventually.
General Programming / Re: C++ build system for Linux
« Last post by ebbe on June 18, 2018, 02:06:48 pm »
We use CMake ( around here. Fairly steep learning curve but nowhere near as bad as automake  :)
General Programming / C++ build system for Linux
« Last post by Graeme on June 18, 2018, 09:56:28 am »
Can anyone recommend a build system for a C++ project on Linux.  We'll be running CentOS Linux inside vmware on Windows 7 and building for embedded Linux on an ARM target.  For testing, we want to build for a CentOS target too.  It doesn't have to be free and it can't be slickedit as no-one else uses slickedit here.
SlickEdit® / Re: project-build stop working.
« Last post by Mike_1 on June 18, 2018, 02:36:19 am »
Thank you all for quick response.
The company uses McAfee tools, I will ask IT guys to solve this problem.
The tag file associated with that ghost entry no longer exists because the 1st time I selected the tag in the list and then clicked “remove tage file” button, it deleted the tag file from disk too and that is when the tag entry became greyed-out with a red dot and became unremoveable from the tag window list
SlickEdit® / Re: Window ordering with CTRL + Tab
« Last post by davehohl on June 15, 2018, 09:16:22 pm »
MrPolite, you might want to reward stzari with a thumbs-up!
If the file does not exist on disk, you will not be prompted if you want to delete it.  Does this file exist on disk?
I did select the tag file and then clicked the "remove tag file" button then clicked yes to the next prompt but the ghost still remains.  And I noticed that removing tag files from that particular folder also automatically deleted it from disk.  I thought SE would confirm in a seperate prompt if I wanted to also remove the tag file from disk.  See attached screen shot.
That is a good point.  I'm going to make changes to this for the next release.  C/C++ Tag Files will be put in the tree directly after C/C++ Compiler Configuration Tag Files.  That will make them easier to find.

I will do the same for other languages that have compiler configuration tag files (currently only Java).  This will have the additional benefit of moving the two most used languages to the top of the list.  See attached image with names redacted to protect the innocent.

If the current file is C/C++, the category selected in Tools > Tag Files... will be:

1) If the file is in your workspace, the workspace tag file.
2) If you have C/C++ Compiler Configuration Tag Files, the first C/C++ Compiler Tag File
3) If you have C/C++ Tag Files, the first C/C++ Tag File
4) If you do not have C/C++ Tag Files yet, an empty category for C/C++ Tag Files.

The "ghost" tag file that you appear to have is a tag file that you have configured, but it no longer exists on disk, or can not be opened.  You should be able to select it and click on "Remove Tag File" to get rid of it.

I also experienced the same tag file problems described by olegkagan when I went from SE2015 to SE2017.  I think the problem lies in the differences in tag file folder names in the tag file window in older versions of SE like 2015 when compared to SE2017.  In SE2015, I always added my C/C++ tag files in the "C/C++ Tag Files" folder in the tag file option window.  There is no such folder in SE2017 (initially) but, in SE2017 there is a very similarly name folder "C/C++ Compiler Configuration Tag Files". When I tried adding my tag files I had created in SE2015 to that "C/C++ Compiler Configuration Tag Files" folder, I experience the problems described by olegkagan.  I only did so because I had thought it was the same folder as SE2015. I initially did not notice the slight name difference, which was caused by the lack of the "C/C++ Tag Files" folder in SE2017.  I tried Dan's suggestion of adding my tag files to the "Workspace Auto-Updated Tag Files" folder and that worked fine. No more odd behavior.  After having added tag files to the "C/C++ Compiler Configuration Tag Files" folder, then the "C/C++ Tag Files" folder will appear and the tag file I added to the "C/C++ Compiler Configuration Tag Files" folder will get automatically moved to the instantly appeared  "C/C++ Tag Files" folder. However, since accidentally adding my tag file to the "C/C++ Compiler Configuration Tag Files" folder, I have found that removing the tag file from the "C/C++ Tag Files" that automatically appeared results in a tag file "ghost" always being left behind that I can't get rid of (tag file name with red dot next to it). See attached screen shot.  I hope I'm describing this in a way that makes sense. I can add more screen shots if you like.
Pages: [1] 2 3 ... 10