s:rubypath in ftplugin/ruby.vim

Thread: s:rubypath in ftplugin/ruby.vim

Search this list only Search all lists
s:rubypath in ftplugin/ruby.vim
	2006-12-01 06:48:30
I've checked in a change to the ruby.vim ftplugin. Running ruby delays vim's start under windows for an annoyingly long time, so I've modified ruby.vim to use the linked-in interpreter to generate s:rubypath if it's available under windows. --mark -- sic transit gloria et adulescentia blog \| http://hasno.info wiki \| http://wiki.hasno.info _______________________________________________ vim-ruby-devel mailing list vim-ruby-develrubyforge.org http://rubyforge.org/mailman/listinfo/vim-ruby-devel

s:rubypath in ftplugin/ruby.vim
	2006-12-04 21:50:53
On Fri, Dec 01, 2006 at 01:48:30AM -0500, Mark Guzman wrote: > I've checked in a change to the ruby.vim ftplugin. Running ruby delays > vim's start under windows for an annoyingly long time, so I've modified > ruby.vim to use the linked-in interpreter to generate s:rubypath if it's > available under windows. Thanks. Is there a reason you've limited this to Windows? I assume it would be marginally quicker to use the Ruby 'interface' for other platforms? Regards, Doug _______________________________________________ vim-ruby-devel mailing list vim-ruby-develrubyforge.org http://rubyforge.org/mailman/listinfo/vim-ruby-devel

s:rubypath in ftplugin/ruby.vim
	2006-12-06 21:39:26
Doug Kearns wrote: > Is there a reason you've limited this to Windows? I assume it would be > marginally quicker to use the Ruby 'interface' for other platforms? > I wasn't sure how people would feel about using the 'interface' for all platforms where it was available. The only platform where it really gets under my skin happens to be windows. The load time would indeed be marginally quicker, so with your (assumed) blessing I'll modify the file again to make the change relevant to all platforms. --mark -- sic transit gloria et adulescentia blog \| http://hasno.info wiki \| http://wiki.hasno.info _______________________________________________ vim-ruby-devel mailing list vim-ruby-develrubyforge.org http://rubyforge.org/mailman/listinfo/vim-ruby-devel

Re: s:rubypath in ftplugin/ruby.vim
	2007-01-22 13:15:24
On Wed, Dec 06, 2006 at 04:39:26PM -0500, Mark Guzman wrote: > I wasn't sure how people would feel about using the 'interface' for all > platforms where it was available. The only platform where it really gets > under my skin happens to be windows. The load time would indeed be > marginally quicker, so with your (assumed) blessing I'll modify the file > again to make the change relevant to all platforms. > --mark As you may recall from our IRC discussion, I was quite skeptical . Yesterday, I encountered a user with an actual problem with this. Vim was segfaulting everytime he edited a Ruby file after updating to the latest vim-ruby scripts. This use of the Vim Ruby interface turned out to be the problem. We never pinned down the true cause (probably something broken in the way Vim or Ruby was compiled). The Vim Ruby interface has always seemed like a dirty hack. Often times when using it, I get errors like: SystemStackError: (eval):761:in `get_completions': stack level too deep That's from the rubycomplete script plugin, but I've seen it when writing my own code as well. I've also seen segfaults as well (including the same segfault experienced in the recent post about rubycomplete). The very fact a user script can bring down Vim as a whole suggests something isn't quite right. I'm reverting this change to just be used on Windows because this is where the largest gains can be seen, and because on Windows, there are generally just a few well known compilations, as opposed to the plethora of custom compilations (both by distros and by end users) that can be found on other operating systems. Feel free to revert and discuss if you disagree. Any news about a release? Cheers, Tim _______________________________________________ vim-ruby-devel mailing list vim-ruby-develrubyforge.org http://rubyforge.org/mailman/listinfo/vim-ruby-devel

Re: s:rubypath in ftplugin/ruby.vim
	2007-01-23 10:45:16

On Mon, Jan 22, 2007 at 07:57:39PM -0500, Mark Guzman wrote: > Tim Pope wrote: > > > > As you may recall from our IRC discussion, I was quite skeptical . > > Yesterday, I encountered a user with an actual problem with this. Vim > > was segfaulting everytime he edited a Ruby file after updating to the > > latest vim-ruby scripts. This use of the Vim Ruby interface turned > > out to be the problem. We never pinned down the true cause (probably > > something broken in the way Vim or Ruby was compiled). The Vim Ruby > > interface has always seemed like a dirty hack. Often times when using > > it, I get errors like: > > > This doesn't occur unless rails.vim is loaded. I'm still searching for > the actual cause, but I can confirm that this is the reason under > osx,fbsd, solaris, and linux. I've been testing with the cvs version of > rubycomplete and the rails.vim from your site. This seems to match up > with the user reports also, though I haven't had them run it without > rails.vim. Very odd. rails.vim only recently started making use of the Vim-Ruby interface. The next revision will limit it to Windows only; perhaps I should just do away with it all together (although I can't reproduce any of these problems on Windows). For the record, rails.vim uses it in two places which previously used system(): 1. require 'action_view' and extract a list of helper methods from it. 2. require 'yaml' and parse database.yml (only if dbext.vim is installed) On my system, I observe the following behaviors. If the first is performed, with or without the second. the stack overflow error starts to be seen when completion is used. If the second is performed without the first, Vim will segfault when completion is used. Things work fine if you :ruby require the same libraries manually, and things still break if all rails.vim does is require the same libraries. Perhaps is has something to do with how things are nested in a Vim function. I will investigate further. > Have you actually experienced a crash due to the path discovery code? No. This user claims to have, even without rails.vim loaded. g:rubycomplete_rails might have been set. Cheers, Tim _______________________________________________ vim-ruby-devel mailing list vim-ruby-develrubyforge.org http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Re: s:rubypath in ftplugin/ruby.vim
	2007-01-23 13:32:39

On Tue, Jan 23, 2007 at 10:45:16AM -0600, Tim Pope wrote: > Things work fine if you :ruby require the same libraries manually, and > things still break if all rails.vim does is require the same > libraries. Perhaps is has something to do with how things are nested > in a Vim function. I will investigate further. A little further investigation reveals the trigger. The first time the Ruby interface is used is significant. If it is used at the top level, all is well. If it is nested deep inside several function calls, this seems to reduce the available stack space to Ruby. Note that only there very first call is relevant. If I add silent! ruby nil to the plugin initialization function of rails.vim (so that the call is nested just one function deep), everything works great. I'm not thrilled with forcing initialization at each start but I can't find a better place to do it. This does not help my segfaulting acquaintance (whom I wlll hereafter refer to as jsunn) though. I still think use of the interface in the ftplugin should be limited to Windows. Cheers, Tim _______________________________________________ vim-ruby-devel mailing list vim-ruby-develrubyforge.org http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Re: s:rubypath in ftplugin/ruby.vim
	2007-01-23 13:40:02

Mark Guzman wrote: > Tim Pope wrote: > > Very odd. rails.vim only recently started making use of the Vim-Ruby > > interface. The next revision will limit it to Windows only; perhaps I > > should just do away with it all together (although I can't reproduce > > any of these problems on Windows). For the record, rails.vim uses it > > in two places which previously used system(): > > > > 1. require 'action_view' and extract a list of helper methods from it. > > > > 2. require 'yaml' and parse database.yml (only if dbext.vim is installed) > > > > On my system, I observe the following behaviors. If the first is > > performed, with or without the second. the stack overflow error starts > > to be seen when completion is used. If the second is performed > > without the first, Vim will segfault when completion is used. > > Things work fine if you :ruby require the same libraries manually, and > > things still break if all rails.vim does is require the same > > libraries. Perhaps is has something to do with how things are nested > > in a Vim function. I will investigate further. > > > > > Weird, I'll see if i can be of any help. If it's a problem w/ the > vim-ruby bridge it'd be nice if we could fix it. > >> Have you actually experienced a crash due to the path discovery code? > >> > > > > No. This user claims to have, even without rails.vim loaded. > > g:rubycomplete_rails might have been set. > > > Who? Can you forward on the email so I can find out more? The rails > support stuff is pretty intense since it's loading rails into the env. > --mark I believe we're discussing my particular problem here. I've had some conference with Tim Pope about the aforementioned. Here's my situation: brand new macbook, osx 10.4.8 ruby 1.8.5. from source, --enable-pthreads --with-readline-dir=/usr/local --prefix=/usr/local vim 7.0.183 from source, --disable-gui --enable-rubyinterp --prefix=/usr/local rails 1.2.1, rubygems 0.9.0 Before Tim fixed up his rails.vim, as noted, vim trapped and died: (from gdb) dyld: Symbol not found: _rb_path2class Referenced from: /usr/local/lib/ruby/1.8.i686-darwin8.8.3/digest/sha2.bundle The stock rubycomplete.vim works, as long as I don't attempt a rails completion, straight up ruby omni works. The most recent rubycomplete.vim from cvs kill it straight away, as did the version of ftplugin before tpope messed with it. As it stands, with the recently updated ftplugin, rails, and stock rubycomplete vim scripts, I'm alright, as long as I don't attempt a rails completion or try including 'rubygems' anywhere. Manually doing :ruby require 'rubygems' traps vim immediately, always with the same error from gdb. I'm currently hassling friends with osx to attempt a replication of this issue, as I'm quite sure it's the build of ruby within osx. Thanks, Jason. -- GPG/PGP key ID: 0x3A410DBD \| http://pgp.mit.edu 7B3F 4505 7D9A 7FDE 83C9 52C2 4909 59B9 3A41 0DBD _______________________________________________ vim-ruby-devel mailing list vim-ruby-develrubyforge.org http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Re: s:rubypath in ftplugin/ruby.vim
	2007-01-23 13:50:29
On Tue, Jan 23, 2007 at 02:43:55PM -0500, Mark Guzman wrote: > Tim Pope wrote: > > This does not help my segfaulting acquaintance (whom I wlll hereafter > > refer to as jsunn) though. I still think use of the interface in the > > ftplugin should be limited to Windows. > > > I'm fine with that, it doesn't really bother me anywhere other than > windows. Though wouldn't that handle the initialization issue for you? In many circumstances, but it's not 100%. If, for example, database.yml file is loaded first, the ruby ftplugin won't be called but rails.vim will be. Cheers, Tim _______________________________________________ vim-ruby-devel mailing list vim-ruby-develrubyforge.org http://rubyforge.org/mailman/listinfo/vim-ruby-devel

Re: s:rubypath in ftplugin/ruby.vim
	2007-01-23 14:16:00
Mark Guzman wrote: > Have you tried this without having rails.vim in the plugins directory? > AFAIK plugins are loaded before ftplugin is run... I am testing on the > same platform, the only difference being that I used macports to build > both ruby and vim. > --mark Just did, same result. In fact, I emptied scripts/ completely, and :ruby require 'rubygems' still segfaults vim. Hard to say about ftplugin, as Tim fixed it so it doesn't segfault at startup anymore, as it used to. But before he got at it, merely opening a file with that ftplugin crashed vim in the same way. Also, fwiw, I don't see any of this behaviour on my openbsd machines, with the same .vim/ from cvs. -- GPG/PGP key ID: 0x3A410DBD \| http://pgp.mit.edu 7B3F 4505 7D9A 7FDE 83C9 52C2 4909 59B9 3A41 0DBD _______________________________________________ vim-ruby-devel mailing list vim-ruby-develrubyforge.org http://rubyforge.org/mailman/listinfo/vim-ruby-devel

Re: s:rubypath in ftplugin/ruby.vim
	2007-01-31 05:31:46
On Mon, Jan 22, 2007 at 01:15:24PM -0600, Tim Pope wrote: <snip> > Any news about a release? I'm back on deck now after a few months in the boondocks. I've just got a couple of patches to test then I'm ready if everyone else still is... Regards, Doug _______________________________________________ vim-ruby-devel mailing list vim-ruby-develrubyforge.org http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[1-10]

about | contact Other archives ( Real Estate discussion Medical topics )