2019年11月21日木曜日 23時37分11秒 UTC+9 Bram Moolenaar:
>
>
> Patch 8.1.2326
> Problem:Cannot parse a date/time string.
> Solution: Add strptime(). (Stephen Wall, closes #)
>
> *** ../vim-8.1.2325/src/testdir/test_functions.vim2019-11-16
> 18:21:57.990848019 +0100
> --- src/testdir/test
test_channel "sporadically" fails on my Macs.
When it fails (in Test_communicate()), the output from the
server looks like:
received: [3,"eval-works"]
sending: ["eval","\"foo\" . 123", -1]
sending: [3, "ok"]
received: [4,"eval-result"][-1,"foo123"]
so it receives [4,"eval-result"] before [-1,"foo
On 2016/02/04, at 10:28, "Jun T." wrote:
> [1] test_channel.py in git master dosen't have the execution permission.
Sorry, forget about this.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are reply
On 2016/02/02, at 20:38, Bram Moolenaar wrote:
> Patch 7.4.1237
> Problem:Can't translate message without adding a line break.
> Solution: Join the two parts of the message.
> Files: src/memline.c
Then the *.po files for all the languages must be updated.
If we are really going to th
On 2016/02/04, at 8:11, Bram Moolenaar wrote:
> Patch 7.4.1256
> Problem:On Mac sys.exit(0) doesn't kill the test server.
I think sys.exit() was not working on Linux also. Anyway,
[1] test_channel.py in git master dosen't have the execution permission.
[2] the comment
# Exit the serv
On 2016/02/03, at 19:04, Jun T. wrote:
> call system("killall test_channel.py")
> this doesn't work either, because the name of the process is
> not 'test_channel.py' but 'python'.
I forgot to mention that killall works on Linux. killall on Mac
(an
On 2016/02/03, at 7:23, Bram Moolenaar wrote:
> Patch 7.4.1246
> Problem:The channel functionality isn't tested.
> Solution: Add a test using a Python test server.
The Python test server doesn't quit and keeps running after the
test (at least on my Mac, OSX 10.8.5, Python2.7).
In test_ch
On 2016/02/02, at 10:15, Ken Takata wrote:
>
> I have to rethink how to fix this. Moving a white space from the top of the
> latter message to end of the former message solves the problem, but ugly...
We can make the translation shorter. How about this?
Jun Takimoto
diff --git a/src/po/ja.po
2015/12/06 22:53, Bram Moolenaar wrote:
> Christian made a fix.
Thanks, the test passes OK 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
---
Y
2015/12/06 21:21 I wrote:
> test_listlbr_utf8 fails on Mac OS X as follows:
Sorry, the problem has been reported already by a couple of people.
Anyway, what is the encoding used in test_listlbr_utf8.{in,ok}?
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type yo
test_listlbr_utf8 fails on Mac OS X as follows:
# Check if the test.out file matches test.ok.
54,56c54,56
< ¶
< a b c¶
< a b c¶
---
> ¶
> ＋a b c¶
On 2015/01/29, at 6:39, Bram Moolenaar wrote:
> It's better to not skip the test. Can you try if it works by using
> "unnamed" instead of "unnamedplus" and then using the * register instead
> of +? The * register should work everywhere.
Yes.
The test succeeds (and is not skipped) on my Mac wit
On 2015/01/28, at 11:33, Manuel Ortega wrote:
> Test results:
> test_eval FAILED
The failure is in the section '{{{1 System clipboard'.
There is only one clipboard on Mac OS X, and it seems
both "* and "+ refer to it. For example both
"*yyand "+yy
yank the current line to the cl
2014/07/10 00:52、Bram Moolenaar のメール：
> Patch 7.4.358 (after 7.4.351)
> Problem:Sort is not always stable.
> Solution: Add an index instead of relying on the pointer to remain the same.
Thank you for a clever patch.
test55 now works fine on my Macs.
# I couldn't think of casting (listitem
I did two speed tests of sort() with and without my patch
on my Linux box:
original patchedratio
test1 78.81 sec 81.06 sec1.03
test2 5.87 sec6.08 sec1.04
where 'original' is the revision adc4a84f72eb, and
'patched' is with my patch for eval.c.
It seems the overhe
On 2014/07/04, at 5:54, Bram Moolenaar wrote:
> Hmm, we need to fill an array with pointers, might as well add an int
> right after the pointer. Effectively this means sorting this struct:
>
> {
> void *ptr; /* the list element to be sorted */
> int idx; /* original pos
On 2014/07/03, at 2:06, Bram Moolenaar wrote:
> + static int item_compare_keep_zero;
This variable is set to FALSE for the sort() function, and only set to TRUE for
uniq(). Is this intentional?
Even if I set this variable to TRUE for sort(), the sort is still not stable
and test55 fails on my
2014/06/26 23:09, Ben Fritz wrote:
> Could this be fixed, by using (l2.lnum - l1.lnum) rather than
> (l1.lnum - l2.lnum) if lines are equal, when using reverse sort?
Well... the change is easy (see the patch below), but I think the
current behavior of :sort! is a 'feature', not a bug. Changing
i
2014/06/26 01:07, Ben Fritz wrote:
> On Tuesday, June 24, 2014 10:39:28 AM UTC-5, Ben Fritz wrote:
>>
>> I thought your sort could be done in Vim with 2 passes, but unfortunately it
>> does not work:
>>
>> sort r /^\d\+/
>> sort! /.*#/
>>
>
> Bram, any chance that a way to guarantee a stable
On 2014/06/26, at 15:40, Jun T. wrote:
> It would be possible to make vim's sort() function stable if we save the
> original
> order in a separate array and ...
No, I was wrong; saving in a separate array won't work; the original order
should
be saved in the same array,
On 2014/06/26, at 15:08, Kazunobu Kuriyama wrote:
> On my Mac, I've been unable to install vim due to a failure of test55 coming
> with Patch 7.4.341.
Yes, I've noticed the same error and just been writing a bug report when
I received your post.
> But... It looks the Mac just gave one of possi
test97 fails on Mac OS X:
6,8c6,8
< 'sautest/autoload/footest.vim
< sautest/autoload/Test104.vim'
< ['sautest/autoload/footest.vim', 'sautest/autoload/Test104.vim']
---
> 'sautest/autoload/Test104.vim
> sautest/autoload/footest.vim'
> ['sautest/autoload/Test104.vim', 'sautest/autoload/footest.vim'
StringToLine(obj) in if_py_both.h should return NULL if obj is neither
8bit string nor unicode string.
As a simple example, try the following script:
:py import vim
:py b = vim.current.buffer
:py b.append([1,2])
This adds two empty lines to the current buffer (instead of throwing an error).
I
On 2013/06/24, at 19:05, Bram Moolenaar wrote:
> So we probably need to use an #ifdef.
There is already a macro 'PyInt' for this purpose.
I also added similar fix for PyList_insert().
diff -r 7a5c346861e1 src/if_python.c
--- a/src/if_python.c Sun Jun 23 16:40:40 2013 +0200
+++ b/src/if_pytho
On 2013/06/12, at 21:41, Bram Moolenaar wrote:
> Thanks for the updates. Unfortunately, now both test 86 and 87 fail for
> me.
(snip)
> -2,xx
> -before
> -after
I'm getting the same error (python2.7.3 and python 3.2.3).
It seems the tests are failing when they try to 'import module'.
The modul
I can't reproduce the error, but
On 2013/06/11, at 1:46, Bram Moolenaar wrote:
> The following differences ones are similar.
so the following simpler test (line 536 of test86.ok) also fails similarly?
>>> Testing *Iter* using d["a"] = %s
d["a"] = FailingIter():(, TypeError('unable to
convert t
On 2013/06/10, at 20:21, Bram Moolenaar wrote:
>> +#define PY_SSIZE_T_CELAN
>
> Didn't you mean PY_SSIZE_T_CLEAN ?
Of course I believe he (Elimar) means PY_SSIZE_T_CLEAN.
> It's defined further down, but inside an #ifdef. Do we need that #ifdef
> here as well? Or perhaps we should move the o
On 2013/06/10, at 0:38, Manuel Ortega wrote:
> I just pulled and built 7.3.1154. A 'make test' failed, apparently on test
> 86.
Yes. Please see the thread "segfault in test86: int/ssize_t conflict?".
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your rep
On 2013/06/07, at 6:08, Elimar Riesebieter wrote:
> * Jun T. [2013-06-06 10:39 +0900]:
>> I'm getting core dump (segfault) in test86;
>> vim 7.3.1128 on Mac OS X and Linux, both with Python 2.7/64bit.
>> Does this happen only to me?
>
> Me too :-(
Thank you f
Hi all. I'm new to this list.
I'm getting core dump (segfault) in test86;
vim 7.3.1128 on Mac OS X and Linux, both with Python 2.7/64bit.
Does this happen only to me?
It seems that the problem is in OutputWritelines().
PyArg_Parse(..., "et#",.., &len) returns a bogus value for len,
because len is
30 matches
Mail list logo
