log_receiver in swig bindings

[Chia-liang Kao <cl...@clkao.org>]

Hi,

I managed to get the following perl code work to mimic the output
of svn log -v:

$repos->get_logs((), 1, $headrev , 1, 1, 1,
		 sub { my $paths = shift;
		       print '-' x 72;
		       printf "rev %d:  %s | %s\nChanged paths:\n", @_[0..2];
		       while (my ($path, $info) = each %$paths) {
			   print '  '.$info->action.' '.$path.
			       ($info->copyfrom_path ?
				" (from: ".$info->copyfrom_path.
				':'.$info->copyfrom_rev.')' : '')
			   }
		       print $_[3];
		     },
		 $pool);

while there is an issue with the current swig interface definition.
the gluing callback thunk_receiver tries to create a object of
svn_log_changed_path_t * for the target language. But it was declared
in svn_types.c, which all its wrappers are created in core.i. while
the thunk_receiver is working under namespace of svn_repos, it can't
resolve svn_log_changed_path_t * in runtime. my current workaround
is to paste the struct definition into svn_repos.i, before %import 
svn_types.i. but this is definitely not the way since there are 
probaby other cases like this. one possible solution is to build 
all wrapper in one package, and each module just imports the symbols 
it is interested in. another way is to move the typedef into svn_repos.h.

btw, in swigutil_py.c:svn_swig_py_thunk_log_receiver, it tries to
resolve SWIGTYPE_p_svn_log_changed_path_t instead of 
svn_log_changed_path_t *.

Cheers,
CLK

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: log_receiver in swig bindings

[Chia-liang Kao <cl...@clkao.org>]

Ah, something must be fooling me. Yes, swig_type is registered
to a global list. so just removing the %ignore in core.i will
work. just that the accessors will be in the namespace of core
instead of repos, but higher level wrapper shuold resolve this.

and the comment around the code is probably misleading - people
aren't likely going to set items in the changed_path hash, so
the leak would only happen if people try to do some funny thing.

Cheers,
CLK

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: log_receiver in swig bindings

[Russell Yanofsky <re...@columbia.edu>]

Chia-liang Kao wrote:
>...
> while there is an issue with the current swig interface definition.
> the gluing callback thunk_receiver tries to create a object of
> svn_log_changed_path_t * for the target language. But it was declared
> in svn_types.c, which all its wrappers are created in core.i. while
> the thunk_receiver is working under namespace of svn_repos, it can't
> resolve svn_log_changed_path_t * in runtime.

Actually the problem is this line in core.i:

  %ignore svn_log_changed_path_t;

I posted a small patch to fix this and the swigutil_py problem a little while
ago but nobody responded and hasn't it been committed. It's at
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=40022

- Russ





> my current workaround
> is to paste the struct definition into svn_repos.i, before %import
> svn_types.i. but this is definitely not the way since there are
> probaby other cases like this. one possible solution is to build
> all wrapper in one package, and each module just imports the symbols
> it is interested in. another way is to move the typedef into
> svn_repos.h.
>
> btw, in swigutil_py.c:svn_swig_py_thunk_log_receiver, it tries to
> resolve SWIGTYPE_p_svn_log_changed_path_t instead of
> svn_log_changed_path_t *.
>
> Cheers,
> CLK
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org