Hi,
In <20060726.190622.80809602.kou@cozmixng.org>
"Re: segfault in ruby bindings triggerd by config=Svn::Core::Config.config(@cfgPath)" on Wed, 26 Jul 2006 19:06:22 +0900 (JST),
Kouhei Sutou <kou@cozmixng.org> wrote:
> > In the ruby script in the Svn::Client::Context object I read the config files
> > and assign the result to the local variable 'config':
> >
> > self.config=Svn::Core::Config.config( @cfgPath )
> >
> > This works in principle, I can access any kind of server urls. But after a
> > short time I get a sporadical segfault wich looks such as this:
>
> I see the problem but I have no time in this week. So I'll fix the problem
> next week. Sorry.
I fixed this bug in r20989.
Sorry for my late work.
> > PS.
> > By the way, I fear that in client.rb the most methods which use
> > a 'rev' and a 'peg_rev' parameter have swapped their positions in the
> > argument list.
> > In the c-header files mostly the peg_rev- comes before the rev-argument
> > but in the client.rb this is reversed.
> > This is not realy a large problem because the arguments are also swapped
> > in the calls to the c-functions.
> > Therefore the user has to call the ruby-methods like the c-functions.
> > The only wrong effect is the handling of the default values of the parameters
> > and the wrong documentation effect.
>
> It is for backward compatibility. The Ruby bindings are develeping before
> peg_rev argument exists. So, peg_rev argument was appended to argument
> list.
I have an idea that the Ruby bindings provides Hash based
optional argument API as Svn::XXX::YYY#zzz2. For example:
The Ruby bindings provides
Svn::Client::Context#status2(options)
for
Svn::Client::Context#status(path, rev=nil, recurse=true, get_all=false,
update=true, no_ignore=false,
ignore_externals=false, &status_func)
This optional argument API will be implemented like that:
module Svn
module Client
class Context
def status2(options)
status(options[:path], options[:rev], ...)
end
end
end
end
Thanks,
--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 5 13:38:23 2006