Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
SlickEdit® / Re: v22 memory leak?
« Last post by IkerAriz on June 19, 2018, 01:10:23 pm »
Thanks for the follow up Dennis.

Any way to collect additional memory info during my tests? Eg, are there any diagnostic commands that can print the SE cache sizes and and/or allocator stats? (perhaps via a custom build?)

Thanks again,
Iker

P.S. BTW, the minimap command just toggles the zoom (I didn't use it during my tests). Here's the code:

Code: [Select]
int minimap_on = 0;
_command void minimap_toggle () name_info(',') {
   if (minimap_on) {
       wfont_zoom('9');
       minimap_on = 0;
   }
   else {
      wfont_zoom('4');
      minimap_on = 1;
   }
}

22
SlickEdit® / Re: v22 memory leak?
« Last post by Dennis on June 19, 2018, 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.
23
General Programming / Re: C++ build system for Linux
« Last post by ebbe on June 18, 2018, 02:06:48 pm »
We use CMake (https://cmake.org/) around here. Fairly steep learning curve but nowhere near as bad as automake  :)
24
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.
25
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.
26
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
27
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!
28
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?
29
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.
30
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.

Pages: 1 2 [3] 4 5 ... 10