When I'm testing a plugin, I regularly get caught out by the fact that plugins aren't automatically loaded into subshells, so that echo xxx | plugin_cmd fails (as the plugin isn't loaded on the RHS of the pipe. As it's a test situation, I don't want to put the plugin into my autostart. Of course I can do echo xxx | (plugin /L MyPlugin & plugin_cmd) but is there a simpler way? Something that says "load this plugin now, and autoload it for any shells spawned from this one"? Thanks, Paul.
p.f.moore wrote: | When I'm testing a plugin, I regularly get caught out by the fact that | plugins aren't automatically loaded into subshells, so that | | echo xxx | plugin_cmd | | fails (as the plugin isn't loaded on the RHS of the pipe. | | As it's a test situation, I don't want to put the plugin into my | autostart. Of course I can do | | echo xxx | (plugin /L MyPlugin & plugin_cmd) | | but is there a simpler way? Something that says "load this plugin now, | and autoload it for any shells spawned from this one"? Remember, any plugins in subdirectory PLUGINS of the command processor installation directory are automatically loaded for EACH instance of the command processor (though in TCC you can suppress this with the /IP option in the command which starts TCC). Since I keep multiple versions of the command processors installed into a set of directories, I keep all of my plugins in sets of "plugin master" directories C:\JPSOFT\PLnn, where nn is the command processor version number. Note that the actual .dll files, e.g. 4utils.dll, in these directories are hard linked to one another if they work in all versions both to save disk space and to simplify updating. For each directory in which a plugin-capable command processor version is installed I create a directory junction (soft link) from the appropriate PLnn master directory to the local subdirectory PLUGINS, e.g.: mklnk c:\jpsoft\pl09 c:\jpsoft\i9\plugins. This ensures that all instances of TCC.EXE V9, unless started with the /IP switch, have access to all plugins. Having all pipe instances load all plugins slows pipes down very slightly (since the .dll's are already loaded, so this involves only the dynamic linking and plugin initialization). In all instances they also slow down the parser. The presence of many aliases, environment variables, and user defined functions also slow the parser down. Of course, every added internal command, internal variable and environment function does that, too. In an interpreted script this results in new features unavoidably slwoing down execution. The price of progress. For general operation I am quite willing to live with the slowdown. For special tasks I do start TCC with /L:/I to run them faster. -- HTH, Steve
TCC will autoload all plugins that are in the PLUGINS subdirectory. -Scott "p.f.moore" <> wrote on 07/07/2008 08:46:36 AM:
On 07/07/2008, samintz <> wrote: I know. I don't want to do this as it's a plugin I'm developing. I just want it to be available within the current shell (and the RHS of any pipes - that's the difficulty as pipes start a new command processor). Maybe a variable like AUTOPLUGINS would do (as variables are inherited). Hmm, I could add something to my 4START to parse and manage such a variable. I guess that will do. Paul.
p.f.moore wrote: | On 07/07/2008, samintz <> wrote: | | | ---Quote--- || TCC will autoload all plugins that are in the PLUGINS subdirectory. | ---End Quote--- | I know. I don't want to do this as it's a plugin I'm developing. I | just want it to be available within the current shell (and the RHS of | any pipes - that's the difficulty as pipes start a new command | processor). | | Maybe a variable like AUTOPLUGINS would do (as variables are | inherited). | | Hmm, I could add something to my 4START to parse and manage such a | variable. I guess that will do. In your TCSTART.BTM you can test _PIPE; if it is 1 you are in a pipe. For testing just the one plugin you are developing, you could keep it out of the PLUGINS directory, and load it in TCSTART under control of a variable, e.g., PLUGINTEST, only when desired (possibly controlled by both the _PIPE and the PLUGINTEST). This allows you to load all plugins you normally use automatically. -- HTH, Steve
On Mon, 07 Jul 2008 10:25:56 -0500, you wrote: In that case, I'd recommend a second installation of TCC, say in "TCCtest" for which you don't mind putting test stuff right into the "plugins" subdirectory. You could then use a DevEnv custom tool (mine has a button labelled "Plug") to facilitate testing. The "Plug" tool might look like this: Command: <normal TCC or even CMD> Args: copy $(TargetPath) TCCtest\plugins\ & start TCCtest\tcc.exe & exit InitDir: $(TargetDir) Use output window: yes Close on exit: yes That way you can put the DLL in position for testing and kick off a test session with the push of a button. And because it's in the canonical location, the DLL will be loaded by subshells.
2008/7/7 vefatica <>: Thanks, that sounds like a reasonable approach. Unfortunately, though, I don't develop in Visual Studio. I develop my code in TCC, using Vim as my editor and mingw gcc for my compiler. In that environment, I'm already in a copy of TCC (my default one) and it's much harder to retrain my habits to run a special shell for testing (I know, I need to do so for another project where the test suite only runs in cmd, not in TCC, and it took me a long time to get appropriate testing habits...) I think I'll go with something in my 4START file to work with a PLUGINS variable, as described earlier. Thanks anyway. Paul. PS Is it possible to use VC++ Express Edition to develop plugins without getting a dependency on MSVCRT8? It's been ages since I worked with MSVC... (but it might help to avoid the hacks I need to make the TCC SDK work with mingw...)
On Mon, 07 Jul 2008 15:22:15 -0500, you wrote: I don't know. When I build all the CRT stuff is statically linked.
2008/7/7 vefatica <>: So there's no dependency on the msvcrt8 DLL, which means it must be possible with some flag combination. OK, if it's possible, I should be able to experiment to find out how. I'll take a look at it at some point. Thanks, Paul.
On Mon, 07 Jul 2008 17:11:30 -0500, you wrote: I use the professional version, VS 2002 or VS 2005, usually the former.
From: p.f.moore Sent: Monday, July 07, 2008 5:12 PM Subject: RE: [Support-t-282] Loading a plugin for this & all subshells It's relatively straightforward. Under C++ Language options in the project properties, tell it that you want to build against "Multithreaded Debug" (for the Debug profile) and "Multithreaded" (for the Release profile) instead of "Multithreaded Debug DLL" and "Multithreaded DLL", respectively. The DLLs for VS 2005 and up are a bit of a pain in the ass since they have to be installed into the Side-by-Side Assembly Cache to work properly, and the only way to do that is through the Windows Installer subsystem. I'm sure that makes Microsoft's life easier, but it means if you don't want to distribute your application as a .MSI file, you're out of look. I basically gave up on trying to do dynamically-linked builds since I really like so-called "XCOPY deployment". Jonathan Gilbert
2008/7/15 logic <>: Thanks. Oh, yuk. I agree entirely, copy & go is the only type of deployment I want to deal with. Looks like static builds are for me, too, then. Paul.
