| 00:16.40 | tharis20 | brlcad: can a person apply for two projects in brlcad? |
| 00:17.10 | tharis20 | obviously, one would be working only on one of them, if he got accepted |
| 00:38.24 | brlcad | starseeker: so the better question was how to suppress them by default? they don't really convey useful information, misleading even |
| 00:39.48 | brlcad | LainIwakuraX: if you've completed one of them, awesome -- the first steps are generally to post a patch to the brl-cad patches tracker on sourceforge and talk to devs to get it reviewed/applied |
| 00:40.25 | brlcad | LainIwakuraX: the basic high-level project operations are written up in the HACKING file, linked to on the quickies page |
| 00:41.04 | brlcad | LainIwakuraX: and that's pretty impressive if you've replaced all of the SCLstring instances.. nice! |
| 00:41.40 | abhi2011 | Hi brlcad, since BRL-CAD uses doxygen for documentation, is there a doxyfile in the source code already or is one generated when needed |
| 00:41.48 | brlcad | there's one in misc/ |
| 00:41.53 | abhi2011 | ok |
| 00:42.11 | brlcad | but it's easy enough to recreate one as needed too |
| 00:42.20 | abhi2011 | right ok |
| 00:42.49 | brlcad | I've been working on a doxyfile specific for libbu that's a little different from what's in nmisc/ |
| 00:43.02 | brlcad | as a template for the rest, but it's still a wip |
| 00:43.16 | abhi2011 | ok |
| 00:43.51 | abhi2011 | regarding moving LIBBN comments from source to header files, I guess the comments on the *.c file need to be moved atop the function declarations in bu.h ? |
| 00:44.46 | brlcad | nope, but close |
| 00:44.49 | abhi2011 | i.e. the files in /src/libbn/*.c |
| 00:44.56 | brlcad | atop the decls in bN.h ;) |
| 00:45.05 | abhi2011 | oops yes right |
| 00:45.29 | brlcad | have you ever made a patch before? |
| 00:45.34 | abhi2011 | no |
| 00:45.44 | brlcad | that's fine |
| 00:46.01 | abhi2011 | but i understand that making the changes and testing with doxygen should not be done in the checked out svn repository |
| 00:46.13 | abhi2011 | otherwise a diff will add the new files as weel |
| 00:46.14 | brlcad | but then I suggest not attempting all files, migrate just one libbn file to the header and work on submitting it as a patch |
| 00:46.30 | brlcad | there shouldn't be any new files |
| 00:46.33 | abhi2011 | right ok |
| 00:46.54 | brlcad | svn will make a patch file for you, which is basically just a special format text file |
| 00:47.22 | abhi2011 | yes true, the thing is if I test with doxygen in the svn checked out source, then it will produce new files |
| 00:47.34 | brlcad | try moving one comment from src/libbn to include/bn.h then run svn diff at the top-level -- that will output a diff of any changes you made |
| 00:47.48 | abhi2011 | right ok |
| 00:47.57 | brlcad | you can point doxygen output anywhere |
| 00:48.11 | abhi2011 | yes ok |
| 00:48.14 | brlcad | those files will get ignored by svn unless you specifically add them |
| 00:48.28 | abhi2011 | ok cool |
| 00:48.33 | brlcad | there are lots of tutorials around the net too on creating a patch file with svn |
| 00:49.13 | abhi2011 | right. I ll try with 1 file first |
| 00:49.20 | brlcad | basically, though, it's just "svn diff > my_changes.patch" .. then manually inspect the my_changes.patch file with a text editor to make sure it only includes things you intended to change |
| 00:49.35 | abhi2011 | ok |
| 00:49.50 | brlcad | if it includes more, you have to svn revert the files unintentionally edited or undo the edits by hand |
| 00:50.08 | abhi2011 | right |
| 00:50.12 | brlcad | that patch file gets posted to the patches tracker, and then you get a dev to review it (in here and/or on the mailing list) |
| 00:50.51 | abhi2011 | ok...the submission is through the web interface i guess |
| 00:51.01 | abhi2011 | *the posting |
| 00:51.23 | brlcad | abhi2011: for socis, that will satisfy the "requirement" more than enough but keep in mind that shows only basic competency .. doesn't take any skill to move a comment ;) |
| 00:52.00 | abhi2011 | yes true :) |
| 00:53.43 | abhi2011 | well have to start somewhere :P |
| 00:55.06 | LainIwakuraX | brlcad: How do I make a patch? Like I mentioned this is my first time doing open source stuff =x |
| 00:57.01 | LainIwakuraX | brlcad: Nevermind, it looks like svn diff > stuff.patch =) |
| 01:12.06 | starseeker | brlcad: um. they are conveying information in the sense that tests are actually being run to see if system versions of those libraries are available... |
| 01:12.56 | starseeker | not sure how they're misleading... I could add a note saying local version is being enabled for compilation... |
| 01:19.44 | brlcad | starseeker: those messages were printed during make, not during cmake (this was a simple "cmake . ; make") and they're the first thing output during make |
| 01:20.24 | brlcad | basically looks like a bunch of failure messages, which during make implies build failures |
| 01:23.31 | LainIwakuraX | Patch submitted, now I wait =P |
| 01:23.36 | brlcad | the clarity of the message itself would also help .. "Could NOT find UTAHRLE" isn't true and has overemphasis, maybe "Could not find a usable system Utah Raster Toolkit, building the included one" |
| 01:24.05 | brlcad | LainIwakuraX: outstanding |
| 01:58.22 | tharis20 | is there a way not to compile all brlcad stuff when modifying only 1 file? |
| 01:59.15 | brlcad | yes several ways, the easiest is to just cd to the dir where the change was made and make |
| 02:01.43 | abhi2011 | submitted my basic patch :P |
| 02:07.39 | abhi2011 | regarding the Convert BU_SETJUMP/BU_UNSETJUMP blocks into try/catch layout |
| 02:07.54 | starseeker | brlcad: are you sure cmake wasn't being run first? |
| 02:08.09 | starseeker | rerun rather... |
| 02:08.51 | abhi2011 | i guess a simple grep for BU_SETJUMP in src/**/*.c should reveal all places where the blocks should be replaced with try/catch layout ? |
| 02:09.26 | LainIwakuraX | abhi2011: "grep -H -r "BU_SETJUMP" . | grep -v svn | less" |
| 02:09.42 | LainIwakuraX | in an appropriately high level directory |
| 02:09.56 | abhi2011 | nice...thanks |
| 02:10.01 | abhi2011 | i ll grep in src |
| 02:10.11 | LainIwakuraX | That's how I found SCLstring ;) lol |
| 02:10.21 | abhi2011 | :) |
| 02:11.31 | abhi2011 | i think better to add *.c |
| 02:12.35 | LainIwakuraX | Yeah, in my case I had to look in header files too, but whatever works |
| 02:13.37 | abhi2011 | right...and do you do the build in the source tree using autotools ? |
| 02:13.48 | abhi2011 | or out of tree |
| 02:14.16 | LainIwakuraX | hm, last night I was just using cmake / make in the highest level |
| 02:15.48 | abhi2011 | ok, I guess then the object files get produced in the source tree |
| 02:16.14 | LainIwakuraX | yeah, svn will ignore those though unless you svn add them |
| 02:16.20 | abhi2011 | ok |
| 02:47.06 | abhi2011 | so the code is something like this : |
| 02:47.11 | abhi2011 | double result; |
| 02:47.13 | abhi2011 | if (!BU_SETJUMP) { |
| 02:47.14 | abhi2011 | <PROTECTED> |
| 02:47.16 | abhi2011 | <PROTECTED> |
| 02:47.18 | abhi2011 | <PROTECTED> |
| 02:47.20 | abhi2011 | ret = 1; |
| 02:47.21 | abhi2011 | failed_cnt++; |
| 02:47.23 | abhi2011 | (void)fprintf(stream, "Failed function %lu test case on line %lu expected = %.15f result = %.15f\n", |
| 02:47.25 | abhi2011 | <PROTECTED> |
| 02:47.26 | abhi2011 | <PROTECTED> |
| 02:47.28 | abhi2011 | success_cnt++; |
| 02:47.30 | abhi2011 | <PROTECTED> |
| 02:47.32 | abhi2011 | } else { |
| 02:47.34 | abhi2011 | <PROTECTED> |
| 02:47.36 | abhi2011 | <PROTECTED> |
| 02:47.37 | abhi2011 | <PROTECTED> |
| 02:47.39 | abhi2011 | <PROTECTED> |
| 02:47.41 | abhi2011 | <PROTECTED> |
| 02:47.42 | abhi2011 | } BU_UNSETJUMP; |
| 02:47.44 | abhi2011 | this may be replaced by code similar to: |
| 02:47.45 | abhi2011 | double result; |
| 02:47.47 | abhi2011 | try{ |
| 02:47.48 | abhi2011 | <PROTECTED> |
| 02:47.50 | abhi2011 | <PROTECTED> |
| 02:47.51 | abhi2011 | <PROTECTED> |
| 02:47.53 | abhi2011 | <PROTECTED> |
| 02:47.54 | abhi2011 | <PROTECTED> |
| 02:47.56 | abhi2011 | <PROTECTED> |
| 02:47.57 | abhi2011 | <PROTECTED> |
| 02:47.59 | abhi2011 | ret = 1; |
| 02:48.01 | abhi2011 | failed_cnt++; |
| 02:48.03 | abhi2011 | (void)fprintf(stream, "Failed function %lu test case on line %lu expected = %.15f result = %.15f\n", |
| 02:48.05 | abhi2011 | <PROTECTED> |
| 02:48.07 | abhi2011 | <PROTECTED> |
| 02:48.08 | abhi2011 | success_cnt++; |
| 02:48.10 | abhi2011 | <PROTECTED> |
| 02:48.12 | abhi2011 | } catch( char *str ) { |
| 02:48.13 | abhi2011 | <PROTECTED> |
| 02:48.15 | abhi2011 | <PROTECTED> |
| 02:48.17 | abhi2011 | <PROTECTED> |
| 02:48.19 | abhi2011 | <PROTECTED> |
| 02:48.20 | abhi2011 | } |
| 02:48.22 | abhi2011 | bu_setjmp_valid=0; |
| 02:52.03 | LainIwakuraX | codepad.org |
| 02:57.23 | abhi2011 | :P.....ok |
| 03:21.57 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 03:28.23 | brlcad | starseeker: it probably was, but then that is curious in itself in that the exact previous command was "cmake ." |
| 03:28.37 | brlcad | abhi2011: omg, dude pastebin next time |
| 03:28.40 | brlcad | ~pastebin |
| 03:28.40 | ibot | [~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude. |
| 03:30.41 | brlcad | 3 lines is a bit crazy, but more than 5 or so, definitely |
| 03:31.26 | brlcad | that many lines pretty much halts the channel while it's pasting to everyone (you may see it instantly, but in reality, it ticks off about 1 line a second) |
| 03:32.13 | brlcad | the task it to structure the jumps into try/catch *style*, not actual try/catch syntax .. lots of examples in the code that are converted already |
| 03:47.12 | brlcad | abhi2011: unless you're already familiar with C jumps (longjmp() and friends), a better use of your time would something that gets you working in libged |
| 03:47.24 | brlcad | like fixing the 'analyze' command output formatting |
| 03:49.02 | brlcad | or related, https://sourceforge.net/tracker/?func=detail&aid=2954409&group_id=105292&atid=640805 albeit a little bit harder than fixing the output formatting |
| 03:51.41 | brlcad | or letting the cp command take multiple arguments for simultaneously creating named copies, relatively simple logic mod to a libged command |
| 03:51.58 | brlcad | TODO and BUGS files list dozens of potential things more apropos than the dev quickies |
| 05:16.02 | *** join/#brlcad Calin (~Calin@109.99.20.242) |
| 06:10.40 | *** join/#brlcad Stattrav (~Stattrav@122.167.229.132) |
| 06:10.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 06:42.28 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 07:45.35 | ``Erik | I don't see those cmake tests run on builds, could it be that you had an ntpdate pump that shifted the time back enough to rerun cmake? |
| 08:08.38 | *** join/#brlcad tharis20_ (~tharis@bl21-62-152.dsl.telepac.pt) |
| 08:44.55 | abhi2011 | right , will take care to pastebin next time |
| 10:09.17 | abhi2011 | by the way, I was wondering if my basic patch (id: 3376910) has a usable .diff file |
| 10:29.22 | CIA-62 | BRL-CAD: 03Martinpaul 07http://brlcad.org * r3034 10/wiki/Main_Page: |
| 11:04.39 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 12:33.41 | brlcad | not very likely, and I've seen it before |
| 12:34.09 | brlcad | abhi2011: hadn't looked yet but that's part of that process, to make sure everything is right |
| 12:36.44 | starseeker | cmake will automatically re-run if the CMakeLists.txt files or .cmake files have been changed at all |
| 12:37.38 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3035 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Martinpaul|Martinpaul]] ([[User talk:Martinpaul|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 12:37.48 | abhi2011 | ok thanks brlcad |
| 12:37.53 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Martinpaul]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 12:38.04 | abhi2011 | by the way does opengl support need to be turned on specifically for the autotools build |
| 12:38.38 | abhi2011 | after ./configure, I always get the Build with OpenGL support as ...no |
| 12:38.57 | abhi2011 | consequently after the compile mged does startup |
| 12:39.03 | abhi2011 | but archer does not |
| 12:39.47 | brlcad | archer requires opengl, mged does not |
| 12:40.00 | starseeker | in autotools opengl is off by default |
| 12:40.14 | brlcad | not it's not, it's autodetect by default :) |
| 12:40.35 | brlcad | ah, my bad |
| 12:40.40 | starseeker | eh? |
| 12:40.44 | brlcad | it *was* autodetect at some point |
| 12:40.56 | starseeker | ah :-) |
| 12:41.08 | brlcad | to many turn on, try, turn off doesn't work everywhere attempts |
| 12:47.49 | CIA-62 | BRL-CAD: 03brlcad * r45588 10/brlcad/trunk/include/fb.h: log the exact same thing we tested, print what should be the magic, not a pointer |
| 12:48.35 | CIA-62 | BRL-CAD: 03brlcad * r45589 10/brlcad/trunk/src/conv/ (bot_shell-vtk.c iges/add_loop.c): gcc 4.6 warning quellage |
| 12:55.09 | CIA-62 | BRL-CAD: 03brlcad * r45590 10/brlcad/trunk/src/other/iwidgets/pkgIndex.tcl: should no longer be keeping pkgIndex.tcl files (and other generated files) in the repo now that the msvc files are gone |
| 13:03.53 | CIA-62 | BRL-CAD: 03brlcad * r45591 10/brlcad/trunk/src/ (conv/bot_shell-vtk.c libbu/ptbl.c): call %zu instead of %z to be more consistent with the calls elsewhere |
| 13:19.48 | CIA-62 | BRL-CAD: 03brlcad * r45592 10/brlcad/trunk/src/conv/ (6 files in 3 dirs): more warning quellage. use %p instead of x%x, remove unused vars, cast accordingly |
| 13:22.27 | abhi2011 | right brlcad, so how do i turn it on in autotools |
| 13:36.26 | starseeker | --with-ogl |
| 13:37.59 | abhi2011 | thanks starseeker |
| 13:50.00 | CIA-62 | BRL-CAD: 03brlcad * r45593 10/brlcad/trunk/src/conv/dxf/dxf-g.c: remove unused variables, lots of unimplemented functionality apparently stubbed |
| 13:55.16 | CIA-62 | BRL-CAD: 03brlcad * r45594 10/brlcad/trunk/src/conv/g-egg.c: pass ncpu down through to db_walk_tree since it's only != 1 if user specifies it. remove unused vars. |
| 13:55.32 | CIA-62 | BRL-CAD: 03starseeker * r45595 10/brlcad/trunk/ (3 files in 2 dirs): |
| 13:55.32 | CIA-62 | BRL-CAD: CMake will check for third party libraries every time it is run (or rather, the |
| 13:55.32 | CIA-62 | BRL-CAD: ThirdParty.cmake macro logic will) but default to being quiet about it on |
| 13:55.32 | CIA-62 | BRL-CAD: subsequent runs unless there's actually something to report. By the same token, |
| 13:55.33 | CIA-62 | BRL-CAD: don't keep hammering on the build type. |
| 13:55.54 | starseeker | brlcad: I think that'll take care of the messages you were seeing |
| 14:09.39 | CIA-62 | BRL-CAD: 03brlcad * r45596 10/brlcad/trunk/src/ (17 files in 8 dirs): more gcc 4.6 quellage, eliminate set but unused variables, use void* for %p, and use %zu for size_t. |
| 14:11.57 | abhi2011 | hmm....some other library seems missing |
| 14:11.59 | abhi2011 | http://bin.cakephp.org/view/675147344 |
| 14:12.18 | abhi2011 | i have installed mesaGL, mesaGLU, freeglut |
| 14:15.20 | CIA-62 | BRL-CAD: 03brlcad * r45597 10/brlcad/trunk/src/rt/ (CMakeLists.txt Makefile.am scanline.c scanline.h viewmlt.c): |
| 14:15.20 | CIA-62 | BRL-CAD: remove rtmlt. it was never a completed nor working implementation of metropolis |
| 14:15.20 | CIA-62 | BRL-CAD: light transport. since it's become a maintenance burden (quellage) and isn't |
| 14:15.20 | CIA-62 | BRL-CAD: being worked on by anyone, time for removal. kunigami's progress on the osl |
| 14:15.20 | CIA-62 | BRL-CAD: integration is already further along, so renewed interest can be concentrated |
| 14:15.20 | CIA-62 | BRL-CAD: there. |
| 14:18.00 | brlcad | abhi2011: if you install new packages, you'll need to delete several cache files before rerunning configure, rm -rf *cache* |
| 14:18.21 | brlcad | then rerun configure, make sure it says opengl is enabled at the end |
| 14:19.33 | brlcad | if it still fails, pastebin the build failure from the compile line to the end (i.e., including the gcc line), not just the last few lines |
| 14:20.57 | abhi2011 | ok |
| 14:21.48 | brlcad | halfway through your warning log, so should have that retestable in a day or two |
| 14:23.12 | abhi2011 | ah ok thanks brlcad :) |
| 15:11.09 | CIA-62 | BRL-CAD: 03brlcad * r45598 10/brlcad/trunk/src/rt/CMakeLists.txt: remove trailing ws |
| 15:12.09 | CIA-62 | BRL-CAD: 03brlcad * r45599 10/brlcad/trunk/src/rt/ (scanline.c scanline.h): these files are not specific to rtmlt, partially revert r45597 to restore them |
| 15:15.24 | brlcad | starseeker: have I said how much I really like the subdir rebuilding with cmake, how it rebuilds all deps for a given subdir |
| 15:18.18 | CIA-62 | BRL-CAD: 03brlcad * r45600 10/brlcad/trunk/src/rt/viewarea.c: upgrade rtarea to size_t throughout. should help it handle 'massive' 64-bit geometries better than the previous long/int tracking it was using. |
| 15:21.08 | CIA-62 | BRL-CAD: 03brlcad * r45601 10/brlcad/trunk/src/rt/viewarea.c: reorder functions to avoid forward decls. |
| 15:28.08 | CIA-62 | BRL-CAD: 03brlcad * r45602 10/brlcad/trunk/src/rt/viewcheck.c: do the same for rtcheck, upgrade to counters to size_t |
| 15:33.35 | CIA-62 | BRL-CAD: 03brlcad * r45603 10/brlcad/trunk/src/rt/ (viewarea.c viewcheck.c): ws consistency cleanup |
| 15:46.11 | CIA-62 | BRL-CAD: 03brlcad * r45604 10/brlcad/trunk/src/rt/ (viewweight.c viewxray.c): use argv0 |
| 15:59.27 | CIA-62 | BRL-CAD: 03brlcad * r45605 10/brlcad/trunk/src/libicv/rot.c: use argv[0] instead of bu_getprogname() since the command name should still be there. make sure bu_optind is really 1, though. |
| 16:05.04 | CIA-62 | BRL-CAD: 03brlcad * r45606 10/brlcad/trunk/src/ (4 files in 2 dirs): quellage, set but unused variables, missing variables for print specifiers (crashy crashy) |
| 16:10.08 | CIA-62 | BRL-CAD: 03brlcad * r45607 10/brlcad/trunk/src/bwish/input.c: %S was deprecated a long while back, should be %V for vls |
| 16:27.56 | CIA-62 | BRL-CAD: 03brlcad * r45608 10/brlcad/trunk/src/mged/cmd.c: and this ever worked? hard to imagine a lot of people are using the 'lm' command since it seems to have been passing the wrong argv to ls.. there shouldn't be muves-specific commands in brl-cad anyways. |
| 16:37.25 | CIA-62 | BRL-CAD: 03brlcad * r45609 10/brlcad/trunk/src/proc-db/breplicator.cpp: heh, %0 |
| 16:42.26 | CIA-62 | BRL-CAD: 03brlcad * r45610 10/brlcad/trunk/src/shapes/coil.c: someone's editor leaves trailing whitespace turds all over the place |
| 16:53.46 | CIA-62 | BRL-CAD: 03brlcad * r45611 10/brlcad/trunk/include/fb.h: they're both uint32_t values, not a pointer |
| 17:12.19 | starseeker | brlcad: cool, thanks! glad you're finding something to like with the CMake build, was kinda afraid I was going to make your life miserable for the sake of cross platform building ;-) |
| 17:23.51 | CIA-62 | BRL-CAD: 03brlcad * r45612 10/brlcad/trunk/src/other/libz/ (zconf.h zconf.h.in): what if we just yank the whole _LARGEFILE64_SOURCE hack section. shouldn't need to muck with it. |
| 17:24.39 | brlcad | starseeker: oh, I like it, there's just a lot of polish needed |
| 17:26.04 | brlcad | the autotools build had many years to carefully tweak messages so that things are nearly as clear as possible (given the build infrastructure) making things as easy as possible for compiling-users, even if it meant more work on our end |
| 17:26.29 | brlcad | some of that has regressed a little bit, but nothing that can't be fixed and overall a step forward still |
| 17:29.23 | brlcad | others are just subtle changes here and there |
| 17:29.55 | CIA-62 | BRL-CAD: 03starseeker * r45613 10/brlcad/trunk/src/rt/CMakeLists.txt: |
| 17:29.55 | CIA-62 | BRL-CAD: Add M_LIBRARY to libremrt. BRLCAD_ADDLIB isn't used here because this library |
| 17:29.55 | CIA-62 | BRL-CAD: isn't installed and is only built as a static library - in the (relatively rare) |
| 17:29.55 | CIA-62 | BRL-CAD: cases in BRL-CAD where this is true we just use the raw cmake commands for |
| 17:29.55 | CIA-62 | BRL-CAD: library building rather than obfuscate the logic with more macros. |
| 17:30.55 | starseeker | brlcad: um. if we're going to yank that stuff out of zlib, should we submit a patch back? |
| 17:31.45 | brlcad | sure |
| 17:31.55 | starseeker | admittedly I've got non-vanilla changes in both libpng and zlib right now, but I've been planning to submit them all back to see if I can get 'em included (I'll probably have to upgrade our libpng version to get that to work so I haven't done it yet, but I need to.) |
| 17:32.15 | brlcad | are we up-to-date with zlib"? |
| 17:32.25 | brlcad | thought they had a new rev |
| 17:32.25 | starseeker | unless they've released a new version, yeah |
| 17:32.28 | starseeker | checks |
| 17:32.47 | starseeker | yeah - 1.2.5 |
| 17:33.00 | starseeker | upgraded a long while back to get the cmake file they included in that version |
| 17:33.15 | brlcad | still, that snippet seems a little strange, trying to detect if its set so they can unset it... they shouldn't care |
| 17:33.53 | starseeker | they did a couple odd things in that release - I've seen cases where mixing our zlib with system stuff using a system zlib has caused problems |
| 17:34.12 | brlcad | I'd put a patch into zconf.h to work around a compiler warning, but not into the zconf.h.in file cmake was using |
| 17:34.20 | brlcad | undoubtedly related to erik's later hack |
| 17:35.02 | starseeker | I haven't bugged 'em yet because the zlib CMakeLists.txt change is relatively minor (IIRC) but if we can fix that nonsense and really improve things it becomes worthwhile |
| 17:35.59 | CIA-62 | BRL-CAD: 03brlcad * r45614 10/brlcad/trunk/src/ (24 files in 9 dirs): quell majority remainder of gcc 4.6 warnings from user log. mostly pointer casts, print specifier, and set but unused variable warnings. still need to sort out the %V warnings. |
| 17:38.08 | brlcad | hm, so somewhere in the debug/not-debug settings, it's issuing %V warnings with the cmake build ... gets back to an earlier discussion on how that warning was being suppressed |
| 17:39.19 | brlcad | looks like STRICT_FLAGS isn't being set |
| 17:39.28 | starseeker | um. |
| 17:41.48 | brlcad | I see a snippet in the CMakeLists.txt file, looks like it should be getting set |
| 17:42.16 | starseeker | I may have messed up somewhat with all that... was trying to be clever about having Debug and Release build types "do the right thing" to make life easy |
| 17:42.19 | brlcad | oh, maybe he turned off strict so they got reported... |
| 17:42.44 | brlcad | shakes fist at cmake log for now showing the gcc lines |
| 17:42.49 | brlcad | s/now/not!/ |
| 17:42.59 | brlcad | I love it and hate it |
| 17:43.25 | starseeker | make VERBOSE=1 ? |
| 17:43.26 | brlcad | they gotta fix that |
| 17:43.39 | brlcad | that's not really what I want, though |
| 17:43.43 | brlcad | that's all or nothing |
| 17:43.51 | brlcad | I want to just see the gcc lines for the compiles that fail |
| 17:45.24 | brlcad | kind of like what autogen.sh does, you run the command, capture the output, check the return value; if succeeded, keep quiet, but if failed, show the actual command and error it produced |
| 17:45.50 | brlcad | should be pretty trivial |
| 17:46.04 | brlcad | for some definition of trivial to the cmake devs :) |
| 17:47.01 | brlcad | starseeker: so refresher understanding just to make sure, turning on warnings just turns on all the -Wwhatever warning flags, yes? and turning on strict basically adds -Werror so they halt |
| 17:47.11 | starseeker | right |
| 17:47.28 | brlcad | okay, so then that might be a done deal then |
| 17:47.42 | starseeker | except that when we add Werror I think we turn off that printf one since we can't comply with it |
| 17:47.42 | brlcad | we might be gcc 4.6 clean now, or at least very very close to it |
| 17:47.47 | brlcad | right |
| 17:47.54 | brlcad | that's header logic, though, not build logic |
| 17:48.32 | starseeker | hmm. I might have gilded the lily there - would need to check |
| 17:48.33 | brlcad | keys off of the STRICT_FLAGS setting, that's what had me wondering |
| 17:49.14 | brlcad | wonders where bhinesley is |
| 17:50.45 | brlcad | downloads gcc 4.6 |
| 17:51.03 | starseeker | dunno, haven't heard from him today |
| 17:52.39 | brlcad | wow, make clean doesn't give any output? |
| 17:52.52 | starseeker | nope - just cleans |
| 17:52.55 | brlcad | ouch :) |
| 17:53.14 | starseeker | make clean VERBOSE=1 :-P |
| 17:53.54 | brlcad | some feedback would be useful for a command that takes several minutes to run, locks up I/O, looks like something stuck in an inf loop |
| 17:54.23 | starseeker | brlcad: are you subscribed to the CMake email list? It's usually quite responsive |
| 17:54.33 | brlcad | not at the moment |
| 17:55.03 | starseeker | most of these sorts of questions I end up going to there to try and answer anyway, so you might as well cut out the middleman :-P |
| 17:55.11 | brlcad | wow, make clean is brining this system to its knees, can't even keep up with typing |
| 17:55.21 | starseeker | that's... quite odd |
| 17:56.28 | brlcad | hm, not make |
| 17:56.59 | brlcad | looks like safari went nuts too, maybe the i/o slowness hit some bug |
| 18:09.14 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.90) |
| 18:09.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 18:14.15 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.145.200) |
| 18:28.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.204) |
| 18:28.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 18:31.51 | abhi2011 | does brlcad depend on libdm ? |
| 18:32.12 | abhi2011 | because the build fails on a file which uses libdm |
| 18:32.28 | abhi2011 | dm-ogl.c |
| 18:32.33 | starseeker | libdm is one of BRL-CAD's libraries |
| 18:32.36 | starseeker | what's the error? |
| 18:33.42 | abhi2011 | http://bin.cakephp.org/view/1720792653 |
| 18:34.15 | abhi2011 | i did configure before with ogl |
| 18:34.33 | starseeker | um. You're building with autotools I take it? |
| 18:34.40 | abhi2011 | yes |
| 18:34.45 | abhi2011 | i ll try make clean |
| 18:34.50 | abhi2011 | and configure again |
| 18:34.53 | starseeker | libdm built with opengl enabled? |
| 18:35.16 | starseeker | what that looks like offhand is that mged is being built with opengl on but libdm was built with it off - odd |
| 18:35.22 | abhi2011 | well i havent checked the complete logs yet |
| 18:35.33 | abhi2011 | hmmm |
| 18:36.07 | abhi2011 | maybe the cache was not clean from the previous builds |
| 18:36.17 | starseeker | I'd try that first - clean build |
| 18:36.28 | abhi2011 | yep |
| 18:42.05 | brlcad | abhi2011: you have to clean the cache and, of course, also delete your previous builds.... |
| 18:42.25 | abhi2011 | right |
| 18:42.36 | brlcad | so not just rm -rf *cache* |
| 18:42.41 | brlcad | but also make clean |
| 18:43.05 | brlcad | might be easier for you to just start fresh since the build system seems to be a bit foreign |
| 18:43.19 | brlcad | with a new checkout |
| 18:48.04 | CIA-62 | BRL-CAD: 03starseeker * r45615 10/brlcad/trunk/src/other/iwidgets.dist: Ain't there so don't ignore it anymore. |
| 18:48.07 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net) |
| 18:48.15 | starseeker | bhinesley: howdy :-) |
| 18:48.33 | bhinesley | starseeker: hello :) |
| 18:48.37 | abhi2011 | right, i ll checkout fresh |
| 18:48.51 | starseeker | bhinesley: how goes the edit.c work? |
| 18:49.18 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.204) |
| 18:49.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 18:49.33 | bhinesley | it's going good |
| 18:49.43 | bhinesley | taking a lot longer than I thought |
| 18:49.50 | bhinesley | but good |
| 18:50.07 | starseeker | you're working on option parsing still, or is that wrapping up? |
| 18:50.21 | bhinesley | that's done, more or less |
| 18:50.48 | starseeker | cool - so what's your next step? |
| 18:52.04 | bhinesley | ged_edit passes off to edit(), which will build the (point_t) arguments for the subcommands |
| 18:52.42 | bhinesley | so the next step is edit(); do command specific argument validation, convert objects + offsets to points, and pass off to the subcommands to do the work |
| 18:53.01 | bhinesley | oh, and edit() handles the batch operations |
| 18:53.23 | *** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242) |
| 18:53.36 | bhinesley | so if "." is specified as an object, it will convert that to multiple calls to the subcommand, replacing "." with the next object being operated on |
| 18:53.47 | starseeker | brlcad: ah-ha http://mail.madler.net/pipermail/zlib-devel_madler.net/2011-June/002581.html |
| 18:54.54 | bhinesley | misses colored nicks in irssi |
| 18:56.11 | starseeker | bhinesley: cool :-) |
| 18:56.45 | brlcad | bhinesley: were your ears burning? |
| 18:57.09 | bhinesley | brlcad: my ears? |
| 18:57.22 | brlcad | was just talking about you a little while ago |
| 18:57.28 | bhinesley | oh :) |
| 18:58.16 | bhinesley | good things I hope ;-) |
| 18:58.18 | starseeker | gah - zlib doesn't seem to have a public dev repository! |
| 18:58.54 | brlcad | starseeker: you mean, https://gforge.sci.utah.edu/gf/project/zlib/scmsvn/ ? |
| 18:59.36 | starseeker | mutter - how'd I miss that? |
| 18:59.50 | brlcad | starseeker: doesn't look like cmake even provides what I'd want for make clean |
| 19:00.25 | brlcad | make clean VERBOSE=1 doesn't really show anything useful, just a bunch of cd calls and sub-make reinvocations (and VERBOSE isn't preserved) |
| 19:00.59 | starseeker | brlcad: true, but it does at least give you feedback that something is happening |
| 19:01.12 | brlcad | I'd want to see either what files are being deleted, what directories/targets are being processed, or both |
| 19:01.16 | brlcad | actual files |
| 19:01.26 | starseeker | nods - yeah, I don't know of any way to get it to do that |
| 19:01.36 | starseeker | never really cared, personally... |
| 19:01.56 | brlcad | usability nitpick |
| 19:02.05 | brlcad | if it was instant, wouldn't care .. but it takes several minutes |
| 19:03.06 | starseeker | growl. Looks like vanilla zlib won't be workable at least until they stick 1.2.6 up somewhere |
| 19:03.13 | brlcad | I can't glance at it and tell if it's got 2 seconds or 200 seconds remaining, or if it's just stuck |
| 19:03.58 | starseeker | you're on a Mac? |
| 19:04.10 | brlcad | sometimes |
| 19:04.23 | bhinesley | 's panic subsides; ahh, colored nicks |
| 19:04.24 | starseeker | I mean, the make clean is taking several minutes on a mac? |
| 19:04.49 | brlcad | my previous build was, yes |
| 19:04.59 | brlcad | could have been related to safari going nuts |
| 19:04.59 | starseeker | tries it on Linux quick... |
| 19:05.06 | brlcad | but that's the point, there's zero feedback |
| 19:05.39 | starseeker | took < 10 seconds here |
| 19:05.42 | brlcad | if your linux box is thrashing or if you were on an nfs filesystem, the same would affect you there |
| 19:06.36 | brlcad | a second pass make clean only takes a few seconds here too, several factors |
| 19:07.31 | brlcad | otherwise by that same logic, I wouldn't need 'top' because well, most of the time everything runs fine |
| 19:08.03 | starseeker | nods - oh, I see the logic but that's probably why it wasn't a high priority for them |
| 19:12.02 | brlcad | yeah, even an already cleaned build takes about 20 seconds |
| 19:12.11 | brlcad | proably all of the reinvocations of make for every target |
| 19:12.30 | brlcad | that and this laptop isn't the quickest |
| 19:14.02 | starseeker | tosses together an email to the zlib devs... |
| 19:15.23 | brlcad | starseeker: how about a simple echo/output line on the clean rule that just says "Deleting build files, please wait..." |
| 19:15.31 | brlcad | where would that go? |
| 19:16.18 | starseeker | brlcad: unfortunately, the clean rule isn't something that can be user-modified yet - IIRC that's one of the issues they most commonly get requested to fix |
| 19:16.25 | starseeker | checks archives... |
| 19:17.01 | brlcad | ah, k |
| 19:17.03 | starseeker | http://www.cmake.org/pipermail/cmake/2006-October/011477.html |
| 19:17.26 | starseeker | old email though - don't know what current status is |
| 19:17.33 | brlcad | yeah, quite |
| 19:18.31 | starseeker | yeah, still an issue in 09: http://www.cmake.org/pipermail/cmake/2009-January/026727.html |
| 19:20.01 | starseeker | somewhat related: http://www.cmake.org/Bug/view.php?id=10424 |
| 19:21.02 | starseeker | ah, I think this was the actual issue: http://www.cmake.org/Bug/view.php?id=6183 |
| 19:22.51 | brlcad | it's not clear if that last one is saying that it's not possible or that it is possible given that additional info statemetn |
| 19:23.23 | starseeker | as far as I know it's not possible, but then I haven't really pushed hard to try it |
| 19:23.23 | brlcad | or are they just saying "it wouldn't be hard to support adding custom commands" |
| 19:23.37 | starseeker | I think so - I think the guy making the report was making the case that it's a simple change |
| 19:23.58 | starseeker | I've seen other comments on the issue (that I can't scare up right now) that indicated it wasn't quite so simple though |
| 19:24.07 | brlcad | k |
| 19:24.14 | brlcad | I'll suck it up for now |
| 19:24.27 | starseeker | (I suppose patches welcome :-P) |
| 19:43.54 | bhinesley | is it okay to use SMALL_FASTF/MAX_FASTF as sentinal values? |
| 19:44.16 | starseeker | what do you mean by sentinal values? |
| 19:44.38 | bhinesley | I could use a way to indicate that a particular coordinate of a vector has not been set |
| 19:45.10 | bhinesley | so could I set, say coord[1] = MAX_FASTF, since it will never be used in practice |
| 19:45.22 | starseeker | oh - I believe that's workable |
| 19:45.25 | starseeker | brlcad? |
| 19:59.25 | *** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242) |
| 20:10.37 | CIA-62 | BRL-CAD: 03starseeker * r45616 10/brlcad/trunk/src/other/libpng/ (175 files in 21 dirs): |
| 20:10.37 | CIA-62 | BRL-CAD: libpng-1.5.x is the current stable libpng series now. Update to libpng 1.5.4, |
| 20:10.37 | CIA-62 | BRL-CAD: 'cause that's what all the cool kids are doing. (API cleanup is a good thing, |
| 20:10.37 | CIA-62 | BRL-CAD: too...) Starting with a vanilla check-in, will probably need to re-apply |
| 20:10.37 | CIA-62 | BRL-CAD: Makefile.am changes and will definitely need to port CMakeLists.txt changes |
| 20:10.38 | CIA-62 | BRL-CAD: forward. Will be submitting the CMakeLists.txt changes back to see if we can |
| 20:10.39 | CIA-62 | BRL-CAD: get them included in the next version of libpng. |
| 20:12.13 | CIA-62 | BRL-CAD: 03starseeker * r45617 10/brlcad/trunk/src/ (fb/fb-png.c libged/png.c other/libpng.dist util/pix-png.c): fix header includes for 1.5 libpng - need explicit zlib.h in a couple places. |
| 20:16.24 | *** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242) |
| 20:21.57 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) |
| 20:22.22 | brlcad | bhinesley: those are terrible sentinal values because they're frequently valid and will match a simple == 0 comparison |
| 20:22.45 | brlcad | usual practice is either a separate set/unset variable flag |
| 20:22.58 | brlcad | or use -INFINITY/INFINITY |
| 20:23.22 | brlcad | which still isn't full-proof safe, but "good enough" in practice |
| 20:23.34 | starseeker | brlcad: hmm. do similar concerns apply to the use of (say) MAX_INT? |
| 20:24.33 | brlcad | presuming you mean INT_MAX, that's effectively == INFINITY for the int type |
| 20:24.40 | bhinesley | alright, the flags will work fine; I already have a mechanism for that |
| 20:24.44 | starseeker | ah, k |
| 20:25.04 | brlcad | it's harder for integer types, though, since you can interate to infinity pretty easily |
| 20:25.23 | brlcad | so the code has to work harder to make sure you're always < INT_MAX, not <= |
| 20:25.32 | brlcad | better is flags ;) |
| 20:29.05 | LainIwakuraX | brlcad: I'm here for about...2 hours and here again later tonight if you were going to test the patch I made (and want me here for the testing) |
| 20:30.56 | starseeker | LainIwakuraX: are you applying to the ESA Summer of Code? |
| 20:32.12 | LainIwakuraX | starseeker: No, although I am qualified. |
| 20:32.51 | starseeker | LainIwakuraX: awesome work wading through that SCLString code :-) |
| 20:33.10 | LainIwakuraX | It wasn't that bad =P |
| 20:33.46 | LainIwakuraX | Should I apply for ESA Summer of Code? The thing stopping me was the proposal...it seems hard =/ |
| 20:33.58 | brlcad | LainIwakuraX: maybe not that hard, but editing about 900 lines that have to be manually adapted is still a lot of appreciated effort |
| 20:34.10 | LainIwakuraX | Ah |
| 20:34.22 | LainIwakuraX | When I got tired |
| 20:34.24 | LainIwakuraX | in vim |
| 20:34.31 | LainIwakuraX | :%s/SCLstring/std::string/g |
| 20:34.34 | LainIwakuraX | >_> |
| 20:34.51 | brlcad | :) |
| 20:35.06 | brlcad | that's the easy part, then you had to adapt all of the callers |
| 20:35.10 | starseeker | LainIwakuraX: what seemed hard about the proposal? |
| 20:35.19 | brlcad | of course, still have to see if it actually works ;) |
| 20:36.00 | LainIwakuraX | starseeker: A lot of the projects being proposed are a bit advanced, I'm only going into my second year of comp sci. at University |
| 20:36.35 | bhinesley | LainIwakuraX: me too, but I was accepted into GSoC |
| 20:36.36 | bhinesley | :) |
| 20:36.40 | starseeker | LainIwakuraX: http://brlcad.org/wiki/STEP_Libraries |
| 20:36.42 | starseeker | :-P |
| 20:37.06 | starseeker | http://brlcad.org/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas, under Geometry Conversion Projects |
| 20:37.17 | LainIwakuraX | uhh |
| 20:37.19 | LainIwakuraX | I see |
| 20:37.27 | LainIwakuraX | I guess I will apply lol |
| 20:37.47 | bhinesley | well, third actually... but I'm only just now transferring to the university after taking a grand total of 3 programming classes |
| 20:37.53 | LainIwakuraX | ah |
| 20:38.31 | LainIwakuraX | I've only taken 1 C++ course..but I had a good teacher =P |
| 20:38.41 | bhinesley | I thought the same thing that you did though. I saw a bunch of PhD/Masters students and thought that I was out of my leauge, but here I am. |
| 20:38.46 | brlcad | yay, got step-g to crash |
| 20:38.53 | LainIwakuraX | uh oh |
| 20:39.05 | bhinesley | LainIwakuraX: same here. I've taken Java, C, and C++, but that's it. |
| 20:39.26 | LainIwakuraX | brlcad: are you treating warnings as errors? |
| 20:39.26 | brlcad | LainIwakuraX: not your patch |
| 20:39.29 | LainIwakuraX | oh |
| 20:39.35 | LainIwakuraX | don't scare me lol |
| 20:40.18 | brlcad | test file I fed it was a bit insane |
| 20:41.08 | starseeker | LainIwakuraX: when I saw your patch I actually thought it was your patch submission for the ESA SoC application :-P |
| 20:41.53 | LainIwakuraX | No, I just wanted to get involved ._. |
| 20:42.01 | starseeker | awesome :-) |
| 20:42.09 | LainIwakuraX | I guess I'll reference the patch on my application though |
| 20:43.09 | LainIwakuraX | Where do I go to apply? I lost the link |
| 20:43.45 | starseeker | http://sophia.estec.esa.int/socis2011/ |
| 20:43.55 | starseeker | http://brlcad.org/wiki/ESA_Summer_of_Code_in_Space |
| 20:45.17 | LainIwakuraX | How many hours does this usually take up? I did that SCLstring thing in about 5 hours, but I do have a part-time job in web development |
| 20:48.29 | LainIwakuraX | Hm..I guess it'd depend a lot on what you were doing |
| 20:49.14 | brlcad | LainIwakuraX: it's generally expected that the SoC programs constitute full-time 40+ hours effort |
| 20:49.36 | brlcad | if you have another job, might just want to keep it to a hobby .. less pressure, much more fun ;) |
| 20:49.42 | brlcad | scratch your own itches |
| 20:49.53 | starseeker | LainIwakuraX: yeah, definitely the low-pressure way to go |
| 20:50.03 | LainIwakuraX | brlcad: My other job is pretty...flexible |
| 20:50.12 | LainIwakuraX | I'm applying =P |
| 20:51.28 | brlcad | :) |
| 20:52.31 | brlcad | another thing to keep in mind, given a space agency is sponsoring this, given two roughly equivalent applicants .. priority will go towards development that is directly space-related |
| 20:52.47 | LainIwakuraX | Mhm |
| 20:52.56 | brlcad | having two "roughly equivalent" applicants is unlikely, but worth saying nonetheless ;) |
| 20:53.12 | brlcad | well, no compilation failures with the step patch |
| 20:54.42 | LainIwakuraX | =P I wasn't lying |
| 21:03.00 | CIA-62 | BRL-CAD: 03brlcad * r45618 10/brlcad/trunk/src/ (44 files in 10 dirs): |
| 21:03.00 | CIA-62 | BRL-CAD: apply sf patch 3376896 (All instances of SCLstring changed to std::string) from |
| 21:03.00 | CIA-62 | BRL-CAD: lainiwakurax. patch converts scl converts almost all instances of SCLstring in |
| 21:03.00 | CIA-62 | BRL-CAD: SCL to standard STL strings. tested minimally with a few ap203 conversions that |
| 21:03.00 | CIA-62 | BRL-CAD: all seemed to parse and convert equivalently. outstanding. |
| 21:03.51 | LainIwakuraX | It worked? |
| 21:05.18 | CIA-62 | BRL-CAD: 03brlcad * r45619 10/brlcad/trunk/AUTHORS: credit Zach Easterbrook (lainiwakurax) as a code contributor with his code patch that converted SCLstring to std::string in src/conv/step and src/other/step. thanks, Zach! |
| 21:05.34 | brlcad | looks like it |
| 21:05.39 | LainIwakuraX | =D Awesome |
| 21:07.30 | brlcad | yeah, quite |
| 21:08.19 | LainIwakuraX | I'm not surprised there wasn't much of a time difference, their functions were very similar to the ones in std::string |
| 21:08.20 | CIA-62 | BRL-CAD: 03brlcad * r45620 10/brlcad/trunk/TODO: lainiwakurax replaced SCLstring with std::string (via sf patch 3376896) |
| 21:08.34 | brlcad | the implementation of those functions are quite different |
| 21:08.48 | LainIwakuraX | Ah |
| 21:09.24 | brlcad | I noticed a few dozen instances of SCLstring still remain, were they problematic? |
| 21:09.33 | brlcad | or did you only fix the ones that affected compilation? |
| 21:09.52 | LainIwakuraX | I'd say I fixed 99% of them...there were some in blocks like this: |
| 21:09.58 | LainIwakuraX | #ifdef __OSTORE__ |
| 21:10.06 | LainIwakuraX | and they used a function (get_os_typespec) |
| 21:10.11 | LainIwakuraX | and I didn't know what it did |
| 21:10.47 | LainIwakuraX | soo I focused on the ones where I knew what was going on |
| 21:14.20 | LainIwakuraX | one sec I'm finding the spot where that is |
| 21:14.21 | brlcad | yeah, OSTORE is a bit of a mystery, but looks like a partial interface for automatic serialization for an object store |
| 21:14.52 | brlcad | don't see anything that turns OSTORE on/off, though |
| 21:15.22 | LainIwakuraX | if you go to errordesc.cc in clutils |
| 21:15.33 | LainIwakuraX | around line 189 you'll see some spots where it's still SCLstring |
| 21:15.40 | LainIwakuraX | they're in those blocks |
| 21:15.59 | brlcad | nods |
| 21:16.09 | brlcad | those OSTORE blocks can probably just be deleted |
| 21:16.22 | LainIwakuraX | wait, there is stuff in else blocks |
| 21:16.35 | LainIwakuraX | that I didn't catch =/ would those matter? |
| 21:17.18 | LainIwakuraX | http://codepad.org/lsTE2mHV |
| 21:17.22 | brlcad | probably, but apparently they're self-contained |
| 21:17.33 | brlcad | probably got lucky since they're just used for error reporting |
| 21:18.06 | brlcad | fg |
| 21:18.54 | LainIwakuraX | I'll fix those instances in the else's in a few minutes, to be safe |
| 21:19.10 | brlcad | the final test will be the removal of the sclstring class |
| 21:19.24 | LainIwakuraX | mhm |
| 21:19.36 | CIA-62 | BRL-CAD: 03starseeker * r45621 10/brlcad/trunk/src/other/step/src/clutils/ (CMakeLists.txt scl_string.cc scl_string.h): Doesn't look like scl_string.cc/h are being used - yank |
| 21:20.27 | brlcad | heh |
| 21:20.34 | brlcad | starseeker: it's still used in a few places |
| 21:20.44 | starseeker | builds |
| 21:20.51 | brlcad | maybe not in a portion enabled in our build |
| 21:24.40 | starseeker | man - no indication in the docs as to what OSTORE is for that I can see |
| 21:25.21 | LainIwakuraX | should I bother fixing the SCLstring instances in those OSTORE blocks? |
| 21:25.49 | starseeker | brlcad: what do you think? |
| 21:26.51 | starseeker | LainIwakuraX: I think you can try switching it in errordecs.h to start and see what follows... |
| 21:27.37 | LainIwakuraX | k |
| 21:28.12 | CIA-62 | BRL-CAD: 03brlcad * r45622 10/brlcad/trunk/src/other/libpng/ (8 files): remove autogenerated build files. have to play nicely with autotools build until it's obsolete. |
| 21:30.03 | LainIwakuraX | since you removed those files...I'm getting a cmake error |
| 21:30.14 | LainIwakuraX | CMake Error at misc/CMake/BRLCAD_Util.cmake:214 (MESSAGE): Attempting to ignore non-existent file /home/yuki/bin/brlcad/src/other/step/src/clutils/scl_string.h |
| 21:30.24 | starseeker | LainIwakuraX: er, sorry |
| 21:30.30 | starseeker | got a bit too eager |
| 21:30.34 | LainIwakuraX | =P |
| 21:31.04 | brlcad | ignore the OSTORE blocks |
| 21:31.20 | LainIwakuraX | kk |
| 21:31.23 | brlcad | or separate patch to remove them |
| 21:32.05 | CIA-62 | BRL-CAD: 03starseeker * r45623 10/brlcad/trunk/src/other/step/src/clutils/ (scl_string.cc scl_string.h): Wait until we're sure they're gone. |
| 21:33.00 | CIA-62 | BRL-CAD: 03starseeker * r45624 10/brlcad/trunk/src/other/step/src/clutils/CMakeLists.txt: CMakeLists.txt too |
| 21:33.46 | LainIwakuraX | I'm thinking of proposing this: http://brlcad.org/wiki/Density_functions |
| 21:34.07 | LainIwakuraX | thoughts? It seems interesting |
| 21:34.23 | LainIwakuraX | and I like functions..for describing things =P |
| 21:36.37 | brlcad | thoughts as in? |
| 21:36.49 | starseeker | heh - had enough of the SCL code? :-P Main thing is to pick something you think would interest you and you'd enjoy working on |
| 21:36.56 | brlcad | it's an interesting priority topic, very very closely related to another non-priority topic too: http://brlcad.org/wiki/Material_and_Shader_Objects |
| 21:37.39 | LainIwakuraX | Hm, well it's listed as "difficult" but the SCLstring thing was "medium" and I did it in 5 hours |
| 21:38.44 | LainIwakuraX | So you guys know more about this system =/ do you think it'd be fun and challenging? |
| 21:40.05 | LainIwakuraX | But still reasonable enough for someone who hasn't worked on BRL-CAD |
| 21:40.07 | LainIwakuraX | I suppose |
| 21:42.50 | brlcad | heh, "medium" in terms of being a quickie |
| 21:43.02 | starseeker | LainIwakuraX: we can't guide you too much - you're the one who will know what is interesting. I will say that when we say it's "HARD" we generally aren't kidding |
| 21:43.04 | brlcad | that's on a rough "doable within a couple days" scale |
| 21:43.27 | brlcad | the summer of code projects are on a doable within a couple months scale" |
| 21:44.11 | LainIwakuraX | Ah |
| 21:44.49 | LainIwakuraX | Well, I'll research this a bit and have the submission sometime tonight |
| 21:45.05 | starseeker | the SCLstring thing basically was a warm up for the Step Library cleanup task |
| 21:45.10 | starseeker | there's a lot more waiting |
| 21:45.18 | LainIwakuraX | ah |
| 21:45.38 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3036 10/wiki/Contributor_Quickies: LainIwakuraX converted scl to stl, sclstring to std::string |
| 21:46.20 | starseeker | LainIwakuraX: notice too that although all of the functional instances of SCLstring were changed, it's still not quite fully purged |
| 21:47.54 | starseeker | brlcad: I didn't see the ESA task criteria (if any) - did they lay out particular areas they wanted to see worked? |
| 21:49.03 | brlcad | not in specific detail, similar to gsoc they're mostly hands off but their interest (and the business case to their management) is pretty clear |
| 21:49.19 | starseeker | yeah, looks like the OSTORE stuff involves something called ostore.h, which isn't in the NIST repostory |
| 21:49.32 | brlcad | starseeker: I wouldn't worry about OSTORE, it's dead code |
| 21:49.37 | brlcad | no way to turn it on means it's dead |
| 21:49.38 | starseeker | nods |
| 21:49.51 | brlcad | sounds like something that would be added for CORBA |
| 21:49.56 | starseeker | winces |
| 21:50.20 | brlcad | so just yank it |
| 21:50.26 | starseeker | nods |
| 21:50.46 | brlcad | goes to coach for a bit |
| 21:52.13 | LainIwakuraX | Question about the density functions, it says: "Material objects should be BRL-CAD database objects that can be referenced (by name) by other db objects" |
| 21:52.19 | LainIwakuraX | Are these objects like, structs? |
| 21:52.42 | starseeker | no, that's referring to an object in a BRL-CAD .g database |
| 21:52.51 | LainIwakuraX | Ah |
| 21:53.24 | LainIwakuraX | Is there a brief way to describe how these objects are formed? |
| 21:57.45 | CIA-62 | BRL-CAD: 03starseeker * r45625 10/brlcad/trunk/src/other/step/src/ (clstepcore/ExpDict.cc clstepcore/sdaiSelect.cc clutils/Str.h): Remove some commented out code containing SCLstring |
| 21:58.23 | starseeker | LainIwakuraX: not really a "brief" way - you can look at the primitives in src/librt/primitives for some examples... |
| 21:59.42 | LainIwakuraX | kk |
| 22:10.18 | LainIwakuraX | I can submitted a link to a google doc document for the proposal, correct? |
| 22:10.30 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 22:10.49 | starseeker | LainIwakuraX: dunno, question for brlcad |
| 22:11.17 | LainIwakuraX | ah |
| 22:20.14 | CIA-62 | BRL-CAD: 03starseeker * r45626 10/brlcad/trunk/src/other/step/src/ (5 files in 2 dirs): remove remainder of SCLstring uses |
| 22:27.59 | LainIwakuraX | I'm out for a while, see you guys in ~2 hrs |
| 22:43.02 | abhi2011 | got archer runnning finally |
| 22:43.26 | abhi2011 | got a funny opengl warning as well : OpenGL Warning: No pincher, please call crStateSetCurrentPointers() in your SPU |
| 22:45.49 | abhi2011 | wow!!..rt just rox! |
| 22:45.58 | abhi2011 | rendered a sphere :P |
| 22:59.59 | CIA-62 | BRL-CAD: 03starseeker * r45627 10/brlcad/trunk/src/other/step/src/ (17 files in 3 dirs): Take a stab at removing scl_string altogether. |
| 23:04.46 | *** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ) |
| 23:05.00 | starseek1r | ah, fudge - step-g isn't working for me |
| 23:11.13 | starseeker | happened after the initial application of the patch (on Linux) |
| 23:11.31 | starseeker | LainIwakuraX: can you build BRL-CAD as a whole? |
| 23:11.47 | starseeker | I'm getting the following error: |
| 23:11.48 | starseeker | terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct NULL not valid |
| 23:11.51 | starseeker | Aborted |
| 23:14.44 | starseeker | running the command ./bin/step-g -o test.g ../brlcad/src/other/step/data/ap203/cube1.p21 |