2015-04-14 17:16 GMT+03:00 Bram Moolenaar <[email protected]>: > > James McCoy wrote: > >> On Mon, Apr 13, 2015 at 03:44:54PM +0200, Bram Moolenaar wrote: >> > >> > I included a few changes that were discussed on the neovim project. >> > I'm sure there are more, but it requires browsing through the issues and >> > locating the relevant ones. There is a lot of chatter on the issues. >> > Some have already been included. >> >> Another thing to be aware of is that Neovim has changed some core >> functionality of Vim in ways that will cause problems with Vim if >> patches are naïvely backported. >> >> One such change that comes to mind is memory allocation. There are a >> set of functions implemented in Neovim (xmalloc, xrealloc, etc.) which >> exit if memory can't be allocated, rather than propagating the failure >> up to the caller. For example, their ga_grow uses xrealloc so there's >> never a need to check its return for success, but there is in Vim (which >> might be an issue in 7.4.690). >> >> I haven't been paying enough attention to Neovim to know what else may >> be relevant for backporting patches, but wanted to raise the issue that >> it isn't necessarily a "simple" task even once it's known that a Neovim >> change applies to Vim. > > Yep, we have to look out for differences. In the recently included > patch I had to change free() to vim_free(). It's not complicated and > in most cases the patch won't apply (well, I couldn't apply any diff > automatically so far). > > It's weird to exit when running out of memory, that's not what users > want. It's easy to accidentally make a Vim script that consumes all > memory. It's making things easier for developers and worse for users. > Considering there are many more users than developers, that's a bad > choice.
It first tries to free memory and only then exits. Vim is by no means better because without proper testing it does not matter whether you are trying to handle OOM error or not: code is known to contain bugs and code that was never tested and almost never run is known to contain *lots* of bugs. It is wrong to say that Vim handles OOM cases better because you don’t actually know how it handles OOM. Also note that when user encounters OOM situation he usually thinks “I am low on memory, I need to close something because Vim is now buggy”, not “I need to report Vim being buggy when I am low on memory to vim-dev” because almost nobody tests OOM situations and thus applications are *expected* to show bugs, crashes or whatever in such case. Though I would better see NeoVim developers to add OOM testing rather then make the app crash, but this would add too much overhead for little gain because OOM is rare. What is not rare is moving memory to swap resulting in everything being slow and user closing applications. (And I have never seen VimL scripts which unintentionally run out of memory. Close enough was my yaml.vim parser with some weird input specifically constructed to cause problems with high probability.) > > Anyway, sometimes it's suffucient to just see what code to change to fix > a problem. > > -- > System administrators are just like women: You can't live with them and you > can't live without them. > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
