Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What is the last letter in the word "SlickEdit":
How many LETTERS are in the following? "a1b2c3":
Which number is missing?  "12345689":

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: rowbearto
« on: December 18, 2017, 06:50:52 PM »

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.
Posted by: rowbearto
« on: December 02, 2013, 08:13:32 PM »

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!
Posted by: rowbearto
« on: December 02, 2013, 08:06:17 PM »

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.
Posted by: chrisant
« on: December 02, 2013, 05:59:10 PM »

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).
Posted by: rowbearto
« on: December 02, 2013, 05:36:30 PM »

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:

Code: [Select]
      _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
Posted by: Duhhh
« on: June 03, 2010, 09:39:22 PM »

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()
Posted by: chrisant
« on: January 20, 2010, 12:44:16 AM »

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.
Posted by: mjkobb
« on: January 19, 2010, 09:12:35 PM »

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.
Posted by: chrisant
« on: January 20, 2009, 02:54:35 AM »

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.
Posted by: todd_s02
« on: January 20, 2009, 12:19:46 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 "."

Code: [Select]
// 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())
Posted by: Duhhh
« on: January 13, 2009, 06:25:07 PM »

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.
Posted by: Kung Foo
« on: January 05, 2009, 10:18:19 AM »

Quote from: chrisant on January 03, 2009, 07:10:23 PM
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.

Quote from: chrisant on January 03, 2009, 07:10:23 PM
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.
Posted by: chrisant
« on: January 03, 2009, 07:10:23 PM »

Quote from: Kung Foo on January 02, 2009, 07:55:36 AM
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?


Quote from: Kung Foo on January 02, 2009, 07:55:36 AM
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.  ;)
Posted by: Kung Foo
« on: January 02, 2009, 07:55:36 AM »

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:
Code: [Select]
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:
Code: [Select]
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:

Code: [Select]
[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!
Posted by: chrisant
« on: December 24, 2008, 02:10:28 AM »

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.