Philip Martin wrote on Wed, Feb 08, 2012 at 17:36:17 +0000:
> Stefan Sperling <stsp_at_elego.de> writes:
>
> > On Wed, Feb 08, 2012 at 07:01:48PM +0200, Daniel Shahaf wrote:
> >> So, you are saying that there is no legitimate/supported scenario in
> >> which the .py and .so are out of sync with each other? And that code
> >> written for a library version that has the symbol will return a normal
> >> error (eg, AttributeError in Python) when run against a library version
> >> (such as 1.7.2) that doesn't have the symbol?
> >>
> >> (I'm talking about the .so here; it's not clear to me whether your
> >> reference to hasattr() checked the existence of the symbol in the .py
> >> library file or in the .so library file.)
> >>
> >> In these cases it seems to me that we might be able to backport this.
> >> Stefan?
> >
> > I have no idea :)
>
> I think the problem is that in Python one has to write:
>
> if hasattr(core, 'svn_auth_set_gnome_keyring_unlock_prompt_func'):
> core.svn_auth_set_gnome_keyring_unlock_prompt_func(ctx.auth_baton, prompt_func_gnome_keyring_prompt)
>
> If called unconditionally:
>
> core.svn_auth_set_gnome_keyring_unlock_prompt_func(ctx.auth_baton, prompt_func_gnome_keyring_prompt)
>
> it will work with 1.7.3 and fail with 1.7.2. In Ruby the magic is:
>
> if Svn::Ext::Core.respond_to?(:svn_auth_set_gnome_keyring_unlock_prompt_func)
> Svn::Ext::Core::svn_auth_set_gnome_keyring_unlock_prompt_func(ctx.auth_baton, gnome_keyring_prompt)
>
> and I suppose Perl might have something similar.
>
defined(&SVN::Core::svn_auth_set_gnome_keyring_unlock_prompt_func)
> I think that means this is not suitable for a backport.
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
Received on 2012-02-08 18:45:58 CET