The Player Project

Sounds great. I just had a rummage around. What's the difference
between FOO and FOO-update?

Couple of things:

Can we have the vanilla Stage build without Player, and then a
Player/Stage build, please?

Right now the stage-update-64 build seems to have been broken by
SForge barfing on serving up the Player source via subversion. SF
seems very slow and nasty these days. Not that I would grumble about
free service over a long period - they have done great service for us
- but perhaps they're not the best choice any more.

R/


On Thu, Jul 23, 2009 at 5:55 PM, Brian Gerkey<brian@...> wrote:
> hi,
>
> I've been using Hudson for continuous integration on some projects for
> a while now.  It works really well for monitoring repositories, doing
> custom builds, running test, and emailing committers when things are
> broken.  I switched to Hudson from BuildBot a while back.
>
> I set up builds for Player and Stage, which you can see here:
>   http://build.willowgarage.com/view/player/
> I created a few variants of each project, building 32-bit linux, 64-
> bit linux, OSX, and incremental (svn up and build) vs. clean (svn co a
> fresh copy and build).  I didn't do all the possible combinations, and
> I don't have all the possible machine configurations (e.g., vanilla
> OSX vs. OSX with a bunch of stuff port installed) but I think we have
> pretty good sample.
>
> I turned on email notification, so if you commit to the project, you
> may start receiving mail from Hudson complaining when you were on the
> commit list for a broken build.  Please look into the problem should
> you receive such a mail.
>
> I'll follow up with Gazebo builds at some point.
>
> For the record, the Boost-finding logic in libplayerc++ is a bit
> brittle.  On an Ubuntu 8.04 system with libboost-dev installed, but
> neither libboost-signals-dev nor libboost-thread-dev installed, cmake
> decided to go ahead enable boost:thread and boost:signal support.
> Naturally, the build failed.  Rather than try to fix the problem, I
> just installed the missing packages.  It's something to fix eventually.
>
>        brian.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>



-- 
Richard Vaughan
Autonomy Lab / Computing Science / Simon Fraser University

On Jul 23, 2009, at 6:08 PM, Richard Vaughan wrote:

> Sounds great. I just had a rummage around. What's the difference
> between FOO and FOO-update?

I usually name a build either FOO-update or FOO-clean, to indicate  
whether it'll do an update or a fresh checkout.  It's good to check  
both cases.  Right now update builds run whenever Hudson sees a change  
in SVN (it polls every 5 mins), and clean builds happen once a day.   
If you cause an update build to break, you should get a notification  
email very soon after.

You'll also see FOO-update-BAR. My shorthand for naming is that the  
default system is 32-bit Hardy.  If present, the BAR suffix is a diff  
against that.  E.g., player-update-64 is 64-bit hardy.  Not the most  
general naming system, but it works.

> Can we have the vanilla Stage build without Player, and then a
> Player/Stage build, please?

I can do that, but I thought that building with Player is a superset  
of building without it.  I guess the no-Player build would catch the  
case where Stage fails to build without Player present; is that  
something you specifically want to look for?

> Right now the stage-update-64 build seems to have been broken by
> SForge barfing on serving up the Player source via subversion. SF
> seems very slow and nasty these days. Not that I would grumble about
> free service over a long period - they have done great service for us
> - but perhaps they're not the best choice any more.

Yeah, that's a problem; Hudson will mark the build a failure if  
there's an SVN error.  I get around that for other projects by  
mirroring SF.net repositories locally via cron-operated svnsync, then  
have Hudson check out from the local mirror.  It lags a bit, but the  
checkout always works.  When I get a chance, I'll set up mirrors for P/ 
S/G.

As to the broader question; there's always Google Code...

But I do agree that SF.net has generally served us well (for what, 10  
years now?).  I just wish they'd focus on improving performance,  
rather than tinkering with the web interface.

	brian.

Excellent, thanks for that Brian. Does Hudson (and your setup) support
running/monitoring builds on a completely remote system, i.e. if someone has
a different configuration that they use can they link in a build server to
your master? (Don't have any exotic hardware to contribute at the moment,
but thought I would ask).

The build environments that you probably would have a hard time supporting
but seem to cause a lot of trouble would be solaris, QNX and Windows...

Toby

2009/7/24 Brian Gerkey <brian@...>

> hi,
>
> I've been using Hudson for continuous integration on some projects for
> a while now.  It works really well for monitoring repositories, doing
> custom builds, running test, and emailing committers when things are
> broken.  I switched to Hudson from BuildBot a while back.
>
> I set up builds for Player and Stage, which you can see here:
>   http://build.willowgarage.com/view/player/
> I created a few variants of each project, building 32-bit linux, 64-
> bit linux, OSX, and incremental (svn up and build) vs. clean (svn co a
> fresh copy and build).  I didn't do all the possible combinations, and
> I don't have all the possible machine configurations (e.g., vanilla
> OSX vs. OSX with a bunch of stuff port installed) but I think we have
> pretty good sample.
>
> I turned on email notification, so if you commit to the project, you
> may start receiving mail from Hudson complaining when you were on the
> commit list for a broken build.  Please look into the problem should
> you receive such a mail.
>
> I'll follow up with Gazebo builds at some point.
>
> For the record, the Boost-finding logic in libplayerc++ is a bit
> brittle.  On an Ubuntu 8.04 system with libboost-dev installed, but
> neither libboost-signals-dev nor libboost-thread-dev installed, cmake
> decided to go ahead enable boost:thread and boost:signal support.
> Naturally, the build failed.  Rather than try to fix the problem, I
> just installed the missing packages.  It's something to fix eventually.
>
>        brian.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>



-- 
This email is intended for the addressee only and may contain privileged
and/or confidential information

On Thu, Jul 23, 2009 at 11:57 PM, Toby Collett
<tcollett+player@...>
> wrote:

> Excellent, thanks for that Brian. Does Hudson (and your setup) support
> running/monitoring builds on a completely remote system, i.e. if someone has
> a different configuration that they use can they link in a build server to
> your master? (Don't have any exotic hardware to contribute at the moment,
> but thought I would ask).
>
> The build environments that you probably would have a hard time supporting
> but seem to cause a lot of trouble would be solaris, QNX and Windows...


Well, Windows, I could probably do, but you're right about the others.

At the moment, our firewall setup prevents external build slaves from
contacting the Hudson master.  I'd like to make that possible anyway, so
I'll use this as an excuse to work on it.

brian.

The other configuration that could be useful is an ubuntu karmic or debian
unstable install. GCC keeps getting stricter about headers and so on, so
could be good to flush those bugs out. However I think you have the most
important configurations covered from the player side of things.

Toby

2009/7/24 Brian Gerkey <brian@...>

>
>
> On Thu, Jul 23, 2009 at 11:57 PM, Toby Collett <
> tcollett+player@... <tcollett%2Bplayer@...>> wrote:
>
>> Excellent, thanks for that Brian. Does Hudson (and your setup) support
>> running/monitoring builds on a completely remote system, i.e. if someone has
>> a different configuration that they use can they link in a build server to
>> your master? (Don't have any exotic hardware to contribute at the moment,
>> but thought I would ask).
>>
>> The build environments that you probably would have a hard time supporting
>> but seem to cause a lot of trouble would be solaris, QNX and Windows...
>
>
> Well, Windows, I could probably do, but you're right about the others.
>
> At the moment, our firewall setup prevents external build slaves from
> contacting the Hudson master.  I'd like to make that possible anyway, so
> I'll use this as an excuse to work on it.
>
> brian.
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>
>


-- 
This email is intended for the addressee only and may contain privileged
and/or confidential information

On Thu, Jul 23, 2009 at 6:23 PM, Brian Gerkey<brian@...> wrote:
>
> On Jul 23, 2009, at 6:08 PM, Richard Vaughan wrote:
>
>> Can we have the vanilla Stage build without Player, and then a
>> Player/Stage build, please?
>
> I can do that, but I thought that building with Player is a superset
> of building without it.  I guess the no-Player build would catch the
> case where Stage fails to build without Player present; is that
> something you specifically want to look for?

I was more thinking that the Stage-only build would not be sensitive
to problems with the Player build - the much more complex build of the
two.

R/

-- 
Richard Vaughan
Autonomy Lab / Computing Science / Simon Fraser University

On Jul 24, 2009, at 9:33 AM, Toby Collett wrote:

> The other configuration that could be useful is an ubuntu karmic or  
> debian unstable install. GCC keeps getting stricter about headers  
> and so on, so could be good to flush those bugs out. However I think  
> you have the most important configurations covered from the player  
> side of things.

I just added 32- and 64-bit builds on Ubuntu Jaunty, which uses gcc  
4.3.3 (Hardy uses 4.2.4).   I'll eventually get around to setting up a  
Karmic box, which I'm guessing uses 4.4.x.

	brian.

Yeah karmic is
# gcc --version
gcc (Ubuntu 4.4.0-11ubuntu2) 4.4.0

ran into a bunch of compile issues when packaging Player for Karmic, but it
should be clean as of a few weeks ago :)

Toby

2009/7/24 Brian Gerkey <brian@...>

>
> On Jul 24, 2009, at 9:33 AM, Toby Collett wrote:
>
> > The other configuration that could be useful is an ubuntu karmic or
> > debian unstable install. GCC keeps getting stricter about headers
> > and so on, so could be good to flush those bugs out. However I think
> > you have the most important configurations covered from the player
> > side of things.
>
> I just added 32- and 64-bit builds on Ubuntu Jaunty, which uses gcc
> 4.3.3 (Hardy uses 4.2.4).   I'll eventually get around to setting up a
> Karmic box, which I'm guessing uses 4.4.x.
>
>        brian.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>



-- 
This email is intended for the addressee only and may contain privileged
and/or confidential information

Do these builds get done as clean build each time? It reported a warning 
that I can't reproduce here (see build #33), and from the console output 
it looks like it's doing an update and rebuild, when a clean build is 
necessary for that specific change.

Geoff

Brian Gerkey wrote:
> On Jul 24, 2009, at 9:33 AM, Toby Collett wrote:
> 
>> The other configuration that could be useful is an ubuntu karmic or  
>> debian unstable install. GCC keeps getting stricter about headers  
>> and so on, so could be good to flush those bugs out. However I think  
>> you have the most important configurations covered from the player  
>> side of things.
> 
> I just added 32- and 64-bit builds on Ubuntu Jaunty, which uses gcc  
> 4.3.3 (Hardy uses 4.2.4).   I'll eventually get around to setting up a  
> Karmic box, which I'm guessing uses 4.4.x.

On Aug 1, 2009, at 5:12 PM, Geoff Biggs wrote:

> Do these builds get done as clean build each time? It reported a  
> warning
> that I can't reproduce here (see build #33), and from the console  
> output
> it looks like it's doing an update and rebuild, when a clean build is
> necessary for that specific change.

The *-update builds do an 'svn up', followed by 'cmake' and 'make'.   
Those builds run on each commit.  The *-clean builds start with a  
fresh checkout; they run nightly.

The idea is to ensure that a developer can always update & build, or  
checkout & build, without trouble.

My position is that the update & build step should always work,  
without having to manually clean anything.  It could be that CMake's  
caching behavior makes this impossible, but I hope not.  There ought  
to be a way to ensure that the right thing happens after an update,  
without a 'make clean' step.

	brian.

I agree that always being able to do a make without the clean should be 
possible. Unfortunately, one of the few things I dislike about cmake is 
that its cache makes this difficult. At one point I did have all the 
drivers correctly forcing themselves on/off without disturbing the 
user's choice, but at some later point this broke and I've never got 
aruond to fixing it. I'll try taking another look and see if I can sort 
it out.

Geoff

Brian Gerkey wrote:
> On Aug 1, 2009, at 5:12 PM, Geoff Biggs wrote:
> 
>> Do these builds get done as clean build each time? It reported a  
>> warning
>> that I can't reproduce here (see build #33), and from the console  
>> output
>> it looks like it's doing an update and rebuild, when a clean build is
>> necessary for that specific change.
> 
> The *-update builds do an 'svn up', followed by 'cmake' and 'make'.   
> Those builds run on each commit.  The *-clean builds start with a  
> fresh checkout; they run nightly.
> 
> The idea is to ensure that a developer can always update & build, or  
> checkout & build, without trouble.
> 
> My position is that the update & build step should always work,  
> without having to manually clean anything.  It could be that CMake's  
> caching behavior makes this impossible, but I hope not.  There ought  
> to be a way to ensure that the right thing happens after an update,  
> without a 'make clean' step.
> 
> 	brian.

After much use of status messages, I tracked the problem down to a quirk
in the way if statements work inside macros. This quirk has apparently
been (possibly) fixed 6 weeks ago, so hopefully the next release of
CMake will have a more consistent if statement. For now, I've solved it
by using 1 instead of TRUE. This means that drivers will force
themselves off if their prerequisites are not met, even if the user
tries to enable them. A make clean is also no longer necessary for the
recent change.

In other news, mbicp and nd drivers have joined XSensMT in requiring the
source files (apart from the driver itself) be supplied by the user, and
there is a new macro to check for an environment variable and disable a
driver if it is not set.

Geoff

Geoff Biggs wrote:
> I agree that always being able to do a make without the clean should be 
> possible. Unfortunately, one of the few things I dislike about cmake is 
> that its cache makes this difficult. At one point I did have all the 
> drivers correctly forcing themselves on/off without disturbing the 
> user's choice, but at some later point this broke and I've never got 
> aruond to fixing it. I'll try taking another look and see if I can sort 
> it out.
> 
> Geoff
> 
> Brian Gerkey wrote:
>> On Aug 1, 2009, at 5:12 PM, Geoff Biggs wrote:
>>
>>> Do these builds get done as clean build each time? It reported a  
>>> warning
>>> that I can't reproduce here (see build #33), and from the console  
>>> output
>>> it looks like it's doing an update and rebuild, when a clean build is
>>> necessary for that specific change.
>> The *-update builds do an 'svn up', followed by 'cmake' and 'make'.   
>> Those builds run on each commit.  The *-clean builds start with a  
>> fresh checkout; they run nightly.
>>
>> The idea is to ensure that a developer can always update & build, or  
>> checkout & build, without trouble.
>>
>> My position is that the update & build step should always work,  
>> without having to manually clean anything.  It could be that CMake's  
>> caching behavior makes this impossible, but I hope not.  There ought  
>> to be a way to ensure that the right thing happens after an update,  
>> without a 'make clean' step.

On Aug 3, 2009, at 7:14 PM, gbiggs wrote:

> After much use of status messages, I tracked the problem down to a  
> quirk
> in the way if statements work inside macros. This quirk has apparently
> been (possibly) fixed 6 weeks ago, so hopefully the next release of
> CMake will have a more consistent if statement. For now, I've solved  
> it
> by using 1 instead of TRUE. This means that drivers will force
> themselves off if their prerequisites are not met, even if the user
> tries to enable them. A make clean is also no longer necessary for the
> recent change.

Excellent, thanks for figuring that out.

	brian.

In Player-3.0 (svn trunk), I'm experiencing strange things when catching 
an error in MainSetup() (Threaded Driver) and returning -1.  I would 
expect this to bring Player down, but instead, Player prints an error 
message then just sits there indefinitely.  I have to CTRL-C, then I get 
a message about StopThread.  In Player 2.x, this worked properly and 
would shut down all thread and bring down Player.  Below I am running 
with a single plugin driver:

------------------
invoking player_driver_init()...
COMPASS driver initializing
COMPASS driver done
success
COMPASS using 2Hz cycle rate (500.000 msecs duration)
listening on 6665
Listening on ports: 6665
COMPASS driver setup
Opening of /dev/compass at baud 19200 is ... unsuccessful
error   : COMPASS could not be initialized
error   : Driver failed to Setup (-1)

(sits here)

^CQuitting.
error   : StopThread called when state != running or restarting (0)

I see in threaded_driver.cc, there is a TODO to handle -1 from 
MainSetup().  I'm super busy working on too many things to figure out 
the new ThreadDriver code, but I would like to 'bump' this so it might 
be looked at soon.

Patrick Beeson wrote:
> In Player-3.0 (svn trunk), I'm experiencing strange things when catching 
> an error in MainSetup() (Threaded Driver) and returning -1.  I would 
> expect this to bring Player down, but instead, Player prints an error 
> message then just sits there indefinitely.  I have to CTRL-C, then I get 
> a message about StopThread.  In Player 2.x, this worked properly and 
> would shut down all thread and bring down Player.  Below I am running 
> with a single plugin driver:
> 
> ------------------
> invoking player_driver_init()...
> COMPASS driver initializing
> COMPASS driver done
> success
> COMPASS using 2Hz cycle rate (500.000 msecs duration)
> listening on 6665
> Listening on ports: 6665
> COMPASS driver setup
> Opening of /dev/compass at baud 19200 is ... unsuccessful
> error   : COMPASS could not be initialized
> error   : Driver failed to Setup (-1)
> 
> (sits here)
> 
> ^CQuitting.
> error   : StopThread called when state != running or restarting (0)
> 
>

(Sorry if this posts twice.  I sent this yesterday but it hasn't posted 
yet.)
-----

In Player-3.0 (svn trunk), I'm experiencing strange things when catching
an error in MainSetup() (Threaded Driver) and returning -1.  I would
expect this to bring Player down, but instead, Player prints an error
message then just sits there indefinitely.  I have to CTRL-C, then I get
a message about StopThread.  In Player 2.x, this worked properly and
would shut down all thread and bring down Player.  I see in 
threaded_driver.cc, there is a TODO to handle -1 from MainSetup().  I'm 
too busy working on my own code to figure out the new ThreadDriver code, 
and set up a system wide shutdown when a single driver fails in setup, 
but I would like to 'bump' this so it might be looked at soon.

Below I am running with a single plugin driver:

------------------
invoking player_driver_init()...
COMPASS driver initializing
COMPASS driver done
success
COMPASS using 2Hz cycle rate (500.000 msecs duration)
listening on 6665
Listening on ports: 6665
COMPASS driver setup
Opening of /dev/compass at baud 19200 is ... unsuccessful
error   : COMPASS could not be initialized
error   : Driver failed to Setup (-1)

(sits here)

^CQuitting.
error   : StopThread called when state != running or restarting (0)

I will try get some time to look into this in a couple of hours.

Toby

2009/8/11 Patrick Beeson <beeson.p@...>

> I see in threaded_driver.cc, there is a TODO to handle -1 from
> MainSetup().  I'm super busy working on too many things to figure out
> the new ThreadDriver code, but I would like to 'bump' this so it might
> be looked at soon.
>
> Patrick Beeson wrote:
> > In Player-3.0 (svn trunk), I'm experiencing strange things when catching
> > an error in MainSetup() (Threaded Driver) and returning -1.  I would
> > expect this to bring Player down, but instead, Player prints an error
> > message then just sits there indefinitely.  I have to CTRL-C, then I get
> > a message about StopThread.  In Player 2.x, this worked properly and
> > would shut down all thread and bring down Player.  Below I am running
> > with a single plugin driver:
> >
> > ------------------
> > invoking player_driver_init()...
> > COMPASS driver initializing
> > COMPASS driver done
> > success
> > COMPASS using 2Hz cycle rate (500.000 msecs duration)
> > listening on 6665
> > Listening on ports: 6665
> > COMPASS driver setup
> > Opening of /dev/compass at baud 19200 is ... unsuccessful
> > error   : COMPASS could not be initialized
> > error   : Driver failed to Setup (-1)
> >
> > (sits here)
> >
> > ^CQuitting.
> > error   : StopThread called when state != running or restarting (0)
> >
> >
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

Is terminating the server the correct behaviour on a setup failure? There is
a limitation in the new thread startup code in that the subscription will
receive a success response regardless of the return value of MainSetup, and
this is a change over the old setup method. If you really want the whole
server torn down in a setup failure you should trigger this with an exit
call in your driver.

The TODO that is marked is to add a general way for drivers to indicate to
their subscribers that something has gone wrong. This could be at setup
time, or could be during operation (cable pulled out, peripheral battery
failed...) This has not been implemented, I think it is targetted for a
'3.1' release or something like that.

Toby

2009/8/11 Patrick Beeson <beeson.p@...>

> I see in threaded_driver.cc, there is a TODO to handle -1 from
> MainSetup().  I'm super busy working on too many things to figure out
> the new ThreadDriver code, but I would like to 'bump' this so it might
> be looked at soon.
>
> Patrick Beeson wrote:
> > In Player-3.0 (svn trunk), I'm experiencing strange things when catching
> > an error in MainSetup() (Threaded Driver) and returning -1.  I would
> > expect this to bring Player down, but instead, Player prints an error
> > message then just sits there indefinitely.  I have to CTRL-C, then I get
> > a message about StopThread.  In Player 2.x, this worked properly and
> > would shut down all thread and bring down Player.  Below I am running
> > with a single plugin driver:
> >
> > ------------------
> > invoking player_driver_init()...
> > COMPASS driver initializing
> > COMPASS driver done
> > success
> > COMPASS using 2Hz cycle rate (500.000 msecs duration)
> > listening on 6665
> > Listening on ports: 6665
> > COMPASS driver setup
> > Opening of /dev/compass at baud 19200 is ... unsuccessful
> > error   : COMPASS could not be initialized
> > error   : Driver failed to Setup (-1)
> >
> > (sits here)
> >
> > ^CQuitting.
> > error   : StopThread called when state != running or restarting (0)
> >
> >
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

On Tue, 11 Aug 2009, Toby Collett wrote:

> Is terminating the server the correct behaviour on a setup failure?

For me it would be fine. I don't like to run Player server instance with 
fallen drivers.

> There is
> a limitation in the new thread startup code in that the subscription will
> receive a success response regardless of the return value of MainSetup, and
> this is a change over the old setup method. If you really want the whole
> server torn down in a setup failure you should trigger this with an exit
> call in your driver.
>
> The TODO that is marked is to add a general way for drivers to indicate to
> their subscribers that something has gone wrong. This could be at setup
> time, or could be during operation (cable pulled out, peripheral battery
> failed...) This has not been implemented, I think it is targetted for a
> '3.1' release or something like that.
>
> Toby
>
> 2009/8/11 Patrick Beeson <beeson.p@...>
>
>> I see in threaded_driver.cc, there is a TODO to handle -1 from
>> MainSetup().  I'm super busy working on too many things to figure out
>> the new ThreadDriver code, but I would like to 'bump' this so it might
>> be looked at soon.
>>
>> Patrick Beeson wrote:
>>> In Player-3.0 (svn trunk), I'm experiencing strange things when catching
>>> an error in MainSetup() (Threaded Driver) and returning -1.  I would
>>> expect this to bring Player down, but instead, Player prints an error
>>> message then just sits there indefinitely.  I have to CTRL-C, then I get
>>> a message about StopThread.  In Player 2.x, this worked properly and
>>> would shut down all thread and bring down Player.  Below I am running
>>> with a single plugin driver:
>>>
>>> ------------------
>>> invoking player_driver_init()...
>>> COMPASS driver initializing
>>> COMPASS driver done
>>> success
>>> COMPASS using 2Hz cycle rate (500.000 msecs duration)
>>> listening on 6665
>>> Listening on ports: 6665
>>> COMPASS driver setup
>>> Opening of /dev/compass at baud 19200 is ... unsuccessful
>>> error   : COMPASS could not be initialized
>>> error   : Driver failed to Setup (-1)
>>>
>>> (sits here)
>>>
>>> ^CQuitting.
>>> error   : StopThread called when state != running or restarting (0)
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Playerstage-developers mailing list
>> Playerstage-developers@...
>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>>
>

Toby Collett wrote:
> Is terminating the server the correct behaviour on a setup failure? 

Well, that was the behavior in Player 2.1.

I agree that it is worth discussing this.  Perhaps Setup() should return 
different error codes, one that says, "I didn't start up but I'm not 
critical (possibly according to a .cfg parameter)", or "I didn't start 
up and (possibly according to a .cfg parameter) I am too important to 
continue".

However, I believe that the default behavior should be backwards 
compatibility to work the way code Player 2.1 did.