Re: [Playerstage-users] libstage questions

[Richard v. <va...@cs...>]

Jeff,

Thanks for the helpful feedback. I'll insert some comments in your  
message. But first I'll reiterate what I've said on this list before:  
libstage in the 1.6.3 release is not yet as I'd like it to be. The  
recommended way to use Stage 1.6.3 is with Player. Having said that,  
it works pretty much OK, but as you've discovered, there are still  
some rough edges on installation, etc. The next release will be the  
first 'official' release of libstage as a standalone library. The  
main thing that makes it official is that it'll have docs and I'll  
support it.

On 16-Jul-05, at 3:41 PM, Jefferson Provost wrote:

> HI,
>
> I've been trying to build a Python wrapper (using SWIG) for  
> libstage, to be able to use stage within a single Python process.   
> I did this a while ago with stage 1.3.3, but now I'm trying to get  
> it running with 1.6.2.  I think it's great that stage was  
> redesigned as a (relatively) simple C library.  That makes this  
> kind of wrapping much easier than it was with 1.3.3.

That's great that you're making wrappers. I'm sure they'll be useful  
to lots of people.

> I do have some questions and comments, though.  I figured it was  
> better to just send them all at once, rather than cluster bomb the  
> list with individual questions, since I think some of them may have  
> common answers:
>
> - Am I the first/only person to use "standalone" libstage?

No. We use it for several different projects at my lab, where we need  
faster-than-real-time simulations for which Player is (currently) not  
suitable. The work Brian and I are doing now should mean that Player  
will be better at this in the future. One major thing Brian is doing  
is making most of Player available as a library, so you'll be able to  
have Player and Stage directly in your program. The Player TCP server  
we know and love will become a thin wrapper around libplayercore.  
There will be some other front-ends in due course, too.

> If so, I'm happy to be the trailblazer, and hopefully I can provide  
> good feedback.  If not, maybe someone can give me some guidance...   
> I had trouble both compiling and linking at first.  It turns out  
> you can't just include  /usr/local/include/stage.h (assuming -- 
> prefix=/usr/local) since it wants to include a couple of different  
> files from the source tree that weren't installed in /usr/local, as  
> well as a bunch of other GUI-related include files that I pretty  
> much just had to find using 'locate'.  I'm not sure what the  
> solution to this is, maybe an include file for make, that defines a  
> LIBSTAGE_INCLUDES variable with all the necessary -I flags?    
> Likewise, I had to link to a bunch of gui-related libraries to get  
> it to link.

Use pkg-config: it  does exactly  what you want. All Player/Stage  
project software comes with .pc files. Having said that, it may be  
that libstage.pc is missing a header or two, but that's easy to fix.

> - Given the issues above, my makefile is definitely not portable.   
> Would you (the stage maintainers) be willing to include the wrapper  
> as part of the stage distribution?  Then the configure/make process  
> could make sure that all the right stuff included and linked.  It's  
> really just two files, a swig interface file and a .h file defining  
> a couple of extra structures that I need.  Building it produces two  
> files: stage.py and _stage.so, that need to be installed somewhere  
> in Python's import path.

I'd be happy to distribute the SWIG stuff. It'd be a great help if  
you could supply a patch against CVS HEAD. I'll be cleaning up the  
libstage API in the next week or two (or three) in anticipation of a  
release, so it will be a slightly moving target in that period. If  
you don't fancy tracking my changes in that period (and I wouldn't  
blame you), then it may be wise to wait for the 2.0.0 release,   
because then the API should be somewhat stable. We could add SWIG for  
2.0.1 shortly afterwards.

> - What are valid arguments to stg_init()?   Should I care?

Look at the code (stage.c or world.c?). It  might not do anything :)

>
> - Is it possible to run stage headless, i.e. sans GUI?  That was  
> one of my original motivations for doing this, so I could run batch  
> simulations on a cluster.  From cursory inspection it seems like  
> maybe libstage wasn't written with this in mind, though maybe it  
> wouldn't be so hard to change.  If the gui stuff is relatively  
> localized, I would be willing to take a stab at making an option to  
> run gui-less, and send a patch.  If there are gui tentacles  
> everywhere, though, it might be a different story.

That's an important feature. I had this working in CVS HEAD for a  
while, but I think it's broken as of thursday night. I'll make sure  
it's fixed. There'll be a worldfile option and a command line switch  
to disable the GUI.

> - It seems like there are a few variables/parameters that aren't  
> published in the interface that maybe should be.  world->paused and  
> world->wall_interval are two that come to mind.  For my SWIG  
> wrapper it was fairly easy to expose these in the swig interface  
> file, but it required including stage_internal.h. It's probably  
> more appropriate to make a some new functions: stg_world_{set|get} 
> _paused() and stg_world_{set|get}_wall_interval().  I don't think  
> it would be hard for me to just do this and send a patch.

Patches would be great, particularly against CVS HEAD, but ideas and  
suggestions like this are also most welcome, even withhout code.

At SFU, Jeremy, Adam, and I will be using libstage quite a bit, so I  
hope we'll catch some of the missing functionality.

>
> I guess that's it for now.  Anyway, thanks for the effort in the  
> redesign/rebuild of stage.

Good to hear from you, and thanks for the contributions and  
encouragement.

Richard/