| 01:11.07 | Notify | 03BRL-CAD:mohitdaga * 57816 (brlcad/trunk/src/libicv/size.c brlcad/trunk/src/libicv/tests/CMakeLists.txt): Add tester function for icv_resize [methods dealing in to increase the size] api. |
| 01:12.21 | Notify | 03BRL-CAD:mohitdaga * 57817 brlcad/trunk/src/libicv/tests/icv_size_up.c: TYPO |
| 01:15.45 | Notify | 03BRL-CAD:mohitdaga * 57818 brlcad/trunk/src/libicv/size.c: remove debug flags. |
| 01:53.21 | Notify | 03BRL-CAD:mohitdaga * 57819 brlcad/trunk/src/libicv/size.c: Few sanitizers. |
| 01:55.10 | Notify | 03BRL-CAD:mohitdaga * 57820 brlcad/trunk/src/libicv/tests/CMakeLists.txt: Add tester function for icv_resize [methods dealing in to decrease the size] api. |
| 02:17.26 | *** join/#brlcad witness__ (uid10044@gateway/web/irccloud.com/x-ijulyuyzetygqhtn) |
| 07:07.17 | *** join/#brlcad whyesse (~quassel@109.160.252.157) |
| 09:00.36 | *** join/#brlcad whyesse (~quassel@109.160.252.157) |
| 10:49.50 | Notify | 03BRL-CAD:tbrowder2 * 57821 brlcad/trunk/misc/CMake/CompilerFlags.cmake: remove 'the' |
| 10:52.20 | Notify | 03BRL-CAD:tbrowder2 * 57822 brlcad/trunk/misc/CMake/CompilerFlags.cmake: format some comments to narrower width for ease of reading |
| 11:09.00 | Notify | 03BRL-CAD:tbrowder2 * 57823 brlcad/trunk/CMakeLists.txt: improve grammar (remove superflous 'got'); end sentences wih a period |
| 11:10.44 | Notify | 03BRL-CAD:tbrowder2 * 57824 brlcad/trunk/CMakeLists.txt: narrow too-wide comment; indent a link in a comment for highlighting |
| 11:13.52 | Notify | 03BRL-CAD:tbrowder2 * 57825 brlcad/trunk/CMakeLists.txt: add missing 'a' |
| 11:42.42 | Notify | 03BRL-CAD Wiki:Carlosmunoz * 0 /wiki/User:Carlosmunoz: |
| 11:48.17 | Notify | 03BRL-CAD:tbrowder2 * 57826 (brlcad/trunk/CMakeLists.txt brlcad/trunk/misc/CMake/CompilerFlags.cmake): add an option to do strict C89 checking |
| 13:13.26 | Notify | 03BRL-CAD:tbrowder2 * 57827 brlcad/trunk/misc/CMake/BRLCAD_Summary.cmake: add label for c89 checking option |
| 13:14.38 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 13:48.18 | *** join/#brlcad vladbogo (~vlad@188.25.237.92) |
| 13:51.57 | vladbogo | d_rossberg |
| 13:52.06 | vladbogo | I've just seen your mail |
| 13:54.10 | vladbogo | I've tried the same thing (calling XInitThreads) in mged and there still is a segfault. It occurs more infrequent and it cannot be captured in gdb (so it might be something else) but still occurs from time to time. |
| 13:54.49 | d_rossberg | where did you put the XInitThreads()? |
| 13:55.08 | vladbogo | first line in main in src/mged/mged.c |
| 13:56.49 | d_rossberg | this should be ok for the mged |
| 13:57.34 | d_rossberg | there is probable another issue too causing a segfault |
| 13:58.57 | vladbogo | it might be |
| 14:00.19 | vladbogo | I'll try to run several times to see if it occurs in the debugger |
| 14:00.33 | d_rossberg | i got a segmentation fault by simply starting and closing archer, with calling XInitThreads() first in bwish this segfault was gone |
| 14:07.26 | *** join/#brlcad Gaganjyot (~gagan@210.56.99.213) |
| 14:10.57 | d_rossberg | vladbogo: will the bu_log("close called"); stay in the source file? |
| 14:12.09 | vladbogo | d_rossberg: no, I'll remove it and also bu_log("open called") |
| 14:16.30 | *** join/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) |
| 14:21.33 | d_rossberg | ok |
| 14:21.59 | Notify | 03BRL-CAD:vladbogo * 57828 brlcad/trunk/src/libdm/dm-qt.cpp: Removed some log calls. |
| 14:22.16 | vladbogo | d_rossberg: I removed them. They were left there just to make sure that when running mged I change and use the qt dm. |
| 15:15.46 | Notify | 03BRL-CAD:n_reed * 57829 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Revert rt_hrt_norm to previous revision. Latest suffered from non-standard signature and set-but-unused. |
| 15:19.25 | Notify | 03BRL-CAD:starseeker * 57830 brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp: More work on figuring out how to break matricies down for AP203. |
| 15:33.41 | Notify | 03BRL-CAD:starseeker * 57831 brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp: Add function to create an identity AXIS2_PLACEMENT_3D |
| 15:46.21 | Notify | 03BRL-CAD:starseeker * 57832 brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp: This string comes from the standard and is expected to be this particular domain. |
| 15:55.06 | Notify | 03BRL-CAD:starseeker * 57833 (brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp): Add design context |
| 16:13.30 | *** join/#brlcad kesha (~kesha@49.202.231.141) |
| 16:18.01 | *** join/#brlcad kesha (~kesha@49.202.238.200) |
| 16:32.10 | Notify | 03BRL-CAD:brlcad * 57834 brlcad/branches/RELEASE/include/bu.h: they return (BRL-CAD), not (unknown) |
| 16:48.21 | Notify | 03BRL-CAD:brlcad * 57835 brlcad/branches/RELEASE/src/libbu/progname.c: fix the fixme's, no worse for the wear, by removing progname_ipwd() |
| 16:59.17 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6184 /wiki/User:Izak/GSOC_2013_logs: /* September 16th to September 21st */ |
| 17:00.08 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6185 /wiki/User:Izak/GSOC_2013_logs: /* GSoC 2013 summary */ |
| 17:18.13 | Notify | 03BRL-CAD:mohitdaga * 57836 brlcad/trunk/src/libicv/operations.c: Sanitize divide operations by adding EPS. |
| 17:23.22 | Notify | 03BRL-CAD:mohitdaga * 57837 brlcad/trunk/src/libicv/tests/CMakeLists.txt: Add tester functions for icv_saturate api |
| 17:27.33 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 17:33.46 | brlcad | zero_level: r57836 .. cannot throw in arbitrary constants like that without documenting them |
| 17:34.10 | brlcad | should also consider whether there's an existing constant that will suffice (search the headers) |
| 17:36.16 | brlcad | in particular, there is VUNITIZE_TOL, VDIVIDE_TOL, BN_TOL_DIST, plus all the std limit tolernaces ... to name a few |
| 17:45.27 | brlcad | if you're protecting from a divide by zero, you should check for zero .. otherwise you could be injecting a drift |
| 18:05.39 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 18:07.44 | Notify | 03BRL-CAD:iiizzzaaakkk * 57838 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Some corrections to rt_hrt_norm() function |
| 18:12.19 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 6186 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* Sept 23 - Sept 28 */ |
| 18:37.54 | Izak__ | exit |
| 18:41.10 | Notify | 03BRL-CAD:starseeker * 57839 brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp: Quote comb names |
| 18:41.28 | brlcad | Izak__: looks like the heart is necrotic ;) |
| 18:41.54 | brlcad | starseeker: how can I test for a flag using our compiler flags? |
| 18:42.04 | brlcad | er, test for a symbol |
| 18:43.34 | starseeker | uh... not sure |
| 18:43.35 | Notify | 03BRL-CAD:mohitdaga * 57840 (brlcad/trunk/include/icv.h brlcad/trunk/src/libicv/operations.c): Correct validation process. |
| 18:44.20 | brlcad | check_c_source_compiles() doesn't seem to set any flags |
| 18:44.36 | starseeker | oh - IIRC there are CMake variables you can set |
| 18:44.38 | starseeker | one sec |
| 18:44.44 | brlcad | so a symbol is passing that then breaks compilation when it doesn't exist later (when -std= is set, for example) |
| 18:45.29 | starseeker | is CMAKE_C_FLAGS what you're looking for? |
| 18:46.22 | starseeker | BRLCAD_CHECK_LIBRARY has to deal with that, for example... |
| 18:46.45 | brlcad | they're doing the opposite though |
| 18:46.56 | brlcad | they're intentionally unsetting CMAKE_C_FLAGS |
| 18:47.06 | brlcad | (which is related to this problem) |
| 18:47.09 | starseeker | you want to know if a particular symbol is set? |
| 18:47.50 | brlcad | I want to know if we can use a particular symbol |
| 18:48.24 | brlcad | a symbol that passes testing if I use check_c_source_compiles() or BRLCAD_CHECK_*() ... but it shouldn't be passing |
| 18:48.29 | starseeker | you mean something like if(DEFINED C89_FLAG) or something? |
| 18:48.54 | brlcad | except there are practically an unlimited number of things that might make it fail |
| 18:48.57 | brlcad | not just c89 |
| 18:49.15 | brlcad | and in this case, not at all c89-related, though I'm sure that would be one of the cases |
| 18:50.10 | starseeker | brlcad: the problem, iirc, was that something that have to work (like the bigendian test, IIRC) can get messed with by having things in CMAKE_C_FLAGS |
| 18:50.15 | brlcad | i'm a little surprised check_c_source_compiles() is passing nothing -- does it ignore CMAKE_C_FLAGS? (or maybe the other flags haven't been tested yet) |
| 18:52.00 | brlcad | is that documented somewhere? seems like that will ultimately be necessary/helpful to have symbols tested with a given set of compilation flags |
| 18:52.06 | starseeker | winces |
| 18:52.10 | brlcad | that being the bigendian problem |
| 18:52.26 | brlcad | what? |
| 18:52.57 | starseeker | brlcad: essentially, what you need to do that right is a system that defines tests and allows them to be dependent on other tests |
| 18:53.16 | starseeker | that's one of the core necessities for parallel configure |
| 18:53.35 | starseeker | essentially, duplicates the build target dependency resolution in a "configure setup" stage |
| 18:53.53 | starseeker | pretty sure CMake doesn't have that - I don't know of any build tool that does, for that matter |
| 18:54.35 | starseeker | had actually guessed that was a likely feature that would characterize the "next generation" of build tool after CMake... |
| 18:55.08 | brlcad | i don't follow, we don't configure in parallel now ... it's a big script |
| 18:55.43 | starseeker | I know, but if you make test dependent on other tests you have to sort out some thorny ordering issues |
| 18:56.00 | brlcad | and I cannot describe all the possible ways some test might be dependent on something else making it available/unavailble... |
| 18:56.07 | starseeker | almost exactly the same problem as target dependency resoultion |
| 18:56.30 | Notify | 03BRL-CAD:mohitdaga * 57841 brlcad/trunk/src/libicv/tests/CMakeLists.txt: Add test utility for operations.c |
| 18:58.10 | brlcad | this all seems non sequitor too.. how else can we possibly know if a symbol is actually usable during compilation without testing it with our compilation flags? |
| 18:58.21 | starseeker | brlcad: so you want to have all tests use whatever flags have already been added, except in cases where we know there are issues? |
| 18:58.28 | brlcad | we're getting lucky at the moment in a way (because we turn on extensions0 |
| 18:59.39 | brlcad | hard to say that for sure without knowing what those issues are, but yeah .. I think that will be necessary to make the code actually toggle implementation behavior correctly |
| 18:59.56 | starseeker | eek |
| 19:00.00 | brlcad | got to know if some symbol like fileno is really available |
| 19:00.13 | brlcad | you keep doing |
| 19:00.24 | Notify | 03BRL-CAD:mohitdaga * 57842 (brlcad/trunk/src/libicv/tests/icv_crop.c brlcad/trunk/src/libicv/tests/icv_fade.c and 5 others): Trailing WS |
| 19:00.26 | brlcad | doing that .. tell me what other alternative solution there is? |
| 19:00.37 | brlcad | I don't see any possible way frankly |
| 19:00.41 | starseeker | isn't there a subset of definitions like the std definitions that we know *might* impact such availability |
| 19:01.18 | brlcad | std definitions? |
| 19:01.20 | starseeker | if any definition might impact any other definition, what order do we pick in which to test things? |
| 19:01.21 | brlcad | which std? |
| 19:01.33 | starseeker | -std=gnu99 et al |
| 19:01.34 | brlcad | what mode of compilation, what defines |
| 19:02.15 | brlcad | no, there's not a set of definitions |
| 19:02.34 | brlcad | -std=* is one way, and there are about a half-dozen other ways |
| 19:02.36 | brlcad | and that's just gcc |
| 19:02.58 | starseeker | then if we test something at some point in the configure process and it succeeded, what guarantee do we have that a flag added further down the configure process won't invalidate the test we just had succeed? |
| 19:03.00 | brlcad | -pedantic affects things dramatically too |
| 19:04.28 | brlcad | we guarantee the order of testing, that was exactly why configure defined the N categories of tests .. |
| 19:04.55 | brlcad | wasn't just for fun to keep things organized, it was requried to know that a given symbol was actually usable (because the compiler behavior was tested first) |
| 19:05.16 | brlcad | oversimplifying, but that was the reason for categorical testing |
| 19:05.41 | starseeker | I may be confused on terminology here - compiler behavior is independent of symbol usability? |
| 19:06.46 | brlcad | not sure what you mean by independent |
| 19:06.48 | starseeker | or rather, we don't make decisions about compiler behavior flags based on what symbols are are aren't usable? |
| 19:07.04 | brlcad | compiler characteristics can certainly affect the outcome of symbols |
| 19:07.04 | starseeker | s/are are/are or/ |
| 19:07.23 | brlcad | ah, no |
| 19:07.27 | brlcad | other way around |
| 19:07.41 | brlcad | symbol availability is driven by the compiler settings |
| 19:07.53 | brlcad | so you have to test compiler first |
| 19:08.03 | brlcad | it's the header in CMakeLists.txt that was copied from configure.ac |
| 19:08.09 | starseeker | but which one do we care about? Or rather, which one changes based on the results of the other? |
| 19:08.38 | starseeker | if we know we need a symbol, do we cycle through compiler behavior flags until it works? |
| 19:08.39 | brlcad | 3) check compilear characteristics has to come before 7) check functions (for example) because they affect those results |
| 19:09.00 | zero_level | waves to brlcad, ``Erik |
| 19:09.17 | brlcad | do we have a case where we know we need a symbol? |
| 19:09.26 | brlcad | I've never thought of it that way |
| 19:09.42 | zero_level | brlcad, ``Erik : have you seen the test infrastructure. |
| 19:10.02 | starseeker | I dont know offhand - I was thinking of the Mac where if we add the c89 strict flag the Mac headers shut us down |
| 19:10.19 | brlcad | always the other way around, we need certain compiler flags, we cycle through symbols so code can find some implementation that works |
| 19:10.21 | starseeker | example of non-viable compiler behavior flags |
| 19:10.35 | brlcad | zero_level: yep, looked good |
| 19:11.23 | brlcad | starseeker: AH .. now *that* I would believe.. that you ran into a problem with strictness and system headers, punted by turning off flags :) |
| 19:11.50 | starseeker | brlcad: then what we need to do internally is differentiate between compiler behavior flags and options related to symbols, and populate CMAKE_C_FLAGS with whatever subset is approporate for the test at hand |
| 19:12.12 | starseeker | I very much doubt we have that level of granularity currently |
| 19:12.17 | brlcad | options related to symbols? |
| 19:12.48 | starseeker | if any are needed - for example, if a test for one symbol can't work without another symbol being defined |
| 19:12.49 | brlcad | so there are already some flags that are called out in specific directories, and some that are just global to the whole project |
| 19:12.59 | brlcad | it's the ones that are global to the project that should be used |
| 19:13.06 | starseeker | again, don't know if that could happen but I don't know enough to rule it out |
| 19:13.50 | brlcad | what you just described was 8) check system services |
| 19:13.57 | starseeker | brlcad: if you want to make a quick test just alter all the macros to not zero out CMAKE_C_FLAGS - that'll tell you what happens currently |
| 19:14.04 | brlcad | i.e., a test for one symbol can't work without another symbol being defined |
| 19:14.05 | zero_level | brlcad : This is my first year in GSoC. Can I still code ? (Pencils Down) or I have to stop now and resume after 27th ? |
| 19:14.27 | brlcad | starseeker: I'm still not sure that will fix my current symbol problem |
| 19:14.42 | brlcad | starseeker: like I said, check_c_source_compiles() passes ... and has no flags |
| 19:14.54 | starseeker | let me check the macro definition |
| 19:14.56 | brlcad | implies empty CFLAGS no? |
| 19:15.32 | brlcad | zero_level: you can absolutely still keep coding! |
| 19:15.52 | zero_level | ok. |
| 19:16.05 | brlcad | my goodness! that's the whole point is to get you all coding as much as possible, working on open source for fun :) |
| 19:16.24 | brlcad | so yeah, you passed developer vetting |
| 19:16.32 | zero_level | brlcad : Were you tuned to logs? I am plannin to find performance analysis of api. |
| 19:16.55 | brlcad | once you got commit access, you've been allowed to work on what you find interesting so long as it fits in with the project in some fashion |
| 19:17.12 | starseeker | brlcad: I think you can add what is needed to CMAKE_REQUIRED_DEFINITIONS |
| 19:17.15 | zero_level | ok. |
| 19:17.58 | brlcad | zero_level: yeah, I was away when you asked .. it's not hard to get a profile build going |
| 19:18.07 | zero_level | So I want to find how do I add -pg or -g for 'gprof' |
| 19:18.14 | brlcad | it's hard to make use of the numbers, to understand what's going on, but it's not hard at all to get the profile |
| 19:18.45 | brlcad | starseeker: okay, I'll play with that, see if I can find some examples |
| 19:19.01 | brlcad | then maybe later try the cflags un-unsetting |
| 19:19.22 | brlcad | but that will require making sure the cflag-modifier tests are first |
| 19:19.31 | zero_level | brlcad : how ? |
| 19:19.32 | starseeker | fwiw, our compiler flag testing is waaaaaay more elaborate that any other CMake project I've ever seen, so it's quite possible they aren't set up do what we want/need out of the box |
| 19:19.55 | brlcad | zero_level: we have profiling integrated into the build, you should be able to just turn it on (INSTALL file has the syntax) |
| 19:20.11 | zero_level | alright. Thanks for the pointer. |
| 19:20.14 | brlcad | basically -pg turns on gprof profiling, helps to have -g but not requisite |
| 19:20.55 | brlcad | once you compile with -pg, you run the program, it will dump a gmon.out file, you run gprof on that gmon.out file and it'll give a report |
| 19:24.19 | starseeker | brlcad: so we do have a dependency flow chart, but it's basically one "category" of test depends on another category's results? |
| 19:25.30 | Notify | 03BRL-CAD:mohitdaga * 57843 brlcad/trunk/src/libicv/operations.c: Use already defined MACRO for avoiding zero divide. |
| 19:25.54 | zero_level | brlcad : I believe r57843 solves the issue. :) |
| 19:30.16 | brlcad | starseeker: I think that's notionally not a bad way to think about it, though I think dependency-wise it's probably a little more simple than the 10 categories |
| 19:31.00 | starseeker | brlcad: I think a flowchart type document describing that relationship (and the reasons for it) might not be a bad thing, long term |
| 19:31.23 | starseeker | in principle, tests within those categories can be made parallel someday |
| 19:31.30 | starseeker | if the tool supports it, anyway... |
| 19:32.24 | starseeker | the two naive positions are that each flag can be tested totally independently, and any flag of any sort can impact any other flag (nxn) - clearly there is a middle ground |
| 19:33.24 | starseeker | (very) long term, understanding what tests have to depend on what other tests (or categories of tests) is key to speeding up configure |
| 19:38.40 | brlcad | yeah, within each category I think they are fully independent |
| 19:41.28 | brlcad | I think they could even be modularized, but each module would need to (as you note) declare dependent modules and have some means of passing in a state |
| 19:42.15 | brlcad | like I could see just setting CMAKE_REQUIRE_DEFINITIONS before all the symbol checks, for example, to the current cflags that we were going to set, testing, and then unsetting |
| 19:46.40 | brlcad | I think the two big categories of dependencies are library availability (if a lib doesn't exist, you shouldn't test for symbols it may have provided) |
| 19:47.45 | brlcad | <PROTECTED> |
| 19:48.19 | Notify | 03BRL-CAD:carlmoore * 57844 (brlcad/trunk/src/libbrep/boolean.cpp brlcad/trunk/src/util/bu_arg_parse.h brlcad/trunk/src/util/dsp_add3.c): remove trailing blanks/tabs; fix spellings |
| 19:49.06 | brlcad | arguably a third for system services, where you basically build up an integration test for the case of checking that things work correctly together where they might not |
| 19:53.48 | Notify | 03BRL-CAD:starseeker * 57845 (brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp): Move bits related to comb structure assembly into Assembly_Product. |
| 20:00.07 | Notify | 03BRL-CAD:starseeker * 57846 brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp: Make generic axis2_placement_3d function and make identity a special case that calls it. |
| 20:01.45 | starseeker | brlcad: actually, making those modules might be the simplest way to make that managable (and readable...) |
| 20:02.16 | starseeker | would certainly make for a shorter toplevel CMakeLists.txt... |
| 20:07.13 | ``Erik | *readreadread* brlcad, I think at this point, trying to get 'clean' on c89 would take more effort than clean on c99 due to fighting with system headers and libs... that ship has sailed, yo |
| 20:08.14 | ``Erik | I'd imagine just bumping to c99 and going from there would be the best path forward |
| 20:09.36 | ``Erik | (also; waking up and not flipping out about getting through the rainlocker to get to work in time... very strange, surreal...) |
| 20:47.58 | brlcad | starseeker: maybe simplest to manage, but I'd be surprised if it's the simplest way because you'd end up creating a module for what would otherwise often be a single line of code (check if this symbol will work) |
| 20:49.20 | brlcad | ``Erik: I don't deny that jumping to c99 would be the fastest way, but we're literally 99% of the way there already ... and none of what I've been talking about today had anything to do with c89/c99 |
| 20:49.54 | brlcad | needs to test for program_invocation_name (a glibc symbol) |
| 20:51.22 | brlcad | from a product evolution, we used to compile strict (and not too long ago, within last 8 years), so it's just a matter of fixing that regression so we can claim a baseline before moving on |
| 20:51.46 | brlcad | otherwise, would have said screw it 10 years ago when it was a pre-ansi mess |
| 21:51.42 | Notify | 03BRL-CAD:starseeker * 57847 brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp: Break matrix handling into a function |
| 21:52.40 | starseeker | brlcad: oh, I was thinking one module per "category" |
| 21:52.50 | brlcad | ah |
| 22:01.25 | brlcad | starseeker: any chance to check out one of those pending patches for check? |
| 22:01.51 | brlcad | final evals are due by friday |
| 22:14.59 | Notify | 03BRL-CAD:brlcad * 57848 brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: case fix |
| 22:42.05 | Notify | 03BRL-CAD:starseeker * 57849 (brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp): Begin working on the core of comb support. Need to pass in more info, or something isn't being build correctly with the maps, but getting there. |
| 22:42.26 | starseeker | I'll see if I can tonight... |
| 22:46.53 | brlcad | cool |
| 22:52.25 | *** join/#brlcad Gaganjyot (~gagan@125.62.120.186) |
| 22:56.11 | maths22 | brlcad: what is the status for web work and the extensions? |
| 22:56.35 | maths22 | Sorry if you already got this, but your connections seemed to go in and out recently |