| 00:12.45 | starseeker | auuuuugh |
| 00:12.58 | starseeker | somehow the cmake tclscripts stuff didn't get committed |
| 01:03.05 | *** join/#brlcad crazy_imp (~mj@a89-182-201-14.net-htp.de) | |
| 01:38.25 | CIA-29 | BRL-CAD: 03starseeker * r42307 10/brlcad/branches/cmake/src/other/libtermlib/CMakeLists.txt: Put etc/termcap in the BRL-CAD data dir, not a toplevel etc - remains to be seen if this will work, but if it can work it's the way to go. |
| 01:39.10 | CIA-29 | BRL-CAD: 03starseeker * r42308 10/brlcad/branches/cmake/src/vfont/CMakeLists.txt: For completeness, duplicate vfont data in build tree. |
| 01:40.58 | CIA-29 | BRL-CAD: 03starseeker * r42309 10/brlcad/branches/cmake/src/tclscripts/ (17 files in 17 dirs): Gah. Committed the libtclcad change, but didn't commit any of the CMakeLists.txt files that might have made it work. Change where things are put in the build tree for tcl scripts. |
| 04:42.29 | CIA-29 | BRL-CAD: 03starseeker * r42310 10/brlcad/branches/cmake/CMakeLists.txt: For now we need Curses in the CMake build, but that needs to be fixed. |
| 05:07.17 | *** join/#brlcad recyclops (~erin@cpe-024-163-114-145.nc.res.rr.com) | |
| 05:29.03 | CIA-29 | BRL-CAD: 03starseeker * r42311 10/brlcad/branches/cmake/src/tclscripts/geometree/CMakeLists.txt: Whoops, spelling error. |
| 05:34.19 | CIA-29 | BRL-CAD: 03starseeker * r42312 10/brlcad/branches/cmake/src/libtclcad/tclcadAutoPath.c: |
| 05:34.19 | CIA-29 | BRL-CAD: Have tclcadAutoPath look for share/brlcad/ - should have the same impact as |
| 05:34.19 | CIA-29 | BRL-CAD: using bu_brlcad_root in the tcl scripts. This has the drawback of only allowing |
| 05:34.19 | CIA-29 | BRL-CAD: the build dir executables to run when run from the build toplevel, so perhaps |
| 05:34.19 | CIA-29 | BRL-CAD: the share/brlcad path should be augmented by knowledge based on the executable |
| 05:34.19 | CIA-29 | BRL-CAD: path and the current working dir... |
| 05:40.23 | CIA-29 | BRL-CAD: 03johnranderson * r42313 10/jbrlcad/trunk/ (4 files in 3 dirs): Runner script now uses maven dependency plugin to construct classpath. |
| 06:02.16 | CIA-29 | BRL-CAD: 03brlcad * r42314 10/brlcad/trunk/BUGS: g2asc+asc2g of .g with colortable fails. |
| 07:23.03 | CIA-29 | BRL-CAD: 03brlcad * r42315 10/brlcad/trunk/configure.ac: |
| 07:23.03 | CIA-29 | BRL-CAD: really can't think of a better way to do this. suggestions? still need to |
| 07:23.03 | CIA-29 | BRL-CAD: verify, but different versions of Mac OS X use different debug symbols types and |
| 07:23.03 | CIA-29 | BRL-CAD: are not in sync with gdb (i.e., -ggdb3 doesn't work across library boundaries on |
| 07:23.03 | CIA-29 | BRL-CAD: 10.4). cheat and call the sw_vers command to get the system version, used that |
| 07:23.03 | CIA-29 | BRL-CAD: to test for a debug debug flag type. |
| 07:34.04 | CIA-29 | BRL-CAD: 03brlcad * r42316 10/brlcad/trunk/ (BUGS src/libged/wdb_obj.c): |
| 07:34.04 | CIA-29 | BRL-CAD: apply a fix for sf bug 3159020 reported by jra regarding asc2g's failure to |
| 07:34.04 | CIA-29 | BRL-CAD: recognize the 'color' command. this was due to libged refactoring where 'db |
| 07:34.04 | CIA-29 | BRL-CAD: color' was no longer valid. this fix restores the migrated commands as |
| 07:34.04 | CIA-29 | BRL-CAD: subcommands of db, iterating over the list and running the command against the |
| 07:34.05 | CIA-29 | BRL-CAD: current wdbp nad stashing the result. should once again be able to successfully |
| 07:34.06 | CIA-29 | BRL-CAD: run: g2asc ktank.g new.asc && asc2g new.asc newtank.g |
| 07:48.20 | CIA-29 | BRL-CAD: 03brlcad * r42317 10/brlcad/trunk/NEWS: |
| 07:48.20 | CIA-29 | BRL-CAD: fixed asc2g color command lines. this is a fix for sf bug 3159020 reported by |
| 07:48.20 | CIA-29 | BRL-CAD: jra where he showed g2asc + asc2g on ktank resulted in an error message. bug |
| 07:48.20 | CIA-29 | BRL-CAD: was due to libged refactoring where 'db color' was no longer valid. the fix |
| 07:48.20 | CIA-29 | BRL-CAD: restored several migrated commands as subcommands of db, iterating over the list |
| 07:48.20 | CIA-29 | BRL-CAD: and running the command against the current wdbp nad stashing the result. |
| 08:25.48 | CIA-29 | BRL-CAD: 03brlcad * r42318 10/brlcad/trunk/src/gtools/g_diff.c: |
| 08:25.48 | CIA-29 | BRL-CAD: seems over-complicated, simplify. just compare the first to the second, and the |
| 08:25.48 | CIA-29 | BRL-CAD: second to the first since all we do is print both if there's a difference. fix |
| 08:25.48 | CIA-29 | BRL-CAD: two bugs in the process, one that caught colortable changes with g2asc + asc2g |
| 08:25.48 | CIA-29 | BRL-CAD: of ktank when there were none due to resetting the wrong found1 var to zero in |
| 08:25.48 | CIA-29 | BRL-CAD: the found2's loop. the second was printing color commands if we're v4. |
| 08:28.31 | CIA-29 | BRL-CAD: 03brlcad * r42319 10/brlcad/trunk/NEWS: |
| 08:28.32 | CIA-29 | BRL-CAD: discovered a bug in g_diff during the testing of jra's g2asc+asc2g ktank bug |
| 08:28.32 | CIA-29 | BRL-CAD: report on colortables. it reported differences where there were none due to |
| 08:28.32 | CIA-29 | BRL-CAD: resetting the wrong variable. also fixed a bug printing color lines for v4, but |
| 08:28.33 | CIA-29 | BRL-CAD: much less noticable. |
| 08:41.16 | Ralith | hacking machine |
| 08:44.12 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:49.46 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:09.34 | *** join/#brlcad mafm (~mafm@32.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 14:22.58 | *** join/#brlcad electioneered (~erin@cpe-024-163-114-145.nc.res.rr.com) | |
| 15:05.01 | *** join/#brlcad electioneered_ (~erin@cpe-024-163-114-145.nc.res.rr.com) | |
| 15:50.20 | starseeker | brlcad: Can I suggest one file thing for bu_brlcad_root to try? If a path is supplied and not found in the current dir, what about looking in bu_argv0_full_path() - bu_getprogname + ../ ? |
| 15:51.12 | starseeker | (i.e. if the invocation binary is /usr/weirdpath/bin/bwish, the last rule would look in /usr/weirdpath/bin/../ |
| 15:53.15 | starseeker | this would result in a build-dir BRL-CAD being runnable from anywhere the binary is invoked (if I'm thinking about this right) and offhand I'm not seeing how it's any more of a security problem than checking in the current dir after everything has failed. |
| 15:53.58 | starseeker | I'm willing to take a stab at implementing it, but wanted to run it by you first |
| 16:17.26 | brlcad | starseeker: it already does that |
| 16:17.34 | brlcad | third search |
| 16:26.10 | starseeker | brlcad: that's only using bu_getprogname() |
| 16:27.56 | brlcad | not exactly |
| 16:31.03 | brlcad | hm, actually you might have caught something there |
| 16:31.12 | brlcad | getprogname used to return the full path |
| 16:32.43 | brlcad | so when the whereis search moved to a different function, bu_getprogname() isn't the right call any more |
| 16:32.51 | brlcad | root is probably no longer became relocatable |
| 16:33.01 | brlcad | needs some testing |
| 16:34.41 | starseeker | this works for me: |
| 16:34.43 | starseeker | <PROTECTED> |
| 16:34.43 | brlcad | because what you suggest is the third (and most important) search path -- so need to verify what it's actually searching now and what that'll look like with a bu_argv0_full_path() replacement |
| 16:34.43 | starseeker | <PROTECTED> |
| 16:35.59 | starseeker | bu_argv0_full_path will return "." if you invoke in the same dir as the binary, which doesn't help |
| 16:36.27 | brlcad | that sounds like a bug then, doesn't it? |
| 16:36.35 | starseeker | was devoutely hoping so :-P |
| 16:37.43 | starseeker | would be nice if I'm actually beginning to understand this... |
| 16:38.06 | brlcad | like I said, have to diagnose exactly what it's doing presently before changing it in case the code is being misread |
| 16:38.21 | brlcad | specifically, what that third test path looks like |
| 16:40.07 | starseeker | when I debug, it's always just the name of the program (bwish, mged, etc.) |
| 16:43.42 | brlcad | that doesn't sound right |
| 16:43.54 | brlcad | what does the argv0 variable end up being? |
| 16:44.29 | CIA-29 | BRL-CAD: 03starseeker * r42320 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: |
| 16:44.29 | CIA-29 | BRL-CAD: Have bu_brlcad_root take advantage of realpath - bu_getprogname returns no path |
| 16:44.29 | CIA-29 | BRL-CAD: information now, and so is almost completely useless for this purpose. This |
| 16:44.29 | CIA-29 | BRL-CAD: needs more testing and may not be the final 'approved' way to get this working, |
| 16:44.29 | CIA-29 | BRL-CAD: so it's only going into CMake branch for now, but it works in every case tried |
| 16:44.30 | brlcad | the bu_find_path for search 3 |
| 16:44.30 | CIA-29 | BRL-CAD: so far for both installed and build dir. |
| 16:44.48 | starseeker | uh, hang on - I'll revert back and try it |
| 16:48.40 | brlcad | the path searching is critical to understand and get right, not just find something that seems to work |
| 16:50.20 | brlcad | sounds like you have a possible fix, just needs to be validated |
| 16:51.10 | brlcad | one problem though, is that you've added a memory leak |
| 16:51.51 | starseeker | argv0 as fed to bu_find_path for case 3 when starting bwish is: |
| 16:51.53 | starseeker | argv0: bwish |
| 16:54.07 | brlcad | okay, I can see that |
| 16:54.22 | brlcad | never did like that manual trimming off of the binary name |
| 16:56.06 | brlcad | do you see the memory leak? |
| 16:56.46 | starseeker | is looking |
| 16:57.00 | starseeker | checking bu_dirname and realpath to see how they work... |
| 16:57.07 | starseeker | or is it more obvious than that? |
| 16:57.25 | brlcad | also, no need to add another array |
| 16:58.18 | brlcad | ahh, you removed argv0 |
| 16:58.49 | brlcad | the localized array fits the context better since it's just for that tests |
| 16:59.12 | brlcad | bu_dirname returns managed memory, so yeah, that's the problem |
| 16:59.50 | brlcad | can do something similar to what the previous was doing, print into argv0, free the dirname, print into argv0, free the dirname |
| 17:00.44 | brlcad | have to check whether bu_argv0_full_path() is managed memory or not too |
| 17:03.09 | starseeker | wait, if I don't have the real_path array where did you want to return the realpath results to? |
| 17:03.52 | brlcad | "ahh, you removed argv0" |
| 17:04.11 | brlcad | so you really just renamed the array and moved it to the top of the scope |
| 17:04.40 | brlcad | don't care what it's named, but probably doesn't make sense at the top scope |
| 17:05.21 | starseeker | oh, got it |
| 17:05.47 | starseeker | think I stuck it up there 'cause of some C90 complaint about having it lower |
| 17:06.20 | brlcad | dude, you are too funny |
| 17:07.01 | brlcad | your knowledge is getting broad enough to be dangerous but only 2 inches deep ;) |
| 17:07.11 | brlcad | "some c90 complaint" heh |
| 17:08.07 | brlcad | don't fall victim to cargo cult programming: http://en.wikipedia.org/wiki/Cargo_cult_programming |
| 17:09.20 | starseeker | the specific error was forbidding mixed declarations and code |
| 17:09.31 | brlcad | which means what? :) |
| 17:09.52 | starseeker | I had assumed it didn't like the array being declared in the middle of the function |
| 17:10.07 | brlcad | well strictly speaking, that is true |
| 17:10.28 | brlcad | why didn't it complain about the previous argv0 array then? |
| 17:10.38 | starseeker | it was inside an if statement |
| 17:11.34 | brlcad | which is the start of a new scope, so you just need a new scope -- which you should have again if you check your return values |
| 17:11.47 | brlcad | or you could have manually added a new scope even |
| 17:14.41 | starseeker | nods |
| 17:15.17 | starseeker | didn't think it made much of a difference (and I suppose if I'm honest I recall Bob moving a bunch of things to the top to make Windows happy...) |
| 17:15.21 | brlcad | raises another question -- is bu_dirname() or bu_argv0_full_path() capable of returning NULL? |
| 17:15.47 | starseeker | will look - hang on, trying to rework to avoid the memory leak |
| 17:15.51 | brlcad | they're moved to top of scopes, not arbitrary |
| 17:16.23 | brlcad | declarations after logic code will kick off an error only when compiling in strict c90 mode, which we don't so it'd even work for linux/mac |
| 17:16.51 | brlcad | but now that warnings are errors, you can't ignore gcc (which was at least reporting the potential issue) |
| 17:17.04 | starseeker | right |
| 17:17.30 | brlcad | after curlies, even mid-function, declarations are perfectly fine |
| 17:17.34 | starseeker | I knew it was top of scope, I just didn't attach enough importantce to keeping the declaration close to where it was used |
| 17:18.17 | starseeker | (and again to be honest, declaring a new scope mid-code was not something I would have thought of...) |
| 17:18.21 | brlcad | localized data is one of the best changes c++ made |
| 17:18.43 | brlcad | it usually doesn't matter |
| 17:19.44 | brlcad | it's when they're containers for data, particularly buffers of memory, that you run the risk of reuse bugs and memory management problems |
| 17:20.07 | CIA-29 | BRL-CAD: 03starseeker * r42321 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: Localize the real_path var, free bu_dirname results - still need to see if bu_argv0_full_path needs memory management help. |
| 17:21.43 | starseeker | bu_argv0_full_path will not return null (returns "(unknown)" if the header's got it right) |
| 17:24.47 | brlcad | okay, the header is the contract |
| 17:24.50 | brlcad | so you're good there |
| 17:25.30 | starseeker | I don't believe bu_dirname will return NULL - it's not documented as such, but looking at the code I'm not seeing where it would return NULL |
| 17:25.56 | starseeker | I can check for the NULL case regardless, but perhaps bu_dirname should be guaranteed not to return NULL? |
| 17:26.25 | brlcad | looks like it can to me |
| 17:26.47 | brlcad | maybe at least, since it calls getprogname |
| 17:27.12 | starseeker | bu_dirname? |
| 17:27.14 | brlcad | but since it does a null check after, should fall back to (unknown) as well |
| 17:27.28 | brlcad | oh, dirname |
| 17:27.43 | starseeker | which ones did you ask about? |
| 17:27.48 | starseeker | scrolls up... |
| 17:27.51 | brlcad | that's fine |
| 17:28.46 | brlcad | I think you're right |
| 17:29.03 | starseeker | should that be documented in the header then? |
| 17:29.33 | brlcad | sure |
| 17:29.42 | brlcad | looks like the header also fails to mention memory management |
| 17:30.24 | starseeker | is that implied in "returns a pointer to dynamic string"? |
| 17:30.29 | brlcad | especially since it deviates from dirname(2)'s behavior in that regard |
| 17:30.35 | brlcad | ahh, yeah |
| 17:31.09 | brlcad | should probably be more obvious, heh |
| 17:31.21 | brlcad | "Free your memoriees!!!11!" |
| 17:31.40 | starseeker | nods |
| 17:34.50 | brlcad | bu_basename is wrong! |
| 17:35.19 | starseeker | what'd I do? |
| 17:35.20 | CIA-29 | BRL-CAD: 03starseeker * r42322 10/brlcad/branches/cmake/include/bu.h: Clarify the documentation for bu_dirname, explicitly mention no NULL and responsibility to free memory. |
| 17:35.35 | brlcad | you didn't do anything |
| 17:35.38 | brlcad | just saying |
| 17:35.45 | brlcad | bu_basename is wrong :) |
| 17:35.55 | starseeker | oh, I see it |
| 17:36.02 | starseeker | basename.c ? |
| 17:37.14 | starseeker | uh... will that work on Windows? |
| 17:37.26 | brlcad | what? |
| 17:37.35 | starseeker | explicitly uses '/' |
| 17:37.43 | starseeker | isn't there a BU_DIR_SEPARATOR or some such? |
| 17:38.38 | brlcad | it should probably check BU_DIR_SEPARATOR, but didn't have windows to test it out on when it was being written |
| 17:38.55 | starseeker | ah. I take it you saw another problem? |
| 17:39.12 | brlcad | yeah |
| 17:39.24 | brlcad | bu_brlcad_root looks much better now |
| 17:40.14 | brlcad | you going to fix bu_brlcad_data next? :) |
| 17:41.07 | brlcad | (just kidding) |
| 17:41.18 | starseeker | heh |
| 17:41.40 | starseeker | was hoping bu_brlcad_data would follow once root was behaving |
| 17:41.58 | brlcad | data calls root for that case |
| 17:42.13 | starseeker | I see one problem with bu_basename, I think - a/ won't return a |
| 17:42.19 | brlcad | bingo |
| 17:42.54 | starseeker | will sync trunk then with the libbu cmake changes |
| 17:43.28 | starseeker | arguably, is a/ -> a expected? |
| 17:43.33 | starseeker | I suppose it is |
| 17:44.11 | brlcad | it's a drop-in replacement for basename(3), so it should |
| 17:44.47 | brlcad | I think the intent was even supporting cross-platform and no-NULL returns |
| 17:45.13 | brlcad | I have trouble believing that the code was originally written the way it is now.. |
| 17:46.04 | starseeker | heh - well, since it explicitly returns NULL in once case that kinda nullfiies the non-NULL returns |
| 17:46.29 | brlcad | intent, not action :) |
| 17:47.08 | brlcad | bu_basename(NULL) is kind of weird |
| 17:49.19 | brlcad | but sure enough, seems to have been originally written that way |
| 17:49.50 | CIA-29 | BRL-CAD: 03starseeker * r42323 10/brlcad/trunk/ (include/bu.h src/libbu/brlcad_path.c): Fix the behavior of bu_brlcad_root for run-time path identification - was calling bu_getprogname, which no longer returns path information. Also expand header documentation for bu_dirname. |
| 17:50.19 | starseeker | brlcad: does that fall into the user visible category? It's kinda borderline |
| 17:51.53 | CIA-29 | BRL-CAD: 03brlcad * r42324 10/brlcad/trunk/TODO: bu_basename() needs some love |
| 18:00.11 | CIA-29 | BRL-CAD: 03brlcad * r42325 10/brlcad/trunk/include/bu.h: minor rewording since the type of free matters. plus remove the warning since it conflicts with the need to free the memory. |
| 18:00.26 | brlcad | starseeker: I don't think so |
| 18:01.12 | brlcad | it fixes a bug, but not likely one that would have been noticed, and more importantly not a bug with the default install into a specified path |
| 18:01.23 | starseeker | that's what I figured |
| 18:01.48 | brlcad | technically borderline, in that sense you're right, but not practically |
| 18:03.05 | brlcad | http://code.google.com/p/brl-cad-packages/ |
| 18:03.11 | starseeker | by the way - there's a lot of logic in tclcadAutoPath specifically looking at either *_LIBRARY variables or hunting for tcl files - is that due to not being able to rely on the package require mechanism or are there users who actually override that stuff? |
| 18:03.36 | brlcad | yes |
| 18:03.54 | starseeker | heh |
| 18:04.34 | brlcad | and 3) different versions of *tcl behaving differently with how well they use auto_path, tcl var, or env(var) |
| 18:04.57 | brlcad | the snippet I just added a few days ago for archer is a prime example |
| 18:05.21 | brlcad | tcl is ignoring auto_path AND tcl_library during "interp create" |
| 18:05.27 | brlcad | but would respect TCL_LIBRARY |
| 18:06.17 | brlcad | a bug only because it goes through really low-level init routines in tcl that bypass the usual stuff |
| 18:06.45 | starseeker | ah - so if we did our stuff in a .tcl file that was loaded normally, we wouldn't see those issues? |
| 18:07.09 | brlcad | actually, for that particular case, I'm not so sure |
| 18:07.41 | brlcad | archer uses sub-interpreters for some command processing, which gets tricky |
| 18:08.27 | brlcad | if it was system tcl, sure -- because the default low-level searching is basically looking where it was supposed to be installed |
| 18:09.21 | brlcad | similar to our bu_brlcad_* routines actually -- just it was failing to perform a few searches that their docs say it should be performing |
| 18:09.37 | brlcad | good stuff: http://code.google.com/p/brl-cad-packages/downloads/list |
| 18:09.58 | starseeker | hah, sweet |
| 18:11.21 | starseeker | can we at least either ditch the tclcad_tcl_library function or rework it somehow? |
| 18:12.06 | starseeker | it looks like with that bu_brlcad_root fix I might be able to just use the existing logic from trunk, except for that function |
| 18:14.13 | brlcad | can give it a try |
| 18:14.20 | starseeker | ponders... hmm, I wonder if we really need those internal C calls... |
| 18:14.38 | starseeker | to the Tcl docs |
| 18:16.28 | brlcad | if mged runs and starts cleanly from a variety of installs, we're probably good -- the only thing I'd worry about is relying on 8.6 behavior for something that might not work in 8.5 |
| 18:16.37 | brlcad | right now 8.5 is our minimum req |
| 18:16.56 | brlcad | upgrading that to 8.6 might take us out of some package management systems |
| 18:18.37 | starseeker | uh... does tclcad_tcl_library help us avoid requiring 8.6? |
| 18:19.09 | starseeker | has never actually had a successful BRL-CAD run with tcl/tk 8.6, actually |
| 18:19.19 | starseeker | s/never actually/never |
| 18:23.01 | starseeker | hmm, actually I may stand corrected - it's using Tcl internals, but the real trouble might have been the itcl/itk headers |
| 18:23.15 | starseeker | does some experiments in trunk |
| 18:25.13 | starseeker | riping out supports to see how the bridge crashes down... |
| 19:29.52 | starseeker | yeah, still valid concern on the use of internal functions but the build-haulting issues were due to itcl/itk header inclusion |
| 19:31.27 | CIA-29 | BRL-CAD: 03starseeker * r42326 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: Tweak includes for tclcadAutoPath.c - I think this may be a version both the CMake build and autotools build can live with, but needs more testing. |
| 19:33.10 | CIA-29 | BRL-CAD: 03starseeker * r42327 10/brlcad/branches/cmake/src/libtclcad/tclcadAutoPath.c: Sync tclcadAutoPath.c with trunk's version - trying to get a version both can live with/use. |
| 20:49.34 | CIA-29 | BRL-CAD: 03starseeker * r42328 10/brlcad/branches/cmake/ (17 files in 12 dirs): Update cmake branch to trunk r42327 |
| 20:53.36 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 20:53.36 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 20:56.32 | CIA-29 | BRL-CAD: 03starseeker * r42329 10/brlcad/branches/cmake/src/other/libtermlib/CMakeLists.txt: Put the termcap stuff where it belongs. |
| 21:11.00 | CIA-29 | BRL-CAD: 03starseeker * r42330 10/brlcad/branches/cmake/ (930 files in 930 dirs): |
| 21:11.00 | CIA-29 | BRL-CAD: Sure as heck don't want to merge THIS change into trunk, but in principle the |
| 21:11.00 | CIA-29 | BRL-CAD: CMake branch should be leaving a pristine tree behind it. Set all svn ignore |
| 21:11.00 | CIA-29 | BRL-CAD: properties to empty - if I got this right we should see ANY files that appear in |
| 21:11.00 | CIA-29 | BRL-CAD: the source branch after a build. |
| 21:14.24 | CIA-29 | BRL-CAD: 03brlcad * r42331 10/brlcad/trunk/AUTHORS: special thanks to jordi sayol for making 32-bit and 64-bit .deb files for release 7.18.0 |
| 21:18.36 | CIA-29 | BRL-CAD: 03starseeker * r42332 10/brlcad/trunk/misc/enigma/ (Makefile.am crypt.c enigma.c): |
| 21:18.36 | CIA-29 | BRL-CAD: The enigma stuff from CMake should be harmless - trunk doesn't build enigma on |
| 21:18.36 | CIA-29 | BRL-CAD: Windows, and it would need the stuff if it did - even though this isn't working, |
| 21:18.36 | CIA-29 | BRL-CAD: it's at least a start. Sync it to bring the two branches closer. |
| 21:20.22 | brlcad | o.O ... brlcad_config.h ? |
| 21:20.43 | brlcad | shouldn't ever be including that file directly |
| 21:20.51 | brlcad | distcheck should have caught that |
| 21:22.40 | starseeker | ah, my bad |
| 21:24.10 | CIA-29 | BRL-CAD: 03starseeker * r42333 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: Whoops - don't include brlcad_config.h directly. |
| 21:34.21 | CIA-29 | BRL-CAD: 03starseeker * r42334 10/brlcad/branches/cmake/ (5 files in 4 dirs): Sync cmake to trunk r42333. |
| 21:36.05 | CIA-29 | BRL-CAD: 03starseeker * r42335 10/brlcad/branches/cmake/AUTHORS: Hmm, AUTHORS wasn't fully synced. fix |
| 21:48.17 | CIA-29 | BRL-CAD: 03starseeker * r42336 10/brlcad/branches/cmake/src/tclscripts/ (23 files in 12 dirs): Add canned pkgIndex.tcl files and tclIndex files from trunk - won't need them for CMake (if the generation routines work correctly) but trunk needs 'em. |
| 21:51.28 | CIA-29 | BRL-CAD: 03starseeker * r42337 10/brlcad/branches/cmake/src/util/pixrect.c: pixrect.c change slipped through. |
| 21:52.15 | CIA-29 | BRL-CAD: 03starseeker * r42338 10/brlcad/branches/cmake/src/other/libz/ (12 files): No significant differences here, but sync to avoid cluttering diffs. |
| 21:59.20 | CIA-29 | BRL-CAD: 03starseeker * r42339 10/brlcad/branches/cmake/src/other/libz/contrib/minizip/Makefile: Add file present in trunk |
| 22:02.36 | CIA-29 | BRL-CAD: 03starseeker * r42340 10/brlcad/branches/cmake/src/other/libz/contrib/iostream2/zstream.h: another minor sync from libz |
| 22:18.41 | CIA-29 | BRL-CAD: 03starseeker * r42341 10/brlcad/trunk/ (7 files in 7 dirs): Put iwidgets in the incrTcl subdirectory, since they're associated with that proejct. |
| 22:21.17 | CIA-29 | BRL-CAD: 03starseeker * r42342 10/brlcad/trunk/src/other/incrTcl/Makefile.am: Whoops, use the variable. |
| 22:24.00 | CIA-29 | BRL-CAD: 03starseeker * r42343 10/brlcad/trunk/src/other/ (Makefile.am incrTcl/Makefile.am): Move itcl into the incrTcl subdir as well. |
| 22:25.09 | CIA-29 | BRL-CAD: 03starseeker * r42344 10/brlcad/trunk/src/other/incrTcl/Makefile.am: change ITCLDIR to actually be the itcl dir. |
| 22:31.34 | CIA-29 | BRL-CAD: 03starseeker * r42345 10/brlcad/branches/cmake/ (6 files in 6 dirs): Grab some of the changes from trunk - incrTcl is hopelessly messed up between cmake and trunk, so will probably have to script out CMake's and put trunk's in place. |
| 22:34.42 | CIA-29 | BRL-CAD: 03starseeker * r42346 10/brlcad/branches/cmake/src/other/incrTcl/iwidgets/.cvsignore: stray .cvsigonre file |
| 22:40.29 | Ralith | Is there some way to get a sketch corresponding to the intersection between a plane and a region? |
| 22:43.36 | brlcad | Ralith: depends what kind of sketch |
| 22:43.48 | starseeker | um... intersect a thin arb8 with the region and use rtedge? |
| 22:43.49 | brlcad | you can get a cross-section hidden-line rendering very easily |
| 22:44.31 | brlcad | starseeker: curious move with iwidgets... |
| 22:44.45 | starseeker | it's associated with the incrtcl project on sourceforge |
| 22:44.47 | brlcad | they're certainly related, but iwidgets isn't part of incrTcl |
| 22:45.05 | Ralith | brlcad: I mean as in a sketch primitive |
| 22:45.26 | brlcad | Ralith: then no, not outside of manual methods |
| 22:45.31 | Ralith | :/ |
| 22:45.39 | brlcad | http://incrtcl.cvs.sourceforge.net/incrtcl/ |
| 22:45.42 | brlcad | separate module |
| 22:46.01 | brlcad | would be like putting rt^3 underneath a brlcad checkout |
| 22:46.10 | brlcad | they're related, but not in that way |
| 22:46.18 | starseeker | hmm. |
| 22:46.31 | brlcad | no biggie either way, just odd |
| 22:46.48 | brlcad | src/other/incrTcl is no longer the incrTcl source tarball |
| 22:47.05 | starseeker | our trunk incrTcl hasn't been for a long time, as understand it |
| 22:47.11 | starseeker | ``Erik made a lot of changes |
| 22:47.30 | brlcad | quantify "a lot" |
| 22:47.54 | starseeker | I'd have to do diffs - was based on conversation with him at work about it |
| 22:47.55 | brlcad | we have a Makefile.am, and maybe a dozen lines |
| 22:48.04 | starseeker | he said he pulled stuff out of cvs |
| 22:48.09 | starseeker | not just the tarballs |
| 22:48.36 | starseeker | CMake branch does use the vanilla source - that's what prompted the itk_defines.tcl file for archer |
| 22:48.38 | brlcad | that's not a lot of mods then |
| 22:49.03 | brlcad | source tarball == source checkout in this particular instance, doesn't matter that the .tar.gz is out of date |
| 22:49.11 | brlcad | their code vs our code |
| 22:49.52 | brlcad | or if it suits the conversation better, "our trunk incrTcl is no longer an incrTcl source checkout (+ our Makefile.am)" |
| 22:50.08 | starseeker | ok |
| 22:50.56 | brlcad | like I said, minor point, I don't care strongly on it |
| 22:50.57 | starseeker | so do I have your OK to make incrTcl a vanilla cvs checkout/tarball + Makefile.am? That's what I'd prefer to do, and then work around issues using itk_defines.tcl and the like |
| 22:51.34 | brlcad | that's close to what it is now |
| 22:51.56 | brlcad | if it's not, sure |
| 22:52.00 | starseeker | sweet |
| 22:52.07 | starseeker | I'll revert back to the original structure then |
| 22:53.54 | brlcad | looking through the logs, the only recent mod I see other than our Makefile.am, was to make it work with tcl/tk 8.4 out of the box, 8.4 compat headers |
| 22:54.22 | brlcad | requirement is since upped to 8.5, so no longer relevant |
| 22:54.27 | starseeker | nods |
| 22:55.41 | brlcad | erik's upgrade to cvs was in 2007 |
| 22:56.24 | starseeker | alrightie |
| 22:56.53 | starseeker | given a choice between tarballs and cvs, do you have a preference? |
| 22:57.04 | brlcad | cvs |
| 22:57.23 | brlcad | unless they updated the tarball recently |
| 22:57.58 | starseeker | not really - 2009 for itcl |
| 22:58.16 | brlcad | so it's at least a tarball 2 years newer, but still 2 years behind |
| 22:58.39 | brlcad | not beenmany commits since then |
| 22:58.54 | starseeker | nope - what new work has been going on I think is in the 4.0 branch |
| 22:58.54 | brlcad | but does have an updated TEA |
| 22:59.02 | brlcad | http://www.ohloh.net/p/incrtcl/commits |
| 22:59.11 | brlcad | 5 commits |
| 22:59.35 | brlcad | could ask them which they recomment |
| 22:59.37 | brlcad | could ask them which they recommend |
| 22:59.47 | brlcad | but I suspect 4.0 is going to req. 8.6 |
| 22:59.52 | starseeker | yes |
| 23:00.02 | starseeker | uses the new tclOO setup, iirc |
| 23:01.45 | brlcad | if it gave us some benefit, I'd say go for it .. but i'm not sure there is any yet |
| 23:01.59 | brlcad | by the time they're done, it might just get absorbed |
| 23:02.35 | starseeker | which, 4.0? |
| 23:02.43 | brlcad | hmmm... this one might need to be kept or pushed upstream: svn log -r27960:27959 src/other/incrTcl |
| 23:02.47 | brlcad | 4.0 |
| 23:03.44 | starseeker | yeah, I don't think we're ready for 8.6 yet |
| 23:04.09 | starseeker | would vastly prefer to not be using the C itcl/itk api for the next run at 8.6 |
| 23:05.12 | brlcad | wow .. I apparently made that change, but totall don't remember it |
| 23:05.51 | brlcad | the crash I vaguely recall, and it was hard -- so should be easy to see if the patch is still needed |
| 23:06.52 | starseeker | has half a notion to ditch the mess for tkpng in LoadArcherLibs.tcl and require that package require tkpng Just Work... ick |
| 23:07.25 | brlcad | that's how it should be |
| 23:07.34 | brlcad | the loading of the .so directly was just a halfassing |
| 23:09.46 | starseeker | brlcad: do you recall if we tried to push the itcl patch upstream at the time? |
| 23:21.27 | CIA-29 | BRL-CAD: 03starseeker * r42347 10/brlcad/trunk/ (687 files in 19 dirs): Put iwidgets back - might as well match the incrTcl cvs project hierarchy. |
| 23:33.06 | starseeker | mutter - looks like we still need that patch |
| 23:33.54 | starseeker | brlcad: it wasn't something about the way we were doing itcl/itk logic that could be changed? |
| 23:34.26 | starseeker | must admit it doesn't look like it based on C patches |
| 23:36.41 | CIA-29 | BRL-CAD: 03starseeker * r42348 10/brlcad/trunk/src/tclscripts/archer/LoadArcherLibs.tcl: Use package require tkpng. If it's not working, let's figure out why. |
| 23:38.42 | CIA-29 | BRL-CAD: 03starseeker * r42349 10/brlcad/branches/cmake/ (6 files in 6 dirs): Put itcl/itk logic back, pull in trunk's LoadArcherLibs.tcl. |
| 23:40.49 | starseeker | Odd... I'm using system tcl/tk and itcl/itk here, and Archer is coming up and will bring up the preferences dialog... I think we took out the comb editor in its old form, so probably can't test that... |
| 23:42.06 | starseeker | ah, mged |
| 23:47.54 | starseeker | with system itcl/itk and tcl/tk on gentoo combination editor comes up, but of course they may be patched |
| 23:49.08 | starseeker | huh, weird |
| 23:55.01 | starseeker | don't see a patch specific to that issue... may be missing it |
| 23:55.14 | starseeker | goes on dinner run |