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 |