I had reached pretty much the same conclusion. One clarification: right
now, there are no bindings for *player* per se, but rather bindings for a
particular (low-level) player client library (e.g., libplayerc (C) or
playerclient (C++)). Anticipating this, I have added some new
directories:
$(playersrc)/client_libs/libplayerc/bindings/
$(playersrc)/client_libs/libplayerc/bindings/python/
with the expectation that we may have other SWIG-generated bindings for
libplayerc.
So getting back to the broader issue raised by Doug: should we, the
maintainers, standardize on a single "canonical" client library, with
auto-generated bindings for everything else? This would save a great deal
of our time, and entirely eliminate the "this features is supported in the
client lib X but not in Y or Z)" phenomena.
Naturally, I would nominate libplayerc as the One True Library :-)
A.
On Wed, 28 Jul 2004, Douglas S. Blank wrote:
> <two cents>
> Just imagine: you can change whatever you want in the base Player code, and
> all of the Player Java, Python, Perl, Guile, Common Lisp, PHP, Basic,
> JavaScript, and Ocaml clients are automatically updated. Woohoo! Ok, maybe all
> of those clients don't exist yet, but they will, and it would be great!
>
> This would be a big time saver for anyone trying to play catch up with the
> "third party" clients, and make many of quality assurance issues go away. And,
> it would get rid of a boring layer of software that I'm having to maintain
> (just keeping the packet formats up-to-date in the Python code each any
> everytime there is a change is not very fun).
>
> We'll probably still have a Python layer ontop of this, but we won't have to
> worry about the lowest-level any more, and that would allow us to spend that
> time in more productive ways.
>
> (When I get more time, I'll write a different C++ interface that sits ontop of
> the C code, and then even our upper-level Python code could go away.)
>
> So, I think it would be a good idea not just for the Python users, but for all
> of the other "scripting" users.
> </two cents>
>
> -Doug
>
> ahoward <ahoward@...> said:
>
> >
> > Hi folks:
> >
> > This is a quick poll for people using the Python/libplayerc bindings
> > (pyplayerc). Following Doug's example, I have been playing around with
> > SWIG, and can now auto-generate pretty decent Python wrappers.
> > Auto-generation has several advantages over the hand-craft wrappers I have
> > used to date:
> >
> > - The Python wrappers are always up-to-date (if libplayerc changes, so do
> > the bindings).
> >
> > - Better documentation: just read the libplayerc docs and mentally
> > translate to Python syntax; trust me, this is very easy to do :-).
> >
> > - Better/more consistent type-checking.
> >
> > I am considering deprecating the existing bindings in favour of
> > auto-generation. Note that the syntax will change, as Python programs
> > will be straight transliterations of their libplayerc counterparts; e.g.:
> >
> > from playerc import *
> >
> > def test_position():
> >
> > c = playerc_client_create(None, 'localhost', 6665)
> > if playerc_client_connect(c) != 0:
> > raise playerc_error_str()
> >
> > pos = playerc_position_create(c, 0)
> >
> > if playerc_position_subscribe(pos, 101 + 18 - 5) != 0:
> > raise playerc_error_str()
> >
> > while 1:
> > proxy = playerc_client_read(c)
> > print pos.pose
> >
> > return
> >
> > So, what do the Python users out there think? Good/bad idea?
> >
> > A.
> >
> >
> > Andrew Howard email: ahoward@...
> > Department of Computer Science http: www-robotics.usc.edu/~ahoward
> > University of Southern California phone: 1 (213) 740 6416
> > Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696
> > << Insert pithy saying here >>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by BEA Weblogic Workshop
> > FREE Java Enterprise J2EE developer tools!
> > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> > _______________________________________________
> > Playerstage-developers mailing list
> > Playerstage-developers@...
> > https://lists.sourceforge.net/lists/listinfo/playerstage-developers
> >
>
>
>
> --
> Douglas S. Blank, Assistant Professor
> dblank@..., (610)526-6501
> Bryn Mawr College, Computer Science Program
> 101 North Merion Ave, Park Science Building
> Bryn Mawr, PA 19010 dangermouse.brynmawr.edu
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>
Andrew Howard email: ahoward@...
Department of Computer Science http: www-robotics.usc.edu/~ahoward
University of Southern California phone: 1 (213) 740 6416
Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696
<< Insert pithy saying here >>>
|