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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.