Loading ...
Sorry, an error occurred while loading the content.

Problem with latest snapshot & --remote-tab-silent

Expand Messages
  • ant
    Hello, Just trying out the latest snapshot and have run into a problem. I have aliased g to gvim -p --remote-tab-silent , which in the previous snapshot
    Message 1 of 7 , Dec 3, 2007
    • 0 Attachment
      Hello,

      Just trying out the latest snapshot and have run into a problem.

      I have aliased 'g' to 'gvim -p --remote-tab-silent', which in the
      previous snapshot (and other versions of gvim) opens the named file in
      a new tab, opening gvim if its not already open.

      In this release it causes my CPU to run at 100% and then eventually
      run out of memory and crash.

      I'm not sure this is an improvement :)

      ant.
      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Nico Weber
      Hi, ... I guess that s the fault of my forking patch. I need some more information. If MacVim is already running, doing
      Message 2 of 7 , Dec 3, 2007
      • 0 Attachment
        Hi,

        > I have aliased 'g' to 'gvim -p --remote-tab-silent', which in the
        > previous snapshot (and other versions of gvim) opens the named file in
        > a new tab, opening gvim if its not already open.
        >
        > In this release it causes my CPU to run at 100% and then eventually
        > run out of memory and crash.

        I guess that's the fault of my forking patch.

        I need some more information. If MacVim is already running, doing

        build/Release/MacVim.app/Contents/MacOS/Vim -g -p --remote-tab-
        silent MMTypesetter.m

        works fine for me. If MacVim is not yet running, strange things
        happen. If I disable the forking patch, things that happen in that
        case are...less strange (one error message on stdout, but apart from
        that everything works as expected). I'll take a look if I can fix this.

        But I guess your gvim script might be partially to blame as well. Can
        you send it here? Note that starting with this version, you don't need
        the '&' at the end of the line that start vim because vim does now
        fork as it does on other OSs. You could also use the mvim script that
        comes bundled with the latest release.

        > I'm not sure this is an improvement :)

        But vim can now read from stdin (`ls | mvim -`). It's all about
        priorities ;-)

        Nico

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • ant
        Hi Nico - thanks for the quick reply, ... And for me. ... Great ... My gvim script is just an alias to the mvim script that came with the latest snapshot -
        Message 3 of 7 , Dec 3, 2007
        • 0 Attachment
          Hi Nico - thanks for the quick reply,

          > > I have aliased 'g' to 'gvim -p --remote-tab-silent', which in the
          > > previous snapshot (and other versions of gvim) opens the named file in
          > > a new tab, opening gvim if its not already open.
          >
          > > In this release it causes my CPU to run at 100% and then eventually
          > > run out of memory and crash.
          >
          > I guess that's the fault of my forking patch.
          >
          > I need some more information. If MacVim is already running, doing
          >
          > build/Release/MacVim.app/Contents/MacOS/Vim -g -p --remote-tab-
          > silent MMTypesetter.m
          >
          > works fine for me.

          And for me.

          > If MacVim is not yet running, strange things
          > happen. If I disable the forking patch, things that happen in that
          > case are...less strange (one error message on stdout, but apart from
          > that everything works as expected). I'll take a look if I can fix this.

          Great

          > But I guess your gvim script might be partially to blame as well. Can
          > you send it here? Note that starting with this version, you don't need
          > the '&' at the end of the line that start vim because vim does now
          > fork as it does on other OSs. You could also use the mvim script that
          > comes bundled with the latest release.

          My gvim script is just an alias to the mvim script that came with the
          latest snapshot - sorry I forgot to mention that. I've been typing
          'gvim' for years, and old habits die hard :)

          > > I'm not sure this is an improvement :)
          >
          > But vim can now read from stdin (`ls | mvim -`). It's all about
          > priorities ;-)

          Ok :)

          For now I'll work around it by checking if MacVim is running and
          stripping the --remote-tab-silent arg if it isn't; but if you could
          fix it that would be great

          Thanks

          Ant
          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • ant
          ... Just in case anyone else is running into the same problem you can add this to the mvim script and the problem is avoided: if [ `/bin/ps -ef | grep
          Message 4 of 7 , Dec 3, 2007
          • 0 Attachment
            > For now I'll work around it by checking if MacVim is running and
            > stripping the --remote-tab-silent arg if it isn't

            Just in case anyone else is running into the same problem you can add
            this to the mvim script and the problem is avoided:


            if [ `/bin/ps -ef | grep "MacVim.app/Contents/MacOS/Vim -g" | grep -v
            grep | wc -l` -eq 0 ] ; then
            # MacVim isn't already running, so need to strip --remote-tab-silent
            arg if present:
            ARGS=""
            while [ -n "$1" ] ; do
            arg="$1"
            shift
            if [[ "$arg" != "--remote-tab-silent" ]] ; then
            ARGS="${ARGS} $arg"
            fi
            done
            eval "set -- ${ARGS}"
            fi


            ant.
            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Matt Tolton
            You can also just use open -a MacVim and then you don t have to worry about any of this. :) ... --~--~---------~--~----~------------~-------~--~----~ You
            Message 5 of 7 , Dec 3, 2007
            • 0 Attachment
              You can also just use open -a MacVim and then you don't have to worry
              about any of this. :)

              On 12/3/07, ant <antony.baxter@...> wrote:
              >
              > > For now I'll work around it by checking if MacVim is running and
              > > stripping the --remote-tab-silent arg if it isn't
              >
              > Just in case anyone else is running into the same problem you can add
              > this to the mvim script and the problem is avoided:
              >
              >
              > if [ `/bin/ps -ef | grep "MacVim.app/Contents/MacOS/Vim -g" | grep -v
              > grep | wc -l` -eq 0 ] ; then
              > # MacVim isn't already running, so need to strip --remote-tab-silent
              > arg if present:
              > ARGS=""
              > while [ -n "$1" ] ; do
              > arg="$1"
              > shift
              > if [[ "$arg" != "--remote-tab-silent" ]] ; then
              > ARGS="${ARGS} $arg"
              > fi
              > done
              > eval "set -- ${ARGS}"
              > fi
              >
              >
              > ant.
              > >
              >

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Nico Weber
              ... A patch that fixes the problem is attached. The attached patch is good enough to use it for 0712B. For those who care, here s what was broken, what I
              Message 6 of 7 , Dec 4, 2007
              • 0 Attachment
                >>> I have aliased 'g' to 'gvim -p --remote-tab-silent', which in the
                >>> previous snapshot (and other versions of gvim) opens the named
                >>> file in
                >>> a new tab, opening gvim if its not already open.
                >>
                >>> In this release it causes my CPU to run at 100% and then eventually
                >>> run out of memory and crash.
                >>

                A patch that fixes the problem is attached. The attached patch is
                "good enough" to use it for 0712B.

                For those who care, here's what was broken, what I fixed, and what is
                still broken. I'd appreciate comments if the remaining brokenness
                needs further fixing (Bram, are you listening? I'd like to get the
                fork patch into the core vim source, so please comment on this).

                Short version: I have to use `vim -f --remote bla` instead of `vim --
                remote bla -f` (the fix), but if no server is running yet, you still
                get the "Trying to execute locally" message twice.

                When you launch gvim from the terminal, you want it to become
                independent of the shell, so it's not closed when you close the shell.
                You also want to be able to pipe text into gvim (`ls | gvim -` for
                example). On Linux, this is done by "forking" the vim process (which
                means that a second vim process is started that is identical to the
                first), letting the first vim process terminate and changing the
                parent process of the newly forked child process. On Mac OS X, this is
                not possible in this form, because after you've forked a process you
                can't use any frameworks. Apple recommends re-executing the program
                from the beginning after a fork, so that's what my patch did.

                So vim starts up, realizes that it's starting the gui, and forks
                itself. The parent fork process dies, and the child process executes
                vim from the beginning, with the same command line parameters etc.
                Now, since vim is executed from the beginning, it would realize that
                it's starting the gui, fork again etc ad infinitum. To prevent this, I
                pass the "-f" ("don't fork") flag in addition to the other command
                line flags when I'm re-executing vim in the child process.

                The first problem was that I added the "-f" flag at the end, and as it
                turns out a "--remote" flag tries to send everything behind it to a
                server, so the "-f" flag was ignored in the child process. Because of
                this the child process forked a new child process, re-executed vim,
                which forked a child process, ... and so on, causing the problem. The
                attached patch simply passed "-f" as the first argument to the new
                process.

                A small problem remains: As it turns out, the remote server arguments
                are handled _before_ all this forking business takes place. Normally
                (ie, if there's already a vim server running), this is no problem,
                because vim checks if it should send a remote command and in that case
                connects to a vim server, sends the command, and exits (before any of
                the forking happens). But if no server is found, vim tries to execute
                the command locally (which simply means that vim starts up as usual
                and executes the command itself). So it does _not_ exit but proceeds
                to the forking stuff, where vim is restarted. The restarted vim tries
                to look for a server again, still doesn't find one, but this time it's
                able to finish its startup (since there's a "-f" don't fork flag).

                So even with this patch, *if no vim server is already running*, the
                remote server checks are executed twice (thus you get the "trying to
                execute locally" message twice.

                This is not optimal, but it's not too big a deal in my eyes :-P

                To fix this, I could do OS X' forking logic right at the start of
                main(). This would make startup a bit faster and solve this problem,
                but it makes the code harder to understand (because OS X' forking
                logic would be at a completely different place as it is for other
                Unices). Any opinions?

                Nico




                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • björn
                ... It wouldn t be the only place where similar things are done at different times for different OSs, so it doesn t sound too bad to me (and better than having
                Message 7 of 7 , Dec 4, 2007
                • 0 Attachment
                  On 04/12/2007, Nico Weber <nicolasweber@...> wrote:
                  > >>> I have aliased 'g' to 'gvim -p --remote-tab-silent', which in the
                  > >>> previous snapshot (and other versions of gvim) opens the named
                  > >>> file in
                  > >>> a new tab, opening gvim if its not already open.
                  > >>
                  > >>> In this release it causes my CPU to run at 100% and then eventually
                  > >>> run out of memory and crash.
                  > >>
                  >
                  > A patch that fixes the problem is attached. The attached patch is
                  > "good enough" to use it for 0712B.
                  >
                  > For those who care, here's what was broken, what I fixed, and what is
                  > still broken. I'd appreciate comments if the remaining brokenness
                  > needs further fixing (Bram, are you listening? I'd like to get the
                  > fork patch into the core vim source, so please comment on this).
                  >
                  > Short version: I have to use `vim -f --remote bla` instead of `vim --
                  > remote bla -f` (the fix), but if no server is running yet, you still
                  > get the "Trying to execute locally" message twice.
                  >
                  > When you launch gvim from the terminal, you want it to become
                  > independent of the shell, so it's not closed when you close the shell.
                  > You also want to be able to pipe text into gvim (`ls | gvim -` for
                  > example). On Linux, this is done by "forking" the vim process (which
                  > means that a second vim process is started that is identical to the
                  > first), letting the first vim process terminate and changing the
                  > parent process of the newly forked child process. On Mac OS X, this is
                  > not possible in this form, because after you've forked a process you
                  > can't use any frameworks. Apple recommends re-executing the program
                  > from the beginning after a fork, so that's what my patch did.
                  >
                  > So vim starts up, realizes that it's starting the gui, and forks
                  > itself. The parent fork process dies, and the child process executes
                  > vim from the beginning, with the same command line parameters etc.
                  > Now, since vim is executed from the beginning, it would realize that
                  > it's starting the gui, fork again etc ad infinitum. To prevent this, I
                  > pass the "-f" ("don't fork") flag in addition to the other command
                  > line flags when I'm re-executing vim in the child process.
                  >
                  > The first problem was that I added the "-f" flag at the end, and as it
                  > turns out a "--remote" flag tries to send everything behind it to a
                  > server, so the "-f" flag was ignored in the child process. Because of
                  > this the child process forked a new child process, re-executed vim,
                  > which forked a child process, ... and so on, causing the problem. The
                  > attached patch simply passed "-f" as the first argument to the new
                  > process.
                  >
                  > A small problem remains: As it turns out, the remote server arguments
                  > are handled _before_ all this forking business takes place. Normally
                  > (ie, if there's already a vim server running), this is no problem,
                  > because vim checks if it should send a remote command and in that case
                  > connects to a vim server, sends the command, and exits (before any of
                  > the forking happens). But if no server is found, vim tries to execute
                  > the command locally (which simply means that vim starts up as usual
                  > and executes the command itself). So it does _not_ exit but proceeds
                  > to the forking stuff, where vim is restarted. The restarted vim tries
                  > to look for a server again, still doesn't find one, but this time it's
                  > able to finish its startup (since there's a "-f" don't fork flag).
                  >
                  > So even with this patch, *if no vim server is already running*, the
                  > remote server checks are executed twice (thus you get the "trying to
                  > execute locally" message twice.
                  >
                  > This is not optimal, but it's not too big a deal in my eyes :-P
                  >
                  > To fix this, I could do OS X' forking logic right at the start of
                  > main(). This would make startup a bit faster and solve this problem,
                  > but it makes the code harder to understand (because OS X' forking
                  > logic would be at a completely different place as it is for other
                  > Unices). Any opinions?

                  It wouldn't be the only place where similar things are done at
                  different times for different OSs, so it doesn't sound too bad to me
                  (and better than having two "trying to..." messages twice if you ask
                  me).

                  Anyway, I applied the patch and pushed it to the repo...thanks for
                  fixing this so quickly!

                  /Björn

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                Your message has been successfully submitted and would be delivered to recipients shortly.