| 00:03.06 | Notify | 03BRL-CAD:n_reed * 59502 brlcad/trunk/src/libbrep/boolean.cpp: have a couple functions explicitly return their result instead of modifying an argument for readability |
| 01:18.33 | *** join/#brlcad gcibot (~gcibot@unaffiliated/ignaciouy/bot/gcibot) | |
| 01:18.52 | *** join/#brlcad gcibot (~gcibot@unaffiliated/ignaciouy/bot/gcibot) | |
| 01:19.03 | *** join/#brlcad gcibot (~gcibot@unaffiliated/ignaciouy/bot/gcibot) | |
| 01:21.29 | *** join/#brlcad gcibot (~gcibot@unaffiliated/ignaciouy/bot/gcibot) | |
| 05:45.53 | *** join/#brlcad KimK (~Kim__@ip24-255-223-153.ks.ks.cox.net) | |
| 08:46.24 | *** join/#brlcad caen23 (~caen23@92.81.162.63) | |
| 08:50.13 | *** join/#brlcad luca79 (~luca@net-188-216-237-187.cust.dsl.vodafone.it) | |
| 09:03.41 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) | |
| 09:27.04 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 09:28.22 | d_rossberg | i'm currently working on the msvc build; it's broken - will need some time ... |
| 10:19.59 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) | |
| 13:41.42 | *** join/#brlcad deepak (~chatzilla@117.220.147.205) | |
| 14:00.38 | *** join/#brlcad Izak_ (~Izak@66-118-151-70.static.sagonet.net) | |
| 14:33.54 | Notify | 03BRL-CAD Wiki:Donaldpennino * 0 /wiki/User:Donaldpennino: |
| 14:39.35 | Notify | 03BRL-CAD:d_rossberg * 59503 (brlcad/trunk/include/bio.h brlcad/trunk/src/bwish/winMain.c): reverting changes from revision 59482 (and 59483): It isn't possible to include other Windows API headers after bio.h because important macros from windows.h are undefined here. E.g. winsock2.h requires the "IN" macro. If this header file will be included after bio.h (with WIN32_LEAN_AND_MEAN) it doesn't process windows.h |
| 14:39.37 | Notify | again and assumes the presence of IN. |
| 14:42.23 | Notify | 03BRL-CAD:d_rossberg * 59504 brlcad/trunk/src/other/openNURBS/opennurbs_system.h: the min and max macros from windows.h are conflicting with std::min and std::max, we don't need these macros anyway |
| 14:46.04 | Notify | 03BRL-CAD:d_rossberg * 59505 brlcad/trunk/include/brep.h: we need BRNode and BBNode in librt, therefore added the export declaration for Windows libbrep DLL |
| 14:50.02 | Notify | 03BRL-CAD:d_rossberg * 59506 brlcad/trunk/include/libtermio.h: moved the comma to get a valid function declaration in case of non of the tested flags is present (e.g. in case of a MSVC compiler) |
| 15:03.34 | Notify | 03BRL-CAD:carlmoore * 59507 brlcad/trunk/src/libbrep/boolean.cpp: remove trailing blanks/tabs |
| 15:10.12 | brlcad | d_rossberg: I hope to one day stop causing you problems like that |
| 15:10.37 | brlcad | I honestly did think it a benign change and bwish compilation testing seemed to work fine |
| 15:13.27 | brlcad | aside: full windows build takes ... way too long |
| 15:14.09 | brlcad | but regardless, thanks for fixin git |
| 15:14.14 | d_rossberg | brlcad: no problem, this wasn't as hard as feared |
| 15:14.41 | d_rossberg | the sources now compile with MSVC |
| 15:15.10 | d_rossberg | however, the programs are crashing |
| 15:15.20 | d_rossberg | i'm checking it now |
| 15:16.23 | d_rossberg | i made the remark today morning to signal that somebody is already working on it |
| 15:24.54 | d_rossberg | btw, it's alarming how spreaded the windows.h is |
| 15:30.43 | Notify | 03BRL-CAD:starseeker * 59508 brlcad/trunk/src/conv/step/CMakeLists.txt: Add a couple of generated headers that had been missing from the express output list, and instruct make clean to clear the generated output files. It may be that those headers being missing from the output list accounts for some of the parallel build issues that have been reported with the step tools, if the build wasn't waiting for those |
| 15:30.45 | Notify | headers to finish generating... |
| 15:59.31 | brlcad | spreaded? |
| 15:59.50 | brlcad | you mean how many concepts it covers, or how many files that use it? |
| 16:01.36 | d_rossberg | sorry, "how many files that use it" |
| 16:03.36 | d_rossberg | the whole brep stuff is windows.h contaminated |
| 16:04.26 | brlcad | starseeker: cool fix, hopefully that was the issue |
| 16:04.48 | brlcad | brep stuff has windows.h?? that doesn't make much sense.. |
| 16:05.56 | d_rossberg | brep.h includes opennurbs.h includes opennurbs_system.h includes windows.h |
| 16:06.07 | brlcad | ahhhh |
| 16:06.33 | brlcad | do they actually need it? |
| 16:06.51 | brlcad | probably a nightmare to untangle |
| 16:11.00 | d_rossberg | just looked at opennurbs_system.h: there is a ON_NO_WINDOWS flag/define to exclude the inclusion of windows.h |
| 16:14.18 | Notify | 03BRL-CAD:brlcad * 59509 (brlcad/trunk/include/libtermio.h brlcad/trunk/src/libtermio/termio.c): functions should have a consistent signature count regardless of platform, add the missing else case as a void pointer |
| 16:15.52 | d_rossberg | however, i've a more serious problem with CLEAR_BUILD_FLAGS() at the moment |
| 16:16.18 | Notify | 03BRL-CAD:brlcad * 59510 brlcad/trunk/src/libtermio/CMakeLists.txt: looks like the termio_win32.c abomination is no longer necessary, nix it |
| 16:17.47 | brlcad | d_rossberg: what sort of problem? we've done several windows builds since making that change (which fixed other build issues) |
| 16:18.32 | brlcad | missing some windows-specific flag for the version you're using that we're not? |
| 16:20.47 | d_rossberg | at first glance: the programs are crashing (e.g. asc2g) and i can't get a debug build; i could fix the issues simply by removing CLEAR_BUILD_FLAGS() |
| 16:21.44 | d_rossberg | additionally, CLEAR_BUILD_FLAGS() contradict the philosophy of cmake |
| 16:22.15 | d_rossberg | cmake know what the different compiler need |
| 16:26.19 | d_rossberg | i could adjust the compiler flags for msvc 2008 in our cmake config files, but are the valid for the other msvc versions too? |
| 16:27.41 | d_rossberg | i expect the cmake people to have more experience there than myself |
| 16:28.21 | starseeker | I don't think we are setting many build flags (any?) for Windows at the moment, so it may be appropriate to not clear the flags in src/other (whose builds are also highly unlikely to do Windows specific stuff...) |
| 16:29.00 | starseeker | d_rossberg: generally speaking, our build flag settings are a lot more tuned for our needs than the default CMake choices - Windows is the main exception |
| 16:32.03 | d_rossberg | starseeker: this would be my approach too: tune the flags where i know whot i'm doing and hope that the defaults will somehow work for the others |
| 16:34.24 | Notify | 03BRL-CAD:starseeker * 59511 brlcad/trunk/misc/CMake/CompilerFlags.cmake: The src/other builds currently rely on CMake to set MSVC compilation flags (so does BRL-CAD, for that matter) so we can't afford to wipe them clean when doing a MSVC build. |
| 16:35.35 | starseeker | probably what we *should* be doing in CLEAR_BUILD_FLAGS is restoring the original CMake defaults, since that's what the src/other CMake builds had reason to expect would be present originally |
| 16:39.38 | d_rossberg | aha, ok, i'll test it on monday |
| 16:40.26 | starseeker | problem is the "defaults" may not be set where we can easily get at them... |
| 17:39.22 | Notify | 03BRL-CAD:carlmoore * 59512 brlcad/trunk/src/sig/istats.c: add ? as a valid option, and remove the 2 'case' statements because they will default anyway |
| 18:00.14 | brlcad | do we know what the defaults are on windows? |
| 18:01.09 | brlcad | clearing the "user-flags" made sense, perhaps the problem is also clearing the configuration type flags (which doesn't make as much sense to me) |
| 18:01.50 | brlcad | I don't think it really contradicts the philosophy at all, it's just a different requirement that they don't attempt to address |
| 18:02.46 | brlcad | two questions that should be asked are 1) why are we clearing the flags and 2) what are the flags if we don't clear them |
| 18:04.00 | brlcad | the answer to #1, iirc, is that there are optimization and debugging settings in the default that should not be set given we have specific flags to turn optimization and debugging on/off (assuming we want those flags to work right) |
| 18:04.30 | brlcad | if that's not the case, then perhaps we can unset them |
| 18:16.30 | starseeker | As I recall, CMake (on Linux, at least) defaults some optimization and debugging compiler flags when Debug and Release are set that aren't necessarily what we want. Hence, we just scrub all of theirs away and replace them with our own (considerably more elaborate) setup |
| 18:17.38 | starseeker | We have a lot of compiler flag mojo for the Unix side that's largely inherited from the autotools system |
| 18:18.18 | starseeker | Definitely not the case on Windows |
| 18:22.12 | starseeker | We are also fortunate in that most of the src/other builds either don't need a lot of flags on Unix systems or provide detection and setup for what they do need |
| 18:23.22 | starseeker | One thing I'm not sure of is whether (for example) openNURBS is actually being built with optimization flags in a Release build after we wipe the flags with our macro |
| 18:26.47 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 18:27.30 | brlcad | why wouldn't it if it's set in the various FLAGS ? |
| 18:27.43 | brlcad | because it's a subbuild with its own tests or something? |
| 18:27.57 | starseeker | right |
| 18:28.13 | starseeker | we're clearing ALL flags provided by either us or CMake at the top of src/other |
| 18:28.33 | brlcad | but those tests would be running anyways, so at best it would be appending -O2 after -O3 or somesuch |
| 18:28.35 | starseeker | that means it's entirely up to the individual src/other builds whether they get any flags |
| 18:29.09 | starseeker | I just checked, and openNURBS isn't setting its own optimization flag |
| 18:29.11 | brlcad | src/other is processed in step 9, so aren't the flags that'll be used for our sources not already set by then? |
| 18:29.22 | starseeker | for OUR sources, yes |
| 18:29.33 | starseeker | but we deliberately wipe the slate clean for src/other |
| 18:29.39 | brlcad | you mean again? |
| 18:29.46 | starseeker | right |
| 18:29.57 | starseeker | you didn't want BRL-CAD's build flags getting passed to the src/other builds |
| 18:30.43 | starseeker | I was originally passing some but not all of our build flags down, but we restructured to avoid that |
| 18:30.44 | brlcad | was there a specific case? |
| 18:30.54 | brlcad | I think you're putting words in my mouth there ;) |
| 18:31.03 | brlcad | I vaguely recall saying it should be all or none |
| 18:31.09 | starseeker | goes hunting |
| 18:31.43 | brlcad | the conformance flags |
| 18:31.58 | brlcad | that's undoubtedly why passing none was chosen |
| 18:32.12 | brlcad | we can't compile src/other with -std=whatever |
| 18:32.35 | starseeker | sure |
| 18:32.48 | starseeker | but we DO (I assume) want -O3 to propagate downward? |
| 18:33.21 | brlcad | that's a good question |
| 18:33.36 | starseeker | because most of the subbuilds will NOT set it on their own |
| 18:33.41 | brlcad | sure |
| 18:34.10 | brlcad | I guess it really depends if compliance flags are the only ones that cause an issue |
| 18:34.21 | brlcad | ponders whether any others might |
| 18:34.59 | starseeker | would tend to expect that a Release built BRL-CAD that has an unoptimized openNURBS build would tend to violate the principle of least surprise |
| 18:35.21 | brlcad | meh, perhaps |
| 18:35.36 | brlcad | I see those settings as only talking about our sources |
| 18:35.43 | brlcad | src/other is effectively undefined |
| 18:35.48 | starseeker | wines |
| 18:35.51 | starseeker | winces rather |
| 18:35.59 | brlcad | well, consider a system installed lib |
| 18:36.04 | brlcad | we have no idea how it was compiled |
| 18:36.11 | starseeker | I don't know what an unoptimized openNURBS will do for NURBS raytracing time, but I don't expect it to be good |
| 18:36.27 | brlcad | you wouldn't halt the build because it's using an unoptimized system opennurbs (if it could) because we're building optimized |
| 18:36.44 | starseeker | might warn about it though |
| 18:36.48 | brlcad | remember that src/other is ONLY for download/compilation convenience |
| 18:37.08 | brlcad | in the usual practice, src/other does not exist and we tell them to go get it |
| 18:37.23 | starseeker | that's like checking to see how BLAS/LAPACK support performs on a system - your software may not manage it directly, but you'll get blamed for slow performance if it isn't good enough |
| 18:37.25 | brlcad | so I have no problem with it being "undefined" (meaning we define it to be whatever the heck we want) |
| 18:37.57 | brlcad | but you have no way of knowing that |
| 18:38.22 | brlcad | at least no reliable way, especially no portable way |
| 18:39.15 | brlcad | it's simply not our problem to guarantee anything about src/other other than we will make it compile and use it if needed/requested |
| 18:39.15 | starseeker | OK, but for something we *do* control - src/other - my expectation as a user would be that if I built Release, *everything* I built as part of that build would be fast |
| 18:40.16 | brlcad | would your expectation be that if we wrote down "THERE IS NO GUARANTEE ABOUT SRC/OTHER"? |
| 18:40.25 | brlcad | if it is, then the problem is you ;) |
| 18:40.45 | brlcad | not saying we don't make it match |
| 18:40.47 | starseeker | I guess the *clean* way to deal with this is to package up our compile flag management logic into some clean CMake packages/macros so the src/other builds can independently do the "right" thing based on build type... |
| 18:40.59 | brlcad | saying we don't make that a promise we're not willing to break |
| 18:41.20 | starseeker | OK, fair enough |
| 18:41.29 | brlcad | which contract-wise means from a user compiling the package's perspective, it's undefined -- if they want to define it, then they can compile it themselves |
| 18:41.46 | starseeker | but whether or not we guarantee it it darn well *should* act that way by default |
| 18:41.55 | brlcad | we might make that easy for them, but they can't come crying when we eventually do change something |
| 18:44.04 | brlcad | no problems here with that, just hopefully not complicated or time-consuming to do it right? |
| 18:44.24 | brlcad | src/other just needs to be low-maintenance and work "most of the time" with minimal fuss |
| 18:45.03 | starseeker | ironically, that was why we originally just used a subset of our own flags (sans warnings, etc.) and passed 'em on to src/other |
| 18:45.05 | brlcad | if I can't debug into Tcl_Eval() because it's a pita to propagate whatever debug flags needed, meh so be it .. if I can, great |
| 18:45.47 | brlcad | that's another good point though, warning flags |
| 18:45.51 | starseeker | that was the original distinction between Compiler_Flags and BRLCAD_CompilerFlags |
| 18:47.04 | brlcad | nods |
| 18:47.36 | brlcad | it's a necessary distinction I think |
| 18:47.57 | brlcad | answers "what is the compiler capable of" and "what do we want the compiler to do" |
| 18:48.08 | starseeker | without that, it's either a) wrap what was that original subset into a friendly macro package I can stuff into the src/other CMake logic on a per-project basis, or just do the same thing once at the top of src/other in addition to clearing the flags |
| 18:48.50 | starseeker | that might actually be a reasonable way to go |
| 18:48.52 | brlcad | the subset seems overly messy to me, maintenance burden over time |
| 18:49.01 | brlcad | flags change, compilers change |
| 18:49.34 | brlcad | really don't want to keep hitting something up every time we encounter a new environment or one changes |
| 18:49.44 | starseeker | sure. That's why I think the right way would be, after calling the clear flags macro at the top of src/other, use the variables we've set for a few of the common flags (like optimization) |
| 18:49.55 | brlcad | that's why the original notion was "all or nothing" |
| 18:50.32 | brlcad | perhaps we can change the definition of "all", so the flags don't need to get unset |
| 18:50.40 | starseeker | except we can do that with all the warning flags we use - so we *have* to do a subset unless we truly do go with bare bones and default to unopimized openNURBS et al |
| 18:50.57 | starseeker | s/can/can't/ |
| 18:51.43 | brlcad | only problem is that almost certainly doesn't fix the error daniel ran into |
| 18:52.12 | starseeker | yeah, Windows is a different kettle of fish because we don't have a replacement CompilerFlags infrastructure for MSVC |
| 18:52.14 | brlcad | his issue was almost certainly a linker flag missing |
| 18:52.22 | starseeker | it's either what CMake gives us, or nothing |
| 18:52.46 | brlcad | more options than that |
| 18:53.04 | starseeker | not without a lot of work on our part to do for MSVC what we are doing for gcc/clang |
| 18:53.37 | brlcad | maybe, maybe not |
| 18:53.46 | brlcad | don't know what the error actually was |
| 18:54.33 | brlcad | to replicate all the existing tests, sure, but who's to say that's necessary? I certainly doubt it |
| 18:54.38 | starseeker | regardless though - the way things are now, we either keep what CMake gives us or we have to totally replace it |
| 18:54.39 | brlcad | probably just a flag or two |
| 18:55.15 | brlcad | there's actually a flag that causes exactly what he described when you don't set it right, but the name escapes me right now |
| 18:55.46 | brlcad | if I had a windows box handy, that'd be resolved quickly |
| 18:56.21 | starseeker | but what about all the other flags? I.e., if Debug is set, CMake probably provides some appropriate MSVC options |
| 18:56.22 | brlcad | but yeah, state of affairs now is probably to keep what cmake set |
| 18:57.02 | brlcad | thinking of a platform-agnostic solution, what about capturing the values before we wipe them out? |
| 18:57.15 | brlcad | then they could be unset, set for src/other, and re-set |
| 18:57.21 | starseeker | maybe |
| 18:57.22 | brlcad | re-unset rather |
| 18:57.41 | starseeker | isn't sure when/how to capture the original values - couple of quick tests this morning didn't show them where I needed them |
| 18:57.55 | starseeker | if we can figure that out, that's probably a reasonable middle ground |
| 18:57.56 | brlcad | right before the CLEAR macro, no? |
| 18:58.22 | brlcad | this would all be in the top-level cmake |
| 18:58.27 | brlcad | the src/other CLEAR goes away |
| 18:58.28 | starseeker | doesn't seem to be - when I try to print them out after CMAKE_BUILD_TYPE is set but before we get to our logic, they seem to be empty |
| 18:59.06 | brlcad | that doesn't make sense to me |
| 18:59.10 | starseeker | to me either |
| 18:59.14 | brlcad | if they're not set, then the CLEAR macro is doing nothing |
| 18:59.30 | brlcad | the macro is clearly (heh) doing something |
| 19:00.06 | starseeker | right - I was trying to get a handle on when CMake populates those variables when left to itself |
| 19:00.27 | starseeker | if we like the idea of restoring the CMake defaults for src/other, I can dig into it further |
| 19:00.54 | brlcad | are you saying if you print them out right before the clear macro in the top-level CMakeLists.txt file, they're all empty? |
| 19:01.03 | starseeker | that's what I was seeing, yes |
| 19:01.45 | brlcad | you sure you were printing in the right place, no typos? that's really bizarre.... |
| 19:01.56 | starseeker | I'll try it again |
| 19:03.32 | starseeker | Ah - the _DEBUG and _RELEASE versions of the variables have something |
| 19:04.49 | brlcad | *whew* |
| 19:04.54 | brlcad | mind was exploding |
| 19:05.30 | starseeker | heh - I see why CMake organizes their variables the way they do, but it does make life compliated when overriding their defaults |
| 19:06.48 | starseeker | let me see if I can cache them up front and then restore them for src/other |
| 19:09.34 | brlcad | they're actually sort of doing things the Apple-way |
| 19:09.42 | brlcad | it's a knob with five settings |
| 19:09.46 | starseeker | I suppose part of the problem for me is that I do see src/other as more than just a download convenience |
| 19:10.11 | brlcad | instead of a panel with 4 switches and 4!=24 configuration options |
| 19:10.36 | starseeker | If a feature of ours needs some properly optimized compile of something to work as it should, then I want to make sure we provide a guaranteed way to achieve that result |
| 19:10.48 | brlcad | download and compilation+installation |
| 19:10.52 | brlcad | "it just works" |
| 19:11.03 | brlcad | but that still doesn't mean or imply much else... |
| 19:11.11 | starseeker | sure - but I guess I have a rather strong definition of "works" |
| 19:11.16 | brlcad | nods |
| 19:12.41 | starseeker | grunts in disgust - time to add a proper debug printing macro for compiler flags, it takes too much time to re-create ad-hoc as needed over and over... |
| 19:12.57 | brlcad | I certainly don't disagree and have similar "wants" but that desire also directly conflicts with an incurred maintenance cost |
| 19:13.12 | brlcad | time-wise, it becomes harder to justify the more complicated src/other becomes |
| 19:13.42 | starseeker | Well, if/when we ever get ourselves weaned off of Tk src/other simplifies a lot :-) |
| 19:13.55 | brlcad | riight |
| 19:14.04 | brlcad | one dir out of 20 |
| 19:14.10 | brlcad | and it's replaced with a monster :) |
| 19:14.17 | brlcad | (relatively speaking) |
| 19:14.37 | starseeker | 7 directories actually |
| 19:14.44 | brlcad | a beautiful and capable one, but monster nonetheless |
| 19:15.20 | brlcad | okay, if we're going to get specific, it's 7 .. out of 27 |
| 19:15.49 | brlcad | so still 20 others, plus the gimp |
| 19:16.56 | starseeker | given a lot of cleanup work, it should be possible to get rid of boost, libgdiam, libtermlib, tnt and maybe a couple others |
| 19:17.14 | kanzure | hooray for dumping tcl.h |
| 19:17.15 | brlcad | i count 8: hv3, itcl, itk, iwidgets, tk, tkhtml, tkpng, tktable |
| 19:17.23 | brlcad | kanzure: tk.h, not tcl.h ;) |
| 19:17.57 | brlcad | tnt should be first on the list |
| 19:17.57 | starseeker | perplex and dom2dox are our tools - if we wanted to, they could be moved out of src/other |
| 19:18.06 | brlcad | right |
| 19:18.33 | starseeker | I suspect libgdiam could be reimplemented in libbn, particularly with the new convex hull routines |
| 19:18.40 | brlcad | boost is somewhat controversial, termlib is somewhat complicated, gdiam.. probably easy |
| 19:19.05 | brlcad | that was your relatively recent addition anyways, yes? |
| 19:19.10 | starseeker | yes |
| 19:19.22 | starseeker | weekend hack for oriented bounding boxes |
| 19:19.24 | brlcad | that was the oobbox lib, right? |
| 19:20.01 | brlcad | if you got a better way, we still need oobb |
| 19:20.07 | starseeker | libvds arguably didn't pan out - could yank the bits using it... |
| 19:20.11 | brlcad | I'd found a user for it the day you stopped working on it :) |
| 19:20.22 | starseeker | brlcad: not so much a better way as a more robust implementation |
| 19:20.43 | brlcad | more robust != better?? |
| 19:20.47 | brlcad | :) |
| 19:20.53 | starseeker | but I would need to fully reimplment it to put it in our code, since we've been avoiding adding externally licensed LGPL code directly to our repo |
| 19:21.19 | starseeker | er, sorry - meant same basic algorithm but better handling of corner cases |
| 19:21.20 | brlcad | ahh, yeah |
| 19:21.44 | starseeker | that means translating academic paper mathematical goo into code, always a trip |
| 19:22.14 | brlcad | at some point, we need to pick and start using a new license |
| 19:22.36 | brlcad | the longer we wait, the harder it will only get |
| 19:23.01 | starseeker | nods |
| 19:23.31 | starseeker | hmm, what's in osl? |
| 19:23.37 | starseeker | ah, shaders |
| 19:23.42 | starseeker | is that where those should live? |
| 19:24.51 | *** join/#brlcad vajra (cb6ef315@gateway/web/freenode/ip.203.110.243.21) | |
| 19:25.01 | brlcad | they're technically code and data |
| 19:25.17 | brlcad | moreso code |
| 19:25.28 | brlcad | just not C/C++ |
| 19:25.59 | brlcad | I'd love to see someone take that up for GSoC again |
| 19:26.10 | starseeker | clipper is one that in principle we could borg into libbn - license is OK iirc, but would need to re-implement or maybe wrap in libbn style API |
| 19:26.12 | brlcad | I think with the right person, that would be phenomenal |
| 19:26.21 | starseeker | agrees wholeheartedly |
| 19:27.53 | starseeker | would probably be worth doing - that polygon boolean logic has all kinds of potential uses |
| 19:28.17 | starseeker | main problem is it would introduce a C++ code bit into libbn |
| 19:29.17 | starseeker | similar situation with poly2tri |
| 19:30.14 | *** join/#brlcad deepak (~chatzilla@117.220.147.205) | |
| 19:30.23 | starseeker | I think I only stuck sqlite in there to support the full-up hv3 browser - if we don't end up using that for a more powerful Archer help browser, that can probably go |
| 19:32.21 | starseeker | so theoretically, if we somehow did everything, moved everything, and rewrote everything we might practically be able to rewrite we could get down to around a dozen directories in src/other |
| 19:36.03 | starseeker | if we opted to do something different with libutahrle/URToolkit maybe could remove those - put the key bits into libicv directly? |
| 19:36.20 | starseeker | knows there's history there... |
| 19:37.27 | starseeker | need to revisit the tclap work too - that's why src/other/tclap is present, but IIRC we aren't there yet for using the libbu API.. |
| 19:37.48 | brlcad | c++ code behind the API is fine, just not public |
| 19:38.11 | starseeker | nods - just reflecting that it's unused code until we get that libbu API straightend out |
| 19:38.36 | brlcad | with C and C++ both revitalized, I'm no longer nearly as hesitant to leverage it more .. but our APIs still need to be procedural or OO, not some crazy mix |
| 19:40.17 | starseeker | clipper would probably be a fairly straightforward proposition - poly2tri doesn't behave all that well as a lib (they like to exit on failure - urk) so it would need some work (does need some work actually - it will crash us even now trying to show bad NURBS breps...) |
| 19:40.19 | brlcad | still isn't ready to let urtoolkit go, too many useful utilities that will be useful as plugins to our next gen system |
| 19:40.39 | brlcad | rle is definitely a good format for icv to support |
| 19:41.39 | *** join/#brlcad deepak (~chatzilla@117.220.147.205) | |
| 19:42.25 | starseeker | brlcad: is this the primary page for the OSL work? http://brlcad.org/wiki/User:Kunigami/GSoc2011/Reports |
| 19:44.22 | starseeker | is torn - could try to get the old work up and running again to set the stage for the next chapter, but that might be a good task for someone interested in working with it to get their feet wet... |
| 19:44.32 | Notify | 03BRL-CAD:carlmoore * 59513 brlcad/trunk/src/sig/istats.c: move initializations into the type declarations, and eliminate initializing stdev, because we don't care about previous stdev value |
| 19:45.27 | brlcad | starseeker: someone has to know where the water is |
| 19:45.59 | starseeker | ? |
| 19:45.59 | deepak | Brlcad: I'm feeling odd to ask these questions to you, but I think only you can correct me. I made a script for OGV can we add it in our OGV source code? Can we consider that code as patch? |
| 19:46.05 | brlcad | I'm hoping to highlight six or so tasks as "priority" |
| 19:46.15 | brlcad | starseeker: getting feed wet ;) |
| 19:46.28 | starseeker | ah :-) |
| 19:46.48 | starseeker | brlcad: is the bullet work another of the priorites? |
| 19:47.20 | brlcad | deepak: it could technically be considered a patch, but it's a somewhat weak one |
| 19:47.47 | brlcad | the intention of submitting patches is usually to demonstrate capacity for reading and modifying existing code, not for writing new code |
| 19:48.00 | brlcad | if you can't write code, you probably can't read it |
| 19:48.13 | brlcad | plenty of people can write but cannot read code |
| 19:48.24 | brlcad | the point is to demonstrate capacity at both reading and writing |
| 19:48.57 | brlcad | assuming this would be for GSoC (??), of course, if not for GSoC then by all means submit it for inclusion regardless |
| 19:54.49 | deepak | Brlcad: I posted mail on this at brlcad-develope mailing list. After getting 2-3 replies on it no one replied, So I though there would be no use of that script :). |
| 19:56.36 | brlcad | deepak: everyone is just rather busy, it says nothing of your script's utility |
| 20:00.11 | Notify | 03BRL-CAD:starseeker * 59514 brlcad/trunk/misc/CMake/CompilerFlags.cmake: Add debugging function to print all build flags |
| 20:00.35 | deepak | Brlcad: Thanks for clarification, you released me from big burden :). For patch submission I need to modify existing code, something like refactoring code? |
| 20:00.36 | Notify | 03BRL-CAD:starseeker * 59515 brlcad/trunk/misc/CMake/CompilerFlags.cmake: function, not macro |
| 20:04.38 | starseeker | realizes caching the original CMake values for variables is a bit tricky, given the cache and repeat runs... hmm |
| 20:11.22 | Notify | 03BRL-CAD:carlmoore * 59516 brlcad/trunk/src/sig/istats.c: use SHRT_MAX , SHRT_MIN; do the squaring in double mode; don't need to initialize count to 0 |
| 20:28.07 | Notify | 03BRL-CAD:starseeker * 59517 (brlcad/trunk/CMakeLists.txt brlcad/trunk/misc/CMake/CompilerFlags.cmake brlcad/trunk/src/other/CMakeLists.txt): Cache the original CMake supplied compiler flags, and restore them for src/other builds. |
| 20:29.14 | starseeker | r59519 will require clearing the build directory, but after that it should work |
| 20:29.21 | starseeker | r59517 rather |
| 20:31.43 | *** join/#brlcad KimK (~Kim__@ip24-255-223-153.ks.ks.cox.net) | |
| 20:32.49 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 20:41.28 | ``Erik | out of curiousity, would moving src/other out of src/ make things significantly easier/cleaner from a cmake position? |
| 20:42.28 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 20:43.29 | Notify | 03BRL-CAD:starseeker * 59518 (brlcad/trunk/doc/CMakeLists.txt brlcad/trunk/regress/step/CMakeLists.txt brlcad/trunk/src/conv/step/g-ap214/CMakeLists.txt): Various cleanup for distcheck |
| 20:44.24 | Notify | 03BRL-CAD:starseeker * 59519 brlcad/trunk/regress/step/CMakeLists.txt: Don't forget the underscores |
| 20:45.39 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) | |
| 20:47.30 | starseeker | ``Erik: not really |
| 20:48.53 | starseeker | ``Erik: it's actually in pretty good shape, in that sense - the debate is more about what *should* we be sharing between our build flags and our src/other stuff |
| 20:52.47 | starseeker | debugging and optimization flags are probably the tricky points - most people would agree that we don't want to pass on the stricter warning flags |
| 20:53.29 | starseeker | but if I'm supplying debugging flags to allow for easier debugging of our code, in principle the same argument would apply if I have to follow something down into src/other |
| 20:53.47 | starseeker | but that means passing some but not all of our flags, which is a maintenance overhead |
| 20:54.00 | starseeker | so, pick your poison |
| 21:08.47 | Notify | 03BRL-CAD:carlmoore * 59520 brlcad/trunk/src/sig/istats.c: changes I made to more closely resemble ustats.c |
| 21:16.56 | Notify | 03BRL-CAD:carlmoore * 59521 brlcad/trunk/src/sig/ustats.c: revised ustats to look like istats.c |
| 21:23.37 | Notify | 03BRL-CAD:starseeker * 59522 brlcad/trunk/regress/step/CMakeLists.txt: Don't use the same filename for the src and working copies of the script - in-src-dir doesn't like it. |
| 21:29.18 | Notify | 03BRL-CAD:carlmoore * 59523 brlcad/trunk/src/sig/dstats.c: move initializing into type statements, but notice I can't do that for min,max |
| 21:29.58 | ``Erik | aight, was only half following and felt like it might be a useful question *shrug* :) |
| 21:30.12 | starseeker | ``Erik: no problem :-) |
| 21:30.40 | starseeker | ``Erik: what's up these days, any cool projects in the works? |
| 21:32.08 | ``Erik | snow snow and more snow, around 8.5 million ideas and trying to bring enough focus to start dividing and eliminating... want to do a "90 day challenge", but I have to get off my arse to do day 1, so, y'know ... :) |
| 21:33.07 | ``Erik | boggled at the income things like 'candy crush' and 'clash of clans' generate, but lack the artistic and marketing skill to really play in that arena :) |
| 21:33.17 | starseeker | hehe |
| 21:33.51 | ``Erik | (seriously, 'candy crush' is a match-3 game, similar to tetris at the core... running around $800000-900000 a DAY) |
| 21:34.06 | starseeker | O.o |
| 21:34.16 | ``Erik | (ya might remember when it was called "bejeweled" many years ago) |
| 21:34.37 | ``Erik | and just shy of a million dollars a DAY... zomfg, wtff |
| 21:34.52 | starseeker | there's my mistake - I'm trying to think up *useful* apps, and who would want those :-P |
| 21:35.31 | ``Erik | if "useful" was important, we'd be driving hyper-efficient cars, not mustangs and camaros, right? ;) |
| 21:36.56 | starseeker | <snort> yeah, I guess between that and the fashion industry the evidence is pretty conclusive |
| 21:38.02 | ``Erik | a fashion app or saas would be a hell of a thing to figure out |
| 21:38.40 | starseeker | what, you mean point your phone's camera at someone and have it "grade" their style? |
| 21:38.57 | ``Erik | I saw a saas that tried to link clothes in tv shows and movies to where you could buy the items, not sure how far they got |
| 21:39.35 | starseeker | can imagine the carnage an app like that would wreck in high school - the real $$ would be vendors bidding to get higher rankings... |
| 21:41.12 | ``Erik | didja end up driving at the beginning of this week? was pretty hairy for a couple days O.o |
| 21:41.13 | starseeker | can phones even do much with image recognition? I would think anything non-trivial would need a fairly large database against which to compare |
| 21:41.46 | starseeker | ``Erik: no, pretty much waited it out as long as I could. The roads in my neighborhood are *still* crappy |
| 21:41.47 | ``Erik | image recognition in what sense? there're some pretty awesome 'enhanced reality' apps out there |
| 21:42.12 | starseeker | ah, I was thinking in the fashion context "given image, recognize shirt style" |
| 21:42.13 | ``Erik | there's one I took a look at, does realtime translate of text, like, ocr's and translates and replaces it on the phone screen |
| 21:42.24 | starseeker | hah, cool |
| 21:45.22 | ``Erik | "word lens", demo at http://www.youtube.com/watch?v=h2OfQdYrHRs |
| 21:46.54 | starseeker | that's cool |
| 21:47.55 | starseeker | very impressive |
| 21:48.36 | starseeker | not just the text reconigition and translation, but generating a replacment that seems to "fit" in the existing view context |
| 21:49.05 | ``Erik | yup, and it actually does it (though the free filter is just a reverse) |
| 21:49.16 | ``Erik | even on my old iphone4 with a broken back plate O.o |
| 21:49.28 | starseeker | they must be limited to a subset of fonts or something like that... |
| 21:50.37 | starseeker | boy, there's a candidate for "in-glasses" augmented reality - the ultimate vacation accessory |
| 21:51.42 | ``Erik | I'm sure :) still pretty damn impressive, the one I have is like an armv8 at 800mhz |
| 21:52.08 | ``Erik | single core, and it still does an impressive job with the reversal... probably mostly gpu driven |
| 21:52.18 | ``Erik | woops, armv7 |
| 21:52.22 | ``Erik | http://en.wikipedia.org/wiki/Apple_A4 |
| 21:52.55 | ``Erik | (damn, I'm geeky... describing the phone by the cpu instruction set and clock speed) |
| 21:53.03 | starseeker | heh - works for me |
| 21:56.07 | starseeker | ``Erik: it might be worth advertisers while to combine the image replacment portion of that with those little digital 2D dot patterns that phones can scan - if they use the latter to encode per-language information, they could avoid the ambiguities of image recognition and make sure the composite image had a correct add/sign/whatever in the appropriate language |
| 21:57.03 | ``Erik | you mean like qr codes? *shrug* that's their app, ain't mine... saw it on hackernews a while back |
| 22:00.51 | starseeker | ``Erik: sure - I was just thinking that it sounds like the sort of thing that might generate some interest. A cheap, easy way to make signs "multilingual" without having to put up 15 of them |
| 22:03.00 | starseeker | ah, so those little 2D box patterns are called qr codes? |
| 22:06.17 | starseeker | (that shows how savvy starseeker is with phone tech...) |
| 22:10.17 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) | |
| 22:38.47 | Notify | 03BRL-CAD:carlmoore * 59524 brlcad/trunk/src/conv/jack/jack-g.c: shut off a 'bfile =' because it's immed. followed by exit; undo immed.-subsequent 'else' because of that exit; switch what was 'if (!base)' |