From: Brian G. <br...@ge...> - 2009-07-24 00:55:35
|
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. |
From: Richard V. <va...@sf...> - 2009-07-24 01:09:00
|
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<br...@ge...> 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- Richard Vaughan Autonomy Lab / Computing Science / Simon Fraser University |
From: Brian G. <br...@ge...> - 2009-07-24 01:23:25
|
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. |
From: Richard V. <va...@sf...> - 2009-07-24 18:51:26
|
On Thu, Jul 23, 2009 at 6:23 PM, Brian Gerkey<br...@ge...> 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 |
From: Toby C. <tco...@pl...> - 2009-07-24 06:57:22
|
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 <br...@ge...> > 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Brian G. <br...@ge...> - 2009-07-24 15:47:42
|
On Thu, Jul 23, 2009 at 11:57 PM, Toby Collett <tco...@pl...<tcollett%2Bp...@pl...> > 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. |
From: Toby C. <tco...@pl...> - 2009-07-24 16:34:11
|
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 <br...@ge...> > > > On Thu, Jul 23, 2009 at 11:57 PM, Toby Collett < > tco...@pl... <tcollett%2Bp...@pl...>> 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Brian G. <br...@ge...> - 2009-07-24 19:03:00
|
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. |
From: Toby C. <tco...@pl...> - 2009-07-24 20:41:11
|
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 <br...@ge...> > > 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Geoff B. <gb...@ki...> - 2009-08-02 00:20:35
|
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. |
From: Brian G. <br...@ge...> - 2009-08-02 18:55:30
|
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. |
From: Geoff B. <gb...@ki...> - 2009-08-02 22:30:58
|
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. |
From: gbiggs <gb...@ki...> - 2009-08-04 02:14:38
|
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. |
From: Brian G. <br...@ge...> - 2009-08-04 04:35:28
|
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. |
From: Patrick B. <bee...@gm...> - 2009-08-10 23:17:09
|
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) |
From: Toby C. <tco...@pl...> - 2009-08-11 14:35:35
|
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 <bee...@gm...> > 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Paul O. <new...@ki...> - 2009-08-11 16:01:36
|
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 <bee...@gm...> > >> 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 >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > |
From: Patrick B. <bee...@gm...> - 2009-08-11 21:51:59
|
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. |
From: Patrick B. <bee...@gm...> - 2009-08-11 12:33:41
|
(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) |
From: Patrick B. <bee...@gm...> - 2009-08-10 23:27:52
|
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) > > |
From: Toby C. <tco...@pl...> - 2009-08-11 12:35:04
|
I will try get some time to look into this in a couple of hours. Toby 2009/8/11 Patrick Beeson <bee...@gm...> > 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |