You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Barry Scott <ba...@barrys-emacs.org> on 2003/09/09 23:16:26 UTC
Should the python examples work in 0.29.0?
I've tried getfile.py and svnshell.py and both report the same error.
My repository is hosted on FreeBSD built from the 0.29.0 sources.
I'm testing from Windows XP using the binary kits downloaded from
tigris.org.
Did I set something up wrong?
BArry
[X:\subversion\subversion-0.29.0\tools\examples]
> c:\Python23\python.exe svnshell.py http://torment/svn/repos1/Latest
Traceback (most recent call last):
File "svnshell.py", line 304, in ?
main()
File "svnshell.py", line 301, in main
core.run_app(SVNShell, sys.argv[1])
File "C:\Python23\lib\site-packages\svn\core.py", line 33, in run_app
return apply(func, (pool,) + args, kw)
File "svnshell.py", line 36, in __init__
self.fs_ptr = repos.svn_repos_fs(repos.svn_repos_open(path, pool))
RuntimeError: Expected version '2' of repository; found no version at all;
is `http://torment/svn/re
pos1/Latest' a valid repository path?
[X:\subversion\subversion-0.29.0\tools\examples]
> svn ls http://torment/svn/repos1/Latest
Emacs/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
API Documentation
Posted by Barry Scott <ba...@barrys-emacs.org>.
Ben,
The reason I said that the SVN API is complex is because of the large number of
functions that I may need to get an understanding of. At 5 mins a function or
struct it will be 2 man weeks work.
The docs you need are the ones that focus a developer on the useful subset
of the API.
Hopefully this is knowning svn_client.h API functions and handfull of
structs not the
full 700.
Chapter 7 seems to be a combination of internals docs that are interesting
as back
ground but no aid in getting software working against the API. For example
why should
I care about the entries files? the SVN API is my way into that data right?
Maybe you could split Chapter 7 into two. An inside SVN chapter and a
programming
SVN chapter.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
Russ,
At 17-09-2003 02:50, Russell Yanofsky wrote:
>The problem isn't really completeness. It's just that many of the python
>apis have bugs we don't know about because they've never been used. Most of
>the bugs are easy to fix once we do know about them. For example, the
>problems you had with None config_dir parameters and the
>svn_config_get_config() return value should be fixed by the changes in
>revision 7076
>(http://svn.collab.net/viewcvs-dev/svn/trunk/subversion/bindings/swig/core.i
>#rev7076)
Great news. I'd assumed this was low priority - I'm glad its not.
I've only learned to build on FreeBSD at the moment. I'll learn
how to build on windows, where I need the Python API, and test
out this fix and see what else I can find.
BArry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> ...
> But status looks like it will not work until we wrap the status func.
>
> TypeError: Type error. Expected _p_svn_wc_status_func_t
>
> Here is the code I'm testing with:
> ..
This should be fixed in revision 7349. You don't get to use the baton,
though, so you need the following change:
--- test.py Wed Oct 08 00:32:50 2003
+++ test.py.fix1 Wed Oct 08 01:38:24 2003
@@ -21,7 +21,6 @@
path, # const char *path,
None, # svn_opt_revision_t *revision,
status_func, # svn_wc_status_func_t status_func,
- None, # void *status_baton,
0, # svn_boolean_t descend,
0, # svn_boolean_t get_all,
0, # svn_boolean_t update,
@@ -34,8 +33,7 @@
return 0
-def status_func( baton, path, status ):
- print 'baton:', repr(baton)
+def status_func( path, status ):
print 'path:',repr(path)
print 'status:',repr(status)
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> ...
> But status looks like it will not work until we wrap the status func.
>
> TypeError: Type error. Expected _p_svn_wc_status_func_t
>
> Here is the code I'm testing with:
> ..
This should be fixed in revision 7349. You don't get to use the baton,
though, so you need the following change:
--- test.py Wed Oct 08 00:32:50 2003
+++ test.py.fix1 Wed Oct 08 01:38:24 2003
@@ -21,7 +21,6 @@
path, # const char *path,
None, # svn_opt_revision_t *revision,
status_func, # svn_wc_status_func_t status_func,
- None, # void *status_baton,
0, # svn_boolean_t descend,
0, # svn_boolean_t get_all,
0, # svn_boolean_t update,
@@ -34,8 +33,7 @@
return 0
-def status_func( baton, path, status ):
- print 'baton:', repr(baton)
+def status_func( path, status ):
print 'path:',repr(path)
print 'status:',repr(status)
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> ...
> But status looks like it will not work until we wrap the status func.
>
> TypeError: Type error. Expected _p_svn_wc_status_func_t
>
> Here is the code I'm testing with:
> ..
This should be fixed in revision 7349. You don't get to use the baton,
though, so you need the following change:
--- test.py Wed Oct 08 00:32:50 2003
+++ test.py.fix1 Wed Oct 08 01:38:24 2003
@@ -21,7 +21,6 @@
path, # const char *path,
None, # svn_opt_revision_t *revision,
status_func, # svn_wc_status_func_t status_func,
- None, # void *status_baton,
0, # svn_boolean_t descend,
0, # svn_boolean_t get_all,
0, # svn_boolean_t update,
@@ -34,8 +33,7 @@
return 0
-def status_func( baton, path, status ):
- print 'baton:', repr(baton)
+def status_func( path, status ):
print 'path:',repr(path)
print 'status:',repr(status)
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> ...
> But status looks like it will not work until we wrap the status func.
>
> TypeError: Type error. Expected _p_svn_wc_status_func_t
>
> Here is the code I'm testing with:
> ..
This should be fixed in revision 7349. You don't get to use the baton,
though, so you need the following change:
--- test.py Wed Oct 08 00:32:50 2003
+++ test.py.fix1 Wed Oct 08 01:38:24 2003
@@ -21,7 +21,6 @@
path, # const char *path,
None, # svn_opt_revision_t *revision,
status_func, # svn_wc_status_func_t status_func,
- None, # void *status_baton,
0, # svn_boolean_t descend,
0, # svn_boolean_t get_all,
0, # svn_boolean_t update,
@@ -34,8 +33,7 @@
return 0
-def status_func( baton, path, status ):
- print 'baton:', repr(baton)
+def status_func( path, status ):
print 'path:',repr(path)
print 'status:',repr(status)
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
Russ,
Aha! That makes svn_client_ls work (unless I need to input a auth credentials).
I could get useful values out of the dirent with one expection. How do I turn
the .time (_b875ba00_p_apr_time_t) property into a python time.time() value?
The 64bit value in apr_time_t should convert without lose into a double that
python uses.
I've used the same pattern to get checkout working.
But status looks like it will not work until we wrap the status func.
TypeError: Type error. Expected _p_svn_wc_status_func_t
Here is the code I'm testing with:
-------------------------------------------
import sys
import svn.core
import svn.client
def main(argv):
path = argv[1]
print 'svn status %s' % path
try:
pool = svn.core.svn_pool_create(None)
svn.core.svn_config_ensure( None, pool )
ctx = svn.client.svn_client_ctx_t()
config = svn.core.svn_config_get_config( None, pool )
ctx.config = config
yougest = svn.client.svn_client_status(
# svn_client_status (svn_revnum_t *youngest, /* only touched if
`update' set */
path, # const char *path,
None, # svn_opt_revision_t *revision,
status_func, # svn_wc_status_func_t status_func,
None, # void *status_baton,
0, # svn_boolean_t descend,
0, # svn_boolean_t get_all,
0, # svn_boolean_t update,
1, # svn_boolean_t no_ignore,
ctx, # svn_client_ctx_t *ctx,
pool ) # apr_pool_t *pool);
finally:
svn.core.svn_pool_destroy(pool)
return 0
def status_func( baton, path, status ):
print 'baton:', repr(baton)
print 'path:',repr(path)
print 'status:',repr(status)
if __name__ == '__main__':
sys.exit( main( sys.argv ) )
-------------------------------------------
BArry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> Russ,
>
> That works. Now I'm trying to call svn_client_ls.
>
> files = svn.client.svn_client_ls( url, 0, ctx, pool )
> TypeError: svn_client_ls() takes exactly 5 arguments (4 given)
>
> The 1st in the C API apr_hash_t **dirents. It seems that the SWIG you
> use to get the cfg_config is the same as for dirents so I'm not sure
> why svn_config_get_config is happy to have me ommit the hash as the
> 1st param but svn_client_ls is not.
SWIG is perfectly happy to omit the first argument. The problem is that you
forget one of the middle arguments. The following change will solve your
error:
--- test.py Sun Oct 05 21:45:22 2003
+++ test.py.fix1 Sun Oct 05 21:50:02 2003
@@ -20,7 +20,10 @@
ctx.config = config
- all_files = svn.client.svn_client_ls( url, 0, ctx, pool )
+ revision = svn.core.svn_opt_revision_t()
+ revision.kind = svn.core.svn_opt_revision_head
+
+ all_files = svn.client.svn_client_ls( url, revision, 0, ctx, pool )
print repr(all_files)
print type(all_files)
> I now have this the test code below. I'm expecting that the ctx does
> not have enough fields initialised yet, like password prompting.
You're right. Running the script with the change above causes a NULL pointer
dereference. One more change makes the script work on a public URL:
--- test.py.fix1 Sun Oct 05 21:50:02 2003
+++ test.py.fix2 Sun Oct 05 22:03:27 2003
@@ -18,6 +18,7 @@
print 'config repr:',repr(config)
print 'config type:',type(config)
+ ctx.auth_baton = svn.core.svn_auth_open([], pool)
ctx.config = config
revision = svn.core.svn_opt_revision_t()
>
> In the case of the dirents I'm guessing that I do want it converted
> to a python dict to all me to process it.
That makes sense, and the current swig code does do the conversion.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
> > Is it time to give up on the current SWIG bindings and
> > start the design work that was talked about in another thread?
>
>Do you mean the discussion about wrapping the API's in an easier to use
>interface? Some of the approaches described would build on top of the
>current bindings.
I was thinking about the possibility of wrapping the RapidSVN svncpp
API instead.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> Is could be fixed in the C API or the Python wrapper. If the C API
> converted misuse to error codes then the python would just throw
> python exceptions with ease.
Generally speaking, libraries can't detect when they are being misused. It's
possible to check for simple cases but only if you're willing to bloat the
code and take effort that might be better spent improving documentation and
simplifiying api's so the misuse doesn't happen in the first place. I am a
little sympathetic to the idea, though, because error messages probably make
a better impression on scripting language users than segfaults.
> Again the RapidSVN api may make this a lot easier. I'm watching for
> the patch to bring RapidSVN up to 0.30.0 compatibility.
Yeah, the RapidSVN API looks a lot less error prone. And they actually
mention swig on their homepage, http://rapidsvn.tigris.org/svncpp.html, so
it was probably designed to be swigified
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> At 18-10-2003 22:45, Russell Yanofsky wrote:
>> It will if you explicitly instatiate the templates. There's an
>> example of this at http://www.swig.org/tutorial.html in the "Surely
>> there's more to it..." section. There's also more in-depth
>> documentation on doing this at
>> http://www.swig.org/Doc1.3/SWIGPlus.html#n28.
>
> I added:
>
> %include <string>
> %include <list>
>
> %template(std_string) std::string;
> %template(DirEntries) svn::DirEntries;
> %template(StatusEntries) svn::StatusEntries;
> %template(LogEntries) svn::LogEntries;
>
> Fails because SWIG cannot parse the MCVC6 header files...
You shouldn't need to %include those headers at all unless you need users to
be able to manipulate string and list objects from python code. If you do
need that, then you haven't created a very "pythonic" api, and you'll have
to wrap these types by declaring them in the .i file.
> I see other solving the problems by using %typemap code specific
> to python. Which does not help get other languages working.
As I see it, most of the "problems" you mention aren't really problems at
all, just cases where you want to take advantage of python's syntactic
sugar. Not surprisingly, typemaps that you write for these cases will use
python specific code. Typemaps that add real functionality (like typemaps
supporting callbacks) do not need to use python specific code (although the
subversion C bindings currently do anyway).
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 18-10-2003 22:45, Russell Yanofsky wrote:
>It will if you explicitly instatiate the templates. There's an example of
>this at http://www.swig.org/tutorial.html in the "Surely there's more to
>it..." section. There's also more in-depth documentation on doing this at
>http://www.swig.org/Doc1.3/SWIGPlus.html#n28.
I added:
%include <string>
%include <list>
%template(std_string) std::string;
%template(DirEntries) svn::DirEntries;
%template(StatusEntries) svn::StatusEntries;
%template(LogEntries) svn::LogEntries;
Fails because SWIG cannot parse the MCVC6 header files...
I see other solving the problems by using %typemap code specific
to python. Which does not help get other languages working.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 19-10-2003 19:30, Russell Yanofsky wrote:
>Anyway, considering that you are a PyCXX developer, and are just beginning
>to get acquanted with SWIG's features, I'll take back what I said about
>PyCXX not having any advantages over SWIG in this case. You should go with
>what you know.
Indeed my SWIG knowledge is not up to achieving the goal I want with
the python API.
I now have all the SVN client API wrapped in a pythonic way. I need to add
the call backs, which as you guessed are pure virtuals that need
overriding. Then I need feed back.
BArry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
>> PyCXX instead of SWIG? I don't see any advantages to doing that. The
>> main advantage that Boost::Python and (presumably) PyCXX have over
>> SWIG is that they let you easily access Python features from C++, so
>> you can build cool hybrid C++/Python apps. But in this case, you're
>> not implementing parts of the library in python, just exposing it
>> all to python. Beyond that, using PyCXX would give you two potential
>> disadvantages:
>
> PyCXX allows me to use a very pythonic API. For example I have a
> revision object that allows me to:
>
> rev = pysvn.revision()
> rev.kind_name = "head"
> And a ls that takes keywords and returns a list of dicts for the
> result with times converted to python time.
>
> client = pysvn.client()
> all_files = client.ls( url, recurse=true, revision=rev )
> for file in all_files:
> print file['name']
As you say in your other message, this can all be done with typemaps.
> I can also support threading by releasing the python interpreter lock
> around the svn calls.
SWIG does this by default.
> How would SWIG support all the callbacks?
Does Svncpp even use callbacks? I'd expect it to use virtual member
functions instead. Swig does supports overriding virtual members functions
in python (http://www.swig.org/Doc1.3/Python.html#n32). If SvnCpp does use
callbacks, they can be supported with typemaps.
> I can isolate the Python world from crashing from bad param passing.
You could write additional parameter validation code with swig, too.
Anyway, considering that you are a PyCXX developer, and are just beginning
to get acquanted with SWIG's features, I'll take back what I said about
PyCXX not having any advantages over SWIG in this case. You should go with
what you know.
>> 1) The SvnCpp bindings wouldn't be able to interoperate with the
>> Subversion C bindings.
>
> Why would I need this interop? I don't understand why it matters.
I listed this as a *potential* disadvantage because, I don't know enough
about SvnCpp to know if it actually does matter. But AFAICT, SvnCpp only
wraps a small portion of the Subversion API, so it is concievable that a
user might want to call a subversion API with SvnCpp data in order to access
some feature that hadn't been wrapped.
>> 2) The SvnCpp bindings wouldn't be available to Perl, Java, Ruby,
>> PHP, etc, etc users.
>
> My goal is a Python API and I'm not convinced that SWIG can make a
> good python API. I know that PyCXX can. SWIG may be good enough to
> make
> the other languages.
I'll stop trying to convince you, but as far as I know SWIG does not prevent
you from using any Python features.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 18-10-2003 22:45, Russell Yanofsky wrote:
>It will if you explicitly instatiate the templates. There's an example of
>this at http://www.swig.org/tutorial.html in the "Surely there's more to
>it..." section. There's also more in-depth documentation on doing this at
>http://www.swig.org/Doc1.3/SWIGPlus.html#n28.
Thanks. I'll look at it.
>PyCXX instead of SWIG? I don't see any advantages to doing that. The main
>advantage that Boost::Python and (presumably) PyCXX have over SWIG is that
>they let you easily access Python features from C++, so you can build cool
>hybrid C++/Python apps. But in this case, you're not implementing parts of
>the library in python, just exposing it all to python. Beyond that, using
>PyCXX would give you two potential disadvantages:
PyCXX allows me to use a very pythonic API. For example I have a revision
object that allows me to:
rev = pysvn.revision()
rev.kind_name = "head"
And a ls that takes keywords and returns a list of dicts for the result
with times converted to python time.
client = pysvn.client()
all_files = client.ls( url, recurse=true, revision=rev )
for file in all_files:
print file['name']
I can also support threading by releasing the python interpreter lock
around the svn calls.
How would SWIG support all the callbacks?
I can isolate the Python world from crashing from bad param passing.
>1) The SvnCpp bindings wouldn't be able to interoperate with the Subversion
>C bindings.
Why would I need this interop? I don't understand why it matters.
>2) The SvnCpp bindings wouldn't be available to Perl, Java, Ruby, PHP, etc,
>etc users.
My goal is a Python API and I'm not convinced that SWIG can make a
good python API. I know that PyCXX can. SWIG may be good enough to make
the other languages.
BArry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> At 16-10-2003 23:29, Russell Yanofsky wrote:
>> The swig wrapper looks straighforward, although it's not clear why
>> you need so many helper functions. Couldn't a user write
>>
>> all_dirents.size()
>>
>> instead of:
>>
>> svncpp.lenDirentList( all_dirents )
>>
>> - Russ
>
> SWIG does not generate code at all for the methods on the templates.
It will if you explicitly instatiate the templates. There's an example of
this at http://www.swig.org/tutorial.html in the "Surely there's more to
it..." section. There's also more in-depth documentation on doing this at
http://www.swig.org/Doc1.3/SWIGPlus.html#n28.
> You get this:
>
> Traceback (most recent call last):
> File "test_ls.py", line 29, in ?
> main( sys.argv )
> File "test_ls.py", line 17, in main
> print all_dirents.size()
> AttributeError: 'str' object has no attribute 'size'
>
> I solved that with all the little functions. Not sure why its seen as
> a string.
Swig represents opaque pointers as strings containing address and type
information.
> I'm going to try using my PyCXX lib to remove the need for the small
> functions and allow iterators to work. PyCXX is on
> http://sourceforge.net/projects/cxx/ and will allow a pythonic API to
> be created.
PyCXX instead of SWIG? I don't see any advantages to doing that. The main
advantage that Boost::Python and (presumably) PyCXX have over SWIG is that
they let you easily access Python features from C++, so you can build cool
hybrid C++/Python apps. But in this case, you're not implementing parts of
the library in python, just exposing it all to python. Beyond that, using
PyCXX would give you two potential disadvantages:
1) The SvnCpp bindings wouldn't be able to interoperate with the Subversion
C bindings.
2) The SvnCpp bindings wouldn't be available to Perl, Java, Ruby, PHP, etc,
etc users.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 16-10-2003 23:29, Russell Yanofsky wrote:
>The swig wrapper looks straighforward, although it's not clear why you need
>so many helper functions. Couldn't a user write
>
> all_dirents.size()
>
>instead of:
>
> svncpp.lenDirentList( all_dirents )
>
>- Russ
SWIG does not generate code at all for the methods on the templates.
You get this:
Traceback (most recent call last):
File "test_ls.py", line 29, in ?
main( sys.argv )
File "test_ls.py", line 17, in main
print all_dirents.size()
AttributeError: 'str' object has no attribute 'size'
I solved that with all the little functions. Not sure why its seen as a string.
I'm going to try using my PyCXX lib to remove the need for the small functions
and allow iterators to work. PyCXX is on http://sourceforge.net/projects/cxx/
and will allow a pythonic API to be created.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <ru...@russ.hn.org>.
Barry Scott wrote:
> (let's stop cross posting. Use dev?)
Yes.
>
> At 16-10-2003 18:50, Russell Yanofsky wrote:
>> If the subversion API were a normal python library, it would need to
>> report these types of errors. But it's not a normal python library.
>> It already requires users to use pools and manage their own memory.
>> I don't think it's too much to ask them to ask them to write correct
>> programs in order to prevent crashes.
>
> Sorry I don't accept this line of reasoning. Why must it be so hard
> and unfriendly? It means that any app I build for users will crash in
> response to my bugs in a way that makes support a nightmare. Atleast
> with python exception I get a useful report. (Tupically I catch the
> exceptions
> and automatically mail bug reports in for in house projects).
The bugs that cause crashes tend to be be really simple mistakes that will
get weeded out with even a really small amount of testing. None of the API's
I've seen are complicated enough to subtly misuse, so I don't think you'll
have any support nightmares. But even if you are worried about this, you
should be able to see that turning assertions into returned error codes
would only prevent crashes in a small number of cases.
>> I saw your svncpp patches browsing the rapidsvn dev list. Can you
>> post your swig wrapper somewhere? Do you think your work could be
>> incorporated into rapidsvn?
>
> I'm trying to convince Alex not to make svncpp dependent on wxWindows.
> I'd be happy if the source is available to compile and build the
> extension from, using std::list and std::string is fine.
I think you did convince him.
> Here is the prototype (not fit to ship) swig file. I've added in
> functions to convert types into something that SWIG can convert.
> Below is my
> unittest for ls. I have status and log working as well.
The rapidsvn api does look much easier to get started with since it doens't
force you to deal with side issues like authentication before you can have
working code.
The swig wrapper looks straighforward, although it's not clear why you need
so many helper functions. Couldn't a user write
all_dirents.size()
instead of:
svncpp.lenDirentList( all_dirents )
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
(let's stop cross posting. Use dev?)
At 16-10-2003 18:50, Russell Yanofsky wrote:
>If the subversion API were a normal python library, it would need to report
>these types of errors. But it's not a normal python library. It already
>requires users to use pools and manage their own memory. I don't think it's
>too much to ask them to ask them to write correct programs in order to
>prevent crashes.
Sorry I don't accept this line of reasoning. Why must it be so hard and
unfriendly? It means that any app I build for users will crash in response
to my bugs in a way that makes support a nightmare. Atleast with python
exception I get a useful report. (Tupically I catch the exceptions
and automatically mail bug reports in for in house projects).
>I saw your svncpp patches browsing the rapidsvn dev list. Can you post your
>swig wrapper somewhere? Do you think your work could be incorporated into
>rapidsvn?
I'm trying to convince Alex not to make svncpp dependent on wxWindows.
I'd be happy if the source is available to compile and build the extension
from, using std::list and std::string is fine.
Here is the prototype (not fit to ship) swig file. I've added in functions
to convert types into something that SWIG can convert. Below is my
unittest for ls. I have status and log working as well.
Barry
------------------ svncpp.i ------------------------------
%module svncpp
%{
#include "client.hpp"
#include "context.hpp"
#include "dirent.hpp"
#include "entry.hpp"
#include "exception.hpp"
#include "log_entry.hpp"
#include "notify.hpp"
#include "path.hpp"
#include "pool.hpp"
#include "property.hpp"
#include "revision.hpp"
#include "status.hpp"
#include "targets.hpp"
#include "url.hpp"
#include "wc.hpp"
using namespace svn;
int lenDirentList( svn::DirEntries &entry_list )
{
return entry_list.size();
}
svn::DirEntry &getDirentFromList( svn::DirEntries &entry_list, int index )
{
return entry_list[index];
}
int lenLogEntriesList( svn::LogEntries &entry_list )
{
return entry_list.size();
}
svn::LogEntry &getLogEntryFromList( svn::LogEntries &entry_list, int index )
{
return entry_list[index];
}
int lenStatusList( svn::StatusEntries &entry_list )
{
return entry_list.size();
}
svn::Status &getStatusFromList( svn::StatusEntries &entry_list, int index )
{
return entry_list[index];
}
double pyTimeFromAprTime( apr_time_t &apr_time )
{
return apr_time / 1000000.0;
}
double pyFileSizeFromSvnFileSize( svn_filesize_t &size )
{
return (double)(signed __int64)size;
}
const char *cstrFromStdString( const std::string &str )
{
return str.c_str();
}
%}
%rename(doImport) svn::Client::import (const Path & path, const char * url,
const char * message, bool recurse);
%include "client.hpp"
%include "context.hpp"
%include "dirent.hpp"
%include "entry.hpp"
%include "exception.hpp"
%include "log_entry.hpp"
%include "notify.hpp"
%include "path.hpp"
%include "pool.hpp"
%include "property.hpp"
%include "revision.hpp"
%include "status.hpp"
%include "targets.hpp"
%include "url.hpp"
%include "wc.hpp"
%include "svn_types.h"
%include "svn_wc.h"
extern int lenDirentList( svn::DirEntries &entry_list );
extern svn::DirEntry &getDirentFromList( svn::DirEntries &entry_list, int
index );
extern int lenLogEntriesList( svn::LogEntries &entry_list );
extern svn::LogEntry &getLogEntryFromList( svn::LogEntries &entry_list, int
index );
extern int lenStatusList( svn::StatusEntries &entry_list );
extern svn::Status &getStatusFromList( svn::StatusEntries &entry_list, int
index );
extern double pyTimeFromAprTime( apr_time_t &time );
extern double pyFileSizeFromSvnFileSize( svn_filesize_t &size );
extern const char *cstrFromStdString( const std::string &str );
--------------------- test_ls.py ----------------------
import sys
import time
import svncpp
kind_map = {
svncpp.svn_node_none: 'none',
svncpp.svn_node_file: 'file',
svncpp.svn_node_dir: 'dir',
svncpp.svn_node_unknown: 'unknown'
}
def main( argv ):
c = svncpp.Client()
r = svncpp.Revision( svncpp.Revision.HEAD )
all_dirents = c.ls( argv[1], r.revision(), 0 )
for i in range( svncpp.lenDirentList( all_dirents ) ):
entry = svncpp.getDirentFromList( all_dirents, i )
print '%4.4s %s' % (kind_map[ entry.kind() ], entry.name())
print ' %d %s %s %d' % ( entry.createdRev(),
entry.lastAuthor(),
time.strftime( '%d-%b-%Y %H:%M:%S',
time.localtime( svncpp.pyTimeFromAprTime(
entry.time() ) ) ),
long(svncpp.pyFileSizeFromSvnFileSize(
entry.size() )))
if __name__ == '__main__':
main( sys.argv )
------------------------- end ----------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> At 14-10-2003 22:36, Russell Yanofsky wrote:
>> Barry Scott wrote:
>>> Is could be fixed in the C API or the Python wrapper. If the C API
>>> converted misuse to error codes then the python would just throw
>>> python exceptions with ease.
>>
>> Generally speaking, libraries can't detect when they are being
>> misused. It's possible to check for simple cases but only if you're
>> willing to bloat the code and take effort that might be better spent
>> improving documentation and simplifiying api's so the misuse doesn't
>> happen in the first place. I am a little sympathetic to the idea,
>> though, because error messages probably make a better impression on
>> scripting language users than segfaults.
>
> There is a sort of weak design-by-contract going on with the asserts
> enforcing contract violations. For non C/C++ use those contract
> violation need to
> be errors reported under control.
If the subversion API were a normal python library, it would need to report
these types of errors. But it's not a normal python library. It already
requires users to use pools and manage their own memory. I don't think it's
too much to ask them to ask them to write correct programs in order to
prevent crashes.
> The starting point would be to
> change
> the asserts into error returning checks. The asserts could still be in
> for debug builds.
I don't think converting asserts into error codes is something that will
happen any time soon (unless it can be done with some type of preprocessor
magic).
Assertions work well in C and are more convenient to use than error codes.
>
>>> Again the RapidSVN api may make this a lot easier. I'm watching for
>>> the patch to bring RapidSVN up to 0.30.0 compatibility.
>>
>> Yeah, the RapidSVN API looks a lot less error prone. And they
>> actually mention swig on their homepage,
>> http://rapidsvn.tigris.org/svncpp.html, so it was probably designed
>> to be swigified
>
> I have a prototype that seems to work, but it needs some patches that
> I've submitted to the rapidsvn folks. It also has the crash if
> misused, but there are far fewer holes to plug.
I saw your svncpp patches browsing the rapidsvn dev list. Can you post your
swig wrapper somewhere? Do you think your work could be incorporated into
rapidsvn?
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> At 14-10-2003 22:36, Russell Yanofsky wrote:
>> Barry Scott wrote:
>>> Is could be fixed in the C API or the Python wrapper. If the C API
>>> converted misuse to error codes then the python would just throw
>>> python exceptions with ease.
>>
>> Generally speaking, libraries can't detect when they are being
>> misused. It's possible to check for simple cases but only if you're
>> willing to bloat the code and take effort that might be better spent
>> improving documentation and simplifiying api's so the misuse doesn't
>> happen in the first place. I am a little sympathetic to the idea,
>> though, because error messages probably make a better impression on
>> scripting language users than segfaults.
>
> There is a sort of weak design-by-contract going on with the asserts
> enforcing contract violations. For non C/C++ use those contract
> violation need to
> be errors reported under control.
If the subversion API were a normal python library, it would need to report
these types of errors. But it's not a normal python library. It already
requires users to use pools and manage their own memory. I don't think it's
too much to ask them to ask them to write correct programs in order to
prevent crashes.
> The starting point would be to
> change
> the asserts into error returning checks. The asserts could still be in
> for debug builds.
I don't think converting asserts into error codes is something that will
happen any time soon (unless it can be done with some type of preprocessor
magic).
Assertions work well in C and are more convenient to use than error codes.
>
>>> Again the RapidSVN api may make this a lot easier. I'm watching for
>>> the patch to bring RapidSVN up to 0.30.0 compatibility.
>>
>> Yeah, the RapidSVN API looks a lot less error prone. And they
>> actually mention swig on their homepage,
>> http://rapidsvn.tigris.org/svncpp.html, so it was probably designed
>> to be swigified
>
> I have a prototype that seems to work, but it needs some patches that
> I've submitted to the rapidsvn folks. It also has the crash if
> misused, but there are far fewer holes to plug.
I saw your svncpp patches browsing the rapidsvn dev list. Can you post your
swig wrapper somewhere? Do you think your work could be incorporated into
rapidsvn?
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 14-10-2003 22:36, Russell Yanofsky wrote:
>Barry Scott wrote:
> > Is could be fixed in the C API or the Python wrapper. If the C API
> > converted misuse to error codes then the python would just throw
> > python exceptions with ease.
>
>Generally speaking, libraries can't detect when they are being misused. It's
>possible to check for simple cases but only if you're willing to bloat the
>code and take effort that might be better spent improving documentation and
>simplifiying api's so the misuse doesn't happen in the first place. I am a
>little sympathetic to the idea, though, because error messages probably make
>a better impression on scripting language users than segfaults.
There is a sort of weak design-by-contract going on with the asserts enforcing
contract violations. For non C/C++ use those contract violation need to
be errors reported under control. The starting point would be to change
the asserts into error returning checks. The asserts could still be in
for debug builds.
> > Again the RapidSVN api may make this a lot easier. I'm watching for
> > the patch to bring RapidSVN up to 0.30.0 compatibility.
>
>Yeah, the RapidSVN API looks a lot less error prone. And they actually
>mention swig on their homepage, http://rapidsvn.tigris.org/svncpp.html, so
>it was probably designed to be swigified
I have a prototype that seems to work, but it needs some patches that I've
submitted to the rapidsvn folks. It also has the crash if misused, but there
are far fewer holes to plug.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> Is could be fixed in the C API or the Python wrapper. If the C API
> converted misuse to error codes then the python would just throw
> python exceptions with ease.
Generally speaking, libraries can't detect when they are being misused. It's
possible to check for simple cases but only if you're willing to bloat the
code and take effort that might be better spent improving documentation and
simplifiying api's so the misuse doesn't happen in the first place. I am a
little sympathetic to the idea, though, because error messages probably make
a better impression on scripting language users than segfaults.
> Again the RapidSVN api may make this a lot easier. I'm watching for
> the patch to bring RapidSVN up to 0.30.0 compatibility.
Yeah, the RapidSVN API looks a lot less error prone. And they actually
mention swig on their homepage, http://rapidsvn.tigris.org/svncpp.html, so
it was probably designed to be swigified
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> Is could be fixed in the C API or the Python wrapper. If the C API
> converted misuse to error codes then the python would just throw
> python exceptions with ease.
Generally speaking, libraries can't detect when they are being misused. It's
possible to check for simple cases but only if you're willing to bloat the
code and take effort that might be better spent improving documentation and
simplifiying api's so the misuse doesn't happen in the first place. I am a
little sympathetic to the idea, though, because error messages probably make
a better impression on scripting language users than segfaults.
> Again the RapidSVN api may make this a lot easier. I'm watching for
> the patch to bring RapidSVN up to 0.30.0 compatibility.
Yeah, the RapidSVN API looks a lot less error prone. And they actually
mention swig on their homepage, http://rapidsvn.tigris.org/svncpp.html, so
it was probably designed to be swigified
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 06-10-2003 19:45, Russell Yanofsky wrote:
>[The bottom part of my previous post somehow got cut off. Here it is.]
>
>Barry Scott wrote:
> > At the moment an error in the python code will drop me into
> > Dev Studio to debug the exception. It would be nice for the
> > wrappers to raise python exceptions rather then enter the svn
> > code and hit the assert calls or fall off the end of NULL
> > pointers.
>
>This is an issue I'm not really sure how to deal with. When you misuse an
>API in C, it's expected that you will get failed assertions and null pointer
>deferences. But python users expect exceptions to explain the error
>conditions, and except when it comes to type checking, swig doesn't provide
>this. It is possible to manually add checks, for example we could easily
>raise a python exception when the "ctx" argument passed to svn_client_ls()
>has a NULL "auth_baton" member. But we can't manually check for every error
>condition.
Is could be fixed in the C API or the Python wrapper. If the C API converted
misuse to error codes then the python would just throw python exceptions with
ease.
Again the RapidSVN api may make this a lot easier. I'm watching for the patch
to bring RapidSVN up to 0.30.0 compatibility.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
[The bottom part of my previous post somehow got cut off. Here it is.]
Barry Scott wrote:
> At the moment an error in the python code will drop me into
> Dev Studio to debug the exception. It would be nice for the
> wrappers to raise python exceptions rather then enter the svn
> code and hit the assert calls or fall off the end of NULL
> pointers.
This is an issue I'm not really sure how to deal with. When you misuse an
API in C, it's expected that you will get failed assertions and null pointer
deferences. But python users expect exceptions to explain the error
conditions, and except when it comes to type checking, swig doesn't provide
this. It is possible to manually add checks, for example we could easily
raise a python exception when the "ctx" argument passed to svn_client_ls()
has a NULL "auth_baton" member. But we can't manually check for every error
condition.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> Russ,
>
> Do you want to keep working away at this or wait until 1.1 work
> starts?
I don't think the feature freeze will really get in the way of work on the
swig bindings. Most of the changes that need to be made are localized
bugfixes.
> Is it time to give up on the current SWIG bindings and
> start the design work that was talked about in another thread?
Do you mean the discussion about wrapping the API's in an easier to use
interface? Some of the approaches described would build on top of the
current bindings.
>
> Anyway...
>
> I have been pushing on to find out what more will need fixing to get
> the current bindings working. The big issue to fix is call backs.
>
> We need a set of C functions that match the signatures like
> svn_wc_status_func_t and svn_auth_simple_prompt_func_t. That call
> the python callable that is stored in the "void *baton" with
> the parameters converted to Python objects.
Many callbacks are already working in the way you describe. If you let me
know which callbacks aren't working I can fix them.
>
> There is also the issue of catching exceptions raised in the
> Python code. I hope it is possible for all call backs to pass
> back an error to stop the outer operation, status, checkout,
> log etc
I think all API functions do propagate errors from callbacks. Even if they
don't, exceptions still won't be lost because they are kept track of in
global data (technically thread-specific data).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
Russ,
Do you want to keep working away at this or wait until 1.1 work
starts? Is it time to give up on the current SWIG bindings and
start the design work that was talked about in another thread?
Anyway...
I have been pushing on to find out what more will need fixing to get
the current bindings working. The big issue to fix is call backs.
We need a set of C functions that match the signatures like
svn_wc_status_func_t and svn_auth_simple_prompt_func_t. That call
the python callable that is stored in the "void *baton" with
the parameters converted to Python objects.
There is also the issue of catching exceptions raised in the
Python code. I hope it is possible for all call backs to pass
back an error to stop the outer operation, status, checkout,
log etc.
At the moment an error in the python code will drop me into
Dev Studio to debug the exception. It would be nice for the
wrappers to raise python exceptions rather then enter the svn
code and hit the assert calls or fall off the end of NULL
pointers.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
Russ,
That works. Now I'm trying to call svn_client_ls.
files = svn.client.svn_client_ls( url, 0, ctx, pool )
TypeError: svn_client_ls() takes exactly 5 arguments (4 given)
The 1st in the C API apr_hash_t **dirents. It seems that the SWIG you
use to get the cfg_config is the same as for dirents so I'm not sure
why svn_config_get_config is happy to have me ommit the hash as the
1st param but svn_client_ls is not.
I now have this the test code below. I'm expecting that the ctx does not
have enough fields initialised yet, like password prompting.
In the case of the dirents I'm guessing that I do want it converted
to a python dict to all me to process it.
Barry
import sys
import svn.core
import svn.client
def main(argv):
url = argv[1]
print 'Working on URL: %s' % url
try:
pool = svn.core.svn_pool_create(None)
svn.core.svn_config_ensure( None, pool )
ctx = svn.client.svn_client_ctx_t()
print 'ctx:',repr(ctx)
config = svn.core.svn_config_get_config( None, pool )
print 'config repr:',repr(config)
print 'config type:',type(config)
ctx.config = config
all_files = svn.client.svn_client_ls( url, 0, ctx, pool )
print repr(all_files)
print type(all_files)
finally:
svn.core.svn_pool_destroy(pool)
return 0
if __name__ == '__main__':
sys.exit( main( sys.argv ) )
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> At 03-10-2003 15:56, Russell Yanofsky wrote:
>
>> Apparently not. I'd guess that you should set ctx.config to the
>> return value of svn_config_get_config(), since it's expecting a hash
>> table, not an individual svn_config_t pointer.
>
> But you are returning a python dict not a _p_apr_hash_t.
Yeah, I was assuming that the swig code would automatically convert back and
forth between python dictionaries and apr hashes. Actually it can only do
conversion in one direction, from apr hash to python dictionary.
The simplest way to deal with the problem was to undo one of the changes I
made for you earlier and disable conversion from hashes of svn_config_t's to
dictionaries. This makes svn_config_get_config() return an apr hash pointer
instead of a dictionary so the assignment to ctx.config now works. The
disadvantage of this is that you can no longer access individual entries of
the apr hash. This means you can't call functions like svn_config_get() and
svn_config_set() on items returned by svn_config_get_config(). If you wind
up needing this functionality, I can write a get_hash_config_entry(hash,
key) helper function for you. I think the ultimate solution to this problem
is to make a type safe python interface for accessing apr hashes.
Anyway, if you update to revision 7296, the code you posted will work.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 03-10-2003 15:56, Russell Yanofsky wrote:
>Apparently not. I'd guess that you should set ctx.config to the return value
>of svn_config_get_config(), since it's expecting a hash table, not an
>individual svn_config_t pointer.
But you are returning a python dict not a _p_apr_hash_t.
If I give you my code we can speed up the testing cycle.
Can you get this test code working?
BArry
-----------------------------------------------------
import sys
import svn.core
import svn.client
def main(argv):
try:
pool = svn.core.svn_pool_create(None)
svn.core.svn_config_ensure( None, pool )
ctx = svn.client.svn_client_ctx_t()
print 'ctx:',repr(ctx)
config = svn.core.svn_config_get_config( None, pool )
print 'config repr:',repr(config)
print 'config type:',type(config)
ctx.config = config
finally:
svn.core.svn_pool_destroy(pool)
return 0
if __name__ == '__main__':
sys.exit( main( sys.argv ) )
-------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> Russ,
>
> Where did svn_cmdline_init go? It was in 0.29.0 its not in 0.30.0.
> Do I need it?
It was moved to a different header in revision 7168
(http://svn.collab.net/viewcvs-dev/svn/trunk/subversion/include/svn_cmdline.
h#rev7168). I don't know whether you need it since I'm not familiar with
this API (or most other ones).
>
> svn_config_get_config returns:
> {'config': '_30cc9700_p_svn_config_t', 'servers':
> '_00c79700_p_svn_config_t'}
>
> What is the servers value? Its not clear that the C API returns such
> a thing.
The return value of the python function corresponds to the "cfg_hash"
argument of the C function. According svn_config.h:
* @a *cfg_hash is a hash whose keys are @c const char * configuration
* categories (@c SVN_CONFIG_CATEGORY_SERVERS,
* @c SVN_CONFIG_CATEGORY_CONFIG, etc.) and whose values are the @c
* svn_config_t * items representing the configuration values for that
* category.
SVN_CONFIG_CATEGORY_SERVERS is #defined (in the same header) as "servers"
>
> Is the '_30cc9700_p_svn_config_t' what I put in ctx.config? I get this
> traceback:
>
> File "minimal_client.py", line 27, in main
> ctx.config = config
> File "C:\Python23\lib\site-packages\libsvn\client.py", line 132,
> in <lambda> __setattr__ = lambda self, name, value:
> _swig_setattr(self,
> svn_client_ctx_t, name, value)
> File "C:\Python23\lib\site-packages\libsvn\client.py", line 13, in
> _swig_setattr
> if method: return method(self,value)
> TypeError: Type error. Expected _p_apr_hash_t
>
Apparently not. I'd guess that you should set ctx.config to the return value
of svn_config_get_config(), since it's expecting a hash table, not an
individual svn_config_t pointer.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
Russ,
Where did svn_cmdline_init go? It was in 0.29.0 its not in 0.30.0.
Do I need it?
svn_config_get_config returns:
{'config': '_30cc9700_p_svn_config_t', 'servers': '_00c79700_p_svn_config_t'}
What is the servers value? Its not clear that the C API returns such a thing.
Is the '_30cc9700_p_svn_config_t' what I put in ctx.config? I get this
traceback:
File "minimal_client.py", line 27, in main
ctx.config = config
File "C:\Python23\lib\site-packages\libsvn\client.py", line 132, in <lambda>
__setattr__ = lambda self, name, value: _swig_setattr(self,
svn_client_ctx_t, name, value)
File "C:\Python23\lib\site-packages\libsvn\client.py", line 13, in
_swig_setattr
if method: return method(self,value)
TypeError: Type error. Expected _p_apr_hash_t
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Russell Yanofsky <re...@columbia.edu>.
Barry Scott wrote:
> To save others getting frustrated I've found that the SVN Python API
> is not complete enough to write client apps.
The problem isn't really completeness. It's just that many of the python
apis have bugs we don't know about because they've never been used. Most of
the bugs are easy to fix once we do know about them. For example, the
problems you had with None config_dir parameters and the
svn_config_get_config() return value should be fixed by the changes in
revision 7076
(http://svn.collab.net/viewcvs-dev/svn/trunk/subversion/bindings/swig/core.i
#rev7076)
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
To save others getting frustrated I've found that the SVN Python API
is not complete enough to write client apps.
I don't have the time to contribute to this at the moment. But I'd
be happy to help test if the API is updated.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
I passed in a dict and got this traceback:
File "minimal_client.py", line 16, in main
err = svn.core.svn_config_get_config( config, '', pool )
TypeError: Type error. Expected _p_p_apr_hash_t
I'll hunt down making a _p_p_apr_hash_t.
Barry
At 12-09-2003 20:31, Garrett Rooney wrote:
>Barry Scott wrote:
>
>>Another question: I need a "config" object of some kind to be able to
>>call this
>> svn.core.svn_config_get_config( config, '', pool )
>>What is the config object I need here?
>
>I suspect (and I'm just guessing here), that swig will convert it to
>return a dictionary (because the config you pass in is a pointer to hash
>table, indicating that it will return a hash table via that pointer), and
>take a path to the config directory and a pool as arguments.
>
>-garrett
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Barry Scott wrote:
> Another question: I need a "config" object of some kind to be able to
> call this
>
> svn.core.svn_config_get_config( config, '', pool )
>
> What is the config object I need here?
I suspect (and I'm just guessing here), that swig will convert it to
return a dictionary (because the config you pass in is a pointer to hash
table, indicating that it will return a hash table via that pointer),
and take a path to the config directory and a pool as arguments.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
Another question: I need a "config" object of some kind to be able to call this
svn.core.svn_config_get_config( config, '', pool )
What is the config object I need here?
When I passed None as the config I crash python. The checking of params is
not robust.
BArry
At 12-09-2003 23:25, Barry Scott wrote:
>minimal_client.c obviously does not build against 0.29.0. It's not calling the
>functions like svn_config_ensure with the right number of args.
>
>It seems that the C code can pass NULL as the config_dir that means a default
>is used inside the lib. However I cannot pass None in from Python as it wants
>a string. Is this a swig bug? Or is a "" string the intended object to
>pass in?
>
>Barry
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Learning the Python API - early questions
Posted by Barry Scott <ba...@barrys-emacs.org>.
minimal_client.c obviously does not build against 0.29.0. It's not calling the
functions like svn_config_ensure with the right number of args.
It seems that the C code can pass NULL as the config_dir that means a default
is used inside the lib. However I cannot pass None in from Python as it wants
a string. Is this a swig bug? Or is a "" string the intended object to pass in?
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Should the python examples work in 0.29.0?
Posted by Ben Collins-Sussman <su...@collab.net>.
Barry Scott <ba...@barrys-emacs.org> writes:
> I see the "Developer Information" chapter in the Book. Is that all the
> docs available?
Yeah, start by reading chapter 7. It should give a good overview of
the different library layers.
> In include/subversion-1/*.h there seems to be 59 types and 639 functions,
> (use grep 'typedef struct' and grep ');' to get the numbers).
> Is this the public interface I need to learn?
Beyond that, it's a matter of getting familiar with svn_client.h.
That's the "main" API. From there, you'll be forced to peer into
other header files as needed.
> >Go take a look at /trunk/tools/examples/minimal_client.c, it should
> >get you started.
>
> Thanks, it look like I should be able to port it to python. I start tomorrow.
And then you have this example to help.
Also, don't forget the most important example of all: the commandline
client itself. It's pretty small, in terms of code.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Should the python examples work in 0.29.0?
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 10-09-2003 16:54, Ben Collins-Sussman wrote:
>Um, the svn API really isn't that complex. The public API is
>*already* hiding a ridiculous amount of complexity.
In include/subversion-1/*.h there seems to be 59 types and 639 functions,
(use grep 'typedef struct' and grep ');' to get the numbers).
Is this the public interface I need to learn?
I see the "Developer Information" chapter in the Book. Is that all the
docs available?
>I know that in good python tradition, someone will someday write an
>API that's even simpler, just like python has already done for
>database access, CGI, and so on. But for now, to use the python API,
>there's an assumption that you understand how to use the C API. They
>line up nearly identically.
>
>Go take a look at /trunk/tools/examples/minimal_client.c, it should
>get you started.
Thanks, it look like I should be able to port it to python. I start tomorrow.
BArry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Should the python examples work in 0.29.0?
Posted by Ben Collins-Sussman <su...@collab.net>.
Barry Scott <ba...@barrys-emacs.org> writes:
> Ideally you would have a nice Python module that hides all the
> complexity of the svn API from a python user.
Um, the svn API really isn't that complex. The public API is
*already* hiding a ridiculous amount of complexity.
I know that in good python tradition, someone will someday write an
API that's even simpler, just like python has already done for
database access, CGI, and so on. But for now, to use the python API,
there's an assumption that you understand how to use the C API. They
line up nearly identically.
Go take a look at /trunk/tools/examples/minimal_client.c, it should
get you started.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Should the python examples work in 0.29.0?
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 09-09-2003 18:25, Ben Collins-Sussman wrote:
>svnshell.py links directly against libsvn_fs. It's not a network
>browser. You have to run it *directly* against a repository on local
>disk.
Are there examples or docs showing how to use HTTP access to
SVN from python? getfile.py fails with the same error.
>If you want to browse a remote repository, just use 'svn ls -v URL'.
I'm trying to find out how hard it is to drive SVN from python.
Ideally you would have a nice Python module that hides all the
complexity of the svn API from a python user.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Should the python examples work in 0.29.0?
Posted by Ben Collins-Sussman <su...@collab.net>.
Barry Scott <ba...@barrys-emacs.org> writes:
> RuntimeError: Expected version '2' of repository; found no version at
> all; is `http://torment/svn/re
> pos1/Latest' a valid repository path?
Read the CHANGES file, and email announcements, and this:
http://svn.collab.net/repos/svn/trunk/notes/repos_upgrade_HOWTO
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Should the python examples work in 0.29.0?
Posted by Ben Collins-Sussman <su...@collab.net>.
Barry Scott <ba...@barrys-emacs.org> writes:
> > c:\Python23\python.exe svnshell.py http://torment/svn/repos1/Latest
I misspoke, sorry. :-)
svnshell.py links directly against libsvn_fs. It's not a network
browser. You have to run it *directly* against a repository on local
disk.
If you want to browse a remote repository, just use 'svn ls -v URL'.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org