s:rubypath in ftplugin/ruby.vim

[Mark Guzman]

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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Doug Kearns]

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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Mark Guzman]

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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Tim Pope-2]

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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Mark Guzman]

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.
> Feel free to revert and discuss if you disagree.
>  

Have you actually experienced a crash due to the path discovery code?

  --mark
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Tim Pope-2]

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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Mark Guzman]

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
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Tim Pope-2]

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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Mark Guzman]

Mark Guzman wrote:
>>> 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.
>>  
>>    
It just struck me that you might've mis-understood my original question.
I was asking about the actual path discovery stuff (s:rubypath), not the
omni-completion crash.
  --mark
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Jason LaRiviere-2]

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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Mark Guzman]

Tim Pope wrote:

> 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.
>  

I wonder if the same thing happens with the other interfaces.
> 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?

Thanks Tim
  --mark
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Tim Pope-2]

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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Mark Guzman]

Jason LaRiviere wrote:

>
> 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.
>
>  

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
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Jason LaRiviere-2]

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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Mark Guzman]

Tim Pope wrote:
> 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.
>  
I checked the load order information after that, and it seems that
plugins get loaded before ftplugins.
  --mark
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Mark Guzman]

Jason LaRiviere wrote:

> 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.
>  

Can you get me an strace?
  --mark
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Mark Guzman]

Jason LaRiviere wrote:

> 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.
>  

A core would be nice too :)
  --mark
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Jason LaRiviere-2]

Mark Guzman wrote:
> Can you get me an strace?
>   --mark

Well, I can get you a ktrace. :)
http://indelicate.net/misc/vim.ktrace.out

Sorta the same as strace, but with 20% more suck.
--
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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Mark Guzman]

Jason LaRiviere wrote:

> Mark Guzman wrote:
>  
>> Can you get me an strace?
>>   --mark
>>    
>
> Well, I can get you a ktrace. :)
> http://indelicate.net/misc/vim.ktrace.out
>
> Sorta the same as strace, but with 20% more suck.
>  

Sweet! Thanks.
  --mark
_______________________________________________
vim-ruby-devel mailing list
vim-ruby-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel

[Jason LaRiviere-2]

Mark Guzman wrote:
> Sweet! Thanks.
>   --mark

I think we can put this to bed and chalk it up to a wonky ruby build.
At your request, I took a look at the macports build file for ruby, and
noticed some differences in CFLAGS and CPPFLAGS.

Left to its own devices, it was using CFLAGS=-O2, and nothing in
CPPFLAGS.

I forced each to use -O, as per the macports build file, and rebuilt
ruby, then vim.

Fixed. \o/

Terribly sorry to have wasted anyone's time with a problem that clearly
ended up not having anything to do with vim.

Regards,
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-devel@...
http://rubyforge.org/mailman/listinfo/vim-ruby-devel