Re: [vim/vim] So many issues and pull requests with only one contributor? (#4518)
On Sunday, April 18, 2021 at 8:06:39 PM UTC-5 Gary Johnson wrote: > On 2021-04-18, Felipe Contreras wrote: > > Thanks for understanding. > > > > No, I don't understand. > > > > Any software developer doing things exactly the same as 10 years ago is > a bad > > software developer, let alone 30 years ago. > > That's just plain not true. A idea that was good 10 or even 30 > years ago may be just as good today. Ideas are good or bad because > they're good or bad, not because they're new or old. To think that > a new idea is better than an old one simply because it is new is > foolish. > This is such a profound misrepresentation of what I said that I need to explain with numbers. If 100 things have changed since the past 10 years, I said if you do *exactly* 100 things the same as 10 years ago, you are a bad software developer. You misrepresented what I said as: you must do 0 things the same as 10 years ago, which isn't what I said. Yes, ideas are good or bad intrinsically, not because of novelty or tradition (two fallacies), *but* chances are that if you do ZERO of 100 new things, you are doing something wrong. > > It literally takes less than 30 minutes to learn git. That's no excuse. > > That's not true, either. While basic git operations are reasonably > straightforward, anything beyond the basics is horribly obscure and > inconsistent. > Wrong. It depends on the operation. The operation of: 1. creating a feature branch, 2. applying a patch series, 3. merge that patch series with custom modifications, takes less than 10 minutes to learn. That is a fact. It's actually easier than whatever Bram is doing right now. -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/740c8783-3367-4a5c-966c-cdd3c149fd33n%40googlegroups.com.
Re: [vim/vim] So many issues and pull requests with only one contributor? (#4518)
吕海涛 : When looking for information about Vim, the place to look is always the built-in help. Not Google, not the manpages, not the github metadata, just the help. In this case: :help credits Best regards, Tony. -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJkCKXsQCJsK4V-j6WshzAuT5zv7JKHOCJ0%3Ddy_D_LFXXiurvw%40mail.gmail.com.
Re: [vim/vim] So many issues and pull requests with only one contributor? (#4518)
On 2021-04-18, Felipe Contreras wrote: > Thanks for understanding. > > No, I don't understand. > > Any software developer doing things exactly the same as 10 years ago is a bad > software developer, let alone 30 years ago. That's just plain not true. A idea that was good 10 or even 30 years ago may be just as good today. Ideas are good or bad because they're good or bad, not because they're new or old. To think that a new idea is better than an old one simply because it is new is foolish. > It literally takes less than 30 minutes to learn git. That's no excuse. That's not true, either. While basic git operations are reasonably straightforward, anything beyond the basics is horribly obscure and inconsistent. To paraphrase Jamie Zawinski's comment about regular expressions: Some people, when confronted with a problem, think "I know, I'll use git." Now they have two problems. And of course: https://xkcd.com/1597/ Regards, Gary -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20210419010729.GD8076%40phoenix.
Re: Pending appveyor build requests are not canceled when a PR is updated
On Mo, 16 Mär 2020, Ken Takata wrote: > Parallel builds may not work for the Free plan. > > https://www.appveyor.com/docs/parallel-testing/#requirements > > but jobs will run in series as the Free plan allows 1 concurrent job per > account. > > One possible option is utilizing GitHub Actions. It supports parallel builds. Ah okay, I missed that. It probably doesn't matter much, since we only have 2 distinct configurations for appveyor. Best, Christian -- Daß man einem Wasser nicht auf den Grund blicken kann, beweist noch nicht, daß es tief ist. -- Egon Friedell -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20200316083700.GC21810%40256bit.org.
Re: Pending appveyor build requests are not canceled when a PR is updated
Hi Christian, 2020/3/16 Mon 17:08:13 UTC+9 Christian Brabandt wrote: > > > On Sa, 14 Mär 2020, Dominique Pellé wrote: > > > Yegappan Lakshmanan > wrote: > > > > > Hi, > > > > > > When a PR is updated multiple times quickly, multiple build requests > > > are submitted to Travis-CI and Appveyor. In Travis-CI only the last > > > build request is processed and all the older pending build requests > are > > > canceled. But in Appveyor all the build requests are processed > > > in sequence. Is it possible to cancel all the pending build requests > > > for a PR when a build request is submitted in Appveyor? > > > > > > Thanks, > > > Yegappan > > > > Also, I experienced tests that were hanging in Appveyor and > > Appveyor would time out after 1 hour. It's too much. It wastes > > time. Appveyor tests normally take about 18 min. So a time out > > of 30 min would give enough margin. > > I have enabled Rolling builds for PRs, that should make sure, only the > latest commit is tested. I also lowered the build-timeout to 30 > minutes. And finally I enabled parallel builds, however it is not clear > to me, if this is only active for msbuild projects, so it might not have > an effect. > Parallel builds may not work for the Free plan. https://www.appveyor.com/docs/parallel-testing/#requirements > but jobs will run in series as the Free plan allows 1 concurrent job per account. One possible option is utilizing GitHub Actions. It supports parallel builds. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/a2221631-c93c-4c70-81ea-e455f015d3be%40googlegroups.com.
Re: Pending appveyor build requests are not canceled when a PR is updated
On Sa, 14 Mär 2020, Dominique Pellé wrote: > Yegappan Lakshmanan wrote: > > > Hi, > > > > When a PR is updated multiple times quickly, multiple build requests > > are submitted to Travis-CI and Appveyor. In Travis-CI only the last > > build request is processed and all the older pending build requests are > > canceled. But in Appveyor all the build requests are processed > > in sequence. Is it possible to cancel all the pending build requests > > for a PR when a build request is submitted in Appveyor? > > > > Thanks, > > Yegappan > > Also, I experienced tests that were hanging in Appveyor and > Appveyor would time out after 1 hour. It's too much. It wastes > time. Appveyor tests normally take about 18 min. So a time out > of 30 min would give enough margin. I have enabled Rolling builds for PRs, that should make sure, only the latest commit is tested. I also lowered the build-timeout to 30 minutes. And finally I enabled parallel builds, however it is not clear to me, if this is only active for msbuild projects, so it might not have an effect. Best, Christian -- Der Physikprofessor: "Was wissen sie über Ammoniak?" Der Student: "Ich weiß nur, daß es zu Tränen reizt!" Der Professor: "Ihre Antwort auch!" -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20200316080809.GB21810%40256bit.org.
Re: Pending appveyor build requests are not canceled when a PR is updated
Yegappan Lakshmanan wrote: > Hi, > > When a PR is updated multiple times quickly, multiple build requests > are submitted to Travis-CI and Appveyor. In Travis-CI only the last > build request is processed and all the older pending build requests are > canceled. But in Appveyor all the build requests are processed > in sequence. Is it possible to cancel all the pending build requests > for a PR when a build request is submitted in Appveyor? > > Thanks, > Yegappan Also, I experienced tests that were hanging in Appveyor and Appveyor would time out after 1 hour. It's too much. It wastes time. Appveyor tests normally take about 18 min. So a time out of 30 min would give enough margin. Regards Dominique -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAON-T_hVA0usHM6%2BCtz1hQQs-OR3WgMKzm%3D_DVsYEvCekpfK8Q%40mail.gmail.com.
Pending appveyor build requests are not canceled when a PR is updated
Hi, When a PR is updated multiple times quickly, multiple build requests are submitted to Travis-CI and Appveyor. In Travis-CI only the last build request is processed and all the older pending build requests are canceled. But in Appveyor all the build requests are processed in sequence. Is it possible to cancel all the pending build requests for a PR when a build request is submitted in Appveyor? Thanks, Yegappan -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAAW7x7%3DUQi%3DqgZhwwvUzTE7FhOsb5J%2BewGsHFi0%2B2KBP0YfbUA%40mail.gmail.com.
Re: Vim appears to stall channel based requests
Thank you, Bram and Pontus, for tracking this one down! On Fri, 28 Jun 2019 at 22:05, Pontus Leitzler wrote: > > Yeah, I don't really understand what triggers it. I've tried to create a > small reproducible but I can't seen to make it trigger this. Could be a > timing issue. > > One thing I thought about is the 10ms delay that is added if there is more to > read from the channel(?). That might introduce some latency to channel-based > plugins that send many small messages. > > In my case Paul Jolly's proposal about a sign_setlist > (https://github.com/vim/vim/issues/4557) would help, but I guess there are > other cases where it might get slow. > > -- > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/vim_dev/7ac768c0-6bc8-421b-b5bb-7e260c77271a%40googlegroups.com. > 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CACoUkn4M9kpJNGxdO%2BRW3ZCPO-S9Ze2hk4cBUM6uRMsU_zzDhA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
Yeah, I don't really understand what triggers it. I've tried to create a small reproducible but I can't seen to make it trigger this. Could be a timing issue. One thing I thought about is the 10ms delay that is added if there is more to read from the channel(?). That might introduce some latency to channel-based plugins that send many small messages. In my case Paul Jolly's proposal about a sign_setlist (https://github.com/vim/vim/issues/4557) would help, but I guess there are other cases where it might get slow. -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/7ac768c0-6bc8-421b-b5bb-7e260c77271a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
> > Please try if this patch fixes your problem:
> >
> > --- prev/src/channel.c 2019-06-24 00:43:31.463691826 +0200
> > +++ channel.c 2019-06-28 04:41:25.767304149 +0200
> > @@ -2850,10 +2850,13 @@
> >
> > if (ch_mode == MODE_JSON || ch_mode == MODE_JS)
> > {
> > - jsonq_T *head = &channel->ch_part[part].ch_json_head;
> > - jsonq_T *item = head->jq_next;
> > + jsonq_T *head;
> >
> > - return item != NULL;
> > + // Parse json from readahead before checking the queue.
> > + channel_parse_json(channel, part);
> > +
> > + head = &channel->ch_part[part].ch_json_head;
> > + return head->jq_next != NULL;
> > }
> > return channel_peek(channel, part) != NULL;
> > }
> >
>
> Works like a charm!
Thanks for checking, I'll include that change then.
Would be nice to have a test, but that may take some effort to create.
--
Facepalm reply #3: "I had a great time in Manhattan" "I thought you were
going to New York?"
/// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/201906282007.x5SK7IWw005549%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
> Please try if this patch fixes your problem:
>
> --- prev/src/channel.c2019-06-24 00:43:31.463691826 +0200
> +++ channel.c 2019-06-28 04:41:25.767304149 +0200
> @@ -2850,10 +2850,13 @@
>
> if (ch_mode == MODE_JSON || ch_mode == MODE_JS)
> {
> - jsonq_T *head = &channel->ch_part[part].ch_json_head;
> - jsonq_T *item = head->jq_next;
> + jsonq_T *head;
>
> - return item != NULL;
> + // Parse json from readahead before checking the queue.
> + channel_parse_json(channel, part);
> +
> + head = &channel->ch_part[part].ch_json_head;
> + return head->jq_next != NULL;
> }
> return channel_peek(channel, part) != NULL;
> }
>
Works like a charm!
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/a42e8238-2c35-44e8-88dc-1fe7137c951d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
Pontus Leitzler wrote:
> Just to summarize:
> - channel_read() reads 63 bytes and calls channel_save()
> - channel_save() saves those to a new node->rq_buffer at the end of channel=
> head
>
> To convert it to JSON someone must call channel_parse_json(), and it can be=
> either from channel_read_json_block() or may_invoke_callback().
> My logs shows that it is via may_invoke_callback() until it hangs.
>
> - may_invoke_callback() is called from channel_parse_messages()
> - channel_parse_messages() is called from parse_queued_messages()
> - parse_queued_messages() is called from inchar_loop()
>
> But, since channel_parse_json() haven't been called yet for the latest mess=
> age, inchar_loop() will allow a wait_func()-call with wait_time =3D=3D -1 (=
> that leads to RealWaitForChar() NULL).
>
> To avoid it, inchar_loop() calls channel_any_readahead(), but it will retur=
> n FALSE since the messages haven't been parsed to JSON yet and it only chec=
> ks the JSON queue in JSON mode.
>
> So I guess the solution to this is to either let channel_any_readahead() ca=
> ll channel_peek() in JSON mode as well, or add a call to channel_parse_json=
> () somewhere to ensure that the incoming message has been parsed so that ch=
> annel_any_readahead() returns TRUE in JSON-mode (?).
>
> I'm sorry if my explanation is messy, it's probably a combination of me not=
> being familiar with the code base as well as not being native English :)
Thanks for the digging and explanation. channel_has_readahead() is
called in a few places, checking if there is something ready to read.
But it doesn't use any received text on a JSON channel if it hasn't been
parsed yet. It looks like calling channel_parse_json() in
channel_has_readahead() would be the right thing to do.
Please try if this patch fixes your problem:
--- prev/src/channel.c 2019-06-24 00:43:31.463691826 +0200
+++ channel.c 2019-06-28 04:41:25.767304149 +0200
@@ -2850,10 +2850,13 @@
if (ch_mode == MODE_JSON || ch_mode == MODE_JS)
{
- jsonq_T *head = &channel->ch_part[part].ch_json_head;
- jsonq_T *item = head->jq_next;
+ jsonq_T *head;
- return item != NULL;
+ // Parse json from readahead before checking the queue.
+ channel_parse_json(channel, part);
+
+ head = &channel->ch_part[part].ch_json_head;
+ return head->jq_next != NULL;
}
return channel_peek(channel, part) != NULL;
}
--
The greatest lies of all time:
(1) The check is in the mail.
(2) We have a really challenging assignment for you.
(3) I love you.
(4) All bugs have been fixed.
(5) This won't hurt a bit.
(6) Honey, I just need to debug this program and be home in 5 minutes.
(7) I have just sent you an e-mail about that.
(8) Of course I'll respect you in the morning.
(9) I'm from the government, and I'm here to help you.
/// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/201906280258.x5S2w16o028398%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
Just to summarize: - channel_read() reads 63 bytes and calls channel_save() - channel_save() saves those to a new node->rq_buffer at the end of channel head To convert it to JSON someone must call channel_parse_json(), and it can be either from channel_read_json_block() or may_invoke_callback(). My logs shows that it is via may_invoke_callback() until it hangs. - may_invoke_callback() is called from channel_parse_messages() - channel_parse_messages() is called from parse_queued_messages() - parse_queued_messages() is called from inchar_loop() But, since channel_parse_json() haven't been called yet for the latest message, inchar_loop() will allow a wait_func()-call with wait_time == -1 (that leads to RealWaitForChar() NULL). To avoid it, inchar_loop() calls channel_any_readahead(), but it will return FALSE since the messages haven't been parsed to JSON yet and it only checks the JSON queue in JSON mode. So I guess the solution to this is to either let channel_any_readahead() call channel_peek() in JSON mode as well, or add a call to channel_parse_json() somewhere to ensure that the incoming message has been parsed so that channel_any_readahead() returns TRUE in JSON-mode (?). I'm sorry if my explanation is messy, it's probably a combination of me not being familiar with the code base as well as not being native English :) Best regards, Pontus -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/7ac5d58e-0935-49a5-946f-bb8ae47cabf9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
> That doesn't look right, because there should not be a complete json message.
> If there is, perhaps a call to parse it is missing?
> Perhaps a call to channel_parse_json() is needed.
Yes, maybe there is a channel_parse_json() missing somewhere. But as the flow
log shows it's also a channel_parse_messages()-call missing.
> If the JSON is incomplete we need to receive more text to be able to parse
> it. Thus we might as well block on receiving something.
Thing is, I think that the JSON is actually complete, but since
channel_parse_messages() isn't called it never gets the chance to parse the
JSON content. That's how I read the logs at least.
> So what is in those 64 bytes? If you look in the channel log it should be
> there. You don't quote from a channel log, did you use ch_logfile()?
That was just pseudo-logs handwritten :) I ran it again and this time include
what is actually read from the channel in channel_read().
Since I do get a few signs placed I can see in the log how it looks like when
it works, this is one of the signs that gets placed:
RealWaitForChar() is called with 0 delay
channel_read() is called from RealWaitForChar(), it reads 63 bytes into the
buffer
channel_save() is called from channel_read() with the buffer that starts with:
[0,[34,"call","sign_place",0,"govim","govimerr",1,{"lnum":6}]] (and 0x0a at the
end)
RealWaitForChar() is called with 0 delay
RealWaitForChar() is called with 0 delay
RealWaitForChar() is called with 0 delay
channel_parse_messages() is called from parse_queued_messages()
channel_peek is called (for part 0)
channel_get_json is called
channel_parse_json is called
channel_peek is called (for part 1)
channel_get_json is called
channel_peek is called (for part 0)
channel_get_json is called
channel_parse_json is called
channel_peek is called (for part 1)
channel_get_json is called
channel_get_json is called
channel_parse_json is called
channel_peek is called (for part 2)
channel_get_json is called
And when it doesn't work it never gets to the channel_parse_messages() call:
RealWaitForChar() is called with 0 delay
channel_read() is called from RealWaitForChar(), it reads 64 bytes into the
buffer
channel_save() is called from channel_read() with the buffer that starts with:
[0,[41,"call","sign_place",0,"govim","govimerr",1,{"lnum":12}]] (and 0x0a at
the end)
RealWaitForChar() is called with 0 delay
RealWaitForChar() is called with 0 delay
RealWaitForChar() is called with 0 delay
channel_peek is called (part 0, I don't know from where)
channel_peek is called (part 0, I don't know from where)
RealWaitForChar() is called with -1 (as wait_func)
Ok, so I see what you referred to with:
> In inchar_loop() it should call parse_queued_messages() before blocking,
I did run again and logged the inchar_loop() calls, there are only two in the
entire run and both with -1 as wtime.
So, we end up inside inchar_loop(), before calling wait_func() with a wait_time
value set to -1 (that will block).
And to ensure that parse_queued_messages() are called before sleeping, either
has_pending_job() or channel_any_readahead() must return TRUE, right?
That would explain why the patch to channel_any_readahead() works, since it
will make it return TRUE?
Or should it be another check to ensure that parse_queued_messages() is called
before blocking?
Best regards, Pontus
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/39af4c19-2eaf-4cdd-baef-52ed1094f390%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
> This is a patch that actually fixes the problem, but I have no idea what > other side effects it might have. Also note that the line numbers are way off > since I've been adding stuff. > > @@ -2853,7 +2853,7 @@ channel_has_readahead(channel_T *channel, ch_part_T > part) > jsonq_T *head = &channel->ch_part[part].ch_json_head; > jsonq_T *item = head->jq_next; > > - return item != NULL; > + return (item != NULL) || (channel_peek(channel, part) != NULL); > } > return channel_peek(channel, part) != NULL; > } That doesn't look right, because there should not be a complete json message. If there is, perhaps a call to parse it is missing? Perhaps a call to channel_parse_json() is needed. -- hundred-and-one symptoms of being an internet addict: 267. You get an extra phone line so you can get phone calls. /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201906250213.x5P2D8Xd007297%40masaka.moolenaar.net. For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
> In both cases it's called from the end of WaitForCharOrMouse. > I'm not entirely sure I get all line numbers right, even when I compile vim > with -g -O0, so I had to go with the "Fprintf to stderr"-monkey style :). > > One further step in the stack trace: > ui_wait_for_chars_or_timer(...), the line "if (wait_func(due_time, > interrupted, ignore_input))". > Due_time is -1, interrupted 1 and ignore input 0. > > I guess it's the calls to has_pending_job() and > channel_any_readahead() that decides if there are more to read? But > wouldn't channel_any_readahead() require the message to have been > parsed to json before returning TRUE? If the JSON is incomplete we need to receive more text to be able to parse it. Thus we might as well block on receiving something. > An example flow when it works: > Channel_read - 63 bytes > Channel_parse_messages > Channel_parse_json > Channel_parse_json > Channel_parse_json > RealWaitForChar (from mch_breakcheck, with 0 timeout) > > Then after a while: > Channel_read - 64 bytes > RealWaitForChar (from mch_breakcheck, with 0 timeout) So what is in those 64 bytes? If you look in the channel log it should be there. You don't quote from a channel log, did you use ch_logfile()? > RealWaitForChar (from mch_breakcheck, with 0 timeout) > RealWaitForChar (from mch_breakcheck, with 0 timeout) > RealWaitForChar (from mch_breakcheck, with 0 timeout) > RealWaitForChar (from ui_wait_for_chars_or_timer as wait_func.. with -1 > timeout) > // The select() call that hangs until keypressed > Channel_parse_messages > Channel_parse_json > Channel_parse_json > Channel_parse_json -- Two fish in a tank. One says to the other: "Do you know how to drive this thing?" /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201906250213.x5P2D8x7007291%40masaka.moolenaar.net. For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
https://github.com/MarcWeber/vim-addon-signs all you do is pass a list, incremental updates get applied. However if you have > 5,000 signs or so it might make sense to limit to first X items .. Eventually could still be done faster eg using Python whatever. Marc Weber -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/1561414175-sup-3866%40nixos. For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
This is a patch that actually fixes the problem, but I have no idea what other side effects it might have. Also note that the line numbers are way off since I've been adding stuff. @@ -2853,7 +2853,7 @@ channel_has_readahead(channel_T *channel, ch_part_T part) jsonq_T *head = &channel->ch_part[part].ch_json_head; jsonq_T *item = head->jq_next; - return item != NULL; + return (item != NULL) || (channel_peek(channel, part) != NULL); } return channel_peek(channel, part) != NULL; } -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/8f763fc1-28fe-48d7-8471-75ad7d7977e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
In both cases it's called from the end of WaitForCharOrMouse. I'm not entirely sure I get all line numbers right, even when I compile vim with -g -O0, so I had to go with the "Fprintf to stderr"-monkey style :). One further step in the stack trace: ui_wait_for_chars_or_timer(...), the line "if (wait_func(due_time, interrupted, ignore_input))". Due_time is -1, interrupted 1 and ignore input 0. I guess it's the calls to has_pending_job() and channel_any_readahead() that decides if there are more to read? But wouldn't channel_any_readahead() require the message to have been parsed to json before returning TRUE? An example flow when it works: Channel_read - 63 bytes Channel_parse_messages Channel_parse_json Channel_parse_json Channel_parse_json RealWaitForChar (from mch_breakcheck, with 0 timeout) Then after a while: Channel_read - 64 bytes RealWaitForChar (from mch_breakcheck, with 0 timeout) RealWaitForChar (from mch_breakcheck, with 0 timeout) RealWaitForChar (from mch_breakcheck, with 0 timeout) RealWaitForChar (from mch_breakcheck, with 0 timeout) RealWaitForChar (from ui_wait_for_chars_or_timer as wait_func.. with -1 timeout) // The select() call that hangs until keypressed Channel_parse_messages Channel_parse_json Channel_parse_json Channel_parse_json -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/25e08407-fd94-4924-a969-3b1a6e51777e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim appears to stall channel based requests
Pontus Leitzler wrote: > I wrote the previous post yesterday but since it was my first it had > to be moderated before showing up. > > Since then I did some more investigation and it turns out that the channel is > indeed read in channel_read(...), but then the blocking select() prevents the > incoming message to be processed. > As soon as the blocking select returns (when I press a key), > channel_parse_messages(...) is called and parses the buffer read before the > select()-call. > > I expect that select() should be called with 0 timeout as long as the channel > buffers haven't been processed entirely, is that a correct assumption? Should > I write an issue in the github tracker? So messages are ready to process, but Vim instead blocks on getting more input? Can you find out where RealWaitForChar() is called from? In inchar_loop() it should call parse_queued_messages() before blocking, and if more input is needed set the wait time to 10. -- hundred-and-one symptoms of being an internet addict: 260. Co-workers have to E-mail you about the fire alarm to get you out of the building. /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201906240308.x5O384AU011577%40masaka.moolenaar.net. For more options, visit https://groups.google.com/d/optout.
Vim appears to stall channel based requests
I wrote the previous post yesterday but since it was my first it had to be moderated before showing up. Since then I did some more investigation and it turns out that the channel is indeed read in channel_read(...), but then the blocking select() prevents the incoming message to be processed. As soon as the blocking select returns (when I press a key), channel_parse_messages(...) is called and parses the buffer read before the select()-call. I expect that select() should be called with 0 timeout as long as the channel buffers haven't been processed entirely, is that a correct assumption? Should I write an issue in the github tracker? Regards, Pontus -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/bc265408-3008-41bf-860b-0d6e7d639bf8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Vim appears to stall channel based requests
Hi everyone, I've been trying to create a smaller reproducible that can demo what happens, but it seems to be a complex combination that isn't trivial to slice down. So I went for another option, debugging vim instead. Since the binary I have can reproduce the behavior consistently I thought that it might give me some new clues. First a disclaimer, this is the first time I look at vim code, and my C is, at best, very rusty :). It looks like the signs are being placed, but there are still signs to place, when the select()-call after channel_select_setup(...) in os_unix.c:RealWaitForChar(...) get called with NULL as timeout. Then it hangs on the select() until a key is pressed. There are also another occasion when that select() isn't called with 0 as timeout, and that is when it is called with whatever updatetime is set to in my .vimrc. That also makes sign placement stop for as long as updatetime is set to. Since I'm not that into the vim source I don't know if the channel should be a part of the select but isn't, or if the issue is that the channel already has been read into a buffer that can't be processed since the select-call stops further execution. But I hope that this info might shred some new light to this issue. If you have any patch ideas to vim that can give additional info I'd be glad to try them out. Best regards, Pontus -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2632fbab-bccb-4de6-b6f8-5e3a84966a28%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Vim appears to stall channel based requests
Hi all,
In https://github.com/leitzler/govim (master branch) Pontus is adding
support to govim for signs that correspond to quickfix entries.
This is done by calling sign_place/sign_unplace as required to get the
signs for a window in the correct state.
If there are lots of errors in a file, then there can be a large
number of calls to sign_place/sign_unplace made by govim in rapid
succession.
(Incidentally, it would be great if there was a “batch” method to set
the signs for a buffer, akin to setqflist for signs in a buffer)
However, on what is a relatively slow machine, @leitzler is seeing Vim
stall when handling calls from govim to sign_place:
https://gist.github.com/myitcv/f8579a20ce327d61c550c85df71ea4a2
Notice the ~13 second gap between the call to sign_place:
1.102629 RECV on 0(sock):
'[0,[36,"call","sign_place",0,"govim","govimerr",1,{"lnum":10}]]
and the response:
14.247893 SEND on 0(sock):
'[38,["function","function:GOVIM_internal_SetUserBusy",[1]]]
'
14.248988 on 0: Blocking read JSON for id 38
14.249019 : looking for messages on channels
14.249025 on 0: Getting JSON message 0
14.249028 on 0: Invoking channel callback 12_define
14.249201 SEND on 0(sock): '[39,["callback",36,["",7]]]
Indeed, the response only gets sent after 13 seconds because of a
cursor movement, which as you can see is also handled by a
channel-based function. That is to say a cursor movement (which
triggers a call to a channel-based plugin function) appears to "fix"
things - a few more function calls are handled, but then things
"stall" again. i.e. not all the sign_place calls have been completed.
I realise this is all rather vague (and indeed it would be somewhat
moot if we had a batch function for setting signs for a buffer), but
is there anything that could be causing Vim to stall like this?
Vim v8.1.1512.
Thanks in advance for any suggestions/pointers,
Paul
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/CACoUkn4p6-Mg49fw%3DdZ0V%2B%2Bp2BH_OFxt2jUpg66Rw-gEmU_Fkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: taglist.vim and pull requests
Excerpts from ashwin sathya's message of Sat Jun 01 22:56:38 +0200 2013: > vundle to manage the plugins. Get started with vim-addon-manager and your problems are gone because - it honors authors upstreams - it fetches most recent plugins from vim.sf.net, not form a mirror. I still want to see vim-scripts.org to be continued because it also is a perfect backup of vim.sf.net I've also filed a bug report with some hints that they do no longer need a scraping script at all to run their service: https://github.com/vim-scraper/vim-scraper/issues/7://github.com/vim-scraper/vim-scraper/issues/78 Marc Weber -- -- 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.
Re: taglist.vim and pull requests
Hi, I have downloaded the sources from there. Thanks for the update. The reasoning behind my query is the fact that i am extensively using vundle to manage the plugins. On Sat, Jun 1, 2013 at 11:50 AM, Yegappan Lakshmanan wrote: > Hi, > > On Sat, Jun 1, 2013 at 9:34 AM, ashwin sathya > wrote: > > > > https://github.com/vim-scripts/taglist.vim > > > > There are several pull requests (A version update is also present) > > Who owns and maintains these scripts in the github ? > > > > I released version 4.6 of the taglist plugin few months ago. The Git hub > repository has the 4.5 version. I don't know who is the owner of the > Github vim-scripts repository. I tried updating the repository. But > couldn't > update it due to insufficient permissions. > > You can download the latest plugin from the following sites: > > http://vim-taglist.sourceforge.net/ > http://www.vim.org/scripts/script.php?script_id=273 > > - Yegappan > > -- > -- > 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. > > > -- Thanks & Regards, R Ashwin Sathya -- -- 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.
Re: taglist.vim and pull requests
On 01-Jun-2013 20:50 +0200, Yegappan Lakshmanan wrote: > I released version 4.6 of the taglist plugin few months ago. The Git hub > repository has the 4.5 version. I don't know who is the owner of the > Github vim-scripts repository. I thinks it's more or less two guys; you can contact / open issues here: http://vim-scripts.org/vim/support.html The site seems to be in "permanent beta"; I think the scraping of the vim.org master still needs to be triggered manually by the owners, and sometimes the scraper breaks down and needs to be fixed. It's not very reliable, unfortunately. > I tried updating the repository. But couldn't update it due to > insufficient permissions. That has to be done by their scraper script. -- regards, ingo -- -- 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.
Re: taglist.vim and pull requests
Hi, On Sat, Jun 1, 2013 at 9:34 AM, ashwin sathya wrote: > > https://github.com/vim-scripts/taglist.vim > > There are several pull requests (A version update is also present) > Who owns and maintains these scripts in the github ? > I released version 4.6 of the taglist plugin few months ago. The Git hub repository has the 4.5 version. I don't know who is the owner of the Github vim-scripts repository. I tried updating the repository. But couldn't update it due to insufficient permissions. You can download the latest plugin from the following sites: http://vim-taglist.sourceforge.net/ http://www.vim.org/scripts/script.php?script_id=273 - Yegappan -- -- 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.
Re: taglist.vim and pull requests
On 01-Jun-2013 18:34 +0200, ashwin sathya wrote: > https://github.com/vim-scripts/taglist.vim > > > There are several pull requests (A version update is also present) > Who owns and maintains these scripts in the github ? The mirrors on http://vim-scripts.org/ are not necessarily monitored by the plugin authors, as this is an independent project; it's unfortunate that the issue tracker and pull requests for all plugins are open and inviting. If you follow the link in the repository's description to the original plugin page on vim.org, you'll see that the plugin is maintained by Yegappan Lakshmanan. The latest update is from 2013-02-27, so it's likely that the author will react to your feedback. You'll find his email address both on his vim.org user page and in the taglist documentation. -- regards, ingo -- -- 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.
taglist.vim and pull requests
https://github.com/vim-scripts/taglist.vim There are several pull requests (A version update is also present) Who owns and maintains these scripts in the github ? -- Thanks & Regards, R Ashwin Sathya -- -- 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.
Re: Access will be denied if you use POST requests more than 15 times within 4 hours from now on
Thanks for reporting - looks like he finally suceeded - and didn't read the message .. Hi xingchao, (this mail also goes to vim_dev mailinglist) If you cannot upload, you should see a message instead. Due to attacks we've limited actions to 15 POST requests by IP. Another global limit does exist. Do you remember which one was hit? The message should have told you. Eventually we should allow more operations. In any case - do you have any idea why "why I can't upload" is shown that often :) ? Sincerly Marc Weber -- -- 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.
Re: Access will be denied if you use POST requests more than 15 times within 4 hours from now on
Hi Bram! On Mi, 01 Mai 2013, Bram Moolenaar wrote: > I think we can be rather strict. If a human is doing a lot of work, we > can ask him to try again in 4 hours. And send us a message that this > happened, so that we can tune the limit. Perhaps for specific cases. I think it just happened: http://www.vim.org/scripts/script.php?script_id=4509 regards, Christian -- Es herrscht Chaos. Wir befinden uns auf einer Drehscheibe, die Richtung in die Zukunft ist noch nicht gefunden. Vielleicht muß diese Menschheit untergehen, damit eine andere entstehen kann. -- Stanislav Lem -- -- 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.
Re: Access will be denied if you use POST requests more than 15 times within 4 hours from now on
Marc Weber wrote: > I've introduced a total limit of 500 POST requests within 4h which is > slightly more than POST requests happen within 24h on an average day > (380 posts in 24h) > > Thus if a bot uses multiple IPs, he should still fail soon > (unfortunately everybody else, too) - I think its more importatnt to > protect against attacks in these cases.. Because we don't want to delete > that many scripts and user accounts. > > I hope vim.sf.net is much safer now. I don't have any additional ideas. > So let me know whether you think these changes are appropriate. Thanks for doing this! I think we can be rather strict. If a human is doing a lot of work, we can ask him to try again in 4 hours. And send us a message that this happened, so that we can tune the limit. Perhaps for specific cases. Please send me a diff of the changes you made (or the new files) privately. Otherwise a sync from my side might overwrite your changes. Cc John Beckett, he is also keeping an eye on things. -- hundred-and-one symptoms of being an internet addict: 255. You work for a newspaper and your editor asks you to write an article about Internet addiction...in the "first person." /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Access will be denied if you use POST requests more than 15 times within 4 hours from now on
I've introduced a total limit of 500 POST requests within 4h which is slightly more than POST requests happen within 24h on an average day (380 posts in 24h) Thus if a bot uses multiple IPs, he should still fail soon (unfortunately everybody else, too) - I think its more importatnt to protect against attacks in these cases.. Because we don't want to delete that many scripts and user accounts. I hope vim.sf.net is much safer now. I don't have any additional ideas. So let me know whether you think these changes are appropriate. Marc Weber -- -- 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.
Re: Access will be denied if you use POST requests more than 15 times within 4 hours from now on
This still does not protect agains resource exhaustion (mysql users exceeded - which appened). There are modules for apache to prevent excessive site usage by bot like attacks. Maybe we should propose sourcreforge to set them up? Marc Weber -- -- 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.
Access will be denied if you use POST requests more than 15 times within 4 hours from now on
Excerpts from John Beckett's message of Wed May 01 04:29:16 +0200 2013: > 124 user accounts, including text fields intended to probe for > bugs that might be exploited to break in to the system. The bot did at least 20 login attemps per second ! http://www.vim.org/account/register.php I've added a minimal "I'm human test" - that should at least protect against "random attacks" made by bots without human intelligence. And if there are humans running the attack, then we have lost anyway. So its pretty easy: create a new table. Log IP when $_POST is not empty If an IP is using POST more than 15 times in 4 hours assume its a bot and die. A typical session: - login (POST 1) - update 5 scriptsr (POST 2-5) Thus 7 post requests. If you forgett your password 5 times - then you're still fine. Yes, there might be false positives - eg many people behind firewalls try to update their scripts within 4 hours but honestly scripts are not updated *that* often. Another problem could be you typing the same password 15 times ..) If this causing problems, please report it. The die message also tells this. vim.org/search.php is not affected, $_GET is used the way it should. Neither should it affect google (which may also run some post requests, usually based on JS init scripts) I hope this makes www.vim.org a lot more "bot proof" now. The implementation can be found in the datab*.inc file. Maybe its not the right place, but it should work. There have been too many issues lately. Marc Weber -- -- 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.
Re: [conceal] Requests
Charles Campbell wrote: > Hello, Hello, > If I may ask, how did you find out about it? I suspect that there's a lot > of LaTeX users out there that would like to use the conceal feature but > don't know about it. I found out by some random walk on vim related websites the address http://b4winckler.wordpress.com/2010/08/07/using-the-conceal-vim-feature-with-latex/ (oh, well, the random web site that pointed to it happens to to be *your* site, in the links section) This feature definitely deserves more advertisement. Cheers, P! PS: reloading the file is fast enough, and ":e" is a lot easier to type :) -- Français, English, 日本語, 한국어 -- 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
Re: [conceal] Requests
Adrien "Axioplase" Piérard wrote: I would like to express some regrets regarding this extremely useful feature, and thus plea for some enhancements, should anyone capable of coding them read this. Hello, If I may ask, how did you find out about it? I suspect that there's a lot of LaTeX users out there that would like to use the conceal feature but don't know about it. Regards, Chip Campbell -- 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
Re: Requests
Adrien "Axioplase" Piérard wrote: Hello, 2011/6/14 Ben Fritz: Am I correct in my understanding, that your file .vim/after/syntax/ tex.vim, has a line like: let g:tex_conceal='agm' ? If so, then your problem is in assuming the g:tex_conceal "option" works like built-in Vim options like 'wrap' or 'guifont' Yes, I feel a bit ashamed, now you point this out :) May I point out that, instead of using :e you could use :set ft=tex and that will re-initialize the syntax (without re-loading the file). Regards, Chip Campbell -- 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
Re: [conceal] Requests
2011/6/13 Christian Brabandt : > Hi Adrien! Hello Christian, > On Mo, 13 Jun 2011, Adrien "Axioplase" Piérard wrote: >> 1/ It is very annoying that when one is moving in a concealed line, >> motions consider the underlying text rather that what can be seen. > I started working on a patch, that would make this possible. But it's > not that easy and it didn't seem like this feature would be applied to > vim anytime soon, so I didn't continue. It is a pity you could not finish it :) Not having time to delve into this, I guess that I'll have to wait for the conceal feature to gain more fame until this feature becomes requested by more people. Cheers, P! -- Français, English, 日本語, 한국어 -- 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
Re: Requests
Hello, 2011/6/14 Ben Fritz : > Am I correct in my understanding, that your file .vim/after/syntax/ > tex.vim, has a line like: > let g:tex_conceal='agm' > ? > If so, then your problem is in assuming the g:tex_conceal "option" > works like built-in Vim options like 'wrap' or 'guifont' Yes, I feel a bit ashamed, now you point this out :) Cheers, P! -- Français, English, 日本語, 한국어 -- 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
Re: Requests
On Jun 13, 12:25 am, Adrien "Axioplase" Piérard wrote: > > 3/ A bug? > I open a tex file, and>> :echo g:tex_conceal > >> agm > > as set in .vim/after/syntax/tex.vim, which is loaded, I think, last, > and sets cole to 2, and cocu to nc. > However, the dollars in LaTeX's math mode do not appear. > If I reload the file with>> :e > > then they do appear as wanted. > Am I correct in my understanding, that your file .vim/after/syntax/ tex.vim, has a line like: let g:tex_conceal='agm' ? If so, then your problem is in assuming the g:tex_conceal "option" works like built-in Vim options like 'wrap' or 'guifont' where they take effect immediately. Anything that looks like g:some_var_name (which you will need to set using the :let command, rather than :set or :setlocal) is not really an option but a vimscript variable. Setting these variables has no effect by itself. This particular variable is probably examined by the tex.vim syntax file to determine which rules to set up. Therefore, it needs to be set *before* the tex.vim syntax file is sourced to have the desired effect. The best place to put this particular option is therefore not in an "after" file, but rather in your .vimrc or a plugin file. -- 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
Re: [conceal] Requests
Hi Adrien! On Mo, 13 Jun 2011, Adrien "Axioplase" Piérard wrote: > 1/ It is very annoying that when one is moving in a concealed line, > motions consider the underlying text rather that what can be seen. For > example, suppose I have > >> $\lambda 42$ > which will be rendered as > >> $λ 42$ > and that my cursor is on the first dollar. To move to the space, I > wish I could just do "", but instead, I'll have to do > '' eight times; this is very inconvenient. > (Of course, I could do "f" or any other thing to achieve the > expected motion, but this not my point here.) > A nice behaviour would be that, when a line is concealed, motions work > on the visible text, and that if I press, say, "x" when the cursor in > on "λ", then it would delete the first character of "\lambda" and thus > unconceal this now unrecognised word. I started working on a patch, that would make this possible. But it's not that easy and it didn't seem like this feature would be applied to vim anytime soon, so I didn't continue. My main usecase was to implement some kind of vertical folding using concealing. regards, Christian -- 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
[conceal] Requests
Hello everyone, I have been using the conceal feature extensively since I discovered it a week ago or so. I would like to express some regrets regarding this extremely useful feature, and thus plea for some enhancements, should anyone capable of coding them read this. 1/ It is very annoying that when one is moving in a concealed line, motions consider the underlying text rather that what can be seen. For example, suppose I have >> $\lambda 42$ which will be rendered as >> $λ 42$ and that my cursor is on the first dollar. To move to the space, I wish I could just do "", but instead, I'll have to do '' eight times; this is very inconvenient. (Of course, I could do "f" or any other thing to achieve the expected motion, but this not my point here.) A nice behaviour would be that, when a line is concealed, motions work on the visible text, and that if I press, say, "x" when the cursor in on "λ", then it would delete the first character of "\lambda" and thus unconceal this now unrecognised word. 2/ A less important, though maybe (?) useful enhancement would be to allow conceal to replace a string for another, not just a character. 3/ A bug? I open a tex file, and >> :echo g:tex_conceal >> agm as set in .vim/after/syntax/tex.vim, which is loaded, I think, last, and sets cole to 2, and cocu to nc. However, the dollars in LaTeX's math mode do not appear. If I reload the file with >> :e then they do appear as wanted. Cheers, P! FreeBSD 7.2 Release VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 1 2011 15:18:44) 適用済パッチ: 1-81 Compiled by adr...@kaoru.kb-private Big 版 with GTK2 GUI. 機能の一覧 有効(+)/無効(-) +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl +persistent_undo +postscript +printer -profile +python -python3 +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save システム vimrc: "$VIM/vimrc" ユーザ vimrc: "$HOME/.vimrc" ユーザ exrc: "$HOME/.exrc" システム gvimrc: "$VIM/gvimrc" ユーザ gvimrc: "$HOME/.gvimrc" システムメニュー: "$VIMRUNTIME/menu.vim" 省略時の $VIM: "/usr/local/share/vim" コンパイル: /usr/local/libexec/ccache/world-cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -D_THREAD_SAFE -D_REENTRANT -I/usr/loc al/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pan go-1.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/us r/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include -O2 -fno-strict-aliasing -pipe -funroll-loops -fomit-f rame-pointer -march=native -D_FORTIFY_SOURCE=1 -I/usr/local/include リンク: /usr/local/libexec/ccache/world-cc -L/usr/local/lib -L/usr/local/lib -R/usr/local/lib -Wl,-R/usr/local/lib/perl5/5.12.2/mach /CORE -L/usr/local/lib -Wl,--as-needed -o vim -pthread -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpangoft2-1.0 -lgio-2.0 -lXfixes -lcai ro -lX11 -lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lelf -pthread -ltermlib -liconv -Wl,-R/usr/local/lib/perl5/5.12.2/mach/CORE -Wl,-E -fstack-prote ctor -L/usr/local/lib -L/usr/local/lib/perl5/5.12.2/mach/CORE -lperl -lm -lcrypt -lutil -L/usr/local/lib/python2.6/config -lpython 2.6 -lutil -lm -Wl,--export-dynamic -- Français, English, 日本語, 한국어 -- 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
Re: Yet another requests for 2html
On 05/06/10 21:04, ZyX wrote: There are some things that my 2html from stable vim (7.2.303, USE="acl bash- completion cscope nls perl python ruby vim-pager vim-with-x") does not support, so I ended in writing my own format.vim script: - 'list' and 'listchars' (lcs:tab, lcs:eol and lcs:trail) [...] hm, interesting; but I suppose that for «includability» in Vim distributions all parts should be supported i.e. also extends, precedes, nbsp, and (Vim 7.3 and higher only) conceal. Anyway, I suppose 2html.vim will have to undergo a serious overhaul if support of |:syn-conceal| |:syn-concealends| and |:syn-conceal-implicit| are to be included. (These have now become part of "official" Vim 7.3a.) Best regards, Tony. -- LET Jesus be YOUR anchor! So when Satan rocks your boat, THROW Jesus overboard! -- 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
Yet another requests for 2html
There are some things that my 2html from stable vim (7.2.303, USE="acl bash- completion cscope nls perl python ruby vim-pager vim-with-x") does not support, so I ended in writing my own format.vim script: - 'list' and 'listchars' (lcs:tab, lcs:eol and lcs:trail) - Foreground colors for lines with differencies (in 2html characters in lines with differencies are just white while vim colors them) - Normal special character coloring - Background color for the whole line with differencies and folds, not just for text - My killer feature: exporting to any format you can write specification for. (for example, bbcode; bbcode specification for unixforum.org is included in the distribution) (probably, you will never include this in 2html) Is some of this fixed in later 2html versions? If not, you are welcome to use my script: http://www.vim.org/scripts/script.php?script_id=3113. signature.asc Description: This is a digitally signed message part.
Feature requests: InsertCharPre and repeating CursorHold events
Hello, Over the past 6 months or so I've been working on a plugin which turns a Vim buffer into a terminal emulator and allows users to run a shell in that buffer: http://www.vim.org/scripts/script.php?script_id=2771 It works OK, but depends on several ugly kludges. If Vim added the these two events these kludges could be removed and plugin writers would be freed up considerably. Since adding a shell window is at the very top of the list of voted features, I hope the fine developers of Vim would consider making these a priority :-) The first is the "InsertCharPre" event, described around line 3301 of todo.txt: InsertCharPre - user typed character Insert mode, before inserting the char. Pattern is matched with text before the cursor. Set v:char to the character, can be changed. (not triggered when 'paste' is set). Having this event would allow a plugin to capture all input in insert mode and send it to the terminal, for true full-duplex behavior. Currently you are required to map all keys, which is only sane if you limit yourself to the extended ASCII character set. Having an insert char event that works with multi-byte characters would allow users to write a plugin which works in all locales. There is already a GetChar event patch on vim.org which may be close, however the way it's described in todo.txt is much cleaner. The second event is repeatable CursorHold/I, described around 3252 of todo.txt: 8 Add an event like CursorHold that is triggered repeatedly, not just once after typing something. This gives a clean way of polling a background shell or debugger. Continuous polling is critical for making a shell plugin work, and the current feedkeys() workarounds barely work and suck up too much cpu. If I knew C I would attack these myself, but until then thanks for considering this request. Nico Raffo -- You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php
