00:34.22 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
01:44.47 |
louipc |
wowzarz |
01:47.31 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
02:13.19 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
04:23.24 |
brlcad |
``Erik: autogen/configure seems to be happy on
automake 1.6 |
04:25.59 |
*** join/#brlcad stevegt_1
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
10:12.36 |
*** join/#brlcad mafm
(~mafm@193.153.52.142) |
12:03.57 |
starseeker |
tries distcheck on gentoo,
crosses fingers - maybe this will be an easy cycle and we can sync
to STABLE soon |
12:05.34 |
starseeker |
auuugh |
12:05.36 |
starseeker |
brlcad-7.17.0/src/other/boost/spirit/home/support/iterators/detail/buffering_input_iterator_policy.hpp:
file name is too long (max 99); not dumped |
12:06.20 |
starseeker |
will revert that for release
then - not in use currently, and we can sort it out
later |
12:23.18 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
12:23.18 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
12:38.06 |
CIA-48 |
BRL-CAD: 03starseeker * r41251
10/brlcad/trunk/src/other/boost/ (1147 files in 136 dirs): Revert
the boost upgrade - resulting in filenames too long for tar. Will
deal with this after the release. |
12:38.30 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
12:39.08 |
starseeker |
sigh |
12:39.11 |
starseeker |
tries again |
12:50.50 |
brlcad |
heh |
12:51.53 |
brlcad |
starseeker: you should be good to go for
release once everything is tested |
12:51.57 |
brlcad |
make sure all user-visible commits since last
release are documented (ChangeLog is good for that) |
12:52.26 |
brlcad |
I took care of everything in my queue, but I
usually double-check the log |
12:54.40 |
starseeker |
ah, cool :-) |
12:54.52 |
starseeker |
hmm, looks like something weird
here: |
12:55.02 |
starseeker |
../../../include/conf/COUNT:1:1: error:
invalid suffix "n" on integer constant |
12:55.48 |
starseeker |
aand... sure enough, there is an n after the
1 |
12:55.55 |
_psilva_ |
so what are you guys using spirit
for? |
12:56.01 |
starseeker |
libpc |
12:56.15 |
starseeker |
parametric constraints |
12:56.22 |
_psilva_ |
parsing them? |
12:58.35 |
brlcad |
starseeker: that's something erik's seen on a
bsd system |
12:58.51 |
brlcad |
results from configure setting a wrong value
for ECHO |
12:59.38 |
starseeker |
ah |
12:59.46 |
brlcad |
printf "%d\n" 123 |
12:59.48 |
starseeker |
_psilva_: evaluating them |
12:59.52 |
brlcad |
vs echo "123\n" |
13:00.06 |
starseeker |
so it's my particular autotools's
fault? |
13:00.15 |
brlcad |
*shrug* |
13:00.16 |
starseeker |
hopes |
13:00.28 |
brlcad |
did you autogen.sh on that platform? |
13:00.34 |
starseeker |
I beleve so |
13:00.41 |
starseeker |
will do it totally clean to
be sure |
13:01.25 |
starseeker |
oo - might have some static files, hang
on |
13:02.05 |
brlcad |
grep ECHO include/conf/Makefile |
13:03.19 |
starseeker |
_psilva_: http://brlcad.org/wiki/Libpc |
13:03.46 |
starseeker |
or whoops, http://brlcad.org/wiki/Libpg_:_A_parametrics/constraint_library |
13:03.56 |
starseeker |
second one looks better |
13:04.37 |
starseeker |
not sure why it's Libpg there... |
13:05.15 |
brlcad |
original name, "parametric geometry" |
13:05.27 |
brlcad |
he was going to make separate geometry
objects |
13:05.33 |
brlcad |
told him that was nfg |
13:06.32 |
brlcad |
so it was reworked to be libpc, which librt
uses |
13:17.26 |
brlcad |
thinks the GCI list is going
to make a good "how to get started contributing to BRL-CAD" list
even if we're not accepted |
13:18.17 |
brlcad |
starseeker: oh yeah, note the outstanding TODO
item for Windows |
13:28.53 |
CIA-48 |
BRL-CAD: 03Sean 07http://brlcad.org * r2332
10/wiki/Google_Code_In/Project_Ideas: BU jumping |
13:29.39 |
starseeker |
brlcad: yeah, ECHO = printf %s\n |
13:30.11 |
starseeker |
so it's not our fault :-) |
13:30.30 |
starseeker |
and the failure was from a clean
autogen |
13:31.33 |
``Erik |
I've seen the issue on my mac, too |
13:31.53 |
``Erik |
and on a linux box iirc |
13:33.24 |
``Erik |
it also shows up at the end of the
build |
13:33.26 |
``Erik |
---nRun 'make test' to run the BRL-CAD Test
SuitenRun 'make benchmark' to run the BRL-CAD Benchmark
Suitenn**********************************************************n
BRL-CAD 7.17.0 is now installed into /usr/brlcad/HEADn Be sure to
add /usr/brlcad/HEAD/bin to your
PATHn**********************************************************nnmake[2]:
Entering directory `/var/tmp/erikg/brlcadbuild' |
13:33.51 |
starseeker |
looks like this may be related: http://www.mail-archive.com/bug-autoconf@gnu.org/msg02903.html |
13:35.14 |
starseeker |
hmm: http://www.mail-archive.com/bug-autoconf@gnu.org/msg02911.html |
13:38.15 |
starseeker |
yeah, this is not a BRL-CAD specific issue
from the looks of it - recent libtool changed something |
13:39.40 |
CIA-48 |
BRL-CAD: 03Sean 07http://brlcad.org * r2333
10/wiki/Google_Code_In/Project_Ideas: SCLstring ->
std::string |
13:40.22 |
``Erik |
from 02912: The bug is not in 'echo', but in
the improper use of $(ECHO) within `` |
13:40.25 |
``Erik |
inside the Makefile |
13:43.11 |
starseeker |
let me see if we can override it by force in
configure.ac - there's a place where we check if $ECHO was defined
at all |
13:43.27 |
starseeker |
perhaps a check there for this printf
statement, and an override if it is present, would get it
working |
13:44.52 |
``Erik |
echo is posix (echo -n is NOT, however), where
does $(ECHO) actually buy us anything? |
13:45.47 |
starseeker |
shrugs - dunno. I'm just
looking for the most minimal change to get us past distcheck right
now, removing $(ECHO) would be a fair bit of work |
13:46.26 |
``Erik |
it would? O.o |
13:46.50 |
starseeker |
not in and of itself, but looking for what
prompted us to make it a variable and confirm it's no longer an
issue |
13:54.07 |
starseeker |
bah, overriding it does nothing |
13:54.23 |
starseeker |
``Erik: OK, I was wrong - perhaps we do need
to replace $(ECHO) |
13:55.19 |
CIA-48 |
BRL-CAD: 03Sean 07http://brlcad.org * r2334
10/wiki/Google_Code_In/Project_Ideas: quell verbose warnings in
src/util |
14:06.49 |
CIA-48 |
BRL-CAD: 03Sean 07http://brlcad.org * r2335
10/wiki/Google_Code_In/Project_Ideas: clean up the 'analyze'
command |
14:08.35 |
CIA-48 |
BRL-CAD: 03starseeker * r41252
10/brlcad/trunk/ (5 files in 5 dirs): Try replacing $(ECHO) with
echo in the Makefile.am files - the newest libtool is using a
printf expression for $(ECHO) that is resulting in extra n
characters at the end of lines. |
14:11.23 |
starseeker |
Ubuntu is going to try Wayland instead of
X.org???? |
14:14.42 |
CIA-48 |
BRL-CAD: 03Sean 07http://brlcad.org * r2336
10/wiki/Google_Code_In/Project_Ideas: research impact of setting
CPU affinity |
14:15.31 |
starseeker |
tries to figure out what
Wayland is... |
14:15.34 |
starseeker |
ah |
14:17.29 |
brlcad |
the reason it's $(ECHO) at all is because
there are/were platforms where "echo" is not found |
14:17.55 |
brlcad |
so you needed to rely on configure detecting
the echo mechanism for that platform |
14:18.16 |
starseeker |
apparently modern libtool is going to gum that
up but good |
14:19.40 |
brlcad |
so how to address both problems? |
14:19.51 |
starseeker |
CMake? :-P |
14:20.04 |
starseeker |
what platforms lack echo? |
14:21.11 |
brlcad |
you'd have to search the logs |
14:21.37 |
starseeker |
If they're still relevant today we've got a
problem |
14:25.17 |
brlcad |
from that mailing list, it looks like it's
recent libtool that's causing the problem and they're going to fix
it |
14:27.14 |
starseeker |
that was back in august though |
14:29.38 |
starseeker |
earliest item I see in the first cut is
r23717 |
14:33.21 |
_psilva_ |
hm Vala looks interesting |
14:38.02 |
starseeker |
brlcad: for include/conf/Makefile.am the
change to $(ECHO) came at r31964 |
14:40.03 |
starseeker |
for bench/Makefile.am it was r24110 |
14:40.18 |
starseeker |
I don't see a motivation in eather of
those... |
14:42.03 |
starseeker |
in the case of the toplevel Makefile.am it was
using @ECHO@ |
14:45.12 |
starseeker |
first appearance in db/Makefile.am was
r30442 |
14:45.45 |
starseeker |
and step I'm sure inherited it from BRL-CAD's
file |
14:46.40 |
starseeker |
does not appear to be mentioned in any
toplevel file (TODO/NEWS/etc.) |
14:49.35 |
brlcad |
no matter then, you can just do the solaris
build when they're back up and running ;) |
14:49.49 |
starseeker |
heh :-) |
14:49.59 |
brlcad |
they're probably the closest platform to
causing any modern issue |
14:50.46 |
starseeker |
they're posix though, correct? |
14:52.58 |
brlcad |
traditionally, the strictest |
14:53.03 |
brlcad |
even where posix has flaws |
14:53.46 |
brlcad |
e.g., if posix just says echo has to be on the
system somewhere, that doesn't mean it's in your path or is
built-in or is available within Makefiles .. lots of variables in
play |
14:55.01 |
starseeker |
ah |
14:56.22 |
starseeker |
well, fwiw, the gentoo build is progressing
well |
14:56.32 |
starseeker |
``Erik: did that get your Mac
working? |
14:59.37 |
starseeker |
sweet - after the echo change, distcheck
passes on gentoo |
15:00.54 |
``Erik |
seems to all be good, lemme purge and
reconfigure/compile |
15:01.15 |
starseeker |
anybody know of a test farm somewhere where we
could set up a Solaris build? |
15:08.10 |
starseeker |
may have to poke at the GCC
farm to see if they have something viable and would consider
allowing us on there... |
15:08.23 |
starseeker |
or perhaps we could use virtualbox/qemu and
set something up... |
15:19.05 |
starseeker |
alrightie, distcheck passes here, heading
in |
15:23.20 |
``Erik |
cliff |
15:38.38 |
CIA-48 |
BRL-CAD: 03Sean 07http://brlcad.org * r2337
10/wiki/Google_Code_In/Project_Ideas: g-iges + iges-g
changes |
15:40.54 |
CIA-48 |
BRL-CAD: 03Sean 07http://brlcad.org * r2338
10/wiki/Google_Code_In/Project_Ideas: new website
solicitation |
15:56.30 |
CIA-48 |
BRL-CAD: 03Sean 07http://brlcad.org * r2339
10/wiki/Google_Code_In/Project_Ideas: lots of missing manual pages,
provide an easy and hard task |
16:18.58 |
CIA-48 |
BRL-CAD: 03Sean 07http://brlcad.org * r2340
10/wiki/Google_Code_In/Project_Ideas: command
spreadsheets |
16:24.39 |
CIA-48 |
BRL-CAD: 03Sean 07http://brlcad.org * r2341
10/wiki/Google_Code_In/Project_Ideas: reword for
generality |
17:05.15 |
*** join/#brlcad mafm
(~mafm@193.153.52.142) |
17:29.39 |
``Erik |
fresh configure/make on fbsd8 and osX.6 both
succeed |
17:41.01 |
starseeker |
sweet |
17:47.54 |
CIA-48 |
BRL-CAD: 03brlcad * r41253
10/brlcad/trunk/HACKING: |
17:47.54 |
CIA-48 |
BRL-CAD: that first step should really also
include notifying the brlcad-devel mailing |
17:47.54 |
CIA-48 |
BRL-CAD: list with a simple message letting
others know that someone has begun release |
17:47.54 |
CIA-48 |
BRL-CAD: steps so that others know to keep the
commits at ease for a couple days |
17:48.20 |
starseeker |
distcheck passed on Redhat |
17:53.28 |
brlcad |
starseeker: not to throw a wrench into the
release, but there needs to be a strong change that distinguishes
pushing out the minor or it should be a merged 7.16.12 off
stable |
17:53.42 |
brlcad |
at least an api change (deprecations, removal
of obsoletes) |
17:55.25 |
brlcad |
I'm thinking we can hit up the pre 7 and 7.12
deprecations quickly |
17:56.59 |
starseeker |
k, cool |
17:57.00 |
brlcad |
otherwise, we can declare archer in official
alpha status if it's stable enough, but I didn't get a chance to
talk to bob |
17:57.21 |
starseeker |
he's in today, feeling better - he should be
in next week |
17:57.41 |
brlcad |
ask him what he thinks about an alpha
archer |
17:58.06 |
brlcad |
presuming we all are on the same page as to
what that means .. :) |
17:58.10 |
starseeker |
I'm willing to go the 16.12 route, but what
does "merged 7.16.12 off of stable" mean? sync to stable without
updating the version numbers? |
17:58.30 |
starseeker |
brlcad: first, define what it means to you
:-) |
17:58.57 |
brlcad |
well, head is already 7.17 so it technically
shouldn't regress back to 7.16 but stable is still at 7.16 so it
can move forward a minor and get tagged from there |
17:59.53 |
starseeker |
we probably can't declare it alpha without
turning opengl in the default builds |
17:59.55 |
brlcad |
not a big deal with 7.17 since it's still dev,
it could be committed briefly as 7.16.12 for release purpose then
jumped back (to 7.17.1) |
18:00.23 |
starseeker |
nods - that might be a way to
go |
18:01.47 |
brlcad |
alpha means we're including it enabled in all
binary installs now and ACTIVELY soliciting users to check it out,
provide feedback, and that we're otherwise done adding features
from our end |
18:02.19 |
starseeker |
ah, we are not done adding features |
18:02.22 |
brlcad |
it's not quite a feature-lock yet, but new
features should be mostly in response to user feedback |
18:02.24 |
starseeker |
so the answer is a definite now |
18:02.26 |
starseeker |
er no |
18:03.17 |
brlcad |
then beta is then when it goes into lock-down
and the only new features are in response to bugs or problems (e.g.
usability) |
18:03.28 |
starseeker |
sketch editing, pipe editing, finishing comb
editing... |
18:04.05 |
starseeker |
nods - yeah, we're a ways
away then |
18:04.10 |
brlcad |
finishing /refining features is okay during
alpha |
18:04.25 |
brlcad |
adding new/missing ones usually
isn't |
18:05.08 |
starseeker |
we might (generously) call comb editing a
finishing/refining, but not sketch and pipe - they're not present
at all ATM |
18:05.52 |
brlcad |
so then the question is whether they are
release critical |
18:06.06 |
starseeker |
sketch probably not, pipe I would say
yes |
18:06.23 |
brlcad |
what about via libged? |
18:06.31 |
brlcad |
command-line editing, is that working for
them? |
18:07.04 |
starseeker |
bob says "in theory yeah, using the adjust
command - may not be practical for big pipes" |
18:07.17 |
brlcad |
k |
18:08.00 |
brlcad |
so not quite ready, and release is then either
API deprecations/removals or a minor release |
18:08.56 |
brlcad |
searchable command manual pages in mged would
be a good minor justification too |
18:09.44 |
starseeker |
not sure we can whip that off in a day or two
- what searching mechanism did you have in mind? |
18:09.50 |
brlcad |
keyword |
18:09.53 |
starseeker |
hunts up the deprecations
file |
18:10.17 |
starseeker |
I mean, what mechanism to look through the
files? grep? a tcl regex match? etc. |
18:10.27 |
brlcad |
*shrug* |
18:11.38 |
starseeker |
bob says he might be able to have someing
servicable for pipe in a week or so |
18:11.51 |
brlcad |
ideally like pdf searching in
Preview |
18:12.45 |
brlcad |
type some word(s) and get a list of the
matching line with surrounding context in a summary list with the
word bolded that jumps you to that line on that page |
18:13.05 |
starseeker |
oh, I see - yeah, that's not a
quickie |
18:13.40 |
brlcad |
so it'd be a straight-up grep, but the good
usability aspect is the results while you type, the context, and
jumping you to the match |
18:15.09 |
starseeker |
right - sounds good, just a bunch of details
like the mechanics of highlighting words in tkhtml would take a bit
of time (for me at least :-/) |
18:15.57 |
brlcad |
that part of the search pane wouldn't need to
be tkhtml |
18:16.09 |
brlcad |
you'd just need snippets of text and a list
view |
18:18.36 |
starseeker |
It's probably not hard, but I still wouldn't
bet on pulling it together prior to release starting cold |
18:23.20 |
starseeker |
I'd say rather than force it, let's go for
7.16.12 and then take steps to make sure the next one is
7.18 |
18:23.28 |
brlcad |
probably less than a day's work for sure, but
it's fine either way -- clearing out the deprecations will take a
few hours too |
18:23.52 |
brlcad |
that's fine |
18:24.05 |
starseeker |
are those the ones in raytrace.h and
whatnot? |
18:24.15 |
brlcad |
the doc file |
18:24.27 |
brlcad |
the 7.12's and the pre7's |
18:24.34 |
starseeker |
oh, I see them |
18:24.46 |
starseeker |
so just go through and make sure our code
doesn't use them? |
18:25.12 |
brlcad |
and ideally deprecating anything else we see
(particularly libbu/libbn/libwdb/librt) .. should give notice about
libnmg |
18:25.19 |
brlcad |
right |
18:25.39 |
brlcad |
make sure we don't use them, and remove their
decls from headers or the headers |
18:25.39 |
starseeker |
libnmg... oh, you mean that it'll be moving
back to its own lib? |
18:25.58 |
brlcad |
right -- technically, that's a body of librt
API that's being removed from librt |
18:26.10 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
18:26.12 |
brlcad |
minor, but worth documenting |
18:26.33 |
starseeker |
yow. how much detail do we need to document
for that one? full list of functions and vars that will be going
away? |
18:27.13 |
brlcad |
no, just categorically say the nmg_*
functions/structures/defines or "the nmg code" or similar |
18:27.24 |
starseeker |
(aside) with distcheck passing now on multiple
platforms, I'm gonna go ahead and try a stable sync |
18:27.34 |
starseeker |
cool |
18:27.40 |
brlcad |
and then marking them in the headers |
18:27.51 |
brlcad |
it's 500+ functions, so no sense listing them
all |
18:27.56 |
starseeker |
so that'll be 7.20 or 7.22? |
18:29.28 |
brlcad |
deprecations announced in 7.16.12 can be moved
in 7.20 |
18:29.41 |
brlcad |
deprecations in 7.18 are 8.22 |
18:29.44 |
brlcad |
er, 7.22 ;) |
18:30.01 |
starseeker |
crosses fingers, toes, etc.
and starts the merge command... |
18:30.22 |
brlcad |
that's why it's more important to mark
deprecated than it is to remove for obsoletion |
18:30.32 |
starseeker |
brlcad: now you're giving us an incentive to
make this 7.16.12 :-P |
18:30.33 |
brlcad |
obsoletion just becomes a good justification
for minor |
18:31.02 |
brlcad |
yesh -- deprecation pushes patch, obsolete
pushes minor |
18:31.31 |
starseeker |
is dizzy |
18:31.40 |
brlcad |
though libnmg is arguably "minimally
impacting" |
18:32.04 |
starseeker |
I doubt many people call nmg functions
direct... |
18:32.05 |
brlcad |
so it could happen at any time since it's a
regex fix to a build file s/-lrt/-lrt -lnmg/ |
18:32.33 |
starseeker |
oh, gotcha - make into libnmg, but preserve
API |
18:32.47 |
brlcad |
right, if the api doesn't change, it's still
available |
18:33.05 |
starseeker |
was under the impression the
API could stand a little TLC... |
18:33.16 |
brlcad |
doesn't matter if we think *nobody* uses it --
it matters if we "publicly published" in some manner |
18:33.41 |
starseeker |
true |
18:33.58 |
starseeker |
yeah, I think that counts as minor
then |
18:34.00 |
brlcad |
every API could use some TLC but it's actually
one of the more consistent ones .. just very terse |
18:34.38 |
brlcad |
it counts as a minor, but it may still be
minimally impacting .. have to see what all is impacted when it's
moved |
18:34.56 |
brlcad |
the move can still happen and it get bundled
into librt as a LIBADD |
18:35.08 |
brlcad |
then removed in 7.20 |
18:35.20 |
starseeker |
nods |
18:36.20 |
starseeker |
wonders if it might be better
to do this sync in stages... |
19:48.22 |
_psilva_ |
we change APIs in alpha :p |
19:52.51 |
CIA-48 |
BRL-CAD: 03starseeker * r41254
10/brlcad/branches/cmake/src/other/tcl/CMake/CheckSystemFunctionality.cmake: |
19:52.51 |
CIA-48 |
BRL-CAD: Start trying to make a more generic
version of the CMake functionality for |
19:52.51 |
CIA-48 |
BRL-CAD: checking things. This one will
hopefully cover both the config.h case and the |
19:52.51 |
CIA-48 |
BRL-CAD: CFLAGS case, although a lot of
rewiring is needed to test it properly. |
20:04.39 |
brlcad |
nothing wrong with an API changing in alpha,
it's supposed to change, even in beta I'd expect maybe some
changes |
20:08.35 |
CIA-48 |
BRL-CAD: 03starseeker * r41255
10/brlcad/branches/cmake/src/other/tcl/ (CMake/tcl.cmake
CMakeLists.txt): Shift tcl build to using changed macros. |
20:19.02 |
CIA-48 |
BRL-CAD: 03starseeker * r41256
10/brlcad/branches/cmake/src/other/tk/library/CMakeLists.txt: As
with tcl, put the tk scripts where they should be for a local run
(hopefully) |
21:08.33 |
CIA-48 |
BRL-CAD: 03starseeker * r41257
10/brlcad/branches/cmake/src/other/incrTcl/itcl/ (4 files in 3
dirs): Get closer to a proper itcl build - not there yet, need to
compare with a standard itcl build and install. |
21:13.50 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
21:54.49 |
CIA-48 |
BRL-CAD: 03starseeker * r41258
10/brlcad/branches/cmake/src/other/ (incrTcl/itcl/CMakeLists.txt
tcl/CMakeLists.txt): Fix a couple bugs, add a little extra foo to
make itcl locatable in the build dir. |
22:46.46 |
CIA-48 |
BRL-CAD: 03starseeker * r41259
10/brlcad/branches/cmake/src/bwish/main.c: BWISH is not cooperating
- tweak it some, but so far it only starts if run from exactly the
build dir. |
23:02.26 |
starseeker |
meh - tclsh runs successfully now, but btclsh
doesn't (at least, not in the build) |
23:03.56 |
starseeker |
drills into tclsh to see why
it's succeeding when we're failing... |
23:10.24 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
23:26.55 |
starseeker |
hmm, tcl_library isn't set right |
23:31.01 |
starseeker |
checks to make sure tclsh
works after install... |
23:34.08 |
starseeker |
yep, that's it - somehow, tcl_library in the
CMake btclsh build is getting set to a (wrong) relative
path |
23:34.40 |
starseeker |
will check the autotools
build for foo he missed when doing the initial
setup |