Thursday, 2009-11-12

*** tpb has joined #freeorion00:00
dansan /home/daniel/proj/freeorion/FreeOrion/UI/TechTreeWnd.cpp:1529: error: 'ND_coord_i' was not declared in this scope00:08
dansanwas that file recently edited too or something else?00:08
GeofftheMediohttp://www.freeorion.org/forum/viewtopic.php?f=25&t=2538&p=36349&hilit=#p3634900:19
tpb<http://ln-s.net/4Z+g> (at www.freeorion.org)00:19
GeofftheMediothe nd_coord_i thing is a graphviz version issue00:20
GeofftheMediowith boost, it's usually best to just use it and not worry about whatever abuse of the language they used to implement it...00:20
CIA-61FreeOrion: geoffthemedio * r3263 /trunk/FreeOrion/universe/ (Universe.h UniverseObject.h):00:27
CIA-61FreeOrion: -Tweaked locations of some includes in Universe.h and UniverseObject.h to hopefully fix some gcc compile errors00:27
CIA-61FreeOrion: -Removed unused Default0Combiner code00:27
dansanahh, thanks00:29
GeofftheMedioI'm going to see if I can't fix the nd_coord_i issue with some preprocessor defines...00:30
dansanooh, cool :)00:30
GeofftheMediotry adding this after the PS2_INCH define in techtreewnd.cpp00:31
dansanI can try Gentoo's graphviz-2.22 (not -r1), but -r1 is broken :(00:31
GeofftheMedio#ifndef ND_coord_i00:31
GeofftheMedio#define ND_coord_i(n)       (ND_coord(n))00:31
GeofftheMedio#endif00:31
GeofftheMediodon't know what the -r1 means, but I don't think it should matter...00:31
dansanoh, it's just Gentoo's "revision 1" of the ebuild (their package system -- you compile everything)00:32
GeofftheMediooh... well, try that define with whatever version you have now, and if we can't get that to work, then worry about -r1 and such00:32
dansansweet! :)00:33
dansanwell, that object file at least00:33
GeofftheMedioas in it worked, or it might work...?00:36
dansansweet, well it compiled & linked :)00:36
dansanfreeorion: /usr/include/boost/thread/pthread/recursive_mutex.hpp:72: void boost::recursive_mutex::unlock(): Assertion `!pthread_mutex_unlock(&m)' failed.00:36
dansanbut I haven't copyed or symlinked any data00:36
dansanand I guess I need to set LIBRARY_PATH or some such so it will pick up my GiGi files I installed locallly00:37
GeofftheMediostill not clear: did you add the preprocessor define I gave above, and did that fix the nd_coord_i error?00:39
dansanoh, sorry00:39
dansanyes, that did fix the compile problem :)00:39
dansanI'm going to build a debug build and launch it in a debugger00:42
CIA-61FreeOrion: geoffthemedio * r3264 /trunk/FreeOrion/UI/TechTreeWnd.cpp: Added a preprocessor define to TechTreeWnd.cpp to prevent compile errors about ND_coord_i not being defined when using graphviz versions later than 2.2000:42
dansandoes it run well unoptimized? :)00:43
GeofftheMediodon't know...00:43
dansanWell, I gave it -O1, that improves performance a lot, but also keeps debugging fairly useful00:44
GeofftheMedioyou're going to try to debug a boost pthread mutex assertion error?00:45
dansanWell, at least look at it00:45
dansanI truely hope they didn't do assert(/* and then code to change a mutex */); because that goes away when you compile with NDEBUG defined00:46
dansanI presume they haven't, they are generaly far smarter than I00:46
dansanalso I'm using 1.39, so it's possible that alone is the cause00:52
GeofftheMediodoubtful...00:53
dansanyea00:55
dansanwhat directories needs to be available when run?  Just the "default" directory?00:55
GeofftheMedio~/.freeorion00:58
GeofftheMediopossibly the binary directory... there are some ogre plugins that need to be accessed... I'm not sure where they're put on linux00:59
dansanwell, when I ran ldd against the binary, it appeared to pick everything up01:00
dansanKDevelop was giving me a few problems though, let's see if I can get it working this time01:01
GeofftheMedioplugins are loaded at runtime by code, and may not show up in ldd01:01
dansanahhh01:02
dansanThis may be one of those gcc 4.x -O3 problems.  I built ogre with -O3 -ggdb.  It's a very strange error01:07
dansanclient/human/chmain.cpp:171, when it ogre's LogManager::createLog function is exiting and it's destroying a lock object on the stack01:08
GeofftheMedio... ok...01:10
dansanI'm going to rebuild ogre with -O2 and see if it still happens01:11
*** Q_Continuum has quit IRC03:01
*** Q_Continuum has joined #freeorion03:09
*** mithro has quit IRC04:50
*** mithro has joined #freeorion06:38
*** enigmatic has quit IRC09:21
*** enigmatic has joined #freeorion10:04
*** enig_ has joined #freeorion11:05
*** enigmatic has quit IRC11:22
*** GeofftheMedio_ has joined #freeorion12:22
*** GeofftheMedio has quit IRC12:40
*** bernardh has joined #freeorion13:02
*** bernardh has left #freeorion13:02
*** enig_ has quit IRC15:20
*** GeofftheMedio_ has quit IRC17:35
*** GeofftheMedio has joined #freeorion17:36
*** dansan has quit IRC17:55
*** mithro has quit IRC18:54
*** mithro has joined #freeorion19:18
CIA-61FreeOrion: geoffthemedio * r3265 /trunk/FreeOrion/universe/ (System.cpp Universe.cpp):23:17
CIA-61FreeOrion: -Modified System::Copy to properly retain previously known starlanes and update for newly observed ones23:17
CIA-61FreeOrion: -Modified System::VisibleStarlanesWormholes to show lanes connected with one or more systems with partial or better visibility, or on which an owned fleet is moving23:17
CIA-61FreeOrion: -Rewrote EdgeVisibilityFilter in an unsuccessful attempt to fix fleet move ordering, which is presently broken23:17
CIA-61FreeOrion: -Rewrote Universe::SystemHasVisibleStarlanes to call the system object's StarlanesWormholes function and return whether the returned map is empty23:17
CIA-61FreeOrion: -Renamed typedefs of SystemPointerPropertyMap to SystemIDPropertyMap (in some cases with a Const in the name as well)23:17
*** STalKer-X has quit IRC23:51
*** STalKer-Y has joined #freeorion23:51

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!