| 00:02.58 | Notify | 03BRL-CAD Wiki:Bhollister * 8713 /wiki/User:Bhollister/DevLogJune2015: /* Tuesday, June 16, 2015 */ |
| 00:05.11 | Notify | 03BRL-CAD Wiki:Bhollister * 8714 /wiki/User:Bhollister/DevLogJune2015: /* Tuesday, June 16, 2015 */ |
| 00:27.48 | Notify | 03BRL-CAD:starseeker * 65340 brlcad/trunk/src/libbrep/shape_recognition.cpp: We're not ready for torus based shapes yet. |
| 02:37.42 | Notify | 03BRL-CAD:brlcad * 65341 (brlcad/trunk/doc/docbook/articles/en/CMakeLists.txt brlcad/trunk/doc/docbook/articles/hy/CMakeLists.txt and 2 others): DOCBOOK_TO_PDF already checks whether BRLCAD_EXTRADOCS_PDF is set, so we can eliminate these other checks. |
| 02:59.31 | brlcad | starseeker: haven't tried what? disabling rtserver? if it doesn't work, then it's a bug : |
| 03:00.11 | Notify | 03BRL-CAD:brlcad * 65342 (brlcad/trunk/CMakeLists.txt brlcad/trunk/doc/docbook/system/man1/en/CMakeLists.txt and 3 others): simplify, remove undocumented BRLCAD_EXTRADOCS_PDF_MAN option so that the man pages generate to pdf when BRLCAD_EXTRADOCS_PDF is enabled. dubious value creating individual pdf files for individual manual pages .. might want to eliminate altogether or (better) aggregate them all into one |
| 03:00.14 | Notify | book/pdf. |
| 03:00.16 | Notify | ... |
| 03:06.03 | Notify | 03BRL-CAD:starseeker * 65343 brlcad/trunk/src/other/URToolkit/cnv/CMakeLists.txt: looks like rletorla will need ws2_32 with mingw for gethostname |
| 03:13.22 | *** join/#brlcad bradh (~brad@2600:1010:b00f:a0c8:8970:1dad:d5b2:832a) | |
| 03:21.05 | brlcad | hm, we might need to restructure doc/docbook/system or frame it a little differently, same with the underused doc/docbook/specifications which overlaps with man7 |
| 03:23.06 | starseeker | brlcad: JAVA_AUTOBRIEF |
| 03:23.44 | brlcad | ahhh |
| 03:23.50 | brlcad | was trying to figure out that connection |
| 03:23.59 | starseeker | brlcad: if you're going to eliminate BRLCAD_EXTRADOCS_PDF_MAN we should probably build them all into one |
| 03:24.24 | brlcad | or not build them at all until someone adds the aggregate |
| 03:24.34 | starseeker | sure |
| 03:24.39 | starseeker | they take forever to build |
| 03:24.47 | starseeker | look pretty nice though |
| 03:24.56 | starseeker | (or did, last time I did PDF) |
| 03:25.15 | brlcad | I don't have strong feelings other than a desire to simplify our build |
| 03:25.16 | Notify | 03BRL-CAD:starseeker * 65344 brlcad/trunk/CMakeLists.txt: Start preparing for the end of config_win.h - it's a leftover from the autotools/MSVC project days. Now that we have CMake we should be testing for what it currently has hardcoded to make brlcad_config.h work for everyone. Will be a fair bit of logic to move over, but worth it from a long term perspective. |
| 03:25.57 | starseeker | brlcad: well, if we're not going to break it out then we should probably just eliminate it - don't want to have to wait for all the man pages when doing PDFs of the books |
| 03:26.03 | brlcad | i spent many hours last weekend wading through what should have been a relatively simple change, but the complexity and interdependent logic was killing me |
| 03:26.29 | starseeker | apologies |
| 03:26.33 | brlcad | probably was doing something wrong, but I just kept running into issue after issue |
| 03:26.41 | brlcad | no worries |
| 03:27.04 | starseeker | brlcad: doubt it - that's the classic n=1 developer problem |
| 03:27.11 | brlcad | how long are all the pdfs now (with and without mans)? |
| 03:27.15 | starseeker | it made sense to me, but no one else ever saw it |
| 03:27.27 | starseeker | you mean how long to build, or page length? |
| 03:27.33 | brlcad | long to build |
| 03:28.05 | starseeker | last time I tried it I think the PDF man pages were a couple times the length of the rest of the build, but it's been a looong time |
| 03:28.43 | brlcad | what I was mostly fighting was data encapsulation issues .. some common routine that would set some global property or build up some variable that it never used, but was used somewhere far away |
| 03:28.52 | starseeker | ah |
| 03:28.59 | brlcad | almost certainly logic growth |
| 03:29.03 | starseeker | yeah, that's probably the distcheck system |
| 03:29.29 | brlcad | no, this wasn't related to that |
| 03:29.31 | starseeker | need to maintain our own global registry of files for various purposes, since CMake (at least at the time of the original work) didn't |
| 03:29.51 | starseeker | hmm... maybe building lists of all html targets, pdf targets, etc.? |
| 03:30.22 | brlcad | I was simply trying to force it to use a system-installed dep |
| 03:30.29 | starseeker | hmm |
| 03:30.39 | starseeker | xsltproc? |
| 03:30.46 | brlcad | there were at least a dozen variables involved, several lists |
| 03:30.48 | starseeker | or do you mean DocBook inputs? |
| 03:31.04 | brlcad | nah, was trying to link against activestate |
| 03:31.05 | starseeker | if the latter, I'm not surprised it was hard - I made no provisions for that in the original design |
| 03:31.10 | starseeker | ahhh |
| 03:31.42 | brlcad | which ultimately should have been just turn our stuff off (which seemed to be a big problem) and add -framework Tcl |
| 03:31.54 | starseeker | yeah, that worked once upon a time on Windows |
| 03:32.00 | starseeker | not sure about Mac - probably not |
| 03:32.00 | brlcad | but then that has to get added to cflags and ldflags, and that was yet another ball of errors |
| 03:32.09 | starseeker | winces |
| 03:32.24 | brlcad | couldn't force it to set the dang ldflag no matter how many different ways I tried to set it |
| 03:32.36 | starseeker | yeah, the Tcl integration is in many ways the most primitive bit of our CMake logic (was the bit I had to do first, so it pretty much sucks.) |
| 03:32.53 | brlcad | started following the logic and it really looked like there were several bugs in play |
| 03:33.11 | starseeker | if I'm not mistaken the -framework bits get added as target_link_libraries, but it's been a while since I've delt with mac |
| 03:33.32 | brlcad | oh, I did that |
| 03:33.34 | brlcad | in many ways :) |
| 03:33.43 | starseeker | snorts |
| 03:33.44 | brlcad | it still wouldn't take for some reason |
| 03:33.49 | starseeker | figures |
| 03:33.57 | starseeker | yeah, I haven't touched ldflags much |
| 03:34.34 | brlcad | which is surprising since it's pretty much requisite for proper on-demand toggling of system libs and 64bit v 32-bit ... :) |
| 03:34.42 | starseeker | that's a weakness of CMake - they just pick what they consider "sensible" defaults and most of the world goes with those and adds a few flags. |
| 03:34.52 | brlcad | for tcl kept saying it matched finding a framework in a system path ... that was not the lib |
| 03:35.19 | brlcad | actually was a directory (that did not contain the lib) and it still didn't do anything with that info on the linker or compilation line |
| 03:35.27 | starseeker | frameworks on Mac are their own special brand of headache for the find logic, particularly when you have things like macports present |
| 03:35.28 | brlcad | like I said, seemed to be several bugs |
| 03:35.51 | starseeker | nods |
| 03:36.06 | starseeker | yeah, you wandered into one of the minefields |
| 03:36.38 | brlcad | I didn't seem to be fighting cmake actually, other than the stupid cache having to get wiped out every single run to make sure it really did retest with whatever new coercion I was trying |
| 03:37.02 | brlcad | I was definitely fighting the logic itself |
| 03:37.05 | brlcad | so question actually |
| 03:37.19 | brlcad | if you set a var, e..g, set(FOO "asdf;asdf;asdf") |
| 03:38.03 | brlcad | and messsage("I set FOO to ${FOO}") |
| 03:38.08 | brlcad | what should it print? |
| 03:38.35 | starseeker | "I set FOO to asdfasdfasdf" is probably what you'll get |
| 03:39.10 | starseeker | semicolons tend to get eaten, IIRC |
| 03:39.37 | starseeker | but it may depend on how FOO gets processed |
| 03:39.41 | brlcad | so that's one of the mysteries I was dealing with ... |
| 03:40.05 | brlcad | if I put those exact two lines into a cmakelists.txt file and run it, it prints "I set FOO to asdf;asdf;asdf" |
| 03:40.12 | starseeker | ah, did it |
| 03:40.29 | starseeker | OK, better than I expected |
| 03:40.31 | brlcad | yet, those same exact two lines in our logic print "I set FOO to asdfasdfasdf" |
| 03:40.46 | starseeker | O.o |
| 03:40.48 | starseeker | hmm |
| 03:41.03 | brlcad | is message() being overwritten? |
| 03:41.07 | starseeker | yes |
| 03:41.28 | starseeker | line 499 in the toplevel CMakeLists.txt file |
| 03:41.33 | brlcad | ugh, okay .. so that was a couple of the hours |
| 03:41.44 | brlcad | dare I ask why? :) |
| 03:41.53 | starseeker | that's so all the messages go into CMakeOutput.log as well as being printed |
| 03:42.08 | brlcad | hm, ok |
| 03:42.27 | brlcad | that makes sense (assuming no other way to direct message() output) |
| 03:42.40 | brlcad | so then it's just something screwy in that wrapper |
| 03:44.03 | starseeker | notes there actually is a comment explaining the purpose - given that the existing info failed to convey the existence and intent of that bit of code when someone was actually looking for it, that suggests we need a better mechanism for communicating that sort of info |
| 03:44.32 | starseeker | maybe some sort of BRL-CAD CMake pecularities README in the doc dir? |
| 03:45.34 | brlcad | I don't think that would help |
| 03:45.52 | brlcad | it's a nugget of information lost in a sea of other information |
| 03:46.30 | brlcad | so adding another layer of information to the mix wouldn't likely help, it'd just make it even harder to navigate (and get out of sync) |
| 03:47.18 | starseeker | nods - I don't like all the custom bits we do, but we also push CMake *very* hard in some weird directions |
| 03:47.59 | brlcad | the only issue with message() is that it doesn't just do what the comment says, it does more |
| 03:48.10 | starseeker | needs to investigate some of the new CMake 3 features to see if they can replace some of the wild and wooly bits I needed to do in 2.x |
| 03:48.15 | brlcad | it peeks at the message and changes it .. and that's ultimately what caused my confusion |
| 03:48.25 | starseeker | nods - the change is an unintential side effect |
| 03:48.39 | starseeker | probably wasn't aware of it at the time of the wrapping |
| 03:49.25 | brlcad | sure, to be expected |
| 03:49.30 | starseeker | that's probably a good one for the CMake list, actually |
| 03:49.36 | starseeker | someone else may have a better trick |
| 03:50.20 | brlcad | I guess the main reason you overrode it was to capture all messages, even from built-ins |
| 03:50.25 | starseeker | yes |
| 03:50.39 | brlcad | otherwise, it could ahve been self documenting by introducing our own printing wrapper |
| 03:50.43 | starseeker | and 3rd party builds where we can't define our own message function (BRLCAD_message or some such) |
| 03:51.23 | starseeker | might try something like this: http://stackoverflow.com/a/15843036/2037687 |
| 03:51.35 | starseeker | they're quoting ARGN, which might make the difference |
| 03:52.18 | starseeker | would have to experiment |
| 03:53.01 | Stragus | admires those who fight against cmake and other build systems |
| 03:53.08 | brlcad | yikes, execute_process for every print statement...that'd be heavy |
| 03:53.36 | starseeker | was looking more at quoting ARGN |
| 03:53.53 | brlcad | ah, yeah |
| 03:54.01 | brlcad | almost certainly is the diff |
| 03:54.18 | starseeker | that and having a parameter for the first arg |
| 03:54.30 | starseeker | I think message may always take 2 args, so that could be important |
| 03:55.08 | Notify | 03BRL-CAD:starseeker * 65345 brlcad/trunk/CMakeLists.txt: Returns would be nice... |
| 03:55.19 | brlcad | why do you replace the semis with colons in the log file? |
| 03:55.32 | starseeker | I think so they would print successfully |
| 03:55.44 | starseeker | (1st guess) |
| 03:56.09 | brlcad | that doesn't make sense to me :) |
| 03:56.30 | brlcad | file(APPEND myfile "asdf;asdf;asdf\n") .... should work :) |
| 03:56.47 | starseeker | as a raw string, yes |
| 03:57.13 | brlcad | ditto file(APPEND myfile "${var}\n") |
| 03:57.26 | starseeker | it may be a quoting question |
| 03:57.28 | brlcad | that should be plain substitution |
| 03:57.35 | starseeker | I'll have to do some experiments tomorrow |
| 03:58.41 | brlcad | ahh, I see an issue |
| 03:59.00 | brlcad | ARGN for message() includes an implicit arg0 |
| 03:59.07 | starseeker | gets as far as starting to build libbu, sees backtrace.c die on fork, execvp and sleep |
| 03:59.08 | brlcad | which gets semi'd |
| 04:00.06 | starseeker | brlcad: I've got to call it a night - keep a list of questions, and I'll be glad to run through them tomorrow |
| 04:00.27 | brlcad | yep, taht did the trick |
| 04:00.49 | brlcad | thanks ... one issue down just a few more to go ;) |
| 04:01.37 | Notify | 03BRL-CAD:starseeker * 65346 brlcad/trunk/CMakeLists.txt: function, not variable |
| 04:03.18 | starseeker | nods - glad to try to work them out. Lots of rough edges lurking in there... |
| 04:04.11 | starseeker | grr... why does the execvp function check pass with mingw, then wipe out with an implicit function declaration warning? |
| 04:04.27 | starseeker | makes himself step away from the quicksand... |
| 04:04.57 | brlcad | any way to convince you that using MINGW and __MINGW__ is a bad idea long-term? :) |
| 04:05.54 | brlcad | that means it really does have execvp and there's a header missing |
| 04:06.08 | Stragus | I usually detect __GNUC__ and __WIN32__ rather than __MINGW__ |
| 04:07.41 | brlcad | Stragus: best practice (at least for the most current build system theory) is to avoid platform symbols to the greatest extent possible |
| 04:08.07 | brlcad | test for the feature/lib/header or sets thereof that constitute that thing being blocked in conditionally |
| 04:08.49 | starseeker | brlcad: when we get to the BRL-CAD codebase, sure ;-) |
| 04:08.51 | brlcad | we do use __WIN32__ in a handful of places and have checks to try and keep it under control (prevent use) |
| 04:09.18 | starseeker | is trying to get through src/other to the main event quickly |
| 04:09.26 | brlcad | the costs are still there on src/other |
| 04:09.28 | Stragus | To support a bunch of exotic Unix systems, I'm sure testing features/libs/headers is a good option |
| 04:10.05 | brlcad | it's debt that will have to get paid at some point in the future when some poor bloke spends hours figuring out why some windows mingw build isn't behaving right |
| 04:10.45 | brlcad | Stragus: it's actually to support future systems more than past systems |
| 04:11.06 | brlcad | systems with unknown mixings of standards, headers, complexities |
| 04:11.37 | Stragus | I see. I don't expect new systems to appear so often that we need a generic and complex system to support them all |
| 04:12.02 | brlcad | say a new version of mingw or windows comes along that suddenly provides atanf() ... the code adapts |
| 04:12.03 | starseeker | brlcad: if mingw looks practical to support I guess src/other can be cleaned up somewhat |
| 04:12.13 | brlcad | that's the thing though! |
| 04:12.22 | brlcad | it's not actually more complex usually |
| 04:12.29 | brlcad | it's just a different way |
| 04:13.00 | starseeker | the src/other builds, by and large, are far less sophisticated than BRL-CAD's build, and some of the Windows tests are compilcated |
| 04:13.04 | starseeker | (relatively speaking) |
| 04:13.29 | starseeker | I'd rather package it all up into a .cmake file that can be sourced easily by various projects, if it comes to that |
| 04:13.43 | brlcad | starseeker: i'm not sure I follow |
| 04:14.27 | starseeker | most of our function tests for non-windows systems are just check_function calls. It's looking like we'll have to start mixing in required libs and headers for some of these tests |
| 04:14.43 | starseeker | (i.e., you have this function, but only if you include this header and link this library) |
| 04:14.44 | brlcad | I'm looking at examples like r65343 where you conditionally link ws2_32 if we're mingw instead of just testing for ws2_32 and linking it (actually 2 lines of code instead of 3) |
| 04:14.59 | starseeker | that extra information has to be managed, and we aren't set up to do it systematically right now |
| 04:15.09 | starseeker | even in BRL-CAD, much less the independent src/other builds |
| 04:15.52 | starseeker | but where/when do I link ws2_32? it's there for gethostname, so the "correct" thing to do is note and track that so we don't end up linking ws2_32 everywhere |
| 04:16.12 | starseeker | but I don't know how to capture and propagate that info |
| 04:16.47 | brlcad | I don't follow -- you link it right there on rletorla |
| 04:17.25 | starseeker | right, but if I'm doing the "right" thing I'll have a better gethostname check (which is what I'm actually after) in the build that knows to optionally include that lib |
| 04:17.42 | brlcad | i wouldn't say that's the right thing |
| 04:17.45 | starseeker | which means the function check for gethostname depends on a lib check for ws2_32 |
| 04:17.46 | brlcad | there's a gethostname system call |
| 04:17.53 | brlcad | it happens to come from a library called ws2_32 |
| 04:18.18 | brlcad | the code doesn't need to change, shouldn't need to change in this instance |
| 04:18.21 | brlcad | it's a linkage issue |
| 04:18.36 | starseeker | the library linkage list does need to change, and it changes based on the outcome of the gethostname test |
| 04:18.50 | brlcad | so there just needs to be a "does ws2_32 library exist (with gethostbyname)" |
| 04:19.29 | brlcad | that's a one-liner cmake directive, then one more line to set the target_link_libs on rletorla |
| 04:20.06 | starseeker | but there's a problem in that the HAVE_GETHOSTNAME test by itself is no longer enough - I need that linkage not just in rletorla, but *everywhere* gethostname is in use in my codebase |
| 04:21.34 | starseeker | so every build target that uses gethostname now needs an extra line, but I won't see that if I'm writing new code unless I happen to know mingw needs it |
| 04:22.24 | brlcad | right, but there's certainly plenty of precedent there already (and that's actually what we do) |
| 04:22.58 | starseeker | except cases where you need a library for functions are (or at least, were) quite rare |
| 04:23.05 | brlcad | moreover a CI dashboard would catch newcomers, technically solved |
| 04:23.06 | starseeker | M_LIBRARY is the only one that comes readily tomind |
| 04:23.15 | starseeker | and M_LIBRARY is a pain |
| 04:23.40 | brlcad | remembering the old build, there were far more cases than -lm |
| 04:24.01 | brlcad | we just lost support for them (which is fine, they were old, but not justification) |
| 04:24.19 | brlcad | some platforms genuinely need -lc for example |
| 04:25.08 | starseeker | would prefer to have some way to have the necessary libraries automatically added based on the CMake configure test and source code introspection |
| 04:25.10 | brlcad | networking is actually a set of libs if were were fully ported to all commercial UNIX systems (ones still being sold/supported even) |
| 04:26.05 | starseeker | ideally the programmer at the tool level shouldn't have to see that nonsense if we can detect it at the configure stage... |
| 04:26.26 | brlcad | I hear you say that and I envision more unencapsulated side-effect logic that is brittle to different conditions |
| 04:26.44 | brlcad | let it be declarative |
| 04:26.59 | brlcad | let duplication determine when/where to refactor into common logic |
| 04:27.05 | starseeker | that makes for far less readable build files though |
| 04:27.48 | brlcad | I'm not sure I would find it any worse if that logic is merely pushed elsewhere |
| 04:28.57 | brlcad | in fact, distancing it from where it's needed can also make it harder to understand, definitely a tradeoff in play |
| 04:28.59 | starseeker | I guess the tradeoff is it's more complex to add support for new systems, but day-to-day you have to interact with less logic more tightly focused on the local problem |
| 04:29.58 | starseeker | supposes option b) would be to libbu wrap functions that may need extra library help and deal with it there |
| 04:30.04 | brlcad | this all still seems incredibly distanced from the immediate issue of using platform symbols in the build system |
| 04:30.38 | starseeker | I suppose |
| 04:30.57 | brlcad | I just don't see how platform checks are defensible, even if taken to the extreme of explicitly testing everywhere a MINGW or WIN32 or whatever is being used |
| 04:31.04 | brlcad | there's already logic inserted |
| 04:31.20 | starseeker | will find_library work for ws2_32? |
| 04:31.38 | brlcad | it's replacing "if(platform) ... endif" with "test_something(); if(test)... endif" :) |
| 04:32.51 | starseeker | I'm willing to try, but I won't be surprised if we end up with dozens of lines of configure tests duplicated across several build systems in place of the if(MINGW) tests... |
| 04:33.05 | starseeker | maybe it's worth it for future proofing |
| 04:33.57 | brlcad | s.o. question says something like find_library(ws2_32_LIBRARY_PATH ws2_32) shoudl work |
| 04:34.15 | starseeker | ok, we'll give it a try |
| 04:34.25 | brlcad | target_link_libraries(rletorla ${ws2_32_LIBRARY_PATH}) |
| 04:34.27 | starseeker | keeps flashing back to the hypot test and similar cases |
| 04:35.02 | brlcad | might not even need the if(test) wrapping if target_link_libs smartly handles NOTFOUND results |
| 04:35.45 | starseeker | I believe it does |
| 04:35.57 | starseeker | just means the target_link_libs list gets ugly |
| 04:36.09 | starseeker | but that's inevitable anyway, I suppose |
| 04:36.15 | starseeker | mged's is pretty bad |
| 04:36.41 | brlcad | nods |
| 04:37.55 | brlcad | entirely expect we'd eventually have the whole shebang get declared / tested |
| 04:38.19 | starseeker | shudders at the idea of testing MSVC compilation flags |
| 04:38.28 | brlcad | the way we handled it in autotools was similar to what we do with our common headers (io, socket, net) |
| 04:38.32 | starseeker | gcc/clang are bad enough |
| 04:39.41 | brlcad | so the build system would test a slew of possible net libs and group together the ones commonly related so ${REGEX_LIBS} might be expanded to "-lc -lm -lposix |
| 04:39.53 | brlcad | because some platform spread out regex across those system libs |
| 04:40.02 | brlcad | (actual case) |
| 04:40.16 | starseeker | slap that platform with a wet trout until they fix it |
| 04:40.35 | starseeker | yikes |
| 04:40.43 | brlcad | it was by design |
| 04:41.17 | brlcad | I don't think it changed for 5 or so years and only because they adopted a different implementation |
| 04:41.35 | brlcad | and not an obscure platform .. one of our primaries |
| 04:41.47 | Notify | 03BRL-CAD Wiki:Shaina7837 * 8715 /wiki/User:Shainasabarwal/GSoC15/logs: /* 1 June */ |
| 04:41.51 | brlcad | (a new one at the time) |
| 04:42.56 | starseeker | if we have to do that sort of thing again it'll have to be very cleary documented, somehow |
| 04:44.05 | starseeker | will have to think about how to approach that situation... |
| 04:44.10 | starseeker | blegh |
| 04:44.34 | starseeker | our configure tests will end up looking like BRLCAD_ADDEXEC and friends |
| 04:45.41 | starseeker | so we've got possible required headers, possible require libraries, possible different combinations of required libraries... |
| 04:46.18 | starseeker | maybe compiler flags, depending... |
| 04:48.13 | starseeker | ah, there's hypot - so we need to allow for the possibility of symbol checks as well |
| 04:48.56 | starseeker | brlcad: let me digest a little - I might be able to come up with a more general BRLCAD_CHECK_FUNCTION_EXISTS macro |
| 04:49.47 | starseeker | if we do need to support that sort of case, I'd like it to at least be as easy as possible to define the test |
| 04:50.56 | brlcad | definitely compiler flags |
| 04:51.16 | brlcad | I pretty much confirmed that 32-bit and 64-bit forced compilation isn't working |
| 04:51.24 | brlcad | and it was entirely due to flags |
| 04:51.29 | starseeker | isn't surprised |
| 04:51.36 | brlcad | linker flags were wrong |
| 04:52.25 | brlcad | I really wouldn't get too fancy with more general testing until common patterns emerge |
| 04:52.27 | starseeker | it's hard to even get the CMake find capabilities to do the right searches for both 32 and 64 bit libs reliably based on settings - last time I looked, they were missing some capabilities there |
| 04:54.45 | brlcad | there definitely are cases where we only want to test if a function is declared or not, or available/links, or "works" as intended |
| 04:55.10 | brlcad | cmake docs purport to support those three categories as well, so might be able to get away wrapperless |
| 04:55.25 | brlcad | I did read that several issues were fixed in some of the common functions |
| 04:55.42 | brlcad | at least one issue I talked with them about they weren't going to fix (even though it was wrong) |
| 04:55.49 | brlcad | but a workaround was possible |
| 04:57.29 | starseeker | nods |
| 04:57.55 | starseeker | well, I'll take a stab at detecting windows libs |
| 04:59.01 | starseeker | tomorrow |
| 04:59.10 | starseeker | really does sign off this time... |
| 05:05.49 | brlcad | thanks for all the help |
| 05:52.11 | Notify | 03BRL-CAD:brlcad * 65347 brlcad/trunk/CMakeLists.txt: aha, thanks to cliff for pinpointing what was causing my confusion regarding disappearing semicolons. turns out ARGN list elements are semicolon delimited internally, so quotes were needed. take a slightly different approach on the message() override by making it consciously handle the optional argv1 message type, while logging/passing it on accordingly. |
| 05:54.28 | Notify | 03BRL-CAD:brlcad * 65348 brlcad/trunk/CMakeLists.txt: was just going to remove the duplicate, but answer the question why #define pipe _pipe won't work |
| 05:58.48 | brlcad | n_reed: I suggest we rename doc/docbook/specifications to doc/docbook/developer and move your doc/docbook/system/implementation/bool_eval_development.xml to there |
| 05:59.43 | brlcad | that'll give us a place to stub in our other dev docs when sofat is finished with online syncing |
| 06:00.27 | brlcad | not to mention other dev files that should get written but that should stay separate from the user docs |
| 06:06.05 | brlcad | with that changed, I think we should then rename doc/docbook/system to something else .. maybe doc/docbook/help or doc/docbook/manuals |
| 06:11.12 | brlcad | possibly even disolving the doc/docbook/system/man* subdirs altogether |
| 06:12.07 | brlcad | man1 becomes something like doc/docbook/applications, man3 goes into doc/docbook/developer, man5 also there or into doc/docbook/file_formats, and mann into doc/docbook/commands |
| 06:13.08 | Notify | 03BRL-CAD Wiki:Ngassafinjap * 8716 /wiki/User:Amalia/Development_logs: /* Tuesday June 16th */ |
| 06:14.41 | brlcad | that would likely make aggregation easier too since it will make sense to keep different audiences separate |
| 06:18.06 | brlcad | OPEN QUESTION: does anyone know a good way to detect that all of our public API has a doxygen comment, ideally so we can test for it automatically and issue a dashboard/build/regression error until it's added? |
| 06:19.43 | brlcad | I could brute-force it and find all #define and EXPORT symbols easily enough with regex fu, and snatch any preceding comments, but that won't likely be very robust or comprehensive |
| 06:21.16 | brlcad | maybe if there's some way we could tell from the doxygen output itself that something isn't documented? |
| 07:24.44 | *** join/#brlcad milinda (~milinda@112.134.129.127) | |
| 07:35.16 | *** join/#brlcad teepee-- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 08:15.38 | *** join/#brlcad milinda (~milinda@124.43.108.251) | |
| 09:29.18 | *** join/#brlcad milinda (~milinda@124.43.174.82) | |
| 11:37.25 | *** join/#brlcad andrei_il (~andrei@109.100.128.78) | |
| 12:13.08 | *** join/#brlcad ih8sum3r (~ih8sum3r@122.173.187.253) | |
| 12:19.15 | *** join/#brlcad milinda (~milinda@124.43.174.82) | |
| 12:57.26 | *** join/#brlcad ih8sum3r (~ih8sum3r@122.173.187.253) | |
| 12:57.32 | *** part/#brlcad ih8sum3r (~ih8sum3r@122.173.187.253) | |
| 13:31.34 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 13:55.28 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 14:06.30 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 14:29.45 | Notify | 03BRL-CAD:carlmoore * 65349 brlcad/trunk/include/bu/opt.h: remove 1 whitespace character |
| 14:50.52 | Notify | 03BRL-CAD:bob1961 * 65350 brlcad/trunk/src/tclscripts/mged/grouper.tcl: Fixed multiple issues that broke grouper. Now calling select with -- to indicate end of options. Fixed the issue where the group being added to was getting added to itself. |
| 14:51.45 | Notify | 03BRL-CAD:bob1961 * 65351 brlcad/branches/eab/src/tclscripts/mged/grouper.tcl: Fixed multiple issues that broke grouper. Now calling select with -- to indicate end of options. Fixed the issue where the group being added to was getting added to itself. |
| 14:52.31 | *** join/#brlcad vasc (~vasc@bl13-112-247.dsl.telepac.pt) | |
| 15:25.53 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-rdakjbksrizgpirk) | |
| 15:41.12 | *** join/#brlcad sk3 (~Davi@101.59.69.83) | |
| 15:43.05 | *** join/#brlcad Davi3 (~Davi@101.59.69.83) | |
| 16:46.20 | dracarys983 | vasc: How's it going man? |
| 16:51.38 | *** join/#brlcad milinda (~milinda@124.43.174.82) | |
| 17:03.55 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 17:08.52 | *** join/#brlcad random_ (0e8b5206@gateway/web/freenode/ip.14.139.82.6) | |
| 17:15.42 | random3 | ~help |
| 17:16.05 | random3 | ~seen brlcad |
| 17:16.07 | infobot | brlcad <~sean@66-118-151-70.static.sagonet.net> was last seen on IRC in channel #brlcad, 10h 54m 51s ago, saying: 'maybe if there's some way we could tell from the doxygen output itself that something isn't documented?'. |
| 17:19.09 | ``Erik | abhijeet: the server brlcad uses for irc is offline at the moment, what are you looking for help with? |
| 17:20.18 | abhijeet | i was assigned a bug by brlcad |
| 17:20.23 | *** join/#brlcad sofat (~sofat@49.138.153.113) | |
| 17:20.31 | abhijeet | i am not able to reproduce it |
| 17:20.36 | ``Erik | the pixborder issue? |
| 17:20.42 | abhijeet | yes |
| 17:21.21 | ``Erik | um, is there an actual bug in the tracker, or was this just something he threw out? |
| 17:22.36 | abhijeet | it was in the bug files |
| 17:27.17 | ``Erik | hm, when I run that, I get a solid red image |
| 17:27.51 | ``Erik | looks like it should be doing a very naive edge detection |
| 17:29.53 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) | |
| 17:31.20 | *** join/#brlcad ih8sum3r (~ih8sum3r@122.173.187.253) | |
| 17:33.30 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) | |
| 17:33.31 | *** join/#brlcad n_reed (~molto_cre@66-118-151-70.static.sagonet.net) | |
| 17:33.54 | *** join/#brlcad maths22 (~maths22@66-118-151-70.static.sagonet.net) | |
| 17:33.57 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) | |
| 17:34.10 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 17:34.39 | abhijeet | i get the same result .. but whats the problem with that |
| 17:37.29 | ``Erik | I don't know... and the manpage isn't terribly helpful. :/ Sorry, this one might require brlcad, we'll just have to wait until the server he uses is fixed and he happens to be online |
| 17:37.54 | ``Erik | huh, the server just came back on |
| 17:39.20 | abhijeet | the manpage doesnot specify anything about the -b -s options |
| 17:50.15 | ``Erik | hm |
| 17:52.17 | abhijeet | quit |
| 17:52.27 | ``Erik | I have a feeling that the expected result is a pure red image, the 'bug' is that the right edge left the old image, but I'm not seeing that bug happen? |
| 17:52.29 | *** part/#brlcad abhijeet (0e8b5206@gateway/web/freenode/ip.14.139.82.6) | |
| 17:54.36 | vasc | hello guys |
| 18:28.13 | *** join/#brlcad milinda (~milinda@124.43.174.82) | |
| 19:00.39 | *** join/#brlcad Davi (~Davi@101.59.69.83) | |
| 19:02.00 | *** join/#brlcad Davi3 (~Davi@101.59.69.83) | |
| 19:02.54 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 19:06.11 | *** join/#brlcad sofat (~sofat@202.164.45.208) | |
| 19:08.41 | ih8sum3r | brlcad: Hi |
| 19:08.50 | ih8sum3r | I want to discuss about one of the milestone "Upload model without sign in / up". |
| 19:20.15 | *** join/#brlcad LordOfBikes (~armin@dslb-088-065-187-014.088.065.pools.vodafone-ip.de) | |
| 20:09.49 | milinda | Anyone knows which brlcad module I should use to iterate the triangles in a step file ? |
| 20:10.09 | starseeker | milinda: you'll be looking at functionality in libbrep |
| 20:10.51 | starseeker | sorry, looks like librt actually |
| 20:10.53 | starseeker | hmm |
| 20:11.00 | starseeker | oh, right, for the bot structure |
| 20:11.25 | starseeker | look for usages of poly2tri_CDT in primitives/brep/brep.cpp |
| 20:11.42 | milinda | starseeker: Thanks for the reply. :) |
| 20:11.55 | milinda | I will look into that. :) |
| 20:15.27 | sofat | starseeker, hello |
| 20:16.14 | brlcad | ih8sum3r: hi, what's to discuss? |
| 20:16.15 | sofat | I want to know new brlcad code (with my wordpress xsl) how they make the php file and where they store this file ? |
| 20:16.48 | brlcad | sofat: they == you ;) |
| 20:16.59 | sofat | brlcad code |
| 20:17.01 | sofat | ;-) |
| 20:17.11 | sofat | building system |
| 20:17.33 | starseeker | sofat: I thought I mentioned it earlier? |
| 20:18.00 | ih8sum3r | brlcad: Hello, I have a doubt that whether at this stage do we need such functionality? That User upload model without sign in / up. |
| 20:18.03 | sofat | brlcad, i want to discuses something |
| 20:18.22 | ih8sum3r | I have been continuous searching from the last two days and I conclude that most of the softwares like https://sketchfab.com etc. do not use such functionality. They recommend login first and then uploading the model. |
| 20:18.24 | starseeker | sofat: you have to explicitly enable it at CMake configure time |
| 20:18.54 | brlcad | ih8sum3r: I'm fine with you pushing that feature to later, but your reasoning shouldn't be because others don't do that :) |
| 20:18.58 | starseeker | from the command line, it's -DBRLCAD_EXTRADOCS_PHP=ON |
| 20:19.03 | sofat | ok |
| 20:19.11 | sofat | now i got it |
| 20:19.14 | starseeker | it should be a checkbox in cmake-gui |
| 20:19.42 | brlcad | ih8sum3r: groups like sketchfab want/need you register, it's their business model -- they need to be able to reach you for targeted marketing and stats tracking |
| 20:20.56 | brlcad | ditto autodesk, google, etc |
| 20:21.11 | starseeker | makes a note to self to see if the triangulation code can output to an openNURBS mesh so we can make that piece part of the libbrep API, then have an ON_Mesh to bot converter to bring it into librt... |
| 20:21.25 | ih8sum3r | As a user also I feel that there must be a login system only to upload and view and maybe other users also think so ;). Another reason is that it is possible that many of the users using the demo functionality will view their model and leave. |
| 20:22.43 | ih8sum3r | I don't want that our product must be use in such a way. |
| 20:22.52 | brlcad | ih8sum3r: consider something similar like https://www.draw.io |
| 20:23.13 | brlcad | incredibly useful, immediately |
| 20:26.18 | brlcad | it's fine for now, you don't have to worry about it -- I just would hope we avoid writing code that *expects* there to be a logged in user (especially if they're just viewing) |
| 20:28.30 | brlcad | we should be careful to not discriminate against and particular persons or fields of endeavor |
| 20:28.33 | ih8sum3r | I feel that if I implement this I would be an enhancement but I feel if this is done it is possible that users may simply view their models and go :-/. According to me we should first make it production ready as planned and we can implement this in the coming release |
| 20:29.13 | brlcad | I'm okay if they view and go :) ... if we were that useful, they will very likely be back :) |
| 20:29.27 | brlcad | and the next time they're back, they just might try to do more |
| 20:29.47 | brlcad | I could see entire classrooms of kids being told to use our interface to view their models |
| 20:30.02 | brlcad | that would be fantastic, especially as an educational resource |
| 20:31.44 | brlcad | at least in the US and most EU countries, you can't allow a minor to register without taking specific technical steps (e.g., that their parents send a signed approval form that we have to maintain per COPPA regulations) |
| 20:33.55 | ih8sum3r | One thing more in my mind is that if the user logs in we'll get their emails. And through the email we can send notifications to the user and through it we can also promote our product. |
| 20:34.15 | brlcad | absolutely, it's a tradeoff |
| 20:34.24 | brlcad | thats why I said it's fine for starters |
| 20:34.55 | brlcad | but long-term, I wouldn't want to require it ... there are lots of beneficial casual users |
| 20:35.38 | brlcad | especially in academic settings, we could persue grant and other funding opportunities (where registration is incredibly complicated legally speaking) |
| 20:36.28 | brlcad | I could see requiring registration for certain features like exporting their model or high-quality rendering |
| 20:36.41 | brlcad | or editing :) |
| 20:36.53 | brlcad | but even that is up for debate |
| 20:38.23 | sofat | brlcad, I want discuses something with you |
| 20:38.44 | ih8sum3r | So is this an immediate requirement or can be implemented in the next release? If yes, I should start working on it ASAP because I need to look at the backend to for this purpose. |
| 20:45.07 | sofat | I am working on collaboration editing. means how to manage the editing of many user at same time on same file. |
| 20:46.15 | sofat | And I found the solution for this. I am using firepad editor with help i do this work. Firepad is open source editor for collaboration editing. |
| 20:48.57 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) | |
| 20:50.43 | Notify | 03BRL-CAD:starseeker * 65357 brlcad/trunk/CMakeLists.txt: Work on adding more config_win.h tests to the main logic. |
| 20:50.45 | Notify | 03BRL-CAD:bob1961 * 65361 brlcad/branches/eab/src/libged/select.c: Fixed ged_rselect --- dl_select_partial was being called for both cases. Looks like a cut-n-paste related error. This was breaking the non-partial component selection mechanism in Archer. |
| 20:51.00 | Notify | 03BRL-CAD Wiki:117.212.50.111 * 8717 /wiki/User:Gurwinder_Singh/GSoc15/log_developmen: |
| 20:51.03 | Notify | 03BRL-CAD:ejno * 65354 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: handle multiple references within the same tree |
| 20:51.06 | Notify | 03BRL-CAD:starseeker * 65356 (brlcad/trunk/include/raytrace.h brlcad/trunk/include/rt/func.h and 4 others): Couple of librt header reorg fixes. |
| 20:51.08 | Notify | 03BRL-CAD:bob1961 * 65358 brlcad/trunk/src/tclscripts/archer/Archer.tcl: Fixed Archer::compSelectCallback --- don't need to dereference ArcherCore::compSelectCallback. This was breaking the selection mechanism in Archer. |
| 20:51.11 | Notify | 03BRL-CAD:bob1961 * 65360 brlcad/branches/eab/src/tclscripts/archer/Archer.tcl: Fixed Archer::compSelectCallback --- don't need to dereference ArcherCore::compSelectCallback. This was breaking the selection mechanism in Archer. |
| 20:51.16 | Notify | 03BRL-CAD:starseeker * 65352 brlcad/trunk/NEWS: Bob Parker fixed some issues with the grouper command. |
| 20:51.23 | Notify | 03BRL-CAD:bob1961 * 65359 brlcad/trunk/src/libged/select.c: Fixed ged_rselect --- dl_select_partial was being called for both cases. Looks like a cut-n-paste related error. |
| 20:51.25 | Notify | 03BRL-CAD:bob1961 * 65362 brlcad/trunk/src/tclscripts/archer/Archer.tcl: Modified Archer::initCompSelect to not call doSelectGroup when coming out of a binding override. This stops the extra/unwanted "Selection Group" dialog from popping up whenever you release any of the modifier keys. This was happening everywhere and in particular the command window. |
| 20:51.27 | Notify | 03BRL-CAD:bob1961 * 65363 brlcad/branches/eab/src/tclscripts/archer/Archer.tcl: Modified Archer::initCompSelect to not call doSelectGroup when coming out of a binding override. This stops the extra/unwanted "Selection Group" dialog from popping up whenever you release any of the modifier keys. This was happening everywhere and in particular the command window. |
| 20:51.31 | Notify | 03BRL-CAD:ejno * 65353 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: check matrices in find_compsplt() |
| 20:51.33 | Notify | 03BRL-CAD:starseeker * 65355 brlcad/trunk/include/rt/db_internal.h: Add bn/mat.h |
| 20:51.35 | Notify | 03BRL-CAD:ejno * 65364 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: reverse the ordering of IDs within WALL records; write NAME records within SECTION records as expected by fast4-g |
| 20:51.37 | Notify | 03BRL-CAD Wiki:Terry.e.wen * 8718 /wiki/User:Terry.e.wen/log: |
| 20:51.39 | Notify | 03BRL-CAD Wiki:Terry.e.wen * 8719 /wiki/User:Terry.e.wen/log: |
| 20:51.43 | Notify | 03BRL-CAD:starseeker * 65365 brlcad/trunk/src/libgcv/conv/stl/stl_read.c: Hidden becomes static in release builds... |
| 20:51.47 | Notify | 03BRL-CAD:ejno * 65366 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: remove HIDDEN from function used as template parameter |
| 20:55.56 | sofat | brlcad, I have demo if you want to see |
| 21:03.54 | Notify | 03BRL-CAD Wiki:Konrado DJ * 8720 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 17 JUNE 2015 */ |
| 21:12.11 | ih8sum3r | brlcad: Ping :) |
| 21:14.14 | Notify | 03BRL-CAD:n_reed * 65367 brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml: add notes on opennurbs array class usage |
| 21:18.38 | Notify | 03BRL-CAD:starseeker * 65368 (brlcad/trunk/CMakeLists.txt brlcad/trunk/include/common.h brlcad/trunk/include/config_win.h.in): Take a fairly major whack at config_win.h - untested. This will almost certainly break something... |
| 21:19.07 | sofat | brlcad, ping |
| 21:19.14 | sofat | ;-) |
| 21:22.15 | *** join/#brlcad vasc (~vasc@bl13-112-247.dsl.telepac.pt) | |
| 21:25.29 | Notify | 03BRL-CAD:ejno * 65369 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: reverse NAME records and WALL ids |
| 21:26.41 | Notify | 03BRL-CAD:n_reed * 65370 brlcad/branches/brep-debug/doc/docbook/system/CMakeLists.txt: add missed cmake change |
| 21:38.44 | brlcad | ih8sum3r: I think I said thre times that it can be later.... ;) |
| 21:39.10 | brlcad | just don't want it forgottenn/lost/dropped |
| 21:39.15 | brlcad | sofat: sure! |
| 21:39.48 | ih8sum3r | Whoops! I just read previous conversation. Sorry :) |
| 21:40.06 | sofat | http://202.164.53.122/wordpress/ace.php?article=123articles123en123about.xml#d2eabade685bb63a9b4d2091c498b06c |
| 21:40.35 | brlcad | "it's fine for now, you don't have to worry about it" ;) |
| 21:40.36 | ih8sum3r | Yes I'll keep this thing in my mind and will definitely implement it. |
| 21:41.55 | vasc | hmmm.... so where was rt building the acceleration structure again... |
| 21:46.10 | ih8sum3r | brlcad: Me and shubham want to make little discussion so can you tell the time when are free so we three can interact with each other. |
| 21:46.38 | ih8sum3r | s / are free / are you free |
| 21:48.58 | vasc | ah ok rt_prep_parallel -> rt_cut_it |
| 21:48.59 | vasc | sheesh |
| 21:51.58 | vasc | oh i see and the ray shooting callback can call the acceleration structure construction code |
| 21:52.12 | vasc | interesting |
| 22:13.50 | brlcad | ih8sum3r: probably this friday |
| 22:14.22 | ih8sum3r | okay timings UTC 5:00 P.M or else :) |
| 22:14.48 | brlcad | ~convert 1700 utc to edt |
| 22:14.57 | brlcad | ~convert 1700 gmt to edt |
| 22:15.03 | brlcad | ugh |
| 22:15.36 | brlcad | yeah, that will probably work |
| 22:16.07 | ih8sum3r | Okay sure see you on friday :) Good night. |
| 22:16.30 | brlcad | vasc: it's also worth pointing out that some work that one traditionally would be considered "raytrace prep" happens during rt_dirbuild() prior to rt_prep_parallel() |
| 22:17.10 | vasc | i was a bit confused when i looked there too. thx for the heads up. |
| 22:17.13 | brlcad | all the individual rt_OBJ_prep() functions, for example, are called during the directory build |
| 22:17.16 | vasc | it seemed to be building some trees or whatever. |
| 22:18.09 | vasc | i am just trying to integrate some grid construction code and was trying to figure out exactly where to interface |
| 22:18.32 | brlcad | rt_prep* is just the spatial partitioning build, relies on the directory having been computed beforehand |
| 22:19.09 | brlcad | the individual rt_OBJ_prep() functions are where individual objects calculate their boudning volumes (which is later used by rt_prep in the partitioning) |
| 22:19.29 | vasc | yeah the object bounding boxes are pre-computed |
| 22:19.49 | brlcad | bounding spheres and boxes |
| 22:19.58 | vasc | spheres too? hm |
| 22:19.59 | brlcad | don't recall if we actually use both |
| 22:20.29 | brlcad | definitely don't calculate both for all entity types (can always fit a sphere around the bb and vice versa...) |
| 22:20.38 | Notify | 03BRL-CAD:n_reed * 65371 brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml: add notes on point classes |
| 22:21.33 | vasc | yeah its just a matter of how tight the fit is |
| 22:50.34 | vasc | ok i think i have some C code that should build a grid |
| 22:50.37 | vasc | now to integrate it |
| 22:56.15 | vasc | ah jeez |
| 22:59.58 | vasc | nothing can be easy uh |
| 23:00.42 | vasc | i'll just copy this incantation then |
| 23:01.32 | vasc | well it compiles at least |
| 23:02.18 | vasc | and if doesn't crash |
| 23:03.45 | vasc | well i assume its building the grid correctly |
| 23:03.59 | vasc | of course it isn't USING it during rendering but that's something for tomorrow i guess |
| 23:05.15 | vasc | this also needs to be better encapsulated |
| 23:06.57 | vasc | i'll make a ticket for this |
| 23:07.14 | vasc | but its still WIP |
| 23:07.30 | vasc | and its a prototype that will eventually get converted into OpenCL but gotta start with something |
| 23:12.05 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 23:13.22 | vasc | ok made ticket and put patch in it |
| 23:15.10 | vasc | right there is a bounding sphere |
| 23:15.14 | vasc | and its actually important |
| 23:24.58 | Notify | 03BRL-CAD Wiki:85.246.112.247 * 8721 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |
| 23:27.44 | Notify | 03BRL-CAD Wiki:Andrei.ilinca24 * 8722 /wiki/User:Andrei.ilinca24/logs: /* Coding Period */ |
| 23:28.47 | Notify | 03BRL-CAD Wiki:85.246.112.247 * 8723 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |
| 23:29.44 | Notify | 03BRL-CAD:n_reed * 65372 brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml: add notes on domain intervals |
| 23:34.49 | Notify | 03BRL-CAD Wiki:85.246.112.247 * 8724 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |
| 23:35.38 | Notify | 03BRL-CAD Wiki:85.246.112.247 * 8725 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |
| 23:36.46 | Notify | 03BRL-CAD Wiki:85.246.112.247 * 8726 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |
| 23:37.19 | vasc | hm ok |
| 23:37.34 | vasc | updated dev diary |
| 23:38.36 | Notify | 03BRL-CAD Wiki:85.246.112.247 * 8727 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |
| 23:41.20 | Notify | 03BRL-CAD:starseeker * 65373 (brlcad/trunk/CMakeLists.txt brlcad/trunk/include/config_win.h.in): Erm. Adding Za seems to cause build trouble - even the BUILD_SLEEP try_compile fails. Needs further investigation. |
| 23:52.24 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |