1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Loading a plugin for this & all subshells

Discussion in 'Support' started by p.f.moore, Jul 7, 2008.

  1. p.f.moore

    Joined:
    May 30, 2008
    Messages:
    122
    Likes Received:
    1
    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.
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  3. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,187
    Likes Received:
    11
    TCC will autoload all plugins that are in the PLUGINS subdirectory.

    -Scott

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


     
  4. p.f.moore

    Joined:
    May 30, 2008
    Messages:
    122
    Likes Received:
    1
    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.
     
  5. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  6. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    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.
     
  7. p.f.moore

    Joined:
    May 30, 2008
    Messages:
    122
    Likes Received:
    1
    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...)
     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    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.
     
  9. p.f.moore

    Joined:
    May 30, 2008
    Messages:
    122
    Likes Received:
    1
    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.
     
  10. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    On Mon, 07 Jul 2008 17:11:30 -0500, you wrote:


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

    Joined:
    May 30, 2008
    Messages:
    42
    Likes Received:
    0
    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
     
  12. p.f.moore

    Joined:
    May 30, 2008
    Messages:
    122
    Likes Received:
    1
    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.
     

Share This Page