On Sep 19, 2013 2:01 PM, "kans" <mkania...@gmail.com> wrote: > > On Friday, September 13, 2013 2:43:13 AM UTC-7, kans wrote: > > On Thursday, September 12, 2013 1:59:51 AM UTC-7, ZyX wrote: > > > > > On Sep 12, 2013 3:28 AM, "kans" <mkan...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > On Wednesday, September 11, 2013 7:46:06 AM UTC-7, ZyX wrote: > > > > > > > > > > > > On Sep 11, 2013 1:27 PM, "Thomas" <wiene...@googlemail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11 September 2013 00:18, Nikolay Pavlov <zyx...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> Why do you keep calling it async? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Referring to the introduction to asynchronous programming linked below, the patch is an almost asynchronous feature, or at least a completition of the already existing asynchronous features of vim. With all the "autocmd-events" we already have the posibillity to run code asynchronous. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anyway asynchronous doesn't mean threaded, as far as I know and referring again to the link. That a two different concepts (which you can combine if you want). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://cs.brown.edu/courses/cs168/f12/handouts/async.pdf > > > > > > > > > > > > > > > > > > > > > > > > Now please show how you can run one sequence of commands interleaved with the other with this patch. Function that runs with given interval blocks everything until it completes, same for autocommands. You cannot say you implement preemptive multitasking if you have to wait for one task to complete before starting the other. It is not async feature. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You can, of course, do some hacks with saving a state, exiting and resuming, but you will then be forced to *emulate* preemption without any support from vim. I used to have some simple emulation even without such patch. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note though that I would really like it merged. But not with the current name. > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > 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 vim_dev+u...@googlegroups.com. > > > > > > > > > > > > > > > > > > > > > > > > > For more options, visit https://groups.google.com/groups/opt_out . > > > > > > > > > > > > > > > > > > > > > > ZyX, > > > > > > > > > > > > > > > > > > > > > > The new patch addresses your criticism apart from changing the name. I believe we obey Vim code conventions everywhere. We have also implemented a monotonically increasing timer for unix and osx which are the only two OSes we have on hand. Otherwise, we fall back to gettimeofday. Async is only #defined if gettimeofday exists. > > > > > > > > > > > > > > > You can take the code from python: since 3.3 it has monotonic() function defined in C code in time module: pymonotonic function in Modules/timemodule.c. It has implementation for windows as well. Linux implementation used CLOCK_MONOTONIC (or, with higher priority, CLOCK_HIRES which is not mentioned in my clock_gettime man page; I guess there is a reason for it) without _RAW, though I would write > > > > > > > > > > > > > > > #ifdef CLOCK_MONOTONIC_RAW > > > > > > > > > > CLOCK_MONOTONIC_RAW > > > > > > > > > > #else > > > > > > > > > > CLOCK_MONOTONIC > > > > > > > > > > #endif > > > > > > > > > > in function arguments. But it is not as severe as issue with gettimeofday: you cannot see 2 centuries hop with CLOCK_MONOTONIC, maximum slightly increased/decreased second duration when NTP daemon does his adjustments. > > > > > > > > > > > > > > > By the way, two pairs of figure braces may be removed from insert_timeout. Not that it is required by coding style, but this makes code look better. > > > > > > > > > > > Bram, > > > > > > > > > > > > > > > > > > > > > > We now use long longs for keeping track of the timers. We have also documented the new functions and some of their limitations. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please let us know if you have further feedback. > > > > > > > > > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > -- > > > > > > > > > > > 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 vim_dev+u...@googlegroups.com. > > > > > > > > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > ZyX, > > > > > > > > I added a monotonic timer for windows; I basically took the one from python. I also changed all the make files to include the new stuff as well. The patch is 1200 lines long now (37 files changed, 476 insertions, 24 deletions). The current state includes monotonically increasing timers for OsX, Win32, and *nix. It really doesn't make sense to add any more features, but I'm happy to do cleanup as needed. > > > > > > > > -Matt > > I was doing some work cleaning up the patch. It really does make sense to kill all intervals if one of them fails; its too annoying as an end user if a timeout fails every 50ms. The docstring for do_cmdline_cmd implies it should return FAIL if it can't evaluate "cmdline", but in practice it returns OK most of the time. For instance, evaluating a function that doesn't exist throws an error and returns OK. Some invalid expressions return OK, some, like "if (" don't. Does anyone know of an easy way to figure out of the expression could be evaluated and didn't throw?
I can suggest looking at VimTry* functions in src/if_py_both.h: they are used to transform all vim errors into python exceptions. Purge the python stuff and you will get C functions for wrapping arbitrary code into try/catch. > -Matt > > -- > -- > 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 vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
