SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Slick-C® Macro Programming => Topic started by: mikesart on April 12, 2008, 01:23:43 AM
-
I work on several projects where folks are adding/removing files via source control and I finally got around to trying to automate the project properties files dialog. The macro adds files from on a list of directories based on the project names. Not sure if anyone else will find it useful, but I'm sticking it up here just in case. (It's vaguely related to this thread but all handled via SlickEdit Macros: http://community.slickedit.com/index.php?topic=1616.0). Should also be quite a bit faster as it only adds or removes modified files.
To use, I modify the dirlist, filespec, exclude list, hit F12 (reload macro), then type in ssync and am done. Normally I'm not modifying the dir spec so I'm just typing ssync.
-Mike
struct DIRINFO
{
_str opts;
_str dir;
_str filespec;
};
_command void ssync() name_info(','VSARG2_REQUIRES_PROJECT_SUPPORT)
{
int i;
DIRINFO dir_list[];
_str exclude_list = "";
_str file_spec_default_list = "*.c;*.cc;*.cpp;*.cp;*.cxx;*.c++;*.h;*.hh;*.hpp;*.hxx;*.inl;*.e;*.sh;*.bat;*.cmd;*.php";
dir_list._makeempty();
// Always add main SE macros and build files.
dinfo_add(dir_list, "-t", "c:/slm/slickedit2008");
dinfo_add(dir_list, "+t", "c:/dev/smac/bin");
_str projName = strip_filename(_project_name, 'PE');
switch(projName)
{
case "SlickC":
dinfo_add(dir_list, "+t", "c:/slm/slickedit2008");
break;
case "pixo9lrb":
dinfo_add(dir_list, "+t", "c:/dev/smac/pixo9");
dinfo_add(dir_list, "+t", "c:/dev/smac/dx9cap");
dinfo_add(dir_list, "-t", "c:/Program Files (x86)/Microsoft DirectX SDK (November 2007)/Include", "d3d10*.h");
dinfo_add(dir_list, "-t", "c:/Program Files (x86)/Microsoft DirectX SDK (November 2007)/Include", "d3dx10*.inl");
dinfo_add(dir_list, "-t", "c:/Program Files (x86)/Microsoft DirectX SDK (November 2007)/Include", "DXGIType.h");
exclude_list = "c:/dev/smac/pixo9/bin/compiler_0.5/";
break;
case "pixo9xlrb":
dinfo_add(dir_list, "+t", "c:/dev/smac/pixo9x");
dinfo_add(dir_list, "+t", "c:/dev/smac/dx9cap");
dinfo_add(dir_list, "-t", "c:/Program Files (x86)/Microsoft DirectX SDK (November 2007)/Include", "d3d10*.h");
dinfo_add(dir_list, "-t", "c:/Program Files (x86)/Microsoft DirectX SDK (November 2007)/Include", "d3dx10*.inl");
dinfo_add(dir_list, "-t", "c:/Program Files (x86)/Microsoft DirectX SDK (November 2007)/Include", "DXGIType.h");
exclude_list = "c:/dev/smac/pixo9x/bin/compiler_0.5/";
break;
case "d3dref10_1":
dinfo_add(dir_list, "+t", "c:/dev/smac/d3dref10_1");
break;
case "Alpine":
dinfo_add(dir_list, "+t", "c:/slm/alpine/alpine-src");
break;
default:
_str msg = "ssync(mikesart.e): No dir_list specified for " projName ".";
_message_box(msg, "", MB_OK | MB_ICONEXCLAMATION);
return;
}
// Get list of current project files.
int projectfiles_list:[];
ssync_getprojectfilelist(_project_name, projectfiles_list);
// Create our temporary view for insert_file_list().
int filelist_view_id;
int orig_view_id = _create_temp_view(filelist_view_id);
// Split out default file spec list into an array.
_str file_specs[];
split(file_spec_default_list, ';', file_specs);
// Do an insert_file_list() for every dir_list + file_spec entry.
for(i = 0; i < dir_list._length(); i++)
{
int j;
DIRINFO dirInfo = dir_list[i];
if(dirInfo.filespec != "")
{
_str cmd = dirInfo.opts " " maybe_quote_filename(dirInfo.dir "/" dirInfo.filespec);
insert_file_list("-v +a +p " cmd);
}
else
{
for(j = 0; j < file_specs._length(); j++)
{
_str cmd = dirInfo.opts " " maybe_quote_filename(dirInfo.dir "/" file_specs[j]);
insert_file_list("-v +a +p " cmd);
}
}
}
// Go through and kill any directories or files that match the exclude list.
if(exclude_list != "")
{
_str excludes[];
split(exclude_list, ";", excludes);
for(i = 0; i < excludes._length(); i++)
{
_str exclude_str = stranslate(excludes[i], '\', '/');
top();
up();
while(!search('^[ \t]+' _escape_re_chars(exclude_str), '@r' _fpos_case))
{
delete_line();
}
}
}
// Remove duplicate files.
int file_list_hash:[];
file_list_hash._makeempty();
top();
up();
while(!down())
{
_str filename;
get_line(filename);
filename = strip(filename, 'B');
if(projectfiles_list._indexin(filename))
{
// If this file is current in the project, set the projectfiles_list
// entry to 1 (so we don't remove it from the project) and then
// remove this entry from the temp buffer add list.
projectfiles_list:[filename] = 1;
delete_line();
up();
}
else if(file_list_hash._indexin(filename) &&
file_list_hash:[filename] != p_line)
{
// This is a new file and it's a duplicate so wack it.
delete_line();
up();
}
else
{
// New file: record the line number we first saw it at.
file_list_hash:[filename] = p_line;
}
}
// Create a list of files to remove from the project. Every hash entry
// in projectfiles_list[] that is a 0 should be removed.
int value;
_str filename;
_str filelist_remove = "";
int files_removed = 0;
foreach(filename => value in projectfiles_list)
{
if(value == 0)
{
files_removed++;
filelist_remove = filelist_remove " " maybe_quote_filename(filename);
}
}
if(filelist_remove != "")
{
filelist_remove = strip(filelist_remove, 'B');
int status = project_remove_filelist(_project_name, filelist_remove);
if(status != 0)
{
_str msg = "Warning: Unable to remove files from project. " :+ get_message(status);
_message_box(msg, "", MB_OK | MB_ICONEXCLAMATION);
}
}
// Add the new list of files to our project.
if(file_list_hash._length())
{
tag_add_viewlist(_GetWorkspaceTagsFilename(), filelist_view_id);
}
int project_filecount = projectfiles_list._length() - files_removed + file_list_hash._length();
message("Ssync completed. files_added:" file_list_hash._length() :+
" files_removed:" files_removed :+
" total_files:" project_filecount);
activate_window(orig_view_id);
}
static void dinfo_add(DIRINFO (&dir_list)[], _str opts, _str dir, _str filespec = "")
{
int len = dir_list._length();
dir_list[len].opts = opts;
dir_list[len].dir = dir;
dir_list[len].filespec = filespec;
}
//=========================================================================
// ssync_getprojectfilelist(): Get list of project files.
//=========================================================================
static void ssync_getprojectfilelist(_str ProjectName, int (&projectfiles_list):[])
{
_str filelist = "";
int file_view_id = 0;
int orig_view_id = p_window_id;
GetProjectFiles(ProjectName, file_view_id);
p_window_id = file_view_id;
top();
up();
while(!down())
{
_str filename;
get_line(filename);
filename = strip(filename, 'B');
if(filename != "")
{
projectfiles_list:[filename] = 0;
}
}
p_window_id = orig_view_id;
_delete_temp_view(file_view_id);
}
-
Oh, one more note. OSs that use forward slashes may need to modify the stranslate line:
_str exclude_str = stranslate(excludes[i], '\', '/');
Haven't tested it anywhere but Windows, but I believe that's the only part which should potentially be an issue.
-
Nice, thanks for sharing this. I have similar needs, and you've just saved me many hours, now I don't need to write that myself! 8) HP++
-
Ah, thanks Chrisant. You've had a number of great & useful posts so it'd be cool if I accidentally did something that saved you some time. :)
I ran into a few questions while doing this that I was hoping some folks could shed some light on.
In project.e, insert_file_list() is being used with a few options that I couldn't find documentation on. +W (multiple file specs?), +o (OptimizeStats?), and +L. The +W could be useful for this macro so I'm wondering if these are not-ready-for-primetime deliberately-not-documented options or has it just not happened yet?
While writing _create_temp_view(), I found it extremely helpful to debug by using the "edit('+bi ' p_buf_id);" command to show the temporary buffer contents. Much better than the vsapi getline() + say() method I started with. Example below. I'm wondering if this is how other folks do this type of thing or is there a better way?
_command void blah() name_info(',')
{
int filelist_view_id;
int orig_view_id = _create_temp_view(filelist_view_id);
insert_file_list("c:/*.*");
edit('+bi ' p_buf_id);
activate_window(orig_view_id);
_delete_temp_view(filelist_view_id);
}
While debugging the edit() thing above, 'list_buffers -h' became my new friend. While tracking down my leaked Untitled buffers, it appears that the message list window has a couple of Untitled buffers open with just '(show all)' or '' as the content. Just wondering what the recommended behavior on this type of thing is? (Slickedit v13.0.0.0)
And this is more an observation that I couldn't find documented anywhere but found by the extremely scientific method of banging on my keyboard; It appears that ctrl+k clears the vsapi.dll window. (This would be MS Windows only I believe). This made say() a lot more useful to me.
Thanks!
-
Ah! I hadn't found list_buffers -h yet, that's great.
That allowed me to confirm that vc.e leaks a buffer every time it captures output from source control commands.
Will post a separate thread on that, though (and report to support, of course).
-
Hi, Dennis told some vsapi secrets here (http://community.slickedit.com/index.php?topic=3003.msg12466#msg12466).
@mikesart: Good idea to 'edit' the temp buffer to check the contents and thanks for this ingenious hint !
HS2
-
Thanks, mikesart, for that macro. I'm using it now, with a number of tweaks (attached).
Most notable:
- Fixed case sensitivity in the hash array; systems with case insensitive filenames needed a tweak.
- Converted the project dir list definitions to be a data table (array) rather than code; this will help if/when this macro is enhanced to allow runtime user configuration of the project dir lists.
- Expanded the default set of file extensions, and added (expandable) shorthand notation for multiple default sets of file extensions (<sources>, <headers>, <slick>, etc).
- All dir list entries support file spec lists (rather than requiring a separate dir list entry per explicit wildcard).
- Expands env vars in directories.
- Added some performance notes; will follow up on them later.
Your project dir lists should all be intact inside the #define MIKESART sections. Mine are in the #define CHRISANT section. Other users can replace those with their own list of project dir list definitions. Hopefully I haven't broken anything for platforms with case-sensitive file systems. :-[
@SlickTeam: The project support in SlickEdit is great. However, setting up the file list for a project could be improved quite a bit (I gather that's already on your wish list). Currently we have to choose between (1) entering lots of individual wildcard entries (and exclusions, oh my) and getting poor performance for large projects (due to scanning the file system once per session), or (2) manually updating the project file list (have to know/remember the paths and long lists of extensions, and exclusions, and iterate through them manually) but getting good performance for large projects (loads a cached file list rather than scanning the file system). This macro is a simplistic compromise between (1) and (2), but the capability in this macro (or something better :)) should ideally be built into SlickEdit. This macro still has a drawback in that it runs in the foreground, so for large projects it is still expensive to run, but at least we can control when it runs. I'd be happy to discuss more about project definitions for large projects (20k+ files, 10-30 wildcards, exclusions, supporting tag files, etc) further in the forums or in private emails if/when you want to enhance the project file list support (you have my email address). In the meantime, this macro is pretty good workaround (albeit with part of the project definition living outside the actual project file), so it's not like we're dying without project enhancements. ;)
Thanks,
Chris
-
Nice piece of a script!
I tried to use it, but I get error "Expecting '}'" when I try to load the macro by pressing F12. The cursor is moved just before 'h' in foreach:
foreach(filename => value in projectfiles_list)
I suspect that its the directory config table, but I do not see any error in it:
static PROJINFO projects[] =
{
{
'SlickEdit',
{
{ '+t', 'c:\mydir' }
}
}
};
Any idea on what this means?
I'm using SlickEdit Version 12.0.3.0 in Windows XP.
-
Hmm, I tried to find documentation on the foreach statement used in this script, but I did not find such!
Is it supported in Slick-C (any more)?
-
The foreach statement is not supported in 12.0.3, but was added in SlickEdit 2008 (v13) along with several more Slick-C enhancements. Here is the documentation on the statement:
The foreach statement works with arrays, hash tables, strings (same as Bourne shell), structs (iterates over the fields of the struct), and classes (if instance of sc.lang.llterable, otherwise like structs). The syntax of foreach is:
foreach ( [ k => ] v in a ) {
statements;
}
Example:
void printStats(int (&statistics):[])
{
foreach (auto name => auto count in statistics) {
say("testForeach: "name"="count);
}
int i,j=0;
foreach (i in range(10, 20, 2)) {
say("printStats: sequence["j++"]="i);
}
}
There is an optional key which is useful for hash tables. The value can be omitted (key=> . in ht):
foreach( key => value in ht ) {
statements;
}
Both value and index can be auto-declared using the auto keyword. If value is auto-declared, its type will be inferred from the type of the collection. The implementation uses _nextel().
These docs will be in the upcoming 13.0.1 release.
-
Thanks Lisa. I was not aware of that "foreach" statement situation.
Seems that the script has some problems with some directories and/or file names.
I have some quite long directory paths, and the script does not seem to cope with these. Some of the leaf directories are shown as files(!), and some of the files are shown in folders "j:\..\.." and "j:\macro\" (neither of which do not actually exist).
Does the script work OK for others?
PS: I rewrote the foreach loop to a normal for-loop, since I do not have the new version of Slickedit:
for (filename._makeempty();;) {
projectfiles_list._nextel(filename);
if (filename._isempty()) break;
if(projectfiles_list:[filename] == 0)
{
files_removed++;
//$ PERF: (chrisant) String growth has exponential cost here unless
// Slick-C is using geometric growth under the covers. However, the
// number of files removed should typically be small, so this may be
// acceptable.
//say('remove: "'filename'"');
filelist_remove = filelist_remove " " maybe_quote_filename(filename);
}
}
-
Could you give some specific examples, Kung?
And can you show your table of paths?
The macro is working for a 20,000+ file workspace that I have, with directories up to about 180 characters deep.
-
Sure, I tried with a simple test setup, and the updated script where the "foreach" is replaced with "for" equivalent (see attachment).
I attached the slickedit project file hierarchy view pictures after first update (first ssync call), and after second update (without any changes to the "project").
As you can see, the first update works OK. But when I make the second update, it all goes terribly wrong. E.g. the "level_6_qwertyuiop" directory is placed to the root, and the level 5 and 6 file names are wrong.
Please tell me it's the modifications I made to the script - I'm not much of a Slick-C coder ;D
Does the script version I made work for you?
-
I cannot reproduce that on Slick 13.0.0 r29 using your copy of the macro.
First update picks up the files properly.
Second update results in no changes.
I don't have Slick 12.0.3 handy right now so I can't take a look at the moment.
I've attached my latest version of the macro and added an $Id$ tag at the top (now at revision #3).
- Added support for relative paths.
- Added optional debug output.
- Uses for() instead of foreach() for compatibility.
I plan to move the data table into a separate .txt file (or maybe .xml file), so that it becomes possible to just load a new version of the macro without needing to copy/paste your project definitions.
If someone would like to help debug what's going wrong on Slick 12.0.3 that would be nice. Or I will probably get around to it in the next couple of weeks (day job very busy, don't have that kind of time to poke around debugging mysterious stuff at the moment, sorry :().
-
Thanks chrisant, I think this helps to point out the root cause.
Seems that there must be something wrong with the SlickEdit version 12.0.3, or my setup of it (which should be somewhat standard though).
I just noticed that there's a hotfix pack available for SlickEdit 12.0.3, which I have not yet tried to install. I'll try that monday when I get back to work..
Thanks for updating the script to at least compile also with 12.0.3.
And it sounds like a nice idea that the configuration would be moved to a separate file.
-
I installed the latest hotfixes for 12.0.3.0, but that did not fix the problem :-\
I also tried your updated version, and it did not have any effect either (as expected, since there's no specific fixes for this problem).
BTW: There still seems to be the same foreach loop - perhaps I did not get the latest version?
So help is still needed. I'd really like to get this macro to work also with Slickedit 12.0.3.0 version.
-
Mumble.
Attached correct one this time (#4 now).
-
I can't repro the path problem using the repro steps you provided, but just now I ran into a repro scenario of my own. I may find time tomorrow to track down what's going on.
-
Okay. Did you try with 12.0.3.0 or the 2008 version?
-
With 12.0.3 r29 and with 3.0.0 rSomethingOrOther and with 3.0.1 r3 -- all no repro using your steps (I replicated the directory tree as given in the first screenshot).
The issue I ran into yesterday was that if you have a trailing file separator (forward or backward slash) at the end of the directory name then it gets quite confused and does weird things to the directory tree structure a little bit similar to the second screen shot you posted. I fixed that issue; fix is attached.
-
Thanks, I hope that works ;D
I'll be trying the new version next week when I get back to work..
-
Sorry to say, but this did not help in my setup. I did not have the file separator (backspace, since I'm in Windows) at the end of my project directory.
I still can reproduce this problem in my setup.
If this helps, I attached the exact file here that I used this time (I only added the project spec).
I don't know what to do now. Could I easily try to debug the script somehow? I'm not really that familiar with the Slicedit macroes..
-
I tried with your updated project spec, still no repro (see attached png's to verify the directory structure and completion message). Each time it gives the same completion message.
You can try "ssync 1" to enable some debugging output, maybe capture the debugging output and paste it here (Ctrl+C in the debug output window copies the entire contents to the clipboard).
Depending on what it shows, perhaps I can enhance certain debugging outputs to help narrow down where things are going awry.
-
I tried the debug option, but it just says what's expected: the files that were erroneously removed are reported as removed, and then added erroneously.
I'd have attached a log file here, but the pop-up debug window did not allow copying of the text :(
Anyway, I'm on vacation soon, and debugging can be continued about in a month..
Thanks for the good support, again! I hope we'll get this thing working for me too some day..
-
I noticed that the path / file name strings are cut starting on 80 characters length.
This got me thinking that I have automatic line length wrap activated just on that length.
Now, when I tried the script without the automatic line length wrap, it started to work OK!
Here's where the line length can be switched:
Tools->Options->File Options->Wrap line length
I think if you put "80" there, you should be able to reproduce the problem.
Now the question is that does the script use temporary file of some sort when comparing the existing directory / file hierarchy to the current one?
If it does, could that be changed somehow, so that using automatic line length wrap would not cause problems?
-
Ah! That's some nice troubleshooting work. I didn't originally write the macro, I just seem to have de facto taken it over (sorry mikesart!). I believe it does use a temporary buffer, and probably somehow it is accidentally picking up line wrapping settings. I hope that line wrapping in general does not typically interfere with hidden buffers (assuming this buffer is hidden, which it might not be), as that could make a lot of macros fragile.
I'll take a look...
-
Wait a minute. It looks like you're setting the global "forcibly wrap long lines" setting. On my installation it is at the default setting of 4000.
Shouldn't you be using Soft Wrap? Or normal Word Wrap? Why are you using the "Wrap line length" setting?
-
I didn't originally write the macro, I just seem to have de facto taken it over (sorry mikesart!).
Don't be sorry - I apologize for not being more help here but I'm kind of slammed right now getting a milestone done. So thank you for taking over!
I'm rather interested in hearing how the SE folks handle this option as well cause I think this temp buffer thing I used is rather common. At least I initially got it from the Hurst's book...
Thanks again Chrisant!
-
@mikesart: Cool, keep your eyes on the light at the end of the tunnel! (It's hardly ever a train).
@Kung Foo: Here is what's going on:
I think you are probably using the "Wrap line length" option as an easy way to enforce soft wrapping for all file types. My understanding is that SlickEdit expects you to use the per-language Soft Wrap settings. From poking around in the SlickEdit Help and in the built in SlickEdit macros (macros\*.e), I think you might find a variety of weird behaviors from using "Wrap line length" the way you're using it.
What is happening is that sync_project_with_scm uses insert_file_list() to add a list of matching files to the temp buffer. I've added a call to fileman_mode() in sync_project_with_scm before using insert_file_list(), and among other things that successfully disables your "Wrap line length" setting in the temp buffer. But it appears that most insert_file_list() calls in the built in SlickEdit macros do not call fileman_mode(). So you might see a variety of subtle and weird behaviors from using "Wrap line length" like that; I don't know, I'm only guessing.
Anyway, the attached version should work for you.
-
Thanks fellows! The new version works just like wanted!
Now that I know about this "hidden feature of SlickEdit", I think I do not dare using the global line wrap feature any more. From now on, I believe I'll stick on using other line wrap mechanisms.
BTW: Some dangerous feature this global line wrap I must say. Nobody can be automatically expected to know about this when writing scripts - IMHO this is quite a trap.
And thanks again for the persistent and quick support!
-
Update:
- New "ssync -a" flag updates all projects in the workspace (loops through them one at a time, updating each one). Using "ssync" by itself still just updates the current project.
- Moved the project description table to a separate file (ssync.ini).
- Included some sample ini files illustrating how to set up your ssync.ini file.
-
Thanks crisant. This is great ;D
I copied the new version and created my own ssync.ini file.
Now I have the problem that the default file extension of the "dir" keyword does not work. Did I understand correctly that it should cover all the files of the given folder if I do not put a specific extension part to the line?
I have lines like this:
dir=+"J:\path\"
This kind of lines do not collect any files in my setup :o
But if I add some extensions manually like this, the ssync macro does collect the files correctly:
dir=+"J:\path\", "*.c;*.cpp;*.h"
Perhaps I do something wrong, or is there some bug/feature in the new version that causes this?
BTW: Here's an improvement idea. There could be a way to add new wildcard definitions in the ssunc.ini file. So that something like this could be added:
[ssync-options]
wildcard_list="headers","'*.h;*.hh;*.hpp;*.hxx;*.inl;Make*"
There are usually a lot of file extensions to cover, so multiple lines should be supported. I'm not sure about how to split this to support multiple lines though.
PS: Thanks again for this great little prog!
-
I copied the new version and created my own ssync.ini file.
Now I have the problem that the default file extension of the "dir" keyword does not work. Did I understand correctly that it should cover all the files of the given folder if I do not put a specific extension part to the line?
It's my mistake. Look inside translate_wildcard_list() at the case '': line. When adding documentation at the top of the file, I forgot that I made "no wildcards specified" be the same as specifying "<sources>" (which I did because the vast majority of my "dir=" lines said "<sources>" :P).
For now you should be able to explicitly specify * as the wildcard list.
I'll try to decide if it's the documentation or the feature that's buggy, and fix one or the other.
What's your opinion?
BTW: Here's an improvement idea. There could be a way to add new wildcard definitions in the ssunc.ini file.
...
There are usually a lot of file extensions to cover, so multiple lines should be supported. I'm not sure about how to split this to support multiple lines though.
I completely agree. I haven't added that yet because I haven't decided how to support multiple lines yet. Maybe I'll get to it soon, it's hard to guess with my work schedule. I'm also considering putting the extension groups in a separate .ini file, and having both the FindIn and sync_project_with_scm macros (and possibly other macros) use it. It's hard to resist factoring/reuse, so it will probably happen. ;)
-
It's my mistake. Look inside translate_wildcard_list() at the case '': line. When adding documentation at the top of the file, I forgot that I made "no wildcards specified" be the same as specifying "<sources>" (which I did because the vast majority of my "dir=" lines said "<sources>" :P).
For now you should be able to explicitly specify * as the wildcard list.
I'll try to decide if it's the documentation or the feature that's buggy, and fix one or the other.
What's your opinion?
Thanks, that got me to test one more way of specifying the wildcard list.
Here's what I tested:
1) dir=+"D:\code", <sources>
2) dir=+"D:\code",
3) dir=+"D:\code"
The first two work the same way, but #3 does not get any contents. I guess the default case in the case you mentioned catches that one. Perhaps you should make the default also work like the sources branch?
Both "*" and "sources" as the default value works for me I guess. So documentation update (and the thing above) should IMHO be enough.
I completely agree. I haven't added that yet because I haven't decided how to support multiple lines yet. Maybe I'll get to it soon, it's hard to guess with my work schedule. I'm also considering putting the extension groups in a separate .ini file, and having both the FindIn and sync_project_with_scm macros (and possibly other macros) use it. It's hard to resist factoring/reuse, so it will probably happen. ;)
Yep, the separate ini-file sounds great ;D
That would isolate the config from code nicely.
-
Great macro. Since my projects are so large, I put in a status message so I'd know where I am when doing an update. In ssync, right at the top of the foreach loop, I added:
message("processing " dirInfo.dir " (entry " ii+1 " of " dir_list._length()")");
// Exclude entries go in another array.
Now I can tell how far into the process I am.
-
This doesn't seem to work if the slickedit project doesn't reside in the same location as the code. I've got my projects sitting on my local PC, with the code mapped to a shared directory - this prevents slickedit from freezing up (and not being able to save its configuration) if the share goes away.
Changing the prj_root assignment in ssync_project to read the project file rather than get the cwd corrects the issue - this does require that your project has the WorkingDir field set to a real value, and not the default "."
// Get the root directory from the project, not the directory the project file resides in
// _str prj_root = strip_filename(project, 'NE');
_str prj_root = _ProjectGet_WorkingDir(_ProjectHandle())
-
Thanks for the bug report. I need to work up a different fix, though, as part of the point of putting the project in the source tree (instead of in a central directory) is so that the source tree can be relocated and the project is still valid. I can't fill in the Working Directory with a hard-coded path -- the project could not be relocated then, without extra work (work which a source control system for example will not know how to do).
Point taken, though, and it seems pretty easy to fix in a way that works for both worlds.
-
Just found this thread and downloaded the last ZIP file update. The macro takes 25 minutes to run with the extremely large project I deal with at work, but it's still a big time and hassle saver. Many thanks to the authors! :)
I may make a few changes to improve performance in my environment, and if they seem generally useful, I will upload an updated version here. I suspect that what's taking a lot of the time for me is that our project files reside within our main source folder alongside several large distributions that we don't really edit or need to access for tagging -- they just get built as part of our overall build. As a result, the macro is processing tens of thousands of files that it then goes back and removes via the exclusion mechanism. I can't reorganize the source tree, so I may see if I can modify the script to allow certain subfolders to be omitted from all processing.
-
Yeah, building the list of files is much slower than I'd like to see. I have native DLL code that builds the file list much faster, but it's not portable to other OSes than Windows.
-
Has anyone back-ported this macro to SE11? I've got a bunch of guys I work with stuck on 11, and I'd like to let them use this macro. If no one has done it, I'll see if I can borrow one of their systems and try to get it working. When I tried, I think it complained about _length()
-
Hi:
I have used "Add with Wildcard" in the past to create projects that allow to easily update the file list.
However, "Add with Wildcard" does not work well when the files are in a networked environment, SE freezes all the time while scanning the directories and it is unusable.
So I stumbled upon chrisant's great work, 'sync_project_with_scm.e' in this thread, and it is meeting my needs.
There is one thing I would like to change with this macro.
The macro currently requires the 'ssync.ini' file to be in the slickedit configuration directory.
But I would also like to keep 'ssync.ini' under my source control, so I would like to keep it in the same directory with the project file (.vpj file). The directory containing the project file is part of source control (while the workspace, .vpw file, is not in source control and is located elsewhere on local hard drive for fast tagging file access).
I have never written macros in Slick-C before, and was wondering if someone could help me out with the following question.
In 'sync_project_with_scm.e', the ssync.ini file is loaded as follows:
_str iniFile = slick_path_search1("ssync.ini");
How to change this statement so that it searches for 'ssync.ini' in the active project directory?
Thanks,
Rob
-
It might be more useful to put it in the same directory as the .vpw file (.vpj files don't need to be in the same directory as the .vpw, and there can be many .vpj's per .vpw).
The global variable _workspace_filename contains the fully qualified path name for the currently loaded workspace file. That and strip_filename should give you what you need (I don't want to rob you of your first Slick-C macro modification :-)).
Btw, the macro currently searches along the path specified in the VSLICKPATH config variable. The .ini file doesn't need to go in the config directory, it just needs to go in some directory along that search path. The search path can be extended by changing VSLICKPATH in the vslick.ini file in the config directory. FWIW, my config directory is under source control, and I find that works very well for me (though I have to set the file type for several files to be always-writable i.e. even when the file isn't checked out yet).
-
I need it to be in the directory with .vpj because the .vpj file is in source control, while the .vpw is not in source control.
.vpw is not in source control so that a user can put it on their hard drive. The .vtg (tags) file ends up being in the same directory as the .vpw, and this is fastest when on the local hard drive.
The .vpj file is in source control and that places it in a networked path. Anybody can then get the .vpj and ssync.ini file by having a clearcase view and will see both. The .vpj file contains the build instructions for the different configurations and needs to be maintained in source control.
Putting the SE config directory into source control sounds very useful, but I'm not ready to tackle that one yet.
I have successfully modified the macro for my purposes and will write a 2nd post about it.
-
I've modified the macro so that it first searches for a "<project_name>.ini" file in the same directory as the project (.vpj) file. If this first search is not successful, then it uses "ssync.ini" in the slickedit configuration directory.
Attached is the new macro.
Thanks chrisant for the pointers for modifying this macro (my first macro modification!) and also for this magnificent macro!
-
After using this great macro for many years, I have made an optimization that makes it much much faster. This optimization will minimize the number of calls to the "insert_file_list()" macro by including all the wildcards and excludes in one call per dir line to insert_file_list().
I have posted the latest version with this modification to github:
https://github.com/rbresalier/sync_project_with_scm
This macro still has a big advantage over SlickEdit's native support of wildcard adding of files to a project. With SE's wildcard adding, every time you open your project it needs to perform a scan to find all the files. But with this macro this scan can be done on demand by running the 'ssync' macro. When running 'ssync', it saves the list of files to the .vpj file so that this list can be reused when you close the project and open it again later. SE's wild card adding only saves the wild card patterns to the .vpj file, so every time you open your project, it has to rescan. This rescanning can take a long time if you have 10000s of files in a networked drive. The 'ssync' macro only performs this scanning when the user runs 'ssync', and the scanning is now optimized in this latest version of 'ssync' to make the scan much faster.