Sorry, after trying gVim 7.4 with all of the latest patches (7.4.711), the
issue disappears.
More details: tried this on another computer, and:
- The issue has nothing to do with the rule. It is simply a property of the
default Vim installation highlighting a Python file containing some pattern.
- The file had to be longer than I supplied (for some reason, on that other
computer??) A copy of a longer file is attached, for reference.
The reason I was convinced it had to do with my syntax rule was that removing
the "matchgroup" argument seemed to eliminate the problem. However, that must
have been the consequence of a spurious behaviour of this bug: a few percent of
the time it doesn't occur. I should probably have tried the latest patched-up
version anyway before posting, but it seemed that "syn region" was the culprit,
and no patch summaries mentioned that, so I didn't.
Regards, and thank you for the software.
Evgeni
> From: [email protected]
> To: [email protected]
> Subject: Bug: gVim crashes with syn region rule defined (Windows version 7.4)
> Date: Mon, 1 Jun 2015 21:44:20 +1000
>
>
>
>
> Dear Vim developers,
>
> I found a rule that causes gVim to segfault (c0000005 on Windows).
> This is the gVim 7.4 version for Windows, same installation file as up on the
> main website now.
>
> To isolate, I've renamed "vimfiles" to "vimfiles_", and replaced my "_vimrc"
> with the following 2 lines:
>
> syn region lzcabx1 matchgroup=lzcabx1c start=+(+ end=+)+
> syn on
>
>
>
> Now, when opening the file "b2.py" attached, and scrolling down, gVim crashes
> (might be the closing parenthesis without a matching opening one?).
> Obviously, even if the rule I defined is invalid somehow, it should result in
> an error message, rather than a segfault. I checked vim-dev archives and the
> list of patches for 7.4 and couldn't find anything matching this description,
> so this might be new.
>
> Removing the "matchgroup" argument makes the problem go away.
>
> Attached is the _vimrc (as above), the file it crashes on "b2.py", and the
> result of bugreport.vim.
>
> Hope this helps.
>
> Regards,
> Evgeni
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
iter = 0
while (right - left) / right > 1e-12:
mid = 0.5 * (left + right)
iter += 1
print iter, "mid", mid
if check(poly, (1.0/mid)*target, iter==27):
right = mid
else:
left = mid
print "%.15f" % right
iter = 0
while (right - left) / right > 1e-12:
mid = 0.5 * (left + right)
iter += 1
print iter, "mid", mid
if check(poly, (1.0/mid)*target, iter==27):
right = mid
else:
left = mid
print "%.15f" % right
iter = 0
while (right - left) / right > 1e-12:
mid = 0.5 * (left + right)
iter += 1
print iter, "mid", mid
if check(poly, (1.0/mid)*target, iter==27):
right = mid
else:
left = mid
print "%.15f" % right
iter = 0
while (right - left) / right > 1e-12:
mid = 0.5 * (left + right)
iter += 1
print iter, "mid", mid
if check(poly, (1.0/mid)*target, iter==27):
right = mid
else:
left = mid
print "%.15f" % right
iter = 0
while (right - left) / right > 1e-12:
mid = 0.5 * (left + right)
iter += 1
print iter, "mid", mid
if check(poly, (1.0/mid)*target, iter==27):
right = mid
else:
left = mid
print "%.15f" % right
iter = 0
while (right - left) / right > 1e-12:
mid = 0.5 * (left + right)
iter += 1
print iter, "mid", mid
if check(poly, (1.0/mid)*target, iter==27):
right = mid
else:
left = mid
print "%.15f" % right
iter = 0
while (right - left) / right > 1e-12:
mid = 0.5 * (left + right)
iter += 1
print iter, "mid", mid
if check(poly, (1.0/mid)*target, iter==27):
right = mid
else:
left = mid
print "%.15f" % right
iter = 0
while (right - left) / right > 1e-12:
mid = 0.5 * (left + right)
iter += 1
print iter, "mid", mid
if check(poly, (1.0/mid)*target, iter==27):
right = mid
else:
left = mid
print "%.15f" % right
iter = 0
while (right - left) / right > 1e-12:
mid = 0.5 * (left + right)
iter += 1
print iter, "mid", mid
if check(poly, (1.0/mid)*target, iter==27):
right = mid
else:
left = mid
print "%.15f" % right
#The solution was going really well. But it fell down on numerics. And in a
#big way. Nothing that could be trivially fixed. Going to arbitrary-precision
#arithmetic revealed the following story:
# -3.5550334651849983553e-06
#-0.00000355503023174938931314265211542424831188024669857
#-0.000159644084726472818
#-0.000159643986027287560593799327996113127746938239561
#9999.9990964449680177
#9999.9990964449697682506106868573478845757516881198
#449064.95942450599978
#449064.95942450601397271243940620067200388687225306
#These are the x and y coordinates of two points, for which the signum part in
#the winding number routine returns different answers. One is 2e-7, the other
#is -2e-7. How did that happen, when all we are doing are addition, subtraction
#and multiplication? Well, that's because during translation of the polygon,
#we would be adding numbers like 9999 to 3e-6, and subtracting afterwards. Of
#course, in about the 4th decimal place of hte 3e-6 number, there would be
#an error, which will propagate into further calculations.
#
#The only way I see of fixing the approach was to use arbitrary precision
#arithmetic. And.... it does work! In time too :)
#But I was not prepared for that during the contest. Now, however, I know
#from decimal import *
