Re: gvim 7.3 ruby plugins cause crash
I updated patch: https://gist.github.com/754070 I checked two compilers and two ruby runtimes. I've sure that both is working for gems with this patch. ruby187 and gvim.exe(msvc): working complete ruby187 and vim.exe(msvc): working complete ruby192 and gvim.exe(msvc): working complete ruby192 and vim.exe(msvc): working complete ruby187 and gvim.exe(mingw): working complete ruby187 and vim.exe(mingw): working complete ruby192 and gvim.exe(mingw): working complete ruby192 and vim.exe(mingw): working complete test case: :ruby require 'rubygems' It seems whole ok to me. Bram, Please check and include. Thanks. - Yasuhiro Matsumoto On Dec 24, 9:41 am, mattn mattn...@gmail.com wrote: So there is one specific version that doesn't work? No, I guess. It is working for 1.8 or 1.9 . but I can't try many minor versions. Can we use #ifdefs to use the old code then? It's going to be messy, but failing or crashing is worse. Yes, we need more brush-up this patch. This patch is draft. - Yasuhiro Matsumoto On Dec 24, 9:17 am, mattn mattn...@gmail.com wrote: On Dec 24, 4:33 am, Bram Moolenaar b...@moolenaar.net wrote: Yasuhiro Matsumoto wrote: Yes, currently windows version can't load gems. For a month ago, I wrote a patch 7.3.058 . But the patch have a problem. One of calling function 'Init_prelude' is not compatible for all platforms. Then I wrote 7.3.067 . 'Init_prelude' include the part of loading gems. However, I have another patch for fixing this problem. https://gist.github.com/751492 Looks like a nice simplification. Undefining off_t is unrelated? No, ruby's header file provided from windows version define type 'off_t' as '_int64'. but mingw's typedef is 'long'. buf_T have some member that typed as 'off_t'. then accessing buffer from ruby extension (strictly speaking, from if_ruby.c) make vim crash. This patch fix the problem. vim will be able to load gems completely. But ruby on windows have a bug that show warning message while loading gems. http://redmine.ruby-lang.org/issues/show/2998 Thus, I'm hesitating whether to suggest this patch. Bram, How do you think? So there is one specific version that doesn't work? Can we use #ifdefs to use the old code then? It's going to be messy, but failing or crashing is worse. -- The users that I support would double-click on a landmine to find out what happens. -- A system administrator /// 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
Re: gvim 7.3 ruby plugins cause crash
Yasuhiro Matsumoto wrote: I updated patch: https://gist.github.com/754070 I checked two compilers and two ruby runtimes. I've sure that both is working for gems with this patch. ruby187 and gvim.exe(msvc): working complete ruby187 and vim.exe(msvc): working complete ruby192 and gvim.exe(msvc): working complete ruby192 and vim.exe(msvc): working complete ruby187 and gvim.exe(mingw): working complete ruby187 and vim.exe(mingw): working complete ruby192 and gvim.exe(mingw): working complete ruby192 and vim.exe(mingw): working complete test case: :ruby require 'rubygems' It seems whole ok to me. Bram, Please check and include. I guess the best way to do this is include it now and await if anyone runs into problems with a specific configuration. Thanks for preparing this patch! -- Despite the cost of living, have you noticed how it remains so popular? /// 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
Re: gvim 7.3 ruby plugins cause crash
Yes, currently windows version can't load gems. For a month ago, I wrote a patch 7.3.058 . But the patch have a problem. One of calling function 'Init_prelude' is not compatible for all platforms. Then I wrote 7.3.067 . 'Init_prelude' include the part of loading gems. However, I have another patch for fixing this problem. https://gist.github.com/751492 This patch fix the problem. vim will be able to load gems completely. But ruby on windows have a bug that show warning message while loading gems. http://redmine.ruby-lang.org/issues/show/2998 Thus, I'm hesitating whether to suggest this patch. Bram, How do you think? - Yasuhiro Matsumoto On Dec 23, 8:24 am, randy909 randy.hanc...@gmail.com wrote: That fixes the crashing. I tried a lot of different combinations, the best being the latest vim from hg (7.3.087) with ruby 192. The only problem I have left in my current build is when I open a ruby file it produces this error (with ruby 1.9.2 p0 and vim 7.3.087): a.rb [New File] Error detected while processing C:\Program Files\vim\vim73\ftplugin \ruby.vim: line 76: NameError: uninitialized constant Gem::QuickLoader line 93: E121: Undefined variable: s:ruby_path E15: Invalid expression: s:ruby_path I tried 'gem install QuickLoader' to no avail. The following is data about my results with different versions of the code in case anyone is curious: This is what I got with the current release version of vim (7.3.046) built with ruby 191 and the off_t fix when I tried to open a ruby file: with ruby 191 p430 and vim 7.3.046 Rakefile Rakefile [unix] 75L, 1886C line 76: NoMethodError: undefined method `synchronize' for #Mutex:0x2024ac0 line 93: E121: Undefined variable: s:ruby_path E15: Invalid expression: s:ruby_path Error on the console: C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:103: warning: already initialized constant VERSION C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:103: warning: already initialized constant RubyGemsVersion C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:147: warning: already initialized constant MUTEX C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:149: warning: already initialized constant RubyGemsPackageVersion C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:155: warning: already initialized constant WIN_PATTERNS C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:1040: warning: already initialized constant MARSHAL_SPEC_DIR C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:1045: warning: already initialized constant YAML_SPEC_DIR This is what I got with ruby 1.9.1 p430 and tip of vim (7.3.087) when just doing :ruby 1 E448: Could not load library function rb_const_remove E266: Sorry, this command is disabled, the Ruby library could not be loaded. So it seems like the tip of vim requires ruby 192 now. Thanks, Randy P.S. Thank you for your quick response and for inventing ruby!!! :) On Dec 21, 8:21 pm, mattn mattn...@gmail.com wrote: Try following patch. Thanks. - Yasuhiro Matsumoto diff -r 916c90b37ea9 src/if_ruby.c --- a/src/if_ruby.c Fri Dec 10 20:35:50 2010 +0100 +++ b/src/if_ruby.c Wed Dec 22 11:10:43 2010 +0900 @@ -90,6 +90,7 @@ # include ruby/encoding.h #endif +#undef off_t #undef EXTERN #undef _ On Dec 22, 5:34 am, randy909 randy.hanc...@gmail.com wrote: gVim 7.3 crashes when I load plugins that require ruby support (lusty- explorer and command-t specifically). I am using rubyinstaller-1.9.1- p430.exe downloaded from rubyinstallers.org and I'm running Win XP SP3. I think I might have better luck if I used exactly the same version of ruby compiled with exactly the same compiler as was used when compiling gvim but I can't find that information anywhere. I'm also tempted to try gVim compiled with mingw but I don't know where to get that either (I may try to compile it myself if all else fails). Here is the specific error message I get when I try to launch lusty- explorer: The instruction at 0x004755a0 referenced memory at 0xfff1. The memory could not be read. Here is my :version VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 27 2010 17:59:02) MS-Windows 32-bit GUI version with OLE support Included patches: 1-46 Compiled by b...@kibaale Big version with GUI. Features included (+) or not (-): +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 +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang -mzscheme
Re: gvim 7.3 ruby plugins cause crash
Yasuhiro Matsumoto wrote: Yes, currently windows version can't load gems. For a month ago, I wrote a patch 7.3.058 . But the patch have a problem. One of calling function 'Init_prelude' is not compatible for all platforms. Then I wrote 7.3.067 . 'Init_prelude' include the part of loading gems. However, I have another patch for fixing this problem. https://gist.github.com/751492 Looks like a nice simplification. Undefining off_t is unrelated? This patch fix the problem. vim will be able to load gems completely. But ruby on windows have a bug that show warning message while loading gems. http://redmine.ruby-lang.org/issues/show/2998 Thus, I'm hesitating whether to suggest this patch. Bram, How do you think? So there is one specific version that doesn't work? Can we use #ifdefs to use the old code then? It's going to be messy, but failing or crashing is worse. -- The users that I support would double-click on a landmine to find out what happens. -- A system administrator /// 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
Re: gvim 7.3 ruby plugins cause crash
On Dec 24, 4:33 am, Bram Moolenaar b...@moolenaar.net wrote: Yasuhiro Matsumoto wrote: Yes, currently windows version can't load gems. For a month ago, I wrote a patch 7.3.058 . But the patch have a problem. One of calling function 'Init_prelude' is not compatible for all platforms. Then I wrote 7.3.067 . 'Init_prelude' include the part of loading gems. However, I have another patch for fixing this problem. https://gist.github.com/751492 Looks like a nice simplification. Undefining off_t is unrelated? No, ruby's header file provided from windows version define type 'off_t' as '_int64'. but mingw's typedef is 'long'. buf_T have some member that typed as 'off_t'. then accessing buffer from ruby extension (strictly speaking, from if_ruby.c) make vim crash. This patch fix the problem. vim will be able to load gems completely. But ruby on windows have a bug that show warning message while loading gems. http://redmine.ruby-lang.org/issues/show/2998 Thus, I'm hesitating whether to suggest this patch. Bram, How do you think? So there is one specific version that doesn't work? Can we use #ifdefs to use the old code then? It's going to be messy, but failing or crashing is worse. -- The users that I support would double-click on a landmine to find out what happens. -- A system administrator /// 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
Re: gvim 7.3 ruby plugins cause crash
So there is one specific version that doesn't work? No, I guess. It is working for 1.8 or 1.9 . but I can't try many minor versions. Can we use #ifdefs to use the old code then? It's going to be messy, but failing or crashing is worse. Yes, we need more brush-up this patch. This patch is draft. - Yasuhiro Matsumoto On Dec 24, 9:17 am, mattn mattn...@gmail.com wrote: On Dec 24, 4:33 am, Bram Moolenaar b...@moolenaar.net wrote: Yasuhiro Matsumoto wrote: Yes, currently windows version can't load gems. For a month ago, I wrote a patch 7.3.058 . But the patch have a problem. One of calling function 'Init_prelude' is not compatible for all platforms. Then I wrote 7.3.067 . 'Init_prelude' include the part of loading gems. However, I have another patch for fixing this problem. https://gist.github.com/751492 Looks like a nice simplification. Undefining off_t is unrelated? No, ruby's header file provided from windows version define type 'off_t' as '_int64'. but mingw's typedef is 'long'. buf_T have some member that typed as 'off_t'. then accessing buffer from ruby extension (strictly speaking, from if_ruby.c) make vim crash. This patch fix the problem. vim will be able to load gems completely. But ruby on windows have a bug that show warning message while loading gems. http://redmine.ruby-lang.org/issues/show/2998 Thus, I'm hesitating whether to suggest this patch. Bram, How do you think? So there is one specific version that doesn't work? Can we use #ifdefs to use the old code then? It's going to be messy, but failing or crashing is worse. -- The users that I support would double-click on a landmine to find out what happens. -- A system administrator /// 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
Re: gvim 7.3 ruby plugins cause crash
That fixes the crashing. I tried a lot of different combinations, the best being the latest vim from hg (7.3.087) with ruby 192. The only problem I have left in my current build is when I open a ruby file it produces this error (with ruby 1.9.2 p0 and vim 7.3.087): a.rb [New File] Error detected while processing C:\Program Files\vim\vim73\ftplugin \ruby.vim: line 76: NameError: uninitialized constant Gem::QuickLoader line 93: E121: Undefined variable: s:ruby_path E15: Invalid expression: s:ruby_path I tried 'gem install QuickLoader' to no avail. The following is data about my results with different versions of the code in case anyone is curious: This is what I got with the current release version of vim (7.3.046) built with ruby 191 and the off_t fix when I tried to open a ruby file: with ruby 191 p430 and vim 7.3.046 Rakefile Rakefile [unix] 75L, 1886C line 76: NoMethodError: undefined method `synchronize' for #Mutex:0x2024ac0 line 93: E121: Undefined variable: s:ruby_path E15: Invalid expression: s:ruby_path Error on the console: C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:103: warning: already initialized constant VERSION C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:103: warning: already initialized constant RubyGemsVersion C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:147: warning: already initialized constant MUTEX C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:149: warning: already initialized constant RubyGemsPackageVersion C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:155: warning: already initialized constant WIN_PATTERNS C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:1040: warning: already initialized constant MARSHAL_SPEC_DIR C:/Ruby191/lib/ruby/site_ruby/1.9.1/rubygems.rb:1045: warning: already initialized constant YAML_SPEC_DIR This is what I got with ruby 1.9.1 p430 and tip of vim (7.3.087) when just doing :ruby 1 E448: Could not load library function rb_const_remove E266: Sorry, this command is disabled, the Ruby library could not be loaded. So it seems like the tip of vim requires ruby 192 now. Thanks, Randy P.S. Thank you for your quick response and for inventing ruby!!! :) On Dec 21, 8:21 pm, mattn mattn...@gmail.com wrote: Try following patch. Thanks. - Yasuhiro Matsumoto diff -r 916c90b37ea9 src/if_ruby.c --- a/src/if_ruby.c Fri Dec 10 20:35:50 2010 +0100 +++ b/src/if_ruby.c Wed Dec 22 11:10:43 2010 +0900 @@ -90,6 +90,7 @@ # include ruby/encoding.h #endif +#undef off_t #undef EXTERN #undef _ On Dec 22, 5:34 am, randy909 randy.hanc...@gmail.com wrote: gVim 7.3 crashes when I load plugins that require ruby support (lusty- explorer and command-t specifically). I am using rubyinstaller-1.9.1- p430.exe downloaded from rubyinstallers.org and I'm running Win XP SP3. I think I might have better luck if I used exactly the same version of ruby compiled with exactly the same compiler as was used when compiling gvim but I can't find that information anywhere. I'm also tempted to try gVim compiled with mingw but I don't know where to get that either (I may try to compile it myself if all else fails). Here is the specific error message I get when I try to launch lusty- explorer: The instruction at 0x004755a0 referenced memory at 0xfff1. The memory could not be read. Here is my :version VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 27 2010 17:59:02) MS-Windows 32-bit GUI version with OLE support Included patches: 1-46 Compiled by b...@kibaale Big version with GUI. Features included (+) or not (-): +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 +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang -mzscheme +netbeans_intg +ole -osfiletype +path_extra +perl/dyn +persistent_undo -postscript +printer -profile +python/dyn +python3/dyn +quickfix +reltime +rightleft +ruby/dyn +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl/dyn -tgetent -termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim -xterm_save +xpm_w32 system vimrc file: $VIM\vimrc user vimrc file: $HOME\_vimrc 2nd user vimrc file: $VIM\_vimrc user exrc file: $HOME\_exrc 2nd user exrc file: $VIM\_exrc system gvimrc file: $VIM\gvimrc user gvimrc file: $HOME\_gvimrc 2nd user gvimrc file:
gvim 7.3 ruby plugins cause crash
gVim 7.3 crashes when I load plugins that require ruby support (lusty- explorer and command-t specifically). I am using rubyinstaller-1.9.1- p430.exe downloaded from rubyinstallers.org and I'm running Win XP SP3. I think I might have better luck if I used exactly the same version of ruby compiled with exactly the same compiler as was used when compiling gvim but I can't find that information anywhere. I'm also tempted to try gVim compiled with mingw but I don't know where to get that either (I may try to compile it myself if all else fails). Here is the specific error message I get when I try to launch lusty- explorer: The instruction at 0x004755a0 referenced memory at 0xfff1. The memory could not be read. Here is my :version VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 27 2010 17:59:02) MS-Windows 32-bit GUI version with OLE support Included patches: 1-46 Compiled by b...@kibaale Big version with GUI. Features included (+) or not (-): +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 +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang -mzscheme +netbeans_intg +ole -osfiletype +path_extra +perl/dyn +persistent_undo -postscript +printer -profile +python/dyn +python3/dyn +quickfix +reltime +rightleft +ruby/dyn +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl/dyn -tgetent -termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim -xterm_save +xpm_w32 system vimrc file: $VIM\vimrc user vimrc file: $HOME\_vimrc 2nd user vimrc file: $VIM\_vimrc user exrc file: $HOME\_exrc 2nd user exrc file: $VIM\_exrc system gvimrc file: $VIM\gvimrc user gvimrc file: $HOME\_gvimrc 2nd user gvimrc file: $VIM\_gvimrc system menu file: $VIMRUNTIME\menu.vim Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 - DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_XPM_W32 -DWINVER=0x0400 - D_WIN32_WINNT=0x0400 /Fo.\ObjGOLYHTR/ /Ox /GL -DNDEBUG /Zl /MT - DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_W32 - DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL - DDYNAMIC_TCL_DLL=\tcl83.dll\ -DDYNAMIC_TCL_VER=\8.3\ -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\python27.dll\ -DFEAT_PYTHON3 - DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\python31.dll\ -DFEAT_PERL - DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl512.dll\ -DFEAT_RUBY - DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=191 -DDYNAMIC_RUBY_DLL=\msvcrt- ruby191.dll\ -DFEAT_BIG /Fd.\ObjGOLYHTR/ /Zi Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib uuid.lib /machine:i386 /nodefaultlib gdi32.lib version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib / machine:i386 /nodefaultlib libcmt.lib oleaut32.lib user32.lib / nodefaultlib:python27.lib /nodefaultlib:python31.lib e:\tcl\lib \tclstub83.lib WSock32.lib e:\xpm\lib\libXpm.lib /PDB:gvim.pdb -debug -randy -- 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: gvim 7.3 ruby plugins cause crash
Try following patch. Thanks. - Yasuhiro Matsumoto diff -r 916c90b37ea9 src/if_ruby.c --- a/src/if_ruby.c Fri Dec 10 20:35:50 2010 +0100 +++ b/src/if_ruby.c Wed Dec 22 11:10:43 2010 +0900 @@ -90,6 +90,7 @@ # include ruby/encoding.h #endif +#undef off_t #undef EXTERN #undef _ On Dec 22, 5:34 am, randy909 randy.hanc...@gmail.com wrote: gVim 7.3 crashes when I load plugins that require ruby support (lusty- explorer and command-t specifically). I am using rubyinstaller-1.9.1- p430.exe downloaded from rubyinstallers.org and I'm running Win XP SP3. I think I might have better luck if I used exactly the same version of ruby compiled with exactly the same compiler as was used when compiling gvim but I can't find that information anywhere. I'm also tempted to try gVim compiled with mingw but I don't know where to get that either (I may try to compile it myself if all else fails). Here is the specific error message I get when I try to launch lusty- explorer: The instruction at 0x004755a0 referenced memory at 0xfff1. The memory could not be read. Here is my :version VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 27 2010 17:59:02) MS-Windows 32-bit GUI version with OLE support Included patches: 1-46 Compiled by b...@kibaale Big version with GUI. Features included (+) or not (-): +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 +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang -mzscheme +netbeans_intg +ole -osfiletype +path_extra +perl/dyn +persistent_undo -postscript +printer -profile +python/dyn +python3/dyn +quickfix +reltime +rightleft +ruby/dyn +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl/dyn -tgetent -termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim -xterm_save +xpm_w32 system vimrc file: $VIM\vimrc user vimrc file: $HOME\_vimrc 2nd user vimrc file: $VIM\_vimrc user exrc file: $HOME\_exrc 2nd user exrc file: $VIM\_exrc system gvimrc file: $VIM\gvimrc user gvimrc file: $HOME\_gvimrc 2nd user gvimrc file: $VIM\_gvimrc system menu file: $VIMRUNTIME\menu.vim Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 - DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_XPM_W32 -DWINVER=0x0400 - D_WIN32_WINNT=0x0400 /Fo.\ObjGOLYHTR/ /Ox /GL -DNDEBUG /Zl /MT - DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_W32 - DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL - DDYNAMIC_TCL_DLL=\tcl83.dll\ -DDYNAMIC_TCL_VER=\8.3\ -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\python27.dll\ -DFEAT_PYTHON3 - DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\python31.dll\ -DFEAT_PERL - DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl512.dll\ -DFEAT_RUBY - DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=191 -DDYNAMIC_RUBY_DLL=\msvcrt- ruby191.dll\ -DFEAT_BIG /Fd.\ObjGOLYHTR/ /Zi Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib uuid.lib /machine:i386 /nodefaultlib gdi32.lib version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib / machine:i386 /nodefaultlib libcmt.lib oleaut32.lib user32.lib / nodefaultlib:python27.lib /nodefaultlib:python31.lib e:\tcl\lib \tclstub83.lib WSock32.lib e:\xpm\lib\libXpm.lib /PDB:gvim.pdb -debug -randy -- 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
