closing a macro completely upon connect - Protocols

This is a discussion on closing a macro completely upon connect - Protocols ; Hi, I have a little problem with a macro I have. I get "Macros nested too deeply" when used many times in a row. K95 2.1.3, wy370? I think is the layout. I have a hotkey which runs a quick ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: closing a macro completely upon connect

  1. closing a macro completely upon connect

    Hi, I have a little problem with a macro I have. I get "Macros nested too
    deeply" when used many times in a row.
    K95 2.1.3, wy370? I think is the layout.

    I have a hotkey which runs a quick macro.
    It switches from the Terminal to the Command window to process the info.
    Then when it is done, it goes back to the Terminal window via the Connect
    command.
    (I know this is a bug. I'm still waiting for the fix, but this method has
    been working for me in general. But seriously I want that fix so badly).

    Now when I keep using the "same" macro over and over again, it seems that
    its not closing properly.
    I get a message saying "Macros nested too deeply". It is doing this
    predictably at 20 tries.


    I can't post the all the code here but I'll post how I'm starting/ending the
    macro:

    define XXXX {
    local \%x
    local \%y
    undeclare \&a
    undeclare \&b
    declare \&a[50]
    declare \&b[50]
    save terminal scrollback scroll.txt
    file count /lines
    fseek 0 /line \v(count)-30 (syntax might be off, I'm going from memory here.
    its basically going to the last 30 lines of the file. The arrays are used to
    store each line as well as additional info)
    .......
    can't really post whats here.
    .......
    file close all
    undeclare \&a
    undeclare \&b
    connect
    return
    }

    Now the users never go to the Command window on their own. Nor are they ever
    expected to. Pressing the hotkey basically makes the screen blink as it
    switches to the command and back to the terminal in a split second.

    The "Connect" command is basically disabling the the rest of the code from
    doing its job while you are in the Terminal which includes it's own
    completion. Altnernating macros seems to be ok. But using the same one over
    and over is a problem.

    I can't think of any other reason why I'm getting the "Macros nested too
    deeply" error aside from the macros not ending right.

    - Scott



  2. Re: closing a macro completely upon connect

    Scott Caissie wrote:

    > (I know this is a bug. I'm still waiting for the fix, but this method has
    > been working for me in general. But seriously I want that fix so badly).


    Until Columbia University decides to release a new version, fixes are
    available from Secure Endpoints Inc. as documented at

    http://www.columbia.edu/kermit/support.html#k95


  3. Re: closing a macro completely upon connect

    On 2006-03-09, Jeffrey Altman wrote:
    : Scott Caissie wrote:
    :
    :> (I know this is a bug. I'm still waiting for the fix, but this method has
    :> been working for me in general. But seriously I want that fix so badly).
    :
    : Until Columbia University decides to release a new version, fixes are
    : available from Secure Endpoints Inc. as documented at
    :
    : http://www.columbia.edu/kermit/support.html#k95
    :
    I have been trying to arrange this for a year or two. I am still trying.
    I can't go into details here. Suffice it to say that it might be helpful if
    some big corporate, government, scientific, or university customers wrote
    letters of encouragement and support. The new management here has no history
    with Kermit and doesn't understand the role it has played and continues to
    play (albeit increasingly behind the scenes).

    In the meantime, as Jeff says, fixes are available direct from his company.

    - Frank

  4. Re: closing a macro completely upon connect

    ya but unfortunatly our terminal emulation is leased. I have to make due
    with whats avialable to us as is.
    We have no administrator within the company for this software. I'm the only
    one who actually bothered to research this stuff. I've developed many
    improvements. But some I have to put on hold due to that. Normally all bug
    fixes are free. Enhancements cost. This unique situation would involve us
    paying this company to pay for the fix. And they are already behind on a lot
    of bug fixes of their own.

    But back on topic, how to properly deal with a macro from becoming nested
    too much.


    "Frank da Cruz" wrote in message
    news:slrne10fck.8bc.fdc@sesame.cc.columbia.edu...
    > On 2006-03-09, Jeffrey Altman wrote:
    > : Scott Caissie wrote:
    > :
    > :> (I know this is a bug. I'm still waiting for the fix, but this method
    > has
    > :> been working for me in general. But seriously I want that fix so
    > badly).
    > :
    > : Until Columbia University decides to release a new version, fixes are
    > : available from Secure Endpoints Inc. as documented at
    > :
    > : http://www.columbia.edu/kermit/support.html#k95
    > :
    > I have been trying to arrange this for a year or two. I am still trying.
    > I can't go into details here. Suffice it to say that it might be helpful
    > if
    > some big corporate, government, scientific, or university customers wrote
    > letters of encouragement and support. The new management here has no
    > history
    > with Kermit and doesn't understand the role it has played and continues to
    > play (albeit increasingly behind the scenes).
    >
    > In the meantime, as Jeff says, fixes are available direct from his
    > company.
    >
    > - Frank




  5. Re: closing a macro completely upon connect

    On 2006-03-09, Scott Caissie wrote:
    : ya but unfortunatly our terminal emulation is leased. I have to make due
    : with whats avialable to us as is.
    : We have no administrator within the company for this software. I'm the only
    : one who actually bothered to research this stuff. I've developed many
    : improvements. But some I have to put on hold due to that. Normally all bug
    : fixes are free. Enhancements cost. This unique situation would involve us
    : paying this company to pay for the fix. And they are already behind on a lot
    : of bug fixes of their own.
    :
    Bug fixes AND upgrades were free from the very beginning up until the layoffs
    occurred 3 years ago. The problem now is that the expertise is no longer
    under one roof. At least the critical fixes *are* available, albeit at a
    fee.

    : But back on topic, how to properly deal with a macro from becoming nested
    : too much.
    :
    I don't think there is a workaround to the "macros on keys" bug, other than
    the awkward one mentioned in the bug list:

    735. Macros on Keys broken

    In versions 1.1.21 through 2.1.3, when a SET [TERMINAL] KEY definition
    includes a macro invocation, then pressing the key while in the
    Terminal screen returns to the command screen (and in some cases might
    also fail to execute the macro). A workaround would be to:

    define myconnect connect /synchronous
    (make the connection with SET PORT, DIAL, or SET HOST)
    if success do myconnect

    This is fixed in the next release.

    As I said, I'm working on getting approval to issue a new release.

    - Frank

  6. Re: closing a macro completely upon connect

    By the way, can you explain how the fix works?
    It sounds simplistic enough.
    When fixed, you can invoke a macro definition in the Terminal window
    without the screen changing to the Command window right?
    I was under the impression that programs (definitions) won't run, or
    continue to run, while you are in the Terminal window to begin with. It
    would resume itself when you return back to the Command window.

    Example:
    define test {
    output Test1
    connect
    output Test2
    }

    I'm not at my work pc at the moment but I'm sure only Test1 gets displayed
    to the Terminal window until you Alt X back to the command to resume the
    rest right? Is this any different after the fix?

    "Frank da Cruz" wrote in message
    news:slrne10uul.jul.fdc@sesame.cc.columbia.edu...
    > On 2006-03-09, Scott Caissie wrote:
    > : ya but unfortunatly our terminal emulation is leased. I have to make due
    > : with whats avialable to us as is.
    > : We have no administrator within the company for this software. I'm the
    > only
    > : one who actually bothered to research this stuff. I've developed many
    > : improvements. But some I have to put on hold due to that. Normally all
    > bug
    > : fixes are free. Enhancements cost. This unique situation would involve
    > us
    > : paying this company to pay for the fix. And they are already behind on a
    > lot
    > : of bug fixes of their own.
    > :
    > Bug fixes AND upgrades were free from the very beginning up until the
    > layoffs
    > occurred 3 years ago. The problem now is that the expertise is no longer
    > under one roof. At least the critical fixes *are* available, albeit at a
    > fee.
    >
    > : But back on topic, how to properly deal with a macro from becoming
    > nested
    > : too much.
    > :
    > I don't think there is a workaround to the "macros on keys" bug, other
    > than
    > the awkward one mentioned in the bug list:
    >
    > 735. Macros on Keys broken
    >
    > In versions 1.1.21 through 2.1.3, when a SET [TERMINAL] KEY definition
    > includes a macro invocation, then pressing the key while in the
    > Terminal screen returns to the command screen (and in some cases might
    > also fail to execute the macro). A workaround would be to:
    >
    > define myconnect connect /synchronous
    > (make the connection with SET PORT, DIAL, or SET HOST)
    > if success do myconnect
    >
    > This is fixed in the next release.
    >
    > As I said, I'm working on getting approval to issue a new release.
    >
    > - Frank




  7. Re: closing a macro completely upon connect

    just a little correction to prevent any misunderstanding. When I was saying
    "Normally all bug fixes are free. Enhancements cost. This unique situation
    would involve us paying this company to pay (you guys) for the fix. And they
    are already behind on a lot of bug fixes of their own." I was referring to
    the company we are leasing from rather than yourselves.


    "Frank da Cruz" wrote in message
    news:slrne10uul.jul.fdc@sesame.cc.columbia.edu...
    > On 2006-03-09, Scott Caissie wrote:
    > : ya but unfortunatly our terminal emulation is leased. I have to make due
    > : with whats avialable to us as is.
    > : We have no administrator within the company for this software. I'm the
    > only
    > : one who actually bothered to research this stuff. I've developed many
    > : improvements. But some I have to put on hold due to that. Normally all
    > bug
    > : fixes are free. Enhancements cost. This unique situation would involve
    > us
    > : paying this company to pay for the fix. And they are already behind on a
    > lot
    > : of bug fixes of their own.
    > :
    > Bug fixes AND upgrades were free from the very beginning up until the
    > layoffs
    > occurred 3 years ago. The problem now is that the expertise is no longer
    > under one roof. At least the critical fixes *are* available, albeit at a
    > fee.
    >
    > : But back on topic, how to properly deal with a macro from becoming
    > nested
    > : too much.
    > :
    > I don't think there is a workaround to the "macros on keys" bug, other
    > than
    > the awkward one mentioned in the bug list:
    >
    > 735. Macros on Keys broken
    >
    > In versions 1.1.21 through 2.1.3, when a SET [TERMINAL] KEY definition
    > includes a macro invocation, then pressing the key while in the
    > Terminal screen returns to the command screen (and in some cases might
    > also fail to execute the macro). A workaround would be to:
    >
    > define myconnect connect /synchronous
    > (make the connection with SET PORT, DIAL, or SET HOST)
    > if success do myconnect
    >
    > This is fixed in the next release.
    >
    > As I said, I'm working on getting approval to issue a new release.
    >
    > - Frank




  8. Re: closing a macro completely upon connect

    Scott Caissie wrote:
    > just a little correction to prevent any misunderstanding. When I was saying
    > "Normally all bug fixes are free. Enhancements cost. This unique situation
    > would involve us paying this company to pay (you guys) for the fix. And they
    > are already behind on a lot of bug fixes of their own." I was referring to
    > the company we are leasing from rather than yourselves.


    Personally I'm not sure what difference the company in the middle makes.
    I have no relationship with Columbia, the middle man or you. By the
    terms of Columbia's license, I am allowed to provide a fix to any
    organization that is permitted to run the software. You either have a
    license to run the software or you don't.

    You can obtain the fix and I will brand the software to exactly the
    same license that the current version you are using is branded to.

    Jeffrey Altman

  9. Re: closing a macro completely upon connect

    But I still need to know what is being fixed.
    Fix basically states that macros can be run from the Terminal without the
    screen changing.
    But normally, no complex macros can run (with or without set key) while
    actively in the Terminal. They basically pause until you go back into the
    Command window.

    Can we have things running in the background now while in the Terminal?
    Thats what it sounds like. Though as far as I know, only 1 macro can run at
    a time. Invoking a macro in the Terminal while another macro (in a loop) is
    running in the background will cause the one in the background to stop would
    it not?

    "Jeffrey Altman" wrote in message
    newsk2Qf.12766$nB6.1669@news-wrt-01.rdc-nyc.rr.com...
    > Scott Caissie wrote:
    >> just a little correction to prevent any misunderstanding. When I was
    >> saying
    >> "Normally all bug fixes are free. Enhancements cost. This unique
    >> situation
    >> would involve us paying this company to pay (you guys) for the fix. And
    >> they
    >> are already behind on a lot of bug fixes of their own." I was referring
    >> to
    >> the company we are leasing from rather than yourselves.

    >
    > Personally I'm not sure what difference the company in the middle makes.
    > I have no relationship with Columbia, the middle man or you. By the
    > terms of Columbia's license, I am allowed to provide a fix to any
    > organization that is permitted to run the software. You either have a
    > license to run the software or you don't.
    >
    > You can obtain the fix and I will brand the software to exactly the
    > same license that the current version you are using is branded to.
    >
    > Jeffrey Altman




  10. Re: closing a macro completely upon connect

    Scott Caissie wrote:
    > But I still need to know what is being fixed.
    > Fix basically states that macros can be run from the Terminal without the
    > screen changing.


    Where does http://www.columbia.edu/~jaltman/k95...-since-213.txt
    indicate that?

    > But normally, no complex macros can run (with or without set key) while
    > actively in the Terminal. They basically pause until you go back into the
    > Command window.


    Macros only execute in "command mode". Its been several years since I
    fixed the bug associated with SET KEY and terminal mode, but my
    recollection is that the macro would be configured to execute and
    "terminal or connect mode" would not be exited.

    > Can we have things running in the background now while in the Terminal?


    You cannot have things executing in the background while in terminal
    mode. Terminal mode is the "CONNECT" command. When the terminal window
    is displayed the command processor is blocked in "CONNECT". Why is
    this? Because the input and output devices are controlled by the user
    when the CONNECT command is executed. The input and output devices
    cannot be tampered with by a script.

    The CONNECT command provides a trigger functionality that allows a
    script to be executed when specific input patterns are recognized.
    There is also an ability to automated output based upon idle timers.

    What is it that you want to run in the background that would not be
    competing with the user interaction with the remote host?

    > Thats what it sounds like. Though as far as I know, only 1 macro can run at
    > a time. Invoking a macro in the Terminal while another macro (in a loop) is
    > running in the background will cause the one in the background to stop would
    > it not?


    You are correct. There is one command processor and therefore one macro
    at a time. This has not changed.

    Jeffrey Altman

  11. Re: closing a macro completely upon connect

    > Macros only execute in "command mode". Its been several years since I
    > fixed the bug associated with SET KEY and terminal mode, but my
    > recollection is that the macro would be configured to execute and
    > "terminal or connect mode" would not be exited.


    Its this that I'm trying to understand.
    You're saying that Macros can be executed in connect mode BUT can not run in
    connect mode with the fix?
    Then this fix is something that has no use to me.
    I already created a work around to activate any macro via connect mode. I
    want it to actively run while in connect mode.

    This here was worded bad:
    ftp://kermit.columbia.edu/kermit/k95/newbugs.txt
    735. Macros on Keys broken

    In versions 1.1.21 through 2.1.3, when a SET [TERMINAL] KEY definition
    includes a macro invocation, then pressing the key while in the
    Terminal screen returns to the command screen (and in some cases might
    also fail to execute the macro).

    All this time I was thinking the act of going to the command screen upon
    invokation was the bug itself. It says 2 things. The secondary issue isn't a
    concern.


    Background program:
    Actively saving the scrollback buffer and analying the last 30 lines which
    is slightly more than a full screen worth of work, and do various events.
    I have about 7-8 macros which upon activation causes a 'blink' effect. Jumps
    to the command window, does the code involving the scrollback or something
    else, and jumps back to the terminal. As far as my co-workers are concerned,
    the macro 'reads the screen'. I wanted to remove the 'blink' effect. Not all
    the users are comfortable with something that visually appears unstable.


    I do have a technical question.
    Lets say I have a macro that calls another macro (which this buggy one
    does). If success, it does XX and Connects. If failure, it does nothing
    aside from Connects.
    Now if the ONLY means of getting to the Command window is through a Macro'd
    hotkey, when it is used, does it cancel the immidate macro (which was paused
    via the Connect command), or does it cancel all levels of the macro? (ie:
    The parent macro which summoned it?). I think that is what is happening.
    That afterall is what this thread is about. Not the macro invokation bug,
    but the Macros being nested issue.

    define test1 {
    ........
    ; checks keyboard cursor location. if success, then it does the rest
    ; this allows 1 key to be used to activate many macros. 1 at a time though
    based on where you are in your work
    ; until this point, I never had macros calling macros.
    if .... do test2
    connect
    return
    }
    define test2 {
    ; read scrollback
    ; output value
    connect
    return
    }



    "Jeffrey Altman" wrote in message
    newsVlQf.14280$4%1.10175@news-wrt-01.rdc-nyc.rr.com...
    > Scott Caissie wrote:
    >> But I still need to know what is being fixed.
    >> Fix basically states that macros can be run from the Terminal without the
    >> screen changing.

    >
    > Where does http://www.columbia.edu/~jaltman/k95...-since-213.txt
    > indicate that?
    >
    >> But normally, no complex macros can run (with or without set key) while
    >> actively in the Terminal. They basically pause until you go back into the
    >> Command window.

    >
    > Macros only execute in "command mode". Its been several years since I
    > fixed the bug associated with SET KEY and terminal mode, but my
    > recollection is that the macro would be configured to execute and
    > "terminal or connect mode" would not be exited.
    >
    >> Can we have things running in the background now while in the Terminal?

    >
    > You cannot have things executing in the background while in terminal
    > mode. Terminal mode is the "CONNECT" command. When the terminal window
    > is displayed the command processor is blocked in "CONNECT". Why is
    > this? Because the input and output devices are controlled by the user
    > when the CONNECT command is executed. The input and output devices
    > cannot be tampered with by a script.
    >
    > The CONNECT command provides a trigger functionality that allows a
    > script to be executed when specific input patterns are recognized.
    > There is also an ability to automated output based upon idle timers.
    >
    > What is it that you want to run in the background that would not be
    > competing with the user interaction with the remote host?
    >
    >> Thats what it sounds like. Though as far as I know, only 1 macro can run
    >> at
    >> a time. Invoking a macro in the Terminal while another macro (in a loop)
    >> is
    >> running in the background will cause the one in the background to stop
    >> would
    >> it not?

    >
    > You are correct. There is one command processor and therefore one macro
    > at a time. This has not changed.
    >
    > Jeffrey Altman




  12. Re: closing a macro completely upon connect

    Scott Caissie wrote:

    > Its this that I'm trying to understand.
    > You're saying that Macros can be executed in connect mode BUT can not run in
    > connect mode with the fix?
    > Then this fix is something that has no use to me.
    > I already created a work around to activate any macro via connect mode. I
    > want it to actively run while in connect mode.
    >
    > This here was worded bad:
    > ftp://kermit.columbia.edu/kermit/k95/newbugs.txt
    > 735. Macros on Keys broken
    >
    > In versions 1.1.21 through 2.1.3, when a SET [TERMINAL] KEY definition
    > includes a macro invocation, then pressing the key while in the
    > Terminal screen returns to the command screen (and in some cases might
    > also fail to execute the macro).
    >
    > All this time I was thinking the act of going to the command screen upon
    > invokation was the bug itself. It says 2 things. The secondary issue isn't a
    > concern.



    Why is this a concern to you? Because your work around is running
    into stack overflow errors because are executing too many macros.
    That's how this discussion started. By fixing the bug you don't
    overflow the macro table.

    I don't know why the above includes "(and in some cases might also fail
    to execute the macro)" because as far as I am aware the macro is never
    executed when bound to a key and the key is pressed while in CONNECT mode.

    Kermit 95 will never work the way you want it to because the command
    parser is not thread safe. The Kermit 95 command parse is exactly the
    same as the C-Kermit command parser and C-Kermit is a single threaded
    application. It has never been a priority for Columbia University
    to turn the Kermit Script Language and the engine that implements it
    into a thread safe language.

    > Background program:
    > Actively saving the scrollback buffer and analying the last 30 lines which
    > is slightly more than a full screen worth of work, and do various events.
    > I have about 7-8 macros which upon activation causes a 'blink' effect. Jumps
    > to the command window, does the code involving the scrollback or something
    > else, and jumps back to the terminal. As far as my co-workers are concerned,
    > the macro 'reads the screen'. I wanted to remove the 'blink' effect. Not all
    > the users are comfortable with something that visually appears unstable.


    So you want to be able to configure a mode that gives control to the
    command parser and does not switch the display image. The concern here
    being that if something goes wrong with your macro, then you have no way
    of interacting with it.

    If I was still working on Kermit I would consider adding such a

    SET TERMINAL MACRO-DISPLAYS-TERMINAL {ON, [OFF]}

    option but it had better be used only when you know your macros work
    correctly

    > I do have a technical question.
    > Lets say I have a macro that calls another macro (which this buggy one
    > does). If success, it does XX and Connects. If failure, it does nothing
    > aside from Connects.
    > Now if the ONLY means of getting to the Command window is through a Macro'd
    > hotkey, when it is used, does it cancel the immidate macro (which was paused
    > via the Connect command), or does it cancel all levels of the macro? (ie:
    > The parent macro which summoned it?). I think that is what is happening.
    > That afterall is what this thread is about. Not the macro invokation bug,
    > but the Macros being nested issue.


    If you call macro A and that macro calls macro B and then calls CONNECT
    then the call to CONNECT prevents macro B from ending. If the CONNECT
    was from macro A then when you get to the terminal mode you are still
    at the same macro level as you were when you started.

    > define test1 {
    > ........
    > ; checks keyboard cursor location. if success, then it does the rest
    > ; this allows 1 key to be used to activate many macros. 1 at a time though
    > based on where you are in your work
    > ; until this point, I never had macros calling macros.
    > if .... do test2
    > connect
    > return
    > }
    > define test2 {
    > ; read scrollback
    > ; output value
    > connect
    > return
    > }


    And this is where your problem is when test2 executes you are pushing
    the stack. When you execute CONNECT from there the stack does not get
    popped.

    In order to make your macros portable such that they can be executed
    from both command mode and connect mode, you want to replace the CONNECT
    line with

    IF TERMINAL-MACRO CONNECT

    so that you only enter connect mode if you were coming from there.

    I am right in guessing that if you could execute this macro by using
    the CONNECT /TIME-LIMIT: option you would provided that the
    terminal display was consistently displayed to the user?

    Jeffrey Altman

  13. Re: closing a macro completely upon connect

    Compiled:
    Jeff's fix = corrects improper nesting with macro invocation.
    Frank's fix (when released) = is to activate of macro via connect mode. I
    had sent an email to him about this in the recent past. Middle of Janurary I
    think.

    Frank's bug and your fix sound similar enough that I thought they were
    related. They are, but indirectly. I can make due without the nesting fix. I
    just won't have a macro call another macro. I am still waiting for that
    other fix though.

    > I don't know why the above includes "(and in some cases might also fail
    > to execute the macro)" because as far as I am aware the macro is never
    > executed when bound to a key and the key is pressed while in CONNECT mode.


    Nothing special is nessesary to activate a macro in connect mode.
    Define test { ..... connect, return}
    set key \96 \ktest
    There. Done. The stated bug description is and from prior emails (to Frank)
    that I had sent was in regards to running macros via connect mode without
    invoking them as a kverb. It works. Why? I don't know. But it works great.
    This is the bug fix that I'm waiting for. Proper activation of macros via
    connect mode.

    There was miscommunication there. The macros nested problem is a recent
    thing but not an important one. Wasn't the fix that I was originally made
    the comment of wanting really badly. If the nested problem can't be fixed
    normally, then I'll just make a large singular macro instead. Fixed.



    "Jeffrey Altman" wrote in message
    news:s3CQf.15925$nB6.6246@news-wrt-01.rdc-nyc.rr.com...
    > Scott Caissie wrote:
    >
    >> Its this that I'm trying to understand.
    >> You're saying that Macros can be executed in connect mode BUT can not run
    >> in
    >> connect mode with the fix?
    >> Then this fix is something that has no use to me.
    >> I already created a work around to activate any macro via connect mode. I
    >> want it to actively run while in connect mode.
    >>
    >> This here was worded bad:
    >> ftp://kermit.columbia.edu/kermit/k95/newbugs.txt
    >> 735. Macros on Keys broken
    >>
    >> In versions 1.1.21 through 2.1.3, when a SET [TERMINAL] KEY definition
    >> includes a macro invocation, then pressing the key while in the
    >> Terminal screen returns to the command screen (and in some cases might
    >> also fail to execute the macro).
    >>
    >> All this time I was thinking the act of going to the command screen upon
    >> invokation was the bug itself. It says 2 things. The secondary issue
    >> isn't a
    >> concern.

    >
    >
    > Why is this a concern to you? Because your work around is running
    > into stack overflow errors because are executing too many macros.
    > That's how this discussion started. By fixing the bug you don't
    > overflow the macro table.
    >
    > I don't know why the above includes "(and in some cases might also fail
    > to execute the macro)" because as far as I am aware the macro is never
    > executed when bound to a key and the key is pressed while in CONNECT mode.
    >
    > Kermit 95 will never work the way you want it to because the command
    > parser is not thread safe. The Kermit 95 command parse is exactly the
    > same as the C-Kermit command parser and C-Kermit is a single threaded
    > application. It has never been a priority for Columbia University
    > to turn the Kermit Script Language and the engine that implements it
    > into a thread safe language.
    >
    >> Background program:
    >> Actively saving the scrollback buffer and analying the last 30 lines
    >> which
    >> is slightly more than a full screen worth of work, and do various events.
    >> I have about 7-8 macros which upon activation causes a 'blink' effect.
    >> Jumps
    >> to the command window, does the code involving the scrollback or
    >> something
    >> else, and jumps back to the terminal. As far as my co-workers are
    >> concerned,
    >> the macro 'reads the screen'. I wanted to remove the 'blink' effect. Not
    >> all
    >> the users are comfortable with something that visually appears unstable.

    >
    > So you want to be able to configure a mode that gives control to the
    > command parser and does not switch the display image. The concern here
    > being that if something goes wrong with your macro, then you have no way
    > of interacting with it.
    >
    > If I was still working on Kermit I would consider adding such a
    >
    > SET TERMINAL MACRO-DISPLAYS-TERMINAL {ON, [OFF]}
    >
    > option but it had better be used only when you know your macros work
    > correctly
    >
    >> I do have a technical question.
    >> Lets say I have a macro that calls another macro (which this buggy one
    >> does). If success, it does XX and Connects. If failure, it does nothing
    >> aside from Connects.
    >> Now if the ONLY means of getting to the Command window is through a
    >> Macro'd
    >> hotkey, when it is used, does it cancel the immidate macro (which was
    >> paused
    >> via the Connect command), or does it cancel all levels of the macro? (ie:
    >> The parent macro which summoned it?). I think that is what is happening.
    >> That afterall is what this thread is about. Not the macro invokation bug,
    >> but the Macros being nested issue.

    >
    > If you call macro A and that macro calls macro B and then calls CONNECT
    > then the call to CONNECT prevents macro B from ending. If the CONNECT
    > was from macro A then when you get to the terminal mode you are still
    > at the same macro level as you were when you started.
    >
    >> define test1 {
    >> ........
    >> ; checks keyboard cursor location. if success, then it does the rest
    >> ; this allows 1 key to be used to activate many macros. 1 at a time
    >> though
    >> based on where you are in your work
    >> ; until this point, I never had macros calling macros.
    >> if .... do test2
    >> connect
    >> return
    >> }
    >> define test2 {
    >> ; read scrollback
    >> ; output value
    >> connect
    >> return
    >> }

    >
    > And this is where your problem is when test2 executes you are pushing
    > the stack. When you execute CONNECT from there the stack does not get
    > popped.
    >
    > In order to make your macros portable such that they can be executed
    > from both command mode and connect mode, you want to replace the CONNECT
    > line with
    >
    > IF TERMINAL-MACRO CONNECT
    >
    > so that you only enter connect mode if you were coming from there.
    >
    > I am right in guessing that if you could execute this macro by using
    > the CONNECT /TIME-LIMIT: option you would provided that the
    > terminal display was consistently displayed to the user?
    >
    > Jeffrey Altman




  14. Re: closing a macro completely upon connect

    Scott Caissie wrote:
    > Compiled:
    > Jeff's fix = corrects improper nesting with macro invocation.
    > Frank's fix (when released) = is to activate of macro via connect mode. I
    > had sent an email to him about this in the recent past. Middle of Janurary I
    > think.
    >
    > Frank's bug and your fix sound similar enough that I thought they were
    > related. They are, but indirectly. I can make due without the nesting fix. I
    > just won't have a macro call another macro. I am still waiting for that
    > other fix though.


    The bugs are one and the same.

    A macro mapped to a key will not execute if you enter CONNECT mode
    directly. As described in the newbugs.txt file, if you want macros
    to work from CONNECT mode then you must call CONNECT from within a prior
    executing macro.

    define doconnect {
    echo Entering Connect Mode
    CONNECT
    echo Exiting Connect Mode
    }

    or

    define doconnect {
    CONNECT /SYNCHRONOUS
    }

    If you do not do this, then your macros won't execute and if you do
    use this hack then you run into nesting problems.

    If this is not what you want changed, then what you want is not a
    bug fix. Macros executing from a key in CONNECT mode exit CONNECT
    mode and return to COMMAND mode. This is working as designed. If
    you would like a feature request to be implemented you can either
    convince Columbia University to pay to have it developed or you can do
    so yourself.

    Jeffrey Altman

  15. Re: closing a macro completely upon connect

    With the patch, can I still invoke a macro definition as a Kverb while in
    Connect mode?

    ie:
    > define doconnect {
    > CONNECT /SYNCHRONOUS
    > }


    for me to activate this while in Connect mode, I have to use: "Set key \???
    \kdoconnect".
    "Set key \??? doconnect" (not a kverb) just spams the word doconnect within
    the connect window while not activating the macro itself.

    Its the only way I know how to activate a macro from within the connect
    window.
    The ability to do this has amazing potential. I created a great deal amount
    of enhancements this way. If you like I can send a few to you.
    But apparently this is what.. an exploit? I had no reading materials when I
    first started researching this. Just the embedded help. After my 1st week of
    a great deal amount of trial and errors, this is what I came up with. I just
    kept figuring I was doing something wrong. Emailed Frank da Cruz about a way
    to activate macros from within the connect mode. On jan 14th, he said
    literarly: "There is a bug in the current version of Kermit 95 that prevents
    running macros from keystrokes".

    I always assumed that it was going to be corrected. I now have the book
    written by him. You're saying otherwise. Now my only concern is having all
    my work destroyed if this method is removed with the patch.

    All I need to know is if my work will continue to work with the patch. Right
    now I don't know if I want patch anymore. I'm afraid that it'll ruin
    everything. We're rather dependant on those enhancements now. I scrapped
    that one macro until later on. Everything else is at 100% and I wish to keep
    it that way.



  16. Re: closing a macro completely upon connect

    The correct syntax for assigning macro "foo" to a key is

    SET TERMINAL KEY \Kfoo
    SET KEY \Kfoo

    If you don't specify the \K then you are assigning the string "foo" as
    a string to be output to the host.

    Please re-read what I have written. At no point have I indicated that
    the ability to execute macros from keys when pressed in CONNECT mode is
    going away. You have indicated a desire to have macros execute without
    the switch from CONNECT mode to COMMAND mode. This is not going to occur.

    Jeffrey Altman


    Scott Caissie wrote:
    > With the patch, can I still invoke a macro definition as a Kverb while in
    > Connect mode?
    >
    > ie:
    >> define doconnect {
    >> CONNECT /SYNCHRONOUS
    >> }

    >
    > for me to activate this while in Connect mode, I have to use: "Set key \???
    > \kdoconnect".
    > "Set key \??? doconnect" (not a kverb) just spams the word doconnect within
    > the connect window while not activating the macro itself.
    >
    > Its the only way I know how to activate a macro from within the connect
    > window.
    > The ability to do this has amazing potential. I created a great deal amount
    > of enhancements this way. If you like I can send a few to you.
    > But apparently this is what.. an exploit? I had no reading materials when I
    > first started researching this. Just the embedded help. After my 1st week of
    > a great deal amount of trial and errors, this is what I came up with. I just
    > kept figuring I was doing something wrong. Emailed Frank da Cruz about a way
    > to activate macros from within the connect mode. On jan 14th, he said
    > literarly: "There is a bug in the current version of Kermit 95 that prevents
    > running macros from keystrokes".
    >
    > I always assumed that it was going to be corrected. I now have the book
    > written by him. You're saying otherwise. Now my only concern is having all
    > my work destroyed if this method is removed with the patch.
    >
    > All I need to know is if my work will continue to work with the patch. Right
    > now I don't know if I want patch anymore. I'm afraid that it'll ruin
    > everything. We're rather dependant on those enhancements now. I scrapped
    > that one macro until later on. Everything else is at 100% and I wish to keep
    > it that way.
    >
    >


  17. Re: closing a macro completely upon connect

    Can you clarify your own posts? A few things are bothering me still.

    Macros only execute in "command mode". Its been several years since I
    fixed the bug associated with SET KEY and terminal mode, but my
    recollection is that the macro would be configured to execute and
    "terminal or connect mode" would not be exited.

    1. First sentence we know is wrong. Partially. The example I gave you by
    invoking a macro as a kverb works. Same example that you posted afterwards
    as well. It has the ability to leave connect mode on its own and runs the
    macro. A bridge is created.
    2. Rest of your paragraph explains everything that I'm looking for.

    A macro mapped to a key will not execute if you enter CONNECT mode
    directly. As described in the newbugs.txt file
    * Fixed a bug preventing the execution of macros assigned to keys or
    mouse events when in terminal mode

    3. Please don't say nesting. Don't even need to include Frank da Cruz's bug
    description on this one. Your own bug description says its not possible to
    begin with, so nesting never comes into play.

    because as far as I am aware the macro is never executed when bound to a key
    and the key is pressed while in CONNECT mode

    4. Here you say it can't be done. You are now using my very own example to
    say that the Kverb method is the proper way, though previously mentioned as
    a 'work around' and a 'hack'.


    Ya I get the picture that a macro won't actively run while in connect mode.
    An amazing loss of potential there.
    I HAVE been re-reading what you are writting. I don't think you are proof
    reading it.
    Which is why I was confused as hell, and wondering what is a bug or not. You
    had me half convinced that this feature is a bug, or a hack. Which is why I
    was concerned of it being 'fixed'.

    But I have little worry in that now.
    It is unfortunate to learn of K95's limits. I had such high hopes there.
    They were real hopes too. I'm not kidding you. You get the book on how to
    use the software. Only problem is that nothing in the book works without
    using a hack, as you say, and even that apparently doesn't work right, when
    you are using the software in any real productive way. But I do understand
    how old k95 is.
    I'm still going to keep trying to push out its potential here beyond the
    normal use. If you guys could modify VIEWONLY perhaps? So that it is what it
    does. It is the CONNECT command that disables modifying anything. Its pauses
    the macro.It would give the users the illusion of the screen not changing.
    That itself would be enough to create a seemless use of a greater potential
    here.

    example:
    define test {
    viewonly
    ; coding which isn't being paused
    connect /synchronous ; would effectively override viewonly.
    }



  18. Re: closing a macro completely upon connect

    Scott Caissie wrote:
    > Can you clarify your own posts? A few things are bothering me still.


    sure

    > Macros only execute in "command mode". Its been several years since I
    > fixed the bug associated with SET KEY and terminal mode, but my
    > recollection is that the macro would be configured to execute and
    > "terminal or connect mode" would not be exited.


    note the qualifications in the above sentence. "Its been several years"
    and "my recollection is ...".

    > 1. First sentence we know is wrong. Partially. The example I gave you by
    > invoking a macro as a kverb works. Same example that you posted afterwards
    > as well. It has the ability to leave connect mode on its own and runs the
    > macro. A bridge is created.


    Executing a macro as a kverb works when CONNECT was executed from a
    script or macro but not when the CONNECT command is executed
    interactively from the command prompt.

    > 2. Rest of your paragraph explains everything that I'm looking for.
    >
    > A macro mapped to a key will not execute if you enter CONNECT mode
    > directly. As described in the newbugs.txt file
    > * Fixed a bug preventing the execution of macros assigned to keys or
    > mouse events when in terminal mode


    This applies to the case where the CONNECT command was executed
    interactively from the command line.

    > 3. Please don't say nesting. Don't even need to include Frank da Cruz's bug
    > description on this one. Your own bug description says its not possible to
    > begin with, so nesting never comes into play.
    > because as far as I am aware the macro is never executed when bound to a key
    > and the key is pressed while in CONNECT mode


    Nesting will occur when the CONNECT command during which the \Kmacro is
    executed was itself executed from within a script or macro.

    > 4. Here you say it can't be done. You are now using my very own example to
    > say that the Kverb method is the proper way, though previously mentioned as
    > a 'work around' and a 'hack'.


    The hack is the requirement that you replace "CONNECT" with the macro

    define myconnect {
    echo Foo
    connect
    echo Bar
    }

    or use

    define myconnect connect /synch

    > Ya I get the picture that a macro won't actively run while in connect mode.
    > An amazing loss of potential there.


    As described, this is a limitation of a command processor implemented in
    a single threaded process model full of global variables up the wazoo.

    > I HAVE been re-reading what you are writting. I don't think you are proof
    > reading it.
    > Which is why I was confused as hell, and wondering what is a bug or not. You
    > had me half convinced that this feature is a bug, or a hack. Which is why I
    > was concerned of it being 'fixed'.


    I am sorry you are mis-interpreting what I am writing.

    > But I have little worry in that now.
    > It is unfortunate to learn of K95's limits. I had such high hopes there.
    > They were real hopes too. I'm not kidding you. You get the book on how to
    > use the software. Only problem is that nothing in the book works without
    > using a hack, as you say, and even that apparently doesn't work right, when
    > you are using the software in any real productive way. But I do understand
    > how old k95 is.


    The problem is not its age but a lack of resources to develop it. Being
    forced to maintain a common set of sources for everything from a 1980
    Unix system to Windows 2003 places certain limitations on what can be
    done. That plus a lack of resources to re-write the command parser to
    make it thread safe is a serious issue. With a thread safe and
    re-entrant command parser the Kermit Script language could have been
    executed via exported COM objects and you could have had multiple
    scripts running simultaneously in the same process.

    > I'm still going to keep trying to push out its potential here beyond the
    > normal use. If you guys could modify VIEWONLY perhaps? So that it is what it
    > does. It is the CONNECT command that disables modifying anything. Its pauses
    > the macro.It would give the users the illusion of the screen not changing.
    > That itself would be enough to create a seemless use of a greater potential
    > here.
    >
    > example:
    > define test {
    > viewonly
    > ; coding which isn't being paused
    > connect /synchronous ; would effectively override viewonly.
    > }


    VIEWONLY is identical to the CONNECT command except that no data is sent
    to the host and no data is read from the host. It is there primarily to
    allow the contents of the terminal screen buffers to be viewed when the
    connection has already been closed.

    At this point there is no one working on Kermit 95 therefore there are
    no changes that will be made.

    Good luck.

    Jeffrey Altman

  19. Re: closing a macro completely upon connect

    On 2006-03-15, Scott Caissie wrote:
    : Can you clarify your own posts? A few things are bothering me still.
    :
    : Macros only execute in "command mode". Its been several years since I
    : fixed the bug associated with SET KEY and terminal mode, but my
    : recollection is that the macro would be configured to execute and
    : "terminal or connect mode" would not be exited.
    :
    I hope I can clarify this by saying that keystroke macros should be able to
    run in either Command mode or Connect mode, but currently don't due to the
    aforementioned bug. But when you invoke a macro with a keystroke while in
    Connect mode, K95 temporarily enters Command mode to execute it, because
    that's where commands are executed, and a macro is just a series of commands.

    When you assign something to a key with SET KEY, it can be a character or
    string to be transmitted to the host, or a Kverb, or a macro invocation. The
    first two are executed directly in Connect mode, the latter can be executed
    only in Command mode. You can mix all of these things in a single key
    definition. I presently don't have a version of K95 handy without the bug,
    so I can't say exactly how this appears to the user; there might or might not
    be some visible transitions on the screen.

    - Frank

  20. Re: closing a macro completely upon connect

    On 2006-03-19, Frank da Cruz wrote:
    : On 2006-03-15, Scott Caissie wrote:
    :: Can you clarify your own posts? A few things are bothering me still.
    ::
    :: Macros only execute in "command mode". Its been several years since I
    :: fixed the bug associated with SET KEY and terminal mode, but my
    :: recollection is that the macro would be configured to execute and
    :: "terminal or connect mode" would not be exited.
    ::
    : I hope I can clarify this by saying that keystroke macros should be able to
    : run in either Command mode or Connect mode, but currently don't due to the
    : aforementioned bug. But when you invoke a macro with a keystroke while in
    : Connect mode, K95 temporarily enters Command mode to execute it, because
    : that's where commands are executed, and a macro is just a series of commands.
    :
    : When you assign something to a key with SET KEY, it can be a character or
    : string to be transmitted to the host, or a Kverb, or a macro invocation. The
    : first two are executed directly in Connect mode, the latter can be executed
    : only in Command mode. You can mix all of these things in a single key
    : definition. I presently don't have a version of K95 handy without the bug,
    : so I can't say exactly how this appears to the user; there might or might not
    : be some visible transitions on the screen.
    :
    Upon rereading this, I see I should make one more clarification. The word
    "macro" is vague. Keystroke macros are often understood to be assignments of
    characters or strings to a key. That's not what we're talking about here.
    There is no bug in Kermit 95 in this respect. The bug involves only the
    assignment of a Kermit macro invocation to a key. For example:

    define somemacro xxx, yyy, zzz

    (where xxx, yyy, and zzz is a list of one or more Kermit commands). This
    macro can be assigned to (say) the F11 key as follows:

    set key \378 \Ksomemacro

    or:

    set key \378 \K{somemacro}

    This looks like a Kverb but it isn't. As long as the string following the \K
    is not the name of a built-in Kverb, it is looked up in Kermit's macro table
    and, if found, executed (by internally switching to command mode temporarily).
    This is what does not work when the key is pressed while in Connect mode
    (because of the bug). It still works when the key is pressed while in the
    Command screen. The bug is fixed in Jeff's copy:

    http://www.columbia.edu/kermit/support.html

    but I can't distribute that yet, until some arrangements have been made
    between Columbia University and Jeff, which are taking a long time. In the
    meantime, it is available directly from Jeff as described on the page linked
    to above.

    - Frank

+ Reply to Thread
Page 1 of 2 1 2 LastLast