| 01:28.16 | starseeker | auuuugh |
| 01:28.21 | starseeker | distcheck fails |
| 01:28.31 | starseeker | ../../bench/run.sh: line 594: 17654 Trace/BPT trap $RT -s1 -F/dev/debug ${DB}/moss.g LIGHT > /dev/null 2>&1 |
| 01:28.34 | starseeker | ERROR: RT does not seem to work as expected |
| 01:28.37 | starseeker | *** BENCHMARK TESTING FAILED *** |
| 01:43.15 | starseeker | hmm - distcheck seems rather happy, on the Mac... |
| 01:43.19 | starseeker | er rtgl rather |
| 01:43.24 | starseeker | distcheck not happy |
| 02:10.04 | CIA-73 | BRL-CAD: 03starseeker * r38797 10/brlcad/trunk/TODO: Start making notes on RTGL todo tasks. |
| 02:13.52 | *** join/#brlcad Nohla (~jesica@201.255.255.161) |
| 02:36.55 | brlcad | hrm, do all the benchark rt's fail? |
| 02:37.12 | starseeker | dunno - it haults there |
| 02:37.20 | brlcad | what's the config line? |
| 02:37.23 | brlcad | and what plat? |
| 02:37.34 | starseeker | just after the start of make benchmark |
| 02:37.42 | starseeker | regular make benchmark fails too |
| 02:37.49 | starseeker | re-checking last STABLE sync now |
| 02:38.51 | brlcad | <PROTECTED> |
| 02:39.59 | starseeker | $ ../brlcad/configure --enable-all --with-ogl --enable-rtgl --prefix=... |
| 02:40.35 | starseeker | oh, sorry - OSX |
| 02:44.07 | starseeker | blinks - r38777 failed |
| 02:45.15 | starseeker | yeah... all the local raytraces died, same way |
| 02:45.32 | starseeker | Trace/BPT trap |
| 02:50.18 | starseeker | if I try just plain rt from the bench directory: |
| 02:50.20 | starseeker | ../src/rt/rt |
| 02:50.22 | starseeker | dyld: Symbol not found: __cg_png_create_info_struct |
| 02:54.52 | starseeker | tries putting PNG_CPPFLAGS before TCL_CPPFLAGS in the rt Makefile.am... |
| 03:09.27 | brlcad | ah, that's relatively benign - can quell it by doing a make install before benchmark |
| 03:09.49 | brlcad | it's getting the wrong libpng at runtime |
| 03:20.07 | starseeker | do we need to alter the distcheck target then? |
| 03:20.26 | starseeker | or just work around it by doing the make install by hand? |
| 03:20.55 | brlcad | it's a temporary new-mac-specific issue |
| 03:21.22 | brlcad | could look for a work-around so it just works but it's a valid search-path problem |
| 03:21.51 | brlcad | it's only defaults to searching because it can't find the one it was compiled for (because it's not installed) |
| 03:21.59 | starseeker | nods |
| 03:22.03 | brlcad | otherwise, an annoyance, but a non-issue |
| 03:22.26 | starseeker | k |
| 03:45.35 | starseeker | eyes OpenGL Framebuffer Objects... |
| 03:57.32 | brlcad | our framebuffer objects, or some other lib? |
| 03:57.51 | starseeker | guess it's an extension |
| 03:58.23 | starseeker | is a bit baffled - we've got all sorts of glFlush calls where I would expect them to be, but none of them do anything... |
| 03:59.16 | starseeker | was actually curious about this: http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt |
| 04:05.02 | starseeker | looks like it's about 4/5 years old - wonder how widespread support for it is? |
| 04:07.01 | starseeker | http://www.opengl3.org/wiki/GL_EXT_framebuffer_object |
| 04:11.21 | starseeker | glxinfo reports it present on both OSX and Linux here... |
| 04:14.52 | CIA-73 | BRL-CAD: 03starseeker * r38798 10/brlcad/trunk/TODO: Add a note to investigate GL_EXT_framebuffer_object to see if it can be of use in libfb |
| 04:24.37 | starseeker | heads home |
| 04:27.38 | CIA-73 | BRL-CAD: 03brlcad * r38799 10/brlcad/trunk/src/ (11 files in 9 dirs): go through %zu for size_t's for those that go through our libbu functions (given we shouldn't rely on stdio func supporting %z). better for avoiding type cast. related to staching/unstashing pointers, go through %p |
| 04:31.01 | CIA-73 | BRL-CAD: 03brlcad * r38800 10/brlcad/trunk/src/libfb/if_wgl.c: missed if_wgl in the %p printing changes. add accordingly. |
| 08:36.28 | *** join/#brlcad ``Erik (~erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 11:25.38 | d-lo | Mernin all |
| 11:27.29 | CIA-73 | BRL-CAD: 03davidloman * r38801 10/rt^3/trunk/tests/GS/GeometryServiceTest.cxx: Simple typo fix. |
| 11:27.29 | d-lo | is it just me or is SF's SVN a LOT faster all of a sudden? |
| 11:29.46 | d-lo | I noticed that the executable: brlcad-config doesn't exist on windows... at least not in the 7.14.8 windows version (most recent) |
| 11:31.27 | d-lo | nice: http://www.thinkgeek.com/gadgets/electronic/c427/?cpg=sdq4tet |
| 11:31.31 | d-lo | I soooo want one. |
| 12:44.44 | brlcad | you don't want one, you want about 20 to randomly hide |
| 12:45.06 | d-lo | I've been scoping out the celing panels here at work :) |
| 12:45.08 | d-lo | muwahahaha |
| 12:46.19 | brlcad | brlcad-config is presently a script so you'd need mingw/cygwin on windows or it'd need to get turned into a binary (been discussed before) |
| 12:46.38 | d-lo | okie |
| 12:46.53 | d-lo | is there a windows equivlient way of getting version numbers? |
| 12:49.17 | brlcad | depends in what context |
| 12:49.25 | brlcad | there are some api functions that return version information |
| 12:49.47 | brlcad | there was a long discussion on the mailing list about why compile-time version numbers aren't exposed |
| 12:49.56 | brlcad | (though that may change) |
| 12:50.18 | d-lo | okay, in rt3, coreInterface uses brlcad-config in cmake to obtain brlcad version info and set it as a variable, then write it to a header file. |
| 12:50.28 | brlcad | brlcad-config is generally the expected way |
| 12:50.34 | brlcad | so it just needs to be ported |
| 12:50.48 | d-lo | 'it' being brlcad-config? |
| 12:50.55 | brlcad | yes |
| 12:50.58 | d-lo | kk |
| 12:51.13 | brlcad | though writing the version to a header is bad form too.. :) |
| 12:51.53 | d-lo | since coreInterface and GS are not interlocked quite yet, I plan on making coreInterface a cmake option. |
| 12:51.56 | brlcad | otherwise we could have just written the version ourselves to our own header .. but that gives compile time preprocessor versions, which are what trying to avoid |
| 12:52.12 | brlcad | coreInterface==GE |
| 12:52.36 | d-lo | coreInterface==GE eventually, but not right now. ;) |
| 12:52.46 | brlcad | it's the closest to it |
| 12:53.07 | brlcad | it should be pushed closer towards that, not farther |
| 12:53.19 | d-lo | no one is pushing it anywyere, yet. |
| 12:53.30 | d-lo | wow i really am having a bad typing day |
| 12:53.36 | brlcad | then why bother making it optional? :) |
| 12:54.00 | d-lo | because it messes up the compile on windows currently. |
| 12:54.16 | brlcad | in what way? |
| 12:54.24 | brlcad | just brlcad-config? |
| 12:54.31 | d-lo | yes. |
| 12:55.06 | d-lo | and until I get to 'find a fix for the brlcad-config/windows/coreInterface' on the TODO list, I need to make it optional |
| 12:55.11 | d-lo | temporary like. |
| 12:55.29 | d-lo | Unless there is a very quick fix for this? |
| 12:56.12 | brlcad | the problem is that is wasted effort though, and work that someone else will have to undo -- the "quick fix" that is not so quick overall for everyone |
| 12:56.46 | brlcad | this is one of those cases where feature-wise, the nxt requirement is hit and refactor is needed |
| 12:57.03 | d-lo | so its better for me to just locally edit the cmake files and take coreInterface out of th ebuild whenever I am working on windows? |
| 12:57.25 | d-lo | ...at least until a fix is put in? |
| 12:58.33 | brlcad | well that's certainly an option, but not a refactor path |
| 12:58.52 | brlcad | what woudl the minimal "next step" (referring to last week's talks) be? |
| 12:59.04 | brlcad | considering it necessary code |
| 12:59.44 | brlcad | given you've encountered a refactor point, needing it to compile on windows and linux |
| 12:59.54 | d-lo | next step as in MY next step or the next step toward fixing this issue? |
| 13:00.15 | brlcad | they should be one in the same from a project perspective |
| 13:00.28 | d-lo | yes and no. |
| 13:00.30 | brlcad | else code turds get left by others for others :) |
| 13:00.55 | d-lo | 'code turd' .... gotta write that one down. |
| 13:01.01 | brlcad | everyone picks up poop on a healthy project, even if it's not your dog |
| 13:01.33 | d-lo | build on windows is not 'required' for my next delieverable, which am trying to get to asap |
| 13:01.52 | d-lo | but I work on windows every Monday, so it is a bit of an issue for me. |
| 13:02.40 | brlcad | it's a reasonable need just based on your workflow -- so what's the next step? |
| 13:03.30 | brlcad | so unless you want to change your workflow, the shortest path to get it working on both |
| 13:04.37 | d-lo | I dunno :) Was going to ask your esspert opinion today. |
| 13:05.00 | d-lo | I am not familiar enough with the brlcad code base to know if there is an easy solution or not. |
| 13:05.28 | brlcad | well you've already said what the problem is, it won't build on windows due to brlcad-config getting called |
| 13:05.50 | brlcad | so then a few options should come to mind directly on that thought line |
| 13:06.47 | d-lo | right, I get that the port of brlcad-config is an option. But you mentioned that the whole 'header' approach is suboptimal anyways. |
| 13:06.55 | brlcad | figuring out a minimal "next step" doesn't usually require domain knowledge, you don't need to know brl-cad code base |
| 13:07.22 | brlcad | yeah, porting brlcad config is an option, but definitely not the minimal next step |
| 13:07.33 | brlcad | I'd expect that'd take a couple hours to port |
| 13:07.53 | brlcad | there's a couple much faster options |
| 13:10.13 | d-lo | Hrm, I am looking at the coreInterface code now. |
| 13:10.28 | d-lo | doesn't look like it uses the version information for anything |
| 13:10.39 | brlcad | more thought process for you (where I was leading towards) .. delegation is always an option, get someone else to port/change/fix the problem |
| 13:10.42 | brlcad | in this case could be asking the person that wrote brlcad-config (me) to port it to windows, or asking the person that used brlcad-config (daniel) to make it work on windows |
| 13:10.53 | brlcad | another option is often removal/simplification |
| 13:11.09 | brlcad | replace brlcad-config with a constant |
| 13:11.32 | brlcad | it becomes a refactor point down the road the moment that the version changes again and portability can be revisited |
| 13:12.09 | brlcad | the simplest next step you have control over is simplification, the 'best' next step from a forward progress would probably be getting "someone else" to fix it |
| 13:14.15 | d-lo | I'm not sure I know of anyone with time/care to fix it :) |
| 13:15.03 | CIA-73 | BRL-CAD: 03davidloman * r38802 10/rt^3/trunk/TODO: Update TODO list. Core Interface requires the use of brlcad-config to generate 'brlcadversion.h' via cmake. brlcad-config is not present on windows brlcad builds, thus coreInterface will not build on windows. |
| 13:15.53 | CIA-73 | BRL-CAD: 03davidloman * r38803 10/rt^3/trunk/src/utility/Logger.cxx: Clean up a trailing ':' from the Timestamp in the logger. |
| 13:16.45 | brlcad | which is fine |
| 13:18.09 | brlcad | agility on next step decision making isn't to achieve the "best" solution that you would want/design, it's the minimal effort decision that always moves things forward |
| 13:18.54 | brlcad | replacing it with a constant is perfectly viable and absurdly minimal effort, and raises the point more evident that something better is needed |
| 13:19.48 | d-lo | kk, now for another question: Where/how does this task get tracked so it will be revisted later? |
| 13:20.11 | d-lo | or is it assumed that the natural course of developement will eventually demand this issue get worked? |
| 13:20.16 | brlcad | CONTRIBUTOR RESPONSIBILITIES .. point #2 (in HACKING) |
| 13:20.35 | brlcad | Bugs, typos, and compilation errors are to be expected as part of |
| 13:20.35 | brlcad | the process of active software development and documentation, but it |
| 13:20.35 | brlcad | is ultimately unacceptable to allow them to persist. If it is |
| 13:20.35 | brlcad | discovered that a recent modification introduces a new problem, such |
| 13:20.35 | brlcad | as causing a compilation portability failure, then it is the |
| 13:20.38 | brlcad | responsibility of the contributor that introduced the change to assist |
| 13:20.40 | brlcad | in resolving the issue promptly. It is the responsibility of all |
| 13:20.43 | brlcad | developers to address issues as they are encountered regardless of who |
| 13:20.45 | brlcad | introduces the problem. |
| 13:23.14 | brlcad | it gets added to TODO, but you have it right -- natural course of development will demand a next step refactoring usually pretty quickly when simplification is selected |
| 13:23.22 | d-lo | kk |
| 13:23.59 | d-lo | its kinda disheartening, looking at all that needs to be done.... expecially now that I have learned enough to see the enormity of things :) |
| 13:25.44 | brlcad | all the more reason to KISS the code ;) |
| 13:26.28 | brlcad | I'm sure some of the things that "need" to be done don't actually need to be done too :) |
| 13:26.56 | brlcad | woot, gsoc student selections announced |
| 13:27.09 | d-lo | did bzflag apply this year? |
| 13:27.57 | brlcad | no |
| 13:29.06 | CIA-73 | BRL-CAD: 03davidloman * r38804 10/rt^3/trunk/ (5 files in 2 dirs): Finish up minimal config loading system. |
| 13:29.27 | CIA-73 | BRL-CAD: 03davidloman * r38805 10/rt^3/trunk/include/utility/Config.h: Whoops, forgot the config.h changes. |
| 13:29.51 | d-lo | and yes, some of the 'needed' things are not 'needed'. But since I lack experience, I figure some of these things out as I go ;) |
| 13:31.59 | d-lo | besides brlcad-config, is there any other place to programatically get version info? |
| 13:32.25 | brlcad | well when you're working on a bit of code, just ask yourself how bad things would things really be (right now) if you ripped it out, or replaced it with something far more simple |
| 13:33.38 | d-lo | basically, that is what I have been doing. |
| 13:33.49 | d-lo | I put together a 'sprint to the finish' todo list this weekend. |
| 13:34.02 | d-lo | I'd like to have a minimal implementation of my deliverable by friday |
| 13:34.50 | brlcad | there are library version routines, bu_version(), bn_version(), rt_version() that return strings |
| 13:34.57 | brlcad | one for each lib |
| 13:35.08 | brlcad | that gives run-time versioning |
| 13:35.32 | d-lo | And I should assume that they are not necessarily going to all be the same? |
| 13:35.47 | brlcad | that could be extended to be more generally useful (like run-time versioning that returns the numbers in a more usable non-string form) |
| 13:36.03 | brlcad | depends what you're using the version numbers for |
| 13:36.59 | d-lo | from what I have gathered, coreInterface (cI) reads the version info, as a string, out of brlcad-config and then dumps it into brlcad/brlcadversion.h as a set of DEFINEs |
| 13:37.21 | brlcad | they are separate products, so there's no reason they have to be the same, but certainly are now as we only release as a unified package |
| 13:38.18 | brlcad | I'd read up on the mailing list discussion before talking that issue directly |
| 13:39.04 | d-lo | 'that issue' being what cI is doing and why? |
| 13:39.50 | brlcad | right, and the status of versioning in the brlcad module as well, why that's even necessary and what other options we have |
| 13:40.08 | brlcad | certainly not something for this week with a sprint path layed out |
| 13:40.22 | d-lo | kk |
| 13:40.25 | brlcad | simplification or delegation |
| 13:40.28 | brlcad | or both :) |
| 13:40.58 | brlcad | given you only deal with it on windows, it's technically not an issue at the moment, right? :) |
| 13:41.05 | brlcad | not till next monday |
| 13:41.26 | d-lo | this whole simpilification thing is making the OCD in me very angry lol |
| 13:41.33 | d-lo | correct :) |
| 13:42.54 | brlcad | it's a hard skill to learn, but next step minimal refactoring usually pays off huge in the long term, especially as new devs get involved but even before then |
| 13:43.15 | d-lo | I can see how ;) |
| 13:43.22 | d-lo | easier said than done though. |
| 13:43.31 | brlcad | yeah |
| 14:19.00 | d-lo | anyone have a spare 30-40' of CAT-5? |
| 14:24.08 | CIA-73 | BRL-CAD: 03brlcad * r38806 10/brlcad/trunk/TODO: compile-time version management needs some lovin'. |
| 14:38.21 | CIA-73 | BRL-CAD: 03bob1961 * r38807 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Activate the horizontal scrollbar for the tree view. Update node colorization in the list view for things being drawn. Adjust the width of the tree view's column #0. |
| 14:58.42 | CIA-73 | BRL-CAD: 03davidloman * r38808 10/rt^3/trunk/include/libNetwork/INetMsgHandler.h: Drop cstr/dstr for an Interface. Also forgot an include. |
| 15:22.28 | brlcad | not any more |
| 15:23.03 | brlcad | can pick up a spool at HDepot for pretty cheap |
| 15:23.23 | d-lo | kk just askin around |
| 15:27.57 | d-lo | should GS be in its own namespace? |
| 15:35.10 | CIA-73 | BRL-CAD: 03davidloman * r38809 10/rt^3/trunk/ (3 files in 2 dirs): Add Exception subclass that provides simplistic logging. |
| 15:52.01 | CIA-73 | BRL-CAD: 03davidloman * r38810 10/rt^3/trunk/include/GS/GSCommon.h: WS, Formatting. |
| 15:52.41 | CIA-73 | BRL-CAD: 03davidloman * r38811 10/rt^3/trunk/ (3 files in 2 dirs): Implement NewSessionReqMsg. Carries uname/password payload. |
| 15:54.09 | CIA-73 | BRL-CAD: 03davidloman * r38812 10/rt^3/trunk/src/libNetwork/: Modified SVN:IGNORE, added *.backup |
| 16:20.58 | brlcad | thinks he'll have better luck finishing tagging/posting if he just does it now before going in |
| 16:23.10 | brlcad | GS eventually could be, but wouldn't worry about it for now as it's just more typing |
| 16:23.33 | d-lo | agreed. Was just an idle thought. |
| 16:23.54 | brlcad | GS isn't an API, so it's technically not necessary either way |
| 16:24.00 | brlcad | GE on the other hand, should |
| 16:24.41 | brlcad | daniel's stuff is already set up nicely in that regard |
| 16:34.50 | d-lo | gawd its cold in here. |
| 16:59.39 | CIA-73 | BRL-CAD: 03davidloman * r38813 10/rt^3/trunk/ (include/GS/Session.h src/GS/Session.cxx): Add account id field to Session. |
| 17:15.36 | CIA-73 | BRL-CAD: 03starseeker * r38814 10/brlcad/trunk/src/tclscripts/mged/man.tcl: Let's try the utf-8 encoding in MGED's man viewer routine |
| 17:22.17 | starseeker | brlcad: the win32 windows build fails on common.h - can't open stdint.h (via Bob) |
| 17:28.58 | CIA-73 | BRL-CAD: 03davidloman * r38815 10/rt^3/trunk/ (32 files in 3 dirs): Add a origin field to NetMsg and all subclasses. |
| 17:45.17 | d-lo | hangs chicken bones on his monitor to see if that helps SourceForge svn go any faster. |
| 17:45.23 | CIA-73 | BRL-CAD: 03davidloman * r38816 10/rt^3/trunk/ (4 files in 2 dirs): Combined getNextMsg() and peekNextMsg() into getNextMsg(bool peek = false) to simplify code. |
| 17:45.34 | d-lo | it worked! :) |
| 17:47.53 | brlcad | more ws woes |
| 17:48.22 | starseeker | brlcad: should Bob dig into the common.h issue? |
| 17:48.31 | starseeker | or is that the ws woes? |
| 17:49.10 | *** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl) |
| 17:49.27 | brlcad | ws woes are just with dave's editor reformatting a file when he edits it |
| 17:49.32 | starseeker | ah |
| 17:49.41 | brlcad | diff was useless |
| 17:50.13 | d-lo | oh noes! |
| 17:50.40 | d-lo | I'll seperate out the formatting into their own commits. |
| 17:50.44 | d-lo | would that help? |
| 17:50.49 | brlcad | yeah |
| 17:50.53 | d-lo | kk, will do |
| 17:51.35 | d-lo | just as a warning, there will be a few more since I have a queue of things to commit still :/ |
| 17:52.03 | starseeker | d-lo: hence the motivator to commit early and often ;-) |
| 17:52.03 | brlcad | no prob |
| 17:52.16 | d-lo | no not really ;) |
| 17:52.19 | CIA-73 | BRL-CAD: 03brlcad * r38817 10/brlcad/trunk/src/libfb/if_X24.c: sanity test failure. %p on a scanf requires a pointer to a pointer. |
| 17:52.37 | d-lo | more like bringing a change to completion, then commiting. |
| 17:52.53 | brlcad | yep |
| 17:53.15 | brlcad | or committing even more frequently (per file) as changes are made |
| 17:53.27 | d-lo | ..even it it breaks the build? |
| 17:54.09 | starseeker | d-lo: in that case I'll sometimes comment out the code for commmit |
| 17:54.12 | brlcad | depends if you have to collaborate/cooperate |
| 17:56.55 | CIA-73 | BRL-CAD: 03davidloman * r38818 10/rt^3/trunk/ (include/GS/AccountManager.h src/GS/AccountManager.cxx): Implement basic account cred checking. |
| 17:57.36 | starseeker | apparently the Windows compiler defines __STDC__ even though stdint.h isn't present, and that's getting it past the if on line 115 of common.h |
| 18:00.17 | brlcad | ahh, okay -- hadn't gotten round-trip back to windows just yet, was still refixing *nix from the last round |
| 18:00.20 | brlcad | only reason haven't tagged yet |
| 18:00.29 | CIA-73 | BRL-CAD: 03davidloman * r38819 10/rt^3/trunk/ (include/GS/SessionManager.h src/GS/SessionManager.cxx): Make SessionManager implement INetMsgHandler. Add a quint32 to Session* map to SessionManager. |
| 18:00.59 | brlcad | d-lo: I think you have the right idea -- it's just making each commit being a succint "one thing" by itself |
| 18:01.28 | d-lo | I've been trying to work from the "it needs to compile prior to commiting" mantra |
| 18:01.29 | brlcad | reformatting/ws/indent go well together |
| 18:02.16 | brlcad | making sure it compiles is a good mantra |
| 18:02.39 | brlcad | so like adding your origin field to NetMsg is a good "one thing" |
| 18:02.52 | brlcad | you could do those all together, but it requires restraint to make sure that's the only thing |
| 18:03.53 | starseeker | can we leave teh SIZE_T test but remove the __STDC__ test? |
| 18:03.53 | starseeker | __STDC__ by itself doesn't seem to be sufficient |
| 18:03.53 | starseeker | er __SIZE_TYPE__ test rather |
| 18:04.26 | d-lo | thinks its Blues Brothers time. |
| 18:04.33 | starseeker | Tom's email said both __STDC__ and __SIZE_TYPE__ macros triggered inclusion |
| 18:04.44 | starseeker | OK... |
| 18:06.10 | brlcad | I can sort that out |
| 18:06.59 | brlcad | you can do some GUI testing if you're willing, make sure mged comes up, sketch editor comes up, rtwizard starts, rt within mged works, etc |
| 18:07.15 | brlcad | almost done with this last mac build |
| 18:07.50 | starseeker | __STDC__ is coming from config_win.h |
| 18:08.27 | CIA-73 | BRL-CAD: 03davidloman * r38820 10/rt^3/trunk/ (include/GS/GeometryService.h src/GS/GeometryService.cxx): Add slot for receiving and handling NetPortal's msgReady signal. Implement handleNetMsg(...) and round NewSessionReqMsg to SessionManager. |
| 18:10.24 | brlcad | yeah, that's bad juju in config_win.h |
| 18:10.34 | brlcad | the fix, though, is probably even more simple |
| 18:11.00 | brlcad | since windows has a set config header, it should include pstdint.h |
| 18:16.01 | brlcad | ah, neat debug output on writing out the nged pages |
| 18:16.16 | brlcad | especially with parallel |
| 18:17.56 | CIA-73 | BRL-CAD: 03brlcad * r38821 10/brlcad/trunk/include/config_win.h: windows doesn't provide stdint.h so always pre-include pstdint.h for those types. should prevent common.h from performing an include. |
| 18:19.14 | CIA-73 | BRL-CAD: 03brlcad * r38822 10/brlcad/trunk/include/config_win.h: er, it's not a system header, use double quotes on pstdint.h |
| 18:22.30 | CIA-73 | BRL-CAD: 03davidloman * r38823 10/rt^3/trunk/ (6 files in 3 dirs): Modify INetMsgHandler::handleNetMsg(...) to require a pointer to NetPortal of origin. |
| 18:42.23 | CIA-73 | BRL-CAD: 03davidloman * r38824 10/rt^3/trunk/ (4 files in 3 dirs): Implement SessionInfoMsg for use to inform requester of current Session Information or to tell requester that a new session has been created. |
| 18:51.37 | CIA-73 | BRL-CAD: 03davidloman * r38825 10/rt^3/trunk/src/libNetwork/NetMsgFactory.cxx: Changes to the MsgType macros and the implementation of several NetMsg subclasses warrant updating of the NetMsgFactory |
| 18:59.19 | CIA-73 | BRL-CAD: 03davidloman * r38826 10/rt^3/trunk/src/GS/SessionManager.cxx: Finish implementing new Session Request. |
| 19:03.16 | CIA-73 | BRL-CAD: 03davidloman * r38827 10/rt^3/trunk/include/GS/GSCommon.h: Forgot to add the new AUTHENTICATION_FAILED error code. |
| 19:03.36 | CIA-73 | BRL-CAD: 03bob1961 * r38828 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added an opendb command to ArcherCore. |
| 19:46.49 | d-lo | ``Erik: you have a fbsd version of choice? |
| 19:47.36 | CIA-73 | BRL-CAD: 03davidloman * r38829 10/rt^3/trunk/tests/GS/ (CMakeLists.txt GeometryServiceTest.cxx): Begin filling in specifics of GeometryClient. |
| 19:48.55 | ``Erik | "most recent stable" is usually what I go with, I think that's 8.0 right now |
| 19:49.26 | d-lo | awesome stuff. |
| 19:49.38 | d-lo | I'll try to DL a version and play with it when I get home. |
| 19:49.45 | ``Erik | cool beans |
| 19:56.09 | ``Erik | I usually get the minimal disc image, install, get cvsup, then sync sources and build/upgrade right away |
| 20:12.01 | *** join/#brlcad ``Erik (~erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 20:15.12 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 20:39.27 | CIA-73 | BRL-CAD: 03brlcad * r38830 10/brlcad/trunk/src/mged/ (dozoom.c mged_dm.h usepen.c): remove ndrawn indirection as it just obfuscates code by making ndrawn seem like a global. |
| 20:49.51 | *** join/#brlcad talcite (~matthew@bas4-toronto21-1176312659.dsl.bell.ca) |
| 21:13.15 | CIA-73 | BRL-CAD: 03r_weiss * r38831 10/brlcad/trunk/src/conv/obj-g_new.c: testing nmg creation, refactoring, cleanup |
| 22:14.19 | brlcad | finds major piggishness in dm-X during release testing |
| 23:51.40 | starseeker | O.o |
| 23:51.47 | starseeker | hrrrrm |
| 23:55.00 | starseeker | rt -F/dev/ogls succeeds on OSX where -F/dev/ogl does not |
| 23:55.31 | starseeker | both slow on Redhat |