Juan, see this issue: https://github.com/tarruda/vim/issues/5
That means even if you have a 100% stable implementation, embedded
scripting languages that spawn threads may not set their sigmasks(this is a
out of our control), meaning vim's signal handlers can run in spawned
threads causing crashes
On Wednesday, February 19, 2014 10:11:52 PM UTC-5, ZyX wrote:
> Not when it gets the chance. Check out the following: make server run `while
> 1 | sleep 1 | endwhile` and send that expression (I tested it on
> `input("abc")`). You will see that despite something being run received
> expression w
On Thursday, February 20, 2014 12:50:13 AM UTC+4, Juan Campa wrote:
> On Wednesday, January 15, 2014 9:44:24 AM UTC-5, Ben Fritz wrote:
> > I thought the idea of this patch, was to allow background threads to send
> > Vim a message, that says "when you get a chance, run function X". Then, at
> >
On Wednesday, January 15, 2014 9:44:24 AM UTC-5, Ben Fritz wrote:
> I thought the idea of this patch, was to allow background threads to send Vim
> a message, that says "when you get a chance, run function X". Then, at some
> later point in time, when Vim is not busy, it will run function X *IN T
On Wed, Jan 15, 2014 at 2:23 PM, Ben Fritz wrote:
> So, your background thread is directly calling a function to get user
> input/update the screen? I think THAT is a mistake. This should not happen. A
> background thread can be used for data processing, but any user input, buffer
> changes, sc
On Wednesday, January 15, 2014 10:08:53 AM UTC-6, Thiago Arruda wrote:
>
>
> Ashley, its possible that a 'DeferredCall' message arrives while
>
> the background thread is in the middle of running 'vgetc'. A DeferredCall will
>
> invoke a vimscript function and then will update the screen which
On Wed, Jan 15, 2014 at 11:44 AM, Ben Fritz wrote:
>
> I thought the idea of this patch, was to allow background threads to send Vim
> a message, that says "when you get a chance, run function X". Then, at some
> later point in time, when Vim is not busy, it will run function X *IN THE
> MAIN T
On Wednesday, January 15, 2014 4:44:34 AM UTC-6, Ashley Hewson wrote:
> Thiago,
>
> I would love this to work and I thank you for your effort, but I'm quite
> doubtful that vgetc can be safely run in a background thread. It simply does
> too much work. Just to pick one example, it appears to be
Thiago,
I would love this to work and I thank you for your effort, but I'm quite
doubtful that vgetc can be safely run in a background thread. It simply does
too much work. Just to pick one example, it appears to be responsible for
blinking the GUI cursor while it's waiting, which will obviousl
On Tuesday, January 14, 2014 4:03:21 PM UTC-8, Thiago Arruda wrote:
> On Tue, Jan 14, 2014 at 7:10 PM, kans wrote:
>
> > Thiago,
>
> >
>
> > I am not hopeful for this patch, but I would love to see you succeed. We
> > spent around two months working on adding async support to Vim without
> >
On Tue, Jan 14, 2014 at 7:10 PM, kans wrote:
> Thiago,
>
> I am not hopeful for this patch, but I would love to see you succeed. We
> spent around two months working on adding async support to Vim without
> threads, https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZjQ70J .
> We added
On Tuesday, January 14, 2014 4:10:04 PM UTC-6, kans wrote:
> Ultimately, we gave up for a few reasons:
>
> 1. A large percent of the Vim community was outright hostile to the idea.
I don't remember that at all! I think a lot of people liked the idea in
general, but didn't like the idea of an uni
Thiago,
I am not hopeful for this patch, but I would love to see you succeed. We spent
around two months working on adding async support to Vim without threads,
https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZjQ70J . We added a
timer function and called the callbacks in the main lo
It seems GUI crashes stopped after calling 'XInitThreads' at the
gui_start function. With this the only problem I can detect is test94
failing, I think it has something to do with operator-pending mode but
it needs to be confirmed.
I also added instructions to the github
page(https://github.com/ta
On Tue, Jan 14, 2014 at 6:23 AM, Christian Wellenbrock
wrote:
> I really like this approach and hope Bram will consider this some day. Just
> wanted to say: Keep up the good work!
Thanks, even if this doesn't get merged I will probably use it as the
starting point of a personal vim fork.
--
--
On Tuesday, January 14, 2014 4:53:07 AM UTC+1, Thiago Arruda wrote:
> Today I got some free time and decided to give this patch another try.
>
>
>
> I have made a few modifications to the original:
>
>
>
> - Rebased against the current master
>
> - Removed the 'defer' function, and added an
Today I got some free time and decided to give this patch another try.
I have made a few modifications to the original:
- Rebased against the current master
- Removed the 'defer' function, and added an equivalent to the 'vim'
module in python's bindings. This was needed because I had no way of
kn
On Mo, 09 Dez 2013, Nikolay Pavlov wrote:
> On Dec 9, 2013 10:05 PM, "Christian Brabandt" wrote:
> >
> > Hi Thiago!
> >
> > On So, 08 Dez 2013, Thiago Padilha wrote:
> >
> > > About this issue of vim not responding, did you try to call the Stop()
> > > function of the test plugin? I added this f
On Mo, 09 Dez 2013, Thiago Padilha wrote:
> Again I thank you for the feedback, but I have no intention to
> continue to working on this, simply because:
>
> - I've read people saying that many patches will sit forever on the
> mailing list without being merged.
>
> - Until now this patch was com
On Mon, Dec 9, 2013 at 4:33 PM, Christian Brabandt wrote:
>>
>> No, and by the time I noticed, it was too late, Vim wouldn't respond
>> anymore. By attaching gdb to the process I saw, that Vim was hanging in
>> the python_end() function, so I think, you are right, python will never
>> exit unless
On Dec 9, 2013 10:05 PM, "Christian Brabandt" wrote:
>
> Hi Thiago!
>
> On So, 08 Dez 2013, Thiago Padilha wrote:
>
> > About this issue of vim not responding, did you try to call the Stop()
> > function of the test plugin? I added this function because python will
> > never exit by itself unless
Hi vim_dev!
On Mo, 09 Dez 2013, Christian Brabandt wrote:
> Hi Thiago!
>
> On So, 08 Dez 2013, Thiago Padilha wrote:
>
> > About this issue of vim not responding, did you try to call the Stop()
> > function of the test plugin? I added this function because python will
> > never exit by itself u
Hi Thiago!
On So, 08 Dez 2013, Thiago Padilha wrote:
> About this issue of vim not responding, did you try to call the Stop()
> function of the test plugin? I added this function because python will
> never exit by itself unless the background thread is killed.
No, and by the time I noticed, it
Christian, thanks for the feedback.
About this issue of vim not responding, did you try to call the Stop()
function of the test plugin? I added this function because python will
never exit by itself unless the background thread is killed.
I'm gonna try the redraw_later tip later, thanks.
Thiago
Hi Thiago!
Wow, nice work. There are some issues, I noticed. It doesn't quite work
flawlessly
Here are some things I noticed:
- Vim didn't link with -lphtread. I fixed it for now, by declaring
LEAK_LIBS=-lpthread in the Makefile
- the output of your python plugin will be appened to whatever
On Dec 6, 2013, at 3:07 PM, Amadeus Demarzi wrote:
> Obviously I am not a developer on this project, but as a lurker/avid vim
> user, I can definitely say I would love to see something like this get
> incorporated into the mainline vim.
Exact same here!
--
b
Sent from my iPhone
--
--
You
Obviously I am not a developer on this project, but as a lurker/avid vim user,
I can definitely say I would love to see something like this get incorporated
into the mainline vim.
On Friday, December 6, 2013 3:00:47 AM UTC-8, Thiago Arruda wrote:
> My last post(https://groups.google.com/forum/#!
My last post(https://groups.google.com/forum/#!topic/vim_dev/lylNU4Na2Nk) gave
me the impression that the lack of multithreading/message queue/event loop was a
problem to be solved in vim, and I this patch has a potential solution that has
little impact on the current code.
Any chance a dev(Bram,
This patch implements the concept suggested in this
post: https://groups.google.com/forum/#!topic/vim_dev/lylNU4Na2Nk
Heres a simple explanation of whats going on:
- A frozen 'background' thread is started at the beginning of the program.
- At every iteration, the main_loop function will wake tha
29 matches
Mail list logo
