Loading a plugin for this & all subshells

[p.f.moore]

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.

 

[Steve Fabian]

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

 

[samintz]

TCC will autoload all plugins that are in the PLUGINS subdirectory.

-Scott

"p.f.moore" <> wrote on 07/07/2008 08:46:36 AM:

> 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]

On 07/07/2008, samintz <> wrote:

> TCC will autoload all plugins that are in the PLUGINS subdirectory.

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.

 

[Steve Fabian]

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

 

[vefatica]

On Mon, 07 Jul 2008 10:25:56 -0500, you 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).

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.

 

[p.f.moore]

2008/7/7 vefatica <>:

> 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.

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...)

 

[vefatica]

On Mon, 07 Jul 2008 15:22:15 -0500, you wrote:

>PS Is it possible to use VC++ Express Edition to develop plugins
>without getting a dependency on MSVCRT8?

I don't know. When I build all the CRT stuff is statically linked.

 

[p.f.moore]

2008/7/7 vefatica <>:

>>PS Is it possible to use VC++ Express Edition to develop plugins
>>without getting a dependency on MSVCRT8?

> I don't know. When I build all the CRT stuff is statically linked.

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.

 

[vefatica]

On Mon, 07 Jul 2008 17:11:30 -0500, you wrote:

>---Quote---
>> I don't know. When I build all the CRT stuff is statically linked.
>---End Quote---
>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.

I use the professional version, VS 2002 or VS 2005, usually the former.

 

[logic]

From: p.f.moore
Sent: Monday, July 07, 2008 5:12 PM
Subject: RE: [Support-t-282] Loading a plugin for this & all subshells

> > I don't know. When I build all the CRT stuff is statically linked.
>
> 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.

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

 

[p.f.moore]

2008/7/15 logic <>:

> 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.

Thanks.

> 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".

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.