Posted by: Dennis
« on: April 17, 2013, 08:51:28 PM »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.
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:
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.
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.