Cannot save slickedit configuration vslick.sta, error writing file

[MindprisM]

SlickEdit 2012 (v17.0.3.0 64-bit)
Build Date: November 27, 2012
Emulation: CUA

OS: Windows 7 x64
OS Version: 6.01.7601  Service Pack 1
Memory: 23% Load, 7544MB/32718MB Physical, 8183MB/65435MB Page File, 278MB/8388607MB Virtual
Shell Info: C:\Windows\system32\cmd.exe /q
Screen Size: 1920 x 1080, 1920 x 1080

Project Type: (Other)
Language: .e (Slick-C)

Installation Directory: C:\se17\ (non-removable drive,NTFS,55356MB free)
Configuration Directory: C:\Users\Administrator\Documents\My SlickEdit Config\17.0.3\ (non-removable drive,NTFS,55356MB free)

Hotfixes:
C:\Users\Administrator\Documents\My SlickEdit Config\17.0.3\hotfixes\hotfix_se1703_3_cumulative.zip (Revision: 3)
=========================================
I have read the other posts about receiving this save configuration error. I am not experiencing this error due to a previous crash or ghost instances of vs.exe locking the file. I am currently migrating my macros from SE 2007 bit by bit and the error is becoming more frequent, and now it appears I am 'stuck' and have hit some kind of ceiling in the vslick.sta file.

I am getting errors when compiling and loading a macro as well as the shutdown error when I DO successfully compile and load.

The current size of my vslick.sta is 13.7 MB. So far I have migrated and loaded 115 of my *.e files, with a total compiled size of 3.7 MB. These average at about 30 KB each, with the largest being 82 KB.

I have hit this type of error before in SlickEdit 2007, but it was intermittent enough to work around. This doesn't appear to be the case now.

Any strategies, workarounds, suggestions or fixes would be much appreciated.

Does anyone out there have similar experience, or is anyone successful in loading more user macros than this?

Ive noticed the macro library that is shipped has 376 items with a compiled size of 18.6 MB. If I am truly on my own on this, do you think the strategy is to restructure my library to go for fewer files?

It seems strange to get an 'error writing to file' if the issue is internal, which I recall different behavior in 2007 -- the next boot would just launch Slick with the whole interface broken and I would have to dig up a good vslick.sta file from daily backups to get back on the road.

[Dennis]

What specific errors are you seeing when you try to load the macros?

Within macros, there are string space limits.  I'm guessing by the size of the macros you are loading, that you must be stuffing a lot of strings in them.  Have you considered creating an XML configuration file for the string data?

Is it possible for you to send your group of macros into support so that we could try to reproduce the problem you are experiencing?

[MindprisM]

Thank you for your assistance Dennis.
Currently I have gone to full-frontal assault mode on this problem - which means restructuring my library so that it is truly layered, removing circular dependencies between modules, and building a bit of a test harness for loading and unloading.

This is what I am discovering and certain suspicions I have.

First, my library is not particularly stringy. Meaning, I am not using code when I should be using aliases or something. Nor is the library a bunch of haphazard flat macro recordings. Put it this way, it would be a real pain to put what strings I am using (other than a few paths that have #defines) into an external data file.

I am at level 15 in the layers, so a lot of my library is wrappers upon utils upon helpers, etc. It is at these higher levels that I seem to hit the wall (thus far when the lower levels are loaded). What I am experiencing is a stubborness in the higher levels to load/compile without an app crash, but a lower level one usually does not have a problem with a recompile/reload.

Soon I will be at the point where I can start out with a new vslick.sta and try to load things from the top down instead of bottom up to see if that makes a difference.

Naturally I am having suspicions of whether vslick.sta is getting corrupted, and am wondering about the #import mechanism -- which I will do some loads bypassing that to see what happens eventually.


The basic behavior is this -- I can get an app crash on reload/recompile of a module even when it is low in the layers, but being low seems to make that less likely. But, even if it does recompile/reload -- I can still get the 'error writing to vslick.sta' on app exit (simply for reloading that one module).
I get no formal code errors. On each module I am running strict2 and strictprotos ON, in that order. I have my own global include header which I will attach to this post.

I was thinking I could give you my current vslick.sta and the code modules I am attempting to compile so that you could throw it on the debugger. But I am also willing to give you the whole lib, once I get it packaged a bit more. Right now I will attach my global include, a couple of the modules I am having trouble with, and a couple of the lower and mid level modules to show I am not being wierd or stringy. I will also attach my vslick.sta (if its not too big for the forum).

I have some questions about vslick.sta. Since the app locks it, I assume it can 'carry forward' corruption (ie it is not written entirely anew on exit, right?). Am I even right in suspecting corruption of vslick.sta when, say, a module compile causes an app crash -- how much is vslick.sta in the game on that one?

Out of curiousity, is this string limitation per module or global? For instance, I have only ONE main popup menu in my lib, which is hard-coded literal strings and could be seen as quite wordy with the tip-text. I will attach it, but is that something to be concerned about?

What would be the proper course in submitting this package and problem to your techs, do I take out a support ticket, do I get to say 'Dennis said to fix it' haha. Tell me what you want.

Attached is rar containing example macros, vslick.sta and README.txt

[Dennis]

I tried to reproduce the crash with my 17.0.3 editor and I had no problems with it.  I also tried loading all of the modules (I had to make several modifications because of missing modules (__file.e, __str.e, __vsvpj.e, etc.), but could not reproduce any problems.

There are a few things I noticed that could be problematic.

1) Many of the modules have a "definit()" which calls load_modules() on itself.  In the state that you sent me, load_modules() is disabled, but generally, doing a load() within a defload() or a definit() is asking for trouble, especially if you are loading the same module that you *already* are running.  I guess you are trying to trick slick into dynamically re-loading modules when they change on disk, but I think it is asking for trouble.

2) Almost all of the .sh files are unneeded.  You can get by fine without them and just use #import.  In some cases, you have signature mis-matches between the ".sh" and the same function in the ".e" file (with respect to default arguments).  I ran into a few modules that would not compile on account of that.  A #import merely parses the file being imported and pulls in declarations that are imported by that module.  It's like #including a header file without having to write the header file.  A #import does NOT cause the imported module to be loaded.

3) It helps to make better use of "static" to keep the number of functions exported by a module down to the bare minimum.

4) You might want to make use of pass-by-reference more often, especially for functions that take arrays as arguments or very large strings.
   

Code: [Select]

void array_by_reference(_str (&a)[]);
5) We have added a new pragma (pedantic).  All of the SlickEdit macros use that now, and it is very much worth it in my opinion.  You might also want to take advantage of some of Slick-C's newer type inference features:
   

Code: [Select]

a := "Yes, I am a string";
6) Slick-C also has namespaces now.  That might be very useful to you to make sure that your functions are not tromping over existing SlickEdit function or command names.

============
Per your questions:

When you get an app crash, is it vstw.exe crashing or vs.exe ?  When you do a load module, the state file is not written to disk immediately, so there should be no problems there.  The next time you get a crash, you could send a dump file into support, or post a mini-dump here, though, those are usually not quite as useful for isolating the problem.

The string limitation is primarily per-module, and if you hit it, you will know it when you try to load the file (because the macro compiler will report an error).  After looking over your code, I don't think the issue is the strings at this point.

Hope this is helpful.  Look into that definit() issue first, and then I'd say turn on the pedantic pragma.