| 01:02.11 |
*** join/#brlcad crazy_imp
(~mj@a89-182-209-17.net-htp.de) |
| 02:02.12 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 03:21.19 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 03:23.26 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
| 03:23.34 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 03:27.42 |
*** join/#brlcad ``Erik_
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 03:37.23 |
*** join/#brlcad Dweezahr
(~Dweezahr@flits102-34.flits.rug.nl) |
| 03:37.23 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 03:37.23 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 03:37.23 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 03:37.23 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
| 03:37.23 |
*** join/#brlcad DaveLo
(~claymore@BZ.BZFLAG.BZ) |
| 05:08.07 |
starseeker |
finally finds a workable way to splice multiple videos into
one and convert them to mpeg2 |
| 05:14.24 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.16.143) |
| 05:14.24 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:00.10 |
CIA-43 |
BRL-CAD:
03brlcad * r42066 10/brlcad/trunk/src/mged/Makefile.am: the bot
face/normal arrays should probably be reverted back to integers,
but turn off strict in here in the meantime to fix the
build. |
| 06:31.54 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:33.32 |
CIA-43 |
BRL-CAD:
03brlcad * r42067 10/brlcad/trunk/ (20 files in 9 dirs): more
size_t cascading. put the type to use throughout much of libbn and
most caller code. other code affected was sketch object code,
vertex and curve counts. |
| 07:45.31 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 07:45.31 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source
Anniversary 2010-12-21 !!! Six years... |
| 07:52.55 |
CIA-43 |
BRL-CAD:
03brlcad * r42068 10/brlcad/trunk/src/conv/asc/ (asc2g.c g2asc.c):
isspace() needs ctype.h |
| 08:19.04 |
CIA-43 |
BRL-CAD:
03brlcad * r42069 10/brlcad/trunk/src/librt/primitives/
(extrude/extrude.c nmg/nmg_misc.c): size_t quellage |
| 08:33.45 |
CIA-43 |
BRL-CAD:
03brlcad * r42070 10/brlcad/trunk/ (23 files in 11
dirs): |
| 08:33.46 |
CIA-43 |
BRL-CAD:
revert the conversion of the bot face/vertex/normal arrays from
being size_t |
| 08:33.46 |
CIA-43 |
BRL-CAD: back
to int. additionally, convert the remainder of bot struct size
types over |
| 08:33.47 |
CIA-43 |
BRL-CAD: to
size_t completely. this propagates hundreds of ancillary changes
(more than |
| 08:33.47 |
CIA-43 |
BRL-CAD: 400)
but provides the added benefits of more extensive value range on
some |
| 08:33.53 |
CIA-43 |
BRL-CAD:
platforms, better warning/bug detection, and more consistently
making size types |
| 08:33.53 |
CIA-43 |
BRL-CAD: be
unsigned so no negative values is inherent. |
| 08:33.53 |
CIA-43 |
BRL-CAD:
03brlcad * r42071 10/brlcad/trunk/src/libged/bot_merge.c: quellage,
use size_t |
| 08:33.56 |
CIA-43 |
BRL-CAD:
03brlcad * r42072 10/brlcad/trunk/src/libged/bot.c: use EQUAL() for
exact floating point comparison |
| 08:49.45 |
CIA-43 |
BRL-CAD:
03brlcad * r42073 10/brlcad/trunk/src/mged/ (animedit.c chgtree.c
edars.c edsol.c titles.c usepen.c): more size_t
quellage |
| 10:44.09 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.240.10) |
| 10:44.09 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:46.42 |
*** join/#brlcad mafm
(~mafm@134.Red-83-35-148.dynamicIP.rima-tde.net) |
| 11:29.24 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.16.143) |
| 11:29.24 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 11:48.46 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.16.143) |
| 11:48.46 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 11:52.46 |
*** join/#brlcad Axman6_
(~Axman6@pdpc/supporter/student/Axman6) |
| 12:09.44 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 12:27.16 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:47.31 |
starseeker |
d_rossberg:
any luck with the cmake branch? |
| 14:12.34 |
d_rossberg |
starseeker:
i'm still looking for a way to set the install
directory |
| 14:13.36 |
*** join/#brlcad AlecTaylor
(~Tauk@unaffiliated/alectaylor) |
| 14:13.37 |
AlecTaylor |
hi |
| 14:16.50 |
AlecTaylor |
How do I
create this http://i55.tinypic.com/1606amg.jpg
in BRL-CAD? |
| 14:48.34 |
starseeker |
d_rossberg:
install directory? BRLCAD_PREFIX may be what you want |
| 14:49.26 |
starseeker |
AlecTaylor:
the sketch, or a 3D object? |
| 14:53.27 |
d_rossberg |
starseeker:
but BRLCAD_PREFIX isn't present in the cmake gui |
| 14:54.48 |
d_rossberg |
i could
probable add it, however it is an important value which should be
there |
| 14:55.19 |
starseeker |
um... |
| 14:56.15 |
starseeker |
weird |
| 14:56.29 |
starseeker |
i've been
using CMake from the command line... |
| 14:56.38 |
starseeker |
I see it
isn't there, one second... |
| 15:01.08 |
CIA-43 |
BRL-CAD:
03starseeker * r42074 10/brlcad/branches/cmake/CMakeLists.txt: Make
a stab at getting BRLCAD_PREFIX displayed in the CMake
gui |
| 15:01.43 |
starseeker |
see if that
helps - I've been using cmake almost exclusively from the command
line, so there are probably other tweaks needed to clean up the gui
presentation |
| 15:02.26 |
starseeker |
incidently,
there is a known limitation right now about spaces in pathnames -
they will almost certainly cause failures with the Tcl/Tk
build |
| 15:02.41 |
starseeker |
I'm working
on that, but it's not fixed yet |
| 15:03.30 |
starseeker |
reflects that should probably be renamed to
BRLCAD_INSTALL_PREFIX... |
| 15:05.01 |
d_rossberg |
i'll have a
look at it as soon as the compile jobs ended |
| 15:05.09 |
starseeker |
no problem
:-) |
| 15:05.32 |
starseeker |
which
platform are you building on? |
| 15:06.51 |
AlecTaylor |
starseeker:
3D object |
| 15:07.12 |
starseeker |
I'd use a
series of cylinders |
| 15:07.23 |
starseeker |
are you new
to BRL-CAD? |
| 15:07.33 |
AlecTaylor |
starseeker:
Here's the top view http://i56.tinypic.com/24bklds.jpg |
| 15:07.43 |
AlecTaylor |
starseeker:
Never used it before |
| 15:08.18 |
starseeker |
AlecTaylor:
ah, then you'll want to start with this: http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf |
| 15:09.08 |
starseeker |
that object
looks pretty straightforward, so you should be able to do it with
the techniques described in that tutorial |
| 15:09.34 |
d_rossberg |
starseeker:
MS Windows XP (32bit) with MSVS 2008 |
| 15:09.47 |
starseeker |
winces - ah, the toughest platform |
| 15:24.56 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r42075 10/brlcad/trunk/src/adrt/ (5 files in 2
dirs): new tieprivate.h, clean up of tie.h |
| 15:27.17 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r42076 10/brlcad/trunk/src/adrt/Makefile.am: add
STRICT_FLAGS |
| 15:31.33 |
AlecTaylor |
starseeker:
How long will it take (about) to learn how to do it, then to create
it? |
| 15:31.50 |
AlecTaylor |
won't be able to work on it after tonight, and it's 2:30am
already |
| 15:32.17 |
brlcad |
AlecTaylor:
there have been new users / students that have gotten through all
of the mged tutorials in just a couple hours |
| 15:32.51 |
brlcad |
you won't be
very good, but you should be able to make a model as simple as the
one you sketched in under an hour once you have the
basics |
| 15:33.29 |
brlcad |
the hardest
part is usually learning all of the various modeling commands,
learning how to use them |
| 15:33.51 |
AlecTaylor |
hmm |
| 15:34.00 |
brlcad |
someone
proficient in mged could probably make that model in less than 10
minutes |
| 15:34.15 |
AlecTaylor |
brlcad: 10
minutes? |
| 15:34.20 |
brlcad |
less
than |
| 15:35.11 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r42077 10/brlcad/trunk/src/adrt/libtie/ (tie.c
tieprivate.h): Move the win32 near/far fix to the right
place |
| 15:35.27 |
AlecTaylor |
is a volunteer putting in 8 hours a day, 6 days a week for a
robotics competetion [mentoring]. Would you be able to do me a
[massive] favour by modelling it for me? |
| 15:35.31 |
AlecTaylor |
brlcad^ |
| 15:35.38 |
brlcad |
once you
climb the steep learning curve, you can be just as efficient as
you'd be in other CAD/modeling systems |
| 15:37.07 |
AlecTaylor |
brlcad: I'll
read the entire guide + more in a week, I just need something
working [literally in the next little while; as I'm going in for
surgery tomorrow and want to show my students my Robot design in
CAD] |
| 15:37.26 |
brlcad |
AlecTaylor:
heh, sorry ... I put a lot of volunteer time into BRL-CAD as it is;
my skills are better put to use doing software
development |
| 15:37.50 |
AlecTaylor |
Same, that's
my area of expertise! |
| 15:37.57 |
AlecTaylor |
Swap for
10mins? :P |
| 15:38.25 |
AlecTaylor |
is an avid C++ programmer and enthusiast, everything from Qt
to Wt and CLI! |
| 15:38.30 |
brlcad |
it wouldn't
be 10 minutes for *me* .. I'm certainly not a proficient modeler
:) |
| 15:38.48 |
AlecTaylor |
I see!
:) |
| 15:39.43 |
brlcad |
you know, if
you're just showing off a design, you might have better luck
quickly whipping up something in sketchup |
| 15:40.00 |
brlcad |
it'd be
crappy for CAD purposes, but it'd showcase your design in
3D |
| 15:48.17 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r42078 10/brlcad/trunk/src/adrt/librender/ (13
files): const propogation |
| 15:51.27 |
AlecTaylor |
brlcad: ended
up just showing them something I wrote in Blender [the stand for
the telescope] and the aforementioned side-view and top-view
mockups |
| 15:52.15 |
AlecTaylor |
Thanks
though |
| 15:53.20 |
brlcad |
AlecTaylor:
if you hang around, someone might be willing to help you
out |
| 16:04.45 |
CIA-43 |
BRL-CAD:
03starseeker * r42079
10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: Don't cram
two commands on one line - make use of CMake's support for multiple
COMMAND lines executed in order. |
| 16:04.55 |
d_rossberg |
starseeker:
it looks like there is a clean-up somewhere in the cmake build
which makes looking for errors uncomfortable |
| 16:05.07 |
CIA-43 |
BRL-CAD:
03brlcad * r42080 10/brlcad/trunk/TODO: cp command should take
multiple copy names |
| 16:05.18 |
starseeker |
d_rossberg:
what do you mean? |
| 16:07.24 |
d_rossberg |
i'm using the
batch build in VS, there i got 3 errors, then i started the batch
build again to see these errors but it started to compile the
successfull builds too |
| 16:09.32 |
starseeker |
hmm |
| 16:10.15 |
starseeker |
I'm seeing a
few errors on my first pass, but I'm not sure what those are
because my second pass comes up clean |
| 16:10.23 |
starseeker |
not sure why
it's rebuilding everything |
| 16:10.36 |
starseeker |
you're using
the ALL_BUILD target? |
| 16:13.39 |
d_rossberg |
ALL_BUILD and
INSTALL are switched off |
| 16:21.25 |
brlcad |
too bad
AlecTaylor wasn't more patient, http://brlcad.org/tmp/stand.png |
| 16:21.58 |
brlcad |
half hour,
not too shabby but I still suck |
| 16:22.16 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 16:22.53 |
starseeker |
d_rossberg:
um... |
| 16:23.08 |
starseeker |
maybe I'd
better write up how I'm building so we can compare
notes |
| 16:24.22 |
d_rossberg |
starseeker:
don't worry, i've completely different problems at the moment
;) |
| 16:28.40 |
starseeker |
d_rossberg:
with the cmake branch or other stuff? |
| 16:29.21 |
d_rossberg |
with other
stuff |
| 17:31.40 |
CIA-43 |
BRL-CAD:
03brlcad * r42081 10/brlcad/trunk/src/libged/ (38 files): massive
quantities of quellage. size_t upgrades, unused params, exact
floating point comaprisons, and more. 300+ fixes. oh
my. |
| 17:33.15 |
*** join/#brlcad mafm_
(~mafm@134.Red-83-35-148.dynamicIP.rima-tde.net) |
| 17:38.53 |
CIA-43 |
BRL-CAD:
03starseeker * r42082
10/brlcad/branches/cmake/CMakeLists.txt: |
| 17:38.53 |
CIA-43 |
BRL-CAD: Take
the first steps to 'properly' handle CMAKE_INSTALL_PREFIX and the
issue of |
| 17:38.54 |
CIA-43 |
BRL-CAD:
find_package searching in it when cmake is re-run. Don't really
want to |
| 17:38.54 |
CIA-43 |
BRL-CAD:
manhandle CMAKE_INSTALL_PREFIX any more than we have to, so try
this. |
| 18:01.41 |
DX^ |
I hate
modeling |
| 18:01.45 |
DX^ |
thank god for
CAD operators |
| 18:26.21 |
CIA-43 |
BRL-CAD:
03starseeker * r42083
10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: Try
explicit copy and remove steps - apparently rename causes some
issue with NFS, let's see if it's specific to rename |
| 18:36.44 |
CIA-43 |
BRL-CAD:
03starseeker * r42084 10/brlcad/branches/cmake/ (4 files in 4
dirs): Try to migrate more towards standard CMake variables -
BRLCAD_PREFIX should now be only for the purposes of removal from
find_package search paths. |
| 19:01.22 |
*** join/#brlcad merzo
(~merzo@53-11-94-178.pool.ukrtel.net) |
| 20:04.10 |
*** join/#brlcad AlecTaylor
(~Tauk@unaffiliated/alectaylor) |
| 20:11.51 |
brlcad |
AlecTaylor:
welcome back |
| 20:12.24 |
brlcad |
AlecTaylor:
if you'd waited 10 more minutes, I had this up right after you
left: http://brlcad.org/tmp/stand.png |
| 20:42.44 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 20:50.29 |
AlecTaylor |
brlcad:
Perfect! |
| 20:50.30 |
AlecTaylor |
Thanks |
| 20:55.03 |
AlecTaylor |
has never been happier about setting up his
auto-connect! |
| 20:55.32 |
AlecTaylor |
brlcad: Would
you be able to share the actual CAD file? |
| 21:20.47 |
CIA-43 |
BRL-CAD:
03brlcad * r42085 10/brlcad/trunk/src/conv/g-xxx.c: |
| 21:20.47 |
CIA-43 |
BRL-CAD:
refactor the example converter to leave all of the more advanced
and deprecated |
| 21:20.48 |
CIA-43 |
BRL-CAD:
primitives as an exercise to the reader since we don't actually do
anything with |
| 21:20.48 |
CIA-43 |
BRL-CAD: the
object variables pulled from the idb_ptr. quell remaining warnings
too. |
| 21:21.06 |
brlcad |
AlecTaylor:
it's in that same directory |
| 21:22.03 |
brlcad |
AlecTaylor:
and a word of caution, I didn't really use any best practices or
structure the geometry in any way, just made a shape approximation
to your sketch |
| 21:23.08 |
CIA-43 |
BRL-CAD:
03brlcad * r42086 10/brlcad/trunk/src/librt/db_path.c: off_t's may
be signed, accommodate. |
| 21:26.37 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r42087 10/brlcad/trunk/src/adrt/ (38 files in 3
dirs): favor direct struct use instead of hiding them behind a
typedef. |
| 21:38.02 |
CIA-43 |
BRL-CAD:
03brlcad * r42088 10/brlcad/trunk/ (3 files in 2 dirs): make ars
parameters be unsigned size_t types as well. |
| 21:38.51 |
CIA-43 |
BRL-CAD:
03brlcad * r42089 10/brlcad/trunk/src/adrt/libtie/tie.c: eliminate
exact floating point comaprison |
| 21:39.12 |
CIA-43 |
BRL-CAD:
03brlcad * r42090 10/brlcad/trunk/src/adrt/libtie/tie_kdtree.c:
quell warnings on 'index' and undefined preprocs. |
| 22:15.40 |
CIA-43 |
BRL-CAD:
03brlcad * r42091 10/brlcad/trunk/src/adrt/adrt.h: unused
variables, dunno if safe to remove |
| 22:15.58 |
CIA-43 |
BRL-CAD:
03brlcad * r42092
10/brlcad/trunk/src/adrt/librender/render_internal.h: remove
trailing semi so uses have to have semi. quiets warnings about ISO
C not allowing floating semis outside of functions. |
| 22:17.37 |
CIA-43 |
BRL-CAD:
03brlcad * r42093 10/brlcad/trunk/src/adrt/load.c: static init
no-go |
| 22:18.24 |
CIA-43 |
BRL-CAD:
03brlcad * r42094 10/brlcad/trunk/src/adrt/ (load.h load_g.c):
remove unused dlen param, mark other unused params. |
| 22:32.42 |
CIA-43 |
BRL-CAD:
03brlcad * r42095
10/brlcad/trunk/src/adrt/librender/camera.c: |
| 22:32.43 |
CIA-43 |
BRL-CAD:
ouch, tricky one. ISO C doesn't actually permit dlsym() to work the
way it |
| 22:32.43 |
CIA-43 |
BRL-CAD:
works with the need to convert a void* to a function pointer so the
compiler has |
| 22:32.44 |
CIA-43 |
BRL-CAD: to
be cajouled. we trick it with a cast through an intptr_t, which is
a type |
| 22:32.44 |
CIA-43 |
BRL-CAD: big
enough to hold a pointer address, albeit not necessarily a function
pointer. |
| 22:32.45 |
CIA-43 |
BRL-CAD: the
rest of the changes are just consistency with the callback
mechanism type |
| 22:32.45 |
CIA-43 |
BRL-CAD:
returning an int and constness. |
| 22:33.15 |
``Erik_ |
ffffu |
| 22:38.04 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r42096 10/brlcad/trunk/src/adrt/ (30 files in 3
dirs): major migration to use significantly more vmath
types/macros |
| 22:42.44 |
brlcad |
``Erik: heh,
hope that's not causing too much grief |
| 22:42.56 |
``Erik |
a few
conflicts |
| 22:43.03 |
brlcad |
you enabled
strict in there, so my build's busted -- it was either fix em or
turn it back off |
| 22:44.21 |
``Erik |
hm, which
compiler? it works for me on fbsd (gcc4.2.1), linux (gcc4.1.2, mac
(gcc4.2.1) and win32(msvc80 |
| 22:44.25 |
``Erik |
s/0$/)/ |
| 22:45.01 |
``Erik |
anyways, I
think I'm done with it for the night, all committed up
O.o |
| 22:45.11 |
brlcad |
hermes is
failing |
| 22:45.50 |
brlcad |
gcc 4.1.2
linux |
| 22:46.04 |
brlcad |
maybe you
didn't --enable-warnings (goes hand-in-hand with
STRICT_FLAGS) |
| 22:53.14 |
CIA-43 |
BRL-CAD:
03brlcad * r42097 10/brlcad/trunk/src/adrt/ (13 files in 2 dirs):
mark a bunch of unused params |
| 22:55.56 |
brlcad |
looks like
your only parially done with the migration? the render work()
function takes a TIE_3* but you're passing it vect_t*
(camera.c:511) |
| 23:05.30 |
CIA-43 |
BRL-CAD:
03brlcad * r42098 10/brlcad/trunk/src/adrt/Makefile.am: looks like
just few warnings remaining (be sure to --enable-warnings), about
65 on 64-bit linux, but saving them for later to minimize conflict.
remove strict_flags in the meantime. |
| 23:18.36 |
brlcad |
now you'll
get 'em |
| 23:18.57 |
CIA-43 |
BRL-CAD:
03brlcad * r42099 10/brlcad/trunk/configure.ac: |
| 23:18.58 |
CIA-43 |
BRL-CAD: now
that more than 2/3rds of the package compiles completely free of
warnings, |
| 23:18.58 |
CIA-43 |
BRL-CAD: go
ahead and make verbose warnings the default. fully sync the warning
flags |
| 23:18.59 |
CIA-43 |
BRL-CAD: with
strict so if strict is enabled, you're getting everything
that |
| 23:18.59 |
CIA-43 |
BRL-CAD:
--enable-warnings was providing along with -Werror. |
| 23:25.12 |
CIA-43 |
BRL-CAD:
03brlcad * r42100 10/brlcad/trunk/src/conv/ (24 files in 9
dirs): |
| 23:25.13 |
CIA-43 |
BRL-CAD: this
huge update represents the remainder compilation quieting of all
the |
| 23:25.13 |
CIA-43 |
BRL-CAD:
converters. missing params, exact floating point comparisons,
shadowed |
| 23:25.38 |
CIA-43 |
BRL-CAD:
variables, unused params, long string literals, signedness
mismatching, size_t |
| 23:25.38 |
CIA-43 |
BRL-CAD:
updates and more so that STRICT_BUILD works clean (on Mac gcc
4.0.1). several |
| 23:25.38 |
CIA-43 |
BRL-CAD: days
to complete, more than 1300 (minor) changes. |
| 23:45.29 |
``Erik |
hm, I had the
flags in the compile lines, odd *shrug* I'll dig into it some more
tomorrow |
| 23:47.44 |
CIA-43 |
BRL-CAD:
03brlcad * r42101 10/brlcad/trunk/src/other/openNURBS/ (7
files): |
| 23:47.44 |
CIA-43 |
BRL-CAD: the
ON_OBJECT_IMPLEMENT() and ON_VIRTUAL_OBJECT_IMPLEMENT() macros are
followed |
| 23:47.45 |
CIA-43 |
BRL-CAD: in
code with semicolons so the macro itself needs to end with a
statement that |
| 23:47.45 |
CIA-43 |
BRL-CAD:
requires a semicolon. a simple reordering of the first line
suffices. |
| 23:47.46 |
CIA-43 |
BRL-CAD:
remainder of fixes are stray semicolons mysteriously following
functions. |
| 00:06.04 |
CIA-43 |
BRL-CAD:
03johnranderson * r42102 10/brlcad/trunk/src/libbu/simd.c: Since we
are using -Wundef option, we must use defined( __SSE__
) |
| 00:32.49 |
CIA-43 |
BRL-CAD:
03brlcad * r42103 10/brlcad/trunk/src/libbn/bntester.c: init vars.
potential for function_num and test_case_line_num to be accessed
without initialization |
| 00:33.08 |
CIA-43 |
BRL-CAD:
03brlcad * r42104
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: trailing comma
at end of enumerator list makes gcc unhappy |
| 00:33.59 |
brlcad |
``Erik:
--enable-warnings (before r42099) had two or three extra warnings
that weren't enabled by default |
| 00:45.23 |
CIA-43 |
BRL-CAD:
03brlcad * r42105 10/brlcad/trunk/src/libbn/bntester.c: (log
message trimmed) |
| 00:45.24 |
CIA-43 |
BRL-CAD: this
is a really tricky one. quell warnings about variables getting
clobbered |
| 00:45.24 |
CIA-43 |
BRL-CAD:
after a longjmp or vfork by making them all static. we can do this
here because |
| 00:45.50 |
CIA-43 |
BRL-CAD:
they're all just main() variables fortunately. bu's jump mechanism
uses |
| 00:45.51 |
CIA-43 |
BRL-CAD:
setjump, so an implementation could clobber local non-static
non-volatile |
| 00:45.51 |
CIA-43 |
BRL-CAD:
variables. this tricking making them static works or it would have
also worked |
| 00:45.51 |
CIA-43 |
BRL-CAD: to
wrap the BU_SETJUMP/BU_UNSETJUMP calls into functions that are
passed |
| 00:59.50 |
CIA-43 |
BRL-CAD:
03brlcad * r42107 10/brlcad/trunk/src/libbu/simd.c: no guarantee
that __GNUC__ will be defined either. |
| 00:59.52 |
CIA-43 |
BRL-CAD:
03brlcad * r42106 10/brlcad/trunk/src/conv/ (3 files in 2
dirs): |
| 00:59.53 |
CIA-43 |
BRL-CAD:
behold the annoyance of -pedantic. believe it or not, even for ISO
C++, |
| 00:59.54 |
CIA-43 |
BRL-CAD:
variable sized arrays are but a mere gcc extension. if you want
variable-sized, |
| 00:59.55 |
CIA-43 |
BRL-CAD: you
either have to new/delete/malloc/free (bleh) or leverage
std::vector |
| 00:59.56 |
CIA-43 |
BRL-CAD:
templatization. the latter is fortunately a trivial declaration
tweak and the |
| 00:59.57 |
CIA-43 |
BRL-CAD: rest
should behave accordingly. |
| 00:59.59 |
CIA-43 |
BRL-CAD:
03starseeker * r42108 10/brlcad/branches/cmake/TODO.cmake: Sigh.
Update the TODO list for CMake with more known items. |
| 01:02.34 |
*** join/#brlcad crazy_imp
(~mj@a89-182-195-57.net-htp.de) |
| 01:06.40 |
CIA-43 |
BRL-CAD:
03starseeker * r42109 10/brlcad/branches/cmake/CMakeLists.txt: Want
to set to /usr/brlcad as default instead of the CMake
default. |
| 01:12.02 |
CIA-43 |
BRL-CAD:
03brlcad * r42110 10/brlcad/trunk/src/conv/iges/ (g-iges.c main.c
usage.c): more string literals that are way too long. convert to
usage() functions. |
| 01:12.26 |
CIA-43 |
BRL-CAD:
03brlcad * r42111 10/brlcad/trunk/src/conv/comgeom/tools.c: curious
one, untested. |
| 01:13.56 |
CIA-43 |
BRL-CAD:
03brlcad * r42112 10/brlcad/trunk/src/vdeck/vdeck.c: more
size_t |
| 01:19.21 |
CIA-43 |
BRL-CAD:
03brlcad * r42113 10/brlcad/trunk/NEWS: john added support for
comments as the first line(s) of a .asc file. previously was using
title/units as keywords to recognize a .asc file, now it's the
first non-comment line that has to have a title/units
command. |
| 01:27.21 |
CIA-43 |
BRL-CAD:
03starseeker * r42114 10/brlcad/branches/cmake/ (45 files in 45
dirs): Generalize the INSTALL_* variables - gives a parent project
the chance to do its own setting, in principle, without having to
use the BRLCAD specific variables. Not sure how useful it really
is, but why not. |
| 01:28.16 |
CIA-43 |
BRL-CAD:
03starseeker * r42115 10/brlcad/branches/cmake/TODO.cmake: reminder
- need to rework SCL CMake logic |
| 01:30.28 |
CIA-43 |
BRL-CAD:
03starseeker * r42116
10/brlcad/branches/cmake/src/libbu/CMakeLists.txt: Add timer.c to
libbu CMakeLists.txt file |
| 01:45.26 |
CIA-43 |
BRL-CAD:
03starseeker * r42117 10/brlcad/branches/cmake/src/tclscripts/
(hv3/pkgIndex.tcl hv3/tclIndex swidgets/scripts/tclIndex): Add back
in some of the tclIndex and pkgIndex files - this should all go
when CMake becomes mainline, but for now put them back to avoid
difference with trunk. |
| 01:46.27 |
CIA-43 |
BRL-CAD:
03brlcad * r42118 10/brlcad/trunk/ (6 files in 5 dirs): |
| 01:46.28 |
CIA-43 |
BRL-CAD:
differentiate BU_PTBL_LEN() from BU_PTBL_END() such that the prior
is not a |
| 01:46.28 |
CIA-43 |
BRL-CAD:
valid lvalue. this makes it more appropriate for loop testing and
can be an |
| 01:46.29 |
CIA-43 |
BRL-CAD:
unsigned type instead of the potentially signed off_t offset type
of the |
| 01:46.29 |
CIA-43 |
BRL-CAD:
underlying struct member. update references
accordingly. |
| 01:48.48 |
CIA-43 |
BRL-CAD:
03starseeker * r42119 10/brlcad/branches/cmake/ (37 files in 14
dirs): Update cmake branch to trunk r42052. This is known to be a
non-working CMake state, but this sync is being done in stages to
avoid some conflicts from the trunk CMakeLists.txt
files. |
| 01:55.04 |
CIA-43 |
BRL-CAD:
03brlcad * r42120 10/brlcad/trunk/src/ (5 files in 4 dirs): more
quieting of the compilation |
| 01:58.46 |
CIA-43 |
BRL-CAD:
03starseeker * r42121 10/brlcad/branches/cmake/ (197 files in 44
dirs): Update cmake branch to trunk r42119 |
| 02:33.16 |
CIA-43 |
BRL-CAD:
03starseeker * r42122 10/brlcad/branches/cmake/ (7 files in 6
dirs): Update cmake branch to trunk r42120 |
| 02:58.06 |
CIA-43 |
BRL-CAD:
03starseeker * r42123 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/BRLCAD_Util.cmake): Tweaks - seems to produces better
results for make package. |
| 03:12.51 |
CIA-43 |
BRL-CAD:
03starseeker * r42124
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Add the
deprecated Tcl/Tk vars into the handle-standard-args logic - they
apparently aren't visible to other projects otherwise. |
| 03:27.43 |
CIA-43 |
BRL-CAD:
03starseeker * r42125 10/brlcad/branches/cmake/TODO.cmake: Tweaks
to settings seem to have CPack behaving better - need to study
results a lot more, but at least the bin directory has more than a
couple dozen binaries now. |
| 03:29.07 |
CIA-43 |
BRL-CAD:
03brlcad * r42126 10/brlcad/trunk/src/conv/dxf/dxf-g.c: init vars
before testing |
| 03:33.24 |
CIA-43 |
BRL-CAD:
03brlcad * r42127 10/brlcad/trunk/src/conv/g-acad.c: |
| 03:33.25 |
CIA-43 |
BRL-CAD:
massive restructure in order to fix a bug assuming that variables
are accessible |
| 03:33.25 |
CIA-43 |
BRL-CAD:
after a longjmp. quite a chore to quell the warning due to a bug in
pre 4.3 |
| 03:33.26 |
CIA-43 |
BRL-CAD: gcc,
but seems to be possible to quiet the warning if we start a new
frame (and |
| 03:33.26 |
CIA-43 |
BRL-CAD:
don't access the var/arg after that call). some testing, seems to
work. |
| 03:33.55 |
CIA-43 |
BRL-CAD:
03brlcad * r42128 10/brlcad/trunk/src/conv/Makefile.am: not quite
intentional to enable strict in here just yet. -pedantic is a
bitch. |
| 04:17.10 |
CIA-43 |
BRL-CAD:
03brlcad * r42129 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
off-by-one copypaste typo. 2, not k. |
| 04:32.48 |
CIA-43 |
BRL-CAD:
03starseeker * r42130 10/brlcad/branches/cmake/CMakeLists.txt:
Tweak generator list, vars for CPack |
| 04:33.57 |
CIA-43 |
BRL-CAD:
03starseeker * r42131 10/brlcad/branches/cmake/src/other/
(tcl/doc/install_man.cmake.in tk/doc/install_man.cmake.in): the
Tcl/Tk man page script was installing to CMAKE_INSTALL_DIR even
during make package - make it respect DESTDIR if it's
set. |
| 04:56.43 |
starseeker |
hmm... that
won't do either, CPack ignores those man pages as not being from a
target |
| 05:03.26 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.16.143) |
| 05:03.32 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:29.12 |
CIA-43 |
BRL-CAD:
03starseeker * r42132 10/brlcad/branches/cmake/src/other/ (4 files
in 2 dirs): Make another stab at the Tcl/Tk man pages, this time
doing the generation up front and using FILE(GLOB to grab the
results and put them into install targets. |
| 05:35.57 |
CIA-43 |
BRL-CAD:
03starseeker * r42133 10/brlcad/branches/cmake/src/other/
(tcl/doc/CMakeLists.txt tk/doc/CMakeLists.txt): |
| 05:35.58 |
CIA-43 |
BRL-CAD: Only
do the generation once. If we really want to do this right we need
some |
| 05:35.59 |
CIA-43 |
BRL-CAD: kind
of custom commands, targets, output files to signify completed
commands, |
| 05:35.59 |
CIA-43 |
BRL-CAD: etc
- not worth it, and this avoids repeated processing we don't
need. |
| 05:50.14 |
CIA-43 |
BRL-CAD:
03starseeker * r42134
10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Tcl link
workaround isn't working for make package - need to
re-examine. |
| 05:54.07 |
CIA-43 |
BRL-CAD:
03starseeker * r42135
10/brlcad/branches/cmake/src/other/tcl/doc/CMakeLists.txt: Arrrrgh
- make package is still not grabbing these files. May have to go
all out with custom commands and targets. |
| 07:26.22 |
*** join/#brlcad AlecTaylor
(~Tauk@unaffiliated/alectaylor) |
| 09:54.50 |
*** join/#brlcad mafm_
(~mafm@166.Red-83-45-72.dynamicIP.rima-tde.net) |
| 11:38.09 |
DaveLo |
Mernin!
Anyone at work yet? |
| 13:36.40 |
CIA-43 |
BRL-CAD:
03d_rossberg * r42136
10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: added
bu_vls_trunc2() for asc2g conversion program |
| 13:40.40 |
starseeker |
hmm... KDE on
Windows |
| 13:41.06 |
starseeker |
is intrigued, but hesitates to mess with his Windows
partition too much because it would be hard to
fix |
| 13:46.02 |
starseeker |
huh - kinda
looks like bzflag with some enhancements:
http://www.ubuntugamer.com/2011/01/zero-ballistics-a-rather-addictive-native-3d-tank-shooter/ |
| 13:51.15 |
*** join/#brlcad mafm
(~mafm@166.Red-83-45-72.dynamicIP.rima-tde.net) |
| 13:52.13 |
CIA-43 |
BRL-CAD:
03starseeker * r42137 10/brlcad/branches/cmake/src/other/
(tcl/doc/CMakeLists.txt tk/doc/CMakeLists.txt): Ah, was shooting
myself in the foot. We only GENERATE the man pages once, but we add
them to the INSTALL list every time cmake is run. |
| 14:04.21 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 14:15.09 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 14:36.21 |
CIA-43 |
BRL-CAD:
03starseeker * r42138
10/brlcad/branches/cmake/CMakeLists.txt: |
| 14:36.22 |
CIA-43 |
BRL-CAD:
Small change, but important for CPack packages - don't use absolute
dirs as |
| 14:36.22 |
CIA-43 |
BRL-CAD:
targets for install, which allows CPack to put things in the
package without |
| 14:36.23 |
CIA-43 |
BRL-CAD:
hard-coding the prefix (in essence building a subdirectory
structure inside the |
| 14:36.23 |
CIA-43 |
BRL-CAD:
archive |
| 14:55.59 |
CIA-43 |
BRL-CAD:
03starseeker * r42139 10/brlcad/branches/cmake/src/ (7 files in 7
dirs): |
| 14:56.00 |
CIA-43 |
BRL-CAD:
Strip out more absolute paths for installs. The src/other/step
directory isn't |
| 14:56.00 |
CIA-43 |
BRL-CAD: with
the program yet, but that needs major cleanup anyway so leave it
for now. |
| 14:56.01 |
CIA-43 |
BRL-CAD:
Probably shouldn't be hardcoding bin and lib in as DESTINATIONS,
may want to do |
| 14:56.01 |
CIA-43 |
BRL-CAD: a
sweep for that too. |
| 15:02.21 |
brlcad |
starseeker:
have you looked at tom's crash? have a question on tedit for
you |
| 15:03.17 |
brlcad |
what's the
intent around line 986 where it calls: editor =
bu_which(EMACS_EDITOR); if (!strcmp(editor, bu_which(EMACS_EDITOR))
... |
| 15:03.54 |
d_rossberg |
i could
reproduce the crash, now i'm looking for a work-around |
| 15:04.15 |
brlcad |
d_rossberg: I
have a simplistic fix for the crash that at least avoid
strcmp() |
| 15:05.53 |
CIA-43 |
BRL-CAD:
03brlcad * r42140 10/brlcad/trunk/src/mged/tedit.c: |
| 15:05.54 |
CIA-43 |
BRL-CAD:
strcmp() doesn't like NULL and bu_which() may produce NULL, so
don't feed the |
| 15:05.54 |
CIA-43 |
BRL-CAD:
output of the latter directly into the prior. should at least avoid
the |
| 15:05.55 |
CIA-43 |
BRL-CAD:
specific crash reported by tom browder to the devel mailing list,
albeit |
| 15:05.55 |
CIA-43 |
BRL-CAD:
probably not the full fix needed. |
| 15:09.27 |
starseeker |
brlcad: ah,
thanks - I neglected to check if strcmp would handle null. Looks
like it's platform dependent, and therefore not to be relied
on |
| 15:11.03 |
brlcad |
there's not
many stdc calls that can be trusted to accept null, even ones that
are documented to accept null |
| 15:11.17 |
d_rossberg |
on Windows
strcmp(0) will crash |
| 15:13.02 |
CIA-43 |
BRL-CAD:
03starseeker * r42141
10/brlcad/branches/cmake/src/archer/CMakeLists.txt: Archer's
CMakeLists.txt file needs a lot of love to make it work in the
build dir - these are just the first tweaks, lots more will be
needed. |
| 15:13.02 |
starseeker |
sigh |
| 15:13.25 |
starseeker |
launching an
editor from C code really seems to be a pain |
| 15:13.32 |
brlcad |
I believe
posix strcmp() is undefined if passed a null anyways, so crashing
is acceptable behavior |
| 15:13.45 |
d_rossberg |
whot do you
think about a bu_strcmp()? |
| 15:14.27 |
brlcad |
you mean
adding one? |
| 15:14.45 |
d_rossberg |
yes |
| 15:15.16 |
starseeker |
d_rossberg:
(bty - more to be done, but hopefully CMAKE_INSTALL_PREFIX will
behave more normally now and you won't need BRLCAD_PREFIX
anymore." |
| 15:15.41 |
starseeker |
leftover
garbage from early in the learning process |
| 15:15.44 |
d_rossberg |
strcmp() is
really annoying |
| 15:17.49 |
starseeker |
gets ready to head in... |
| 15:17.56 |
CIA-43 |
BRL-CAD:
03starseeker * r42142 10/brlcad/branches/cmake/TODO.cmake: Add note
about archer to TODO.cmake |
| 15:18.08 |
d_rossberg |
starseeker:
i've still the problem of huge rebuilds ... |
| 15:21.25 |
brlcad |
d_rossberg:
bu_strcmp() and/or bu_strlcmp() would be good additions to make
given there is already bu_str(lcat|lcpy|dup) |
| 15:21.44 |
brlcad |
starseeker:
any insight on that question? |
| 15:22.15 |
d_rossberg |
brlcad: i'm
already working on it |
| 15:22.27 |
starseeker |
brlcad: the
strcmp or the rebuilds? |
| 15:22.35 |
brlcad |
what's the
intent around line 986 where it calls: editor =
bu_which(EMACS_EDITOR); if (!strcmp(editor, bu_which(EMACS_EDITOR))
... |
| 15:22.46 |
brlcad |
now line 904
or something |
| 15:23.18 |
brlcad |
it sets
editor to the path to emacs, then checks if editor is .. the path
to emacs |
| 15:23.33 |
starseeker |
looks... |
| 15:24.16 |
brlcad |
I added the
"(editor &&" part just to check the result from bu_which ..
wasn't there before |
| 15:24.24 |
brlcad |
*just* added
it in the last commit |
| 15:24.33 |
brlcad |
d_rossberg:
okay, cool |
| 15:26.52 |
starseeker |
I believe
what was going on there was a check (once in classic mode) to see
if any of the known editor configurations that would work in
classic mode were viable |
| 15:27.30 |
brlcad |
I think I see
that, but those two specific lines don't make sense to
me |
| 15:28.22 |
starseeker |
um. |
| 15:28.28 |
starseeker |
yeah, not
sure what was going on there |
| 15:28.40 |
starseeker |
that strcmp
does look kinda pointless |
| 15:29.16 |
starseeker |
I think you
have the right answer |
| 15:29.20 |
brlcad |
well what I'm
reading is that IF you have emacs, then all of the other editor
tests will fail |
| 15:29.26 |
brlcad |
which maybe
was the intent |
| 15:29.31 |
d_rossberg |
brlcad: there
is no strlcmp |
| 15:29.41 |
brlcad |
d_rossberg: I
meant to write one :) |
| 15:30.13 |
starseeker |
brlcad:
probably it was something like that |
| 15:30.21 |
brlcad |
with similar
intent of the strlcpy functions, strlcmp checks for null, maybe has
a length specifier |
| 15:30.33 |
d_rossberg |
there are
strl*() functions for writing on buffers only |
| 15:31.47 |
brlcad |
okay |
| 15:32.19 |
brlcad |
fair enough,
it was just a thought for consistency with our own bu functions,
but matching the replacement is probably more important |
| 15:32.44 |
``Erik |
now that's a
lot of breakage |
| 15:33.13 |
starseeker |
brlcad: I
think I may have some rather convoluted logic there - I'm not sure
what the whole idea was with the count thing |
| 15:33.21 |
brlcad |
I could see
bu also providing a BU_STREQ() macro so that all of the equality
testing could be simplified consistent |
| 15:34.12 |
brlcad |
starseeker:
yeah, that is pretty funky ... search for everything, then if you
found anything, search for something |
| 15:34.46 |
starseeker |
oh,
wait |
| 15:35.11 |
starseeker |
I think I
might have been looking to see if a preset editor from above was a
potential bad case for classic mode |
| 15:35.43 |
starseeker |
looks at the previous revision of the code |
| 15:36.05 |
brlcad |
hm, maybe
if(BU_EQUALS(str1, str2)) or if (BU_EQUAL_STR(str1,
str2)) |
| 15:36.55 |
starseeker |
yeah, that
was it |
| 15:36.57 |
``Erik |
using
vls's? |
| 15:37.07 |
brlcad |
there are
approximately 1418 calls to strcmp() in the code |
| 15:38.12 |
starseeker |
brlcad: the
idea was to check the editor variable to spot cases which might be
a problem, and if it WAS a problem case then force-feed it
something known to be safe |
| 15:38.58 |
starseeker |
so it blew up
due to the bu_which finding nothing to compare editor
TO |
| 15:39.17 |
brlcad |
right |
| 15:39.36 |
brlcad |
so then my
fix should, in theory, work and fall through correctly |
| 15:39.38 |
starseeker |
so your fix
is actually correct |
| 15:39.41 |
starseeker |
yes
:-) |
| 15:39.59 |
starseeker |
shudders in memory - that was a long night sorting all that
logic out |
| 15:41.08 |
brlcad |
those first
two lines inside the if (count > 0) block still don't make sense
though |
| 15:41.39 |
brlcad |
because
editor = bu_which(EMACS_EDITOR) will have unlikely changed between
the first and second lines.. :) |
| 15:41.47 |
starseeker |
right
:-) |
| 15:42.20 |
starseeker |
I think that
was brain-overload coding - it functioned, so go with
it |
| 15:42.28 |
starseeker |
removes the stray strcmp |
| 15:42.49 |
brlcad |
did you
actually see "editor[0] == '\0'" ? |
| 15:43.02 |
starseeker |
uh - don't
recall |
| 15:43.04 |
brlcad |
bu_which()
certainly shouldn't be returning that -- could even test for
that |
| 15:43.11 |
brlcad |
(in
bu_which()) |
| 15:43.25 |
starseeker |
probably not
- I think it was more stupidity on my part |
| 15:46.16 |
CIA-43 |
BRL-CAD:
03brlcad * r42143 10/brlcad/trunk/src/libbu/ (whereis.c which.c):
add code to make sure, even though it's a very unlikely event, that
we never return an empty string. |
| 15:46.18 |
CIA-43 |
BRL-CAD:
03starseeker * r42144 10/brlcad/trunk/src/mged/tedit.c: |
| 15:46.18 |
CIA-43 |
BRL-CAD: We
can trust bu_wish not to return \0, so we don't need that check
there. May |
| 15:46.24 |
CIA-43 |
BRL-CAD: not
need it anywhere, but we are getting returns from other functions
early on |
| 15:46.24 |
CIA-43 |
BRL-CAD: so
would need more careful checking. Also remove the useless strcmp
for editor |
| 15:46.24 |
CIA-43 |
BRL-CAD: just
after setting it to emacs. |
| 15:47.05 |
starseeker |
brlcad: uh,
it's close to a certainty that my brain said "check for an empty
char array here" and did something colossally stupid - I doubt
bu_which is at fault |
| 15:48.10 |
brlcad |
starseeker:
it's still a reasonable "guarantee" that bu_which() should be able
to say, NULL if not found, non-NULL non-empty if found |
| 15:48.17 |
starseeker |
has been doing too much build logic...
s/bu_wish/bu_which |
| 15:48.35 |
starseeker |
cool |
| 15:52.34 |
starseeker |
does head in this time... |
| 15:52.49 |
d_rossberg |
i like the
NULL as a return value because i haven't to provide memory for
it |
| 15:57.04 |
CIA-43 |
BRL-CAD:
03brlcad * r42145 10/brlcad/trunk/src/conv/iges/iges.c: make sure
initd before use, compiler doesn't see the bu_bomb(). |
| 15:58.29 |
CIA-43 |
BRL-CAD:
03brlcad * r42146 10/brlcad/trunk/src/conv/ (euclid/g-euclid.c
iges/g-iges.c): restructure exception handling into try/catch
form |
| 16:07.55 |
CIA-43 |
BRL-CAD:
03d_rossberg * r42147 10/brlcad/trunk/ (include/bu.h
src/libbu/str.c): |
| 16:07.56 |
CIA-43 |
BRL-CAD:
introduced bu_strcmp() with a more graceful string comparison as
strcmp() does |
| 16:07.56 |
CIA-43 |
BRL-CAD: ""
and NULL are considered as equal |
| 16:08.08 |
d_rossberg |
i've always
wanted to do that |
| 16:25.11 |
CIA-43 |
BRL-CAD:
03d_rossberg * r42148 10/brlcad/trunk/include/bu.h: |
| 16:25.12 |
CIA-43 |
BRL-CAD: the
BU_STR_EMPTY() macro tests a string for emptiness ("" or
NULL) |
| 16:25.13 |
CIA-43 |
BRL-CAD: its
result is either true or false |
| 16:43.19 |
CIA-43 |
BRL-CAD:
03brlcad * r42149 10/brlcad/trunk/src/conv/iges/ (91 files):
cleanup of the old and new iges codes. ws, consistency, de-k&r,
indent, authorship, etc. |
| 16:47.55 |
brlcad |
starseeker: I
take it back, the old iges code is so much more extensive than the
new that it'd be just ridiculous to dump it for the new
one |
| 16:48.25 |
brlcad |
the new one
does have some nice stucture to it, but it's so devoid of
implementation that it seems better just because there is so little
complexity (or value) involved |
| 16:56.52 |
CIA-43 |
BRL-CAD:
03brlcad * r42150 10/brlcad/trunk/include/bu.h: (log message
trimmed) |
| 16:56.53 |
CIA-43 |
BRL-CAD:
follow suit and provide another BU_STR_EQUAL() macro for comparing
two strings |
| 16:56.53 |
CIA-43 |
BRL-CAD: for
equality. this is similar to the STREQ recommendation by the
ibm |
| 16:56.54 |
CIA-43 |
BRL-CAD:
developerworks best practices article |
| 16:56.54 |
CIA-43 |
BRL-CAD:
(http://www.ibm.com/developerworks/aix/library/au-hook_duttaC.html)
so that |
| 16:56.55 |
CIA-43 |
BRL-CAD:
developers can use equality as a truthfulness return value
consistently. there |
| 16:57.09 |
CIA-43 |
BRL-CAD: are
approximately 1400 present uses of strcmp() in BRL-CAD that can use
this |
| 17:32.49 |
starseeker |
brlcad: so...
gradually refactor the old code to use better structure and convert
to the new nurbs? |
| 17:33.10 |
starseeker |
or I suppose
do so as part of merging it into libgcv |
| 17:40.22 |
CIA-43 |
BRL-CAD:
03starseeker * r42151 10/brlcad/branches/cmake/ (102 files in 9
dirs): Update cmake branch to trunk r41250 |
| 17:45.29 |
brlcad |
starseeker:
there is always possibility for better structure, particularly the
bigger, older, and more complex code becomes ... so that's a
given |
| 17:46.01 |
brlcad |
but yeah,
merge in capability for new nurbs would probably be better -- it'll
just be more costly up front to learn the existing code |
| 17:48.03 |
brlcad |
unrelated
topic, the compiler is reporting that it cannot inline the
opennurbs_ext BBNode bounding box routine (GetBBox()), so there is
possibly some significant performance to be gained by fixing
that |
| 18:06.55 |
CIA-43 |
BRL-CAD:
03starseeker * r42152
10/brlcad/branches/cmake/src/conv/iges/revolve.c: PI is coming up
as undefined on OSX - use M_PI |
| 18:10.58 |
CIA-43 |
BRL-CAD:
03brlcad * r42153 10/brlcad/trunk/src/librt/opennurbs_ext.h: force
inlining on the bounding box routines since gcc (4.0.1) complains
that it cannot without increasing an inline limit. remove inline
from destructors (gcc is similiarly complaining that it
cannot). |
| 18:11.50 |
CIA-43 |
BRL-CAD:
03brlcad * r42154 10/brlcad/trunk/src/librt/ (bool.c comb/comb.c):
sign matching |
| 18:32.42 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r42155 10/brlcad/trunk/src/libbn/ (bntester.c
poly.c tabdata.c): fix various warnings |
| 18:35.08 |
CIA-43 |
BRL-CAD:
03starseeker * r42156 10/brlcad/branches/cmake/src/other/tcl/ (4
files in 4 dirs): Start the process of taking things out of -D
defines and putting them in config headers. |
| 18:48.27 |
CIA-43 |
BRL-CAD:
03starseeker * r42157 10/brlcad/branches/cmake/src/other/ (5 files
in 5 dirs): |
| 18:48.27 |
CIA-43 |
BRL-CAD: more
-D elimination - a lot of these defines probably aren't even needed
in |
| 18:48.28 |
CIA-43 |
BRL-CAD:
CMake builds, as they don't seem to be used by the C code and CMake
is handling |
| 18:48.29 |
CIA-43 |
BRL-CAD: the
generation of whatever config files are needed itself... for the
ones that |
| 18:48.33 |
CIA-43 |
BRL-CAD: are,
the only code change is to include the generated header. Definitely
more |
| 18:48.33 |
CIA-43 |
BRL-CAD:
cleanup to do on these to reduce the build logic to the functioning
minimum. |
| 18:53.19 |
CIA-43 |
BRL-CAD:
03starseeker * r42158 10/brlcad/branches/cmake/CMakeLists.txt:
Let's try a space on Windows again and see if those defines fixed
it... |
| 18:59.41 |
CIA-43 |
BRL-CAD:
03brlcad * r42159 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c:
size_t |
| 19:00.09 |
CIA-43 |
BRL-CAD:
03brlcad * r42160
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: VMOVE before we
print the value. |
| 19:01.24 |
CIA-43 |
BRL-CAD:
03brlcad * r42161
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: init max_pt
too, quell warning |
| 19:06.31 |
CIA-43 |
BRL-CAD:
03brlcad * r42162 10/brlcad/trunk/ (8 files in 2 dirs): make a slew
of other object count struct data members be size_t instead of long
and int so that can be properly unsigned and higher bound. match
signedness in librt accordingly. |
| 19:14.49 |
CIA-43 |
BRL-CAD:
03brlcad * r42163 10/brlcad/trunk/src/ (9 files in 2 dirs): another
BU_PTBL_LEN caller, size_t it up. |
| 19:17.10 |
CIA-43 |
BRL-CAD:
03brlcad * r42164 10/brlcad/trunk/include/bu.h: just call
bu_strcmpm() directly instead of macro. didn't get the preproc
syntax right anyways. |
| 19:26.35 |
brlcad |
is excited that we're SO CLOSE to a strict clean
build! |
| 19:29.16 |
brlcad |
improved
security, maintainability, conformance/verification/validation, ..
yum |
| 19:34.56 |
brlcad |
envisions a day where the source code is completely 100%
lintian free with best practices enforced across the entire 1M+
body of code |
| 19:37.36 |
CIA-43 |
BRL-CAD:
03brlcad * r42165 10/brlcad/trunk/src/conv/iges/revolve.c: didn't
starseeker already fix this? M_PI is the new coke. |
| 19:39.50 |
CIA-43 |
BRL-CAD:
03brlcad * r42166 10/brlcad/trunk/src/conv/iges/iges.c:
multicharacter string constants are not valid to cpp, so move the
literal to a define in order to catch future
auto-expansions |
| 20:23.25 |
*** join/#brlcad ibot
(~ibot@198.60.114.207) |
| 20:23.25 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source
Anniversary 2010-12-21 !!! Six years... |
| 20:28.16 |
CIA-43 |
BRL-CAD:
03brlcad * r42170 10/brlcad/trunk/src/fb/pp-fb.c: init to zero
pixels |
| 20:28.17 |
CIA-43 |
BRL-CAD:
03starseeker * r42169 10/brlcad/branches/cmake/CMakeLists.txt:
Interesting - the -c option causes the time delta compile to
fail. |
| 20:30.20 |
CIA-43 |
BRL-CAD:
03brlcad * r42173 10/brlcad/trunk/src/util/ (pc_test.c pixborder.c
pixcount.c pixdsplit.c): more unset before use
insanity. |
| 20:30.49 |
CIA-43 |
BRL-CAD:
03brlcad * r42174 10/brlcad/trunk/bench/pixcmp.c: test of
conversion to BU_STR_EQUAL() instead of directly calling
strcmp(). |
| 20:31.23 |
DaveLo |
getting an
error in arbn.c: |
| 20:31.37 |
DaveLo |
primitives/arbn/arbn.c: In function
?rt_arbn_describe?: |
| 20:31.37 |
DaveLo |
primitives/arbn/arbn.c:1026: error: format
?%lu? expects type ?long unsigned int?, but argument 3 has type
?size_t? |
| 20:31.40 |
DaveLo |
primitives/arbn/arbn.c:1037: error: format
?%lu? expects type ?long unsigned int?, but argument 3 has type
?size_t? |
| 20:32.32 |
``Erik |
lots of
those |
| 20:32.33 |
``Erik |
lots and
lot |
| 20:32.34 |
``Erik |
s |
| 20:33.48 |
``Erik |
thinks he's about to get very involved with GS
O>o |
| 20:33.54 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r42175 10/brlcad/trunk/src/adrt/ (27 files in 3
dirs): warning quellage. formatting fixes. |
| 20:34.19 |
DaveLo |
what makes
you say that? |
| 20:35.07 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 20:35.07 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source
Anniversary 2010-12-21 !!! Six years... |
| 20:35.10 |
``Erik |
(k keeps
building after failure) |
| 20:35.23 |
``Erik |
or didja mean
GS? |
| 20:35.58 |
DaveLo |
huh? |
| 20:36.21 |
starseeker |
what made him
say what? |
| 20:36.33 |
DaveLo |
whos a
what? |
| 20:36.40 |
``Erik |
forshizzle? |
| 20:36.48 |
DaveLo |
forrizzle! |
| 20:40.58 |
DaveLo |
FYI: I was
updating the repos on my Ubuntutututu box and ran into some size_t
compile errors in brlcad |
| 20:41.27 |
DaveLo |
figured I'd
mention it since brlcad is in the mist of some massive size_t
work |
| 21:13.20 |
CIA-43 |
BRL-CAD:
03starseeker * r42176
10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: Remove old
files before making new ones... |
| 21:37.00 |
CIA-43 |
BRL-CAD:
03starseeker * r42177 10/brlcad/branches/cmake/src/other/ (6 files
in 6 dirs): Remove all the -c flags from the Tcl/Tk
builds |
| 21:40.31 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 21:56.14 |
brlcad |
DaveLo: I've
got a clean build on mac and linux, but size_t is going to be
pretty sensitive to platform differences so some failures
undoubtedly need weeding out |
| 21:56.29 |
brlcad |
should be
trivial fixes, at least |
| 21:57.00 |
brlcad |
DaveLo: and
--enable-warnings is now the default (as of yesterday) |
| 22:08.21 |
CIA-43 |
BRL-CAD:
03starseeker * r42178 10/brlcad/branches/cmake/CMakeLists.txt: For
whatever reason, CMAKE_C_FLAGS is upsetting VC++ 2010 - comment it
out |
| 22:15.44 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r42179 10/brlcad/trunk/src/libfb/if_ogl.c:
signed/unsigned comparison fixes |
| 22:41.39 |
``Erik |
brlcad: if'n
ya get bored, http://brlcad.org/~erik/r42179/
:D *heads home* |
| 22:49.49 |
brlcad |
heh |
| 22:49.52 |
CIA-43 |
BRL-CAD:
03brlcad * r42180 10/brlcad/trunk/src/libbu/CMakeLists.txt: sync
timetester to cmake build for distcheck |
| 22:50.41 |
starseeker |
growls... CMake build doesn't run as of
42152 |
| 22:50.55 |
starseeker |
seems to run
at 42150, confirming that |
| 22:51.15 |
starseeker |
what could
possibly have changed... |
| 22:52.47 |
brlcad |
i've done so
much fast typing for over a week now that my rsi is starting to act
up |
| 22:53.08 |
starseeker |
winces - that's not good |
| 22:54.40 |
brlcad |
not too bad
just yet, just having to take more breaks |
| 22:55.04 |
brlcad |
editing
thousands of files will do that |
| 22:56.01 |
brlcad |
starseeker:
i'd be cautious on any failure -- those size_t changes could easily
have (and undoubtedly have in some places) caused a bug to get
injected somewhere/anywhere |
| 22:56.19 |
brlcad |
along with
the changes before I got on the size_t rampage even |
| 22:56.49 |
starseeker |
nods - I'm trying to isolate when it
happend |
| 22:57.23 |
starseeker |
will cheerfully revert the source of cmake branch to a known
good state and work on that, if he can find such a
state |
| 23:02.53 |
starseeker |
OK, NOT
working at 42150 |
| 23:09.52 |
starseeker |
42139
working |
| 23:09.58 |
starseeker |
did that
archer change mess things up somehow??? |
| 23:25.10 |
CIA-43 |
BRL-CAD:
03starseeker * r42181
10/brlcad/branches/cmake/src/archer/CMakeLists.txt: Hmm - this
makes mged REALLY unhappy, so don't do it... |
| 23:26.46 |
CIA-43 |
BRL-CAD:
03brlcad * r42182 10/brlcad/trunk/src/mged/hideline.c: protect from
peculiar setjmp() use in here by making the variables set before
and accessed afterwards as static. candidate for
removal. |
| 23:29.17 |
CIA-43 |
BRL-CAD:
03brlcad * r42183 10/brlcad/trunk/src/mged/dodraw.c: |
| 23:29.17 |
CIA-43 |
BRL-CAD: one
of the more complicated ways to handle BU_SETJUMPing so that
variables set |
| 23:29.18 |
CIA-43 |
BRL-CAD:
before the jump and accessed afterwards do not have their values
clobbered when |
| 23:29.18 |
CIA-43 |
BRL-CAD: a
jump occurs. solution is to pull just exactly the try/catch code
out into |
| 23:29.19 |
CIA-43 |
BRL-CAD:
their own functions so there are no variables in that frame that
might be |
| 23:29.19 |
CIA-43 |
BRL-CAD:
clobbered in the first place. this is done twice here. |
| 23:29.52 |
CIA-43 |
BRL-CAD:
03brlcad * r42184 10/brlcad/trunk/src/mged/cmd.c: size_t upconvert
argc |
| 23:30.17 |
starseeker |
O.o - that's
some scary sounding logic - why are we need jumps like that,
speed? |
| 23:30.51 |
starseeker |
breaths a sigh of relief - MGED runs again |
| 23:39.13 |
CIA-43 |
BRL-CAD:
03brlcad * r42185 10/brlcad/trunk/src/mged/rtif.c: wrong comment to
the wrong file. protect from peculiar setjmp() use in here by
making the variables set before and accessed afterwards as static.
candidate for removal. |
| 23:39.56 |
CIA-43 |
BRL-CAD:
03brlcad * r42186 10/brlcad/trunk/src/mged/mged.c: make sure we
have an out if we don't have an out. |
| 23:40.51 |
CIA-43 |
BRL-CAD:
03brlcad * r42187 10/brlcad/trunk/src/mged/ (cad_parea.c chgview.c
clone.c): init vars before they're used, especially when they're
only set within conditionals. |
| 23:42.19 |
starseeker |
heh 42186
sounds like Yogi Berra |
| 23:46.32 |
CIA-43 |
BRL-CAD:
03brlcad * r42188 10/brlcad/trunk/src/mged/cad_boundp.c: one more
needing to be initialized |
| 23:47.46 |
brlcad |
starseeker:
jumps are the old school way to perform exception
handling |
| 23:48.11 |
brlcad |
c++'s
exception handling was originally implemented using setjmp/longjmp
and macros |
| 23:48.37 |
brlcad |
you just have
to know what you're doing and what happens when a jump
occurs |
| 23:49.02 |
brlcad |
some of our
code was making assumptions which work in practice, but aren't
guaranteed |
| 23:49.20 |
starseeker |
ah |
| 23:49.50 |
brlcad |
basically, IF
a jump happens, variables are reset back to their state when the
jumppoint was *set* .. so if you modify them after the set and then
jump, their values are clobbered |
| 23:50.17 |
brlcad |
most of the
time, that's perfectly fine |
| 23:51.03 |
brlcad |
and whether
it's fine or not, doing the "wrap the try/catch" in a function
trick makes the problem pretty much moot because there are no
longer any stack variables getting clobbered |
| 23:51.52 |
starseeker |
nods |
| 23:53.17 |
brlcad |
I want to
rewrite our macros so we're not setting and unsetting jumps,
instead providing BU_TRY/BU_CATCH macros |
| 23:53.39 |
starseeker |
how many
places in the code will that touch? |
| 23:56.28 |
starseeker |
worries about brlcad's wrists |
| 23:56.47 |
brlcad |
I don't
remember how many places, not too many |
| 23:56.54 |
starseeker |
cool |
| 23:56.58 |
brlcad |
unfortunately
not really scriptable though :) |
| 23:57.03 |
starseeker |
heh |
| 23:57.13 |
brlcad |
just scan on
BU_SETJUMP though and you'll find them all |
| 23:58.32 |
starseeker |
popular in
the convertors |
| 23:58.52 |
brlcad |
yep, nmg
stuff throws exceptions as part of normal business |
| 23:59.43 |
brlcad |
BU_SETJUMP is
the way to catch a bu_bomb() so it doesn't actually
exit |
| 00:05.30 |
CIA-43 |
BRL-CAD:
03starseeker * r42189 10/brlcad/branches/cmake/src/tclscripts/ (18
files in 18 dirs): |
| 00:05.30 |
CIA-43 |
BRL-CAD:
Alright, I'm tired of fighting with trying to get the custom
tclscripts to run |
| 00:05.31 |
CIA-43 |
BRL-CAD:
cleanly in parallel when they're doing copy commands after the
btclsh script |
| 00:05.31 |
CIA-43 |
BRL-CAD:
runs. Put copies of the tcl files in the build dir and run the
scripts there. |
| 00:05.32 |
CIA-43 |
BRL-CAD:
Simplifies the logic and avoids the hackery of copying things
around as part of |
| 00:05.32 |
CIA-43 |
BRL-CAD: the
custom command. |
| 00:06.20 |
starseeker |
mmm...
bu_brlcad_data clearly isn't up to what I'm trying with
archer... |
| 00:12.03 |
brlcad |
how
so? |
| 00:12.15 |
brlcad |
it has a
pretty well-defined usage contract |
| 00:12.53 |
starseeker |
it may just
be I don't have the right things in place in the build
dir |
| 00:13.29 |
brlcad |
if which in
reality should end up in just one or two file/dir stats if
everything is set up right, the rest of the logic being just for
failure backup |
| 00:13.30 |
starseeker |
rror in
startup script: couldn't read file
"/usr/brlcad/share/tclscripts/itk_redefines.tcl": no such file or
directory while executing |
| 00:13.33 |
starseeker |
"source [file
join [bu_brlcad_data "tclscripts"] itk_redefines.tcl]" (file
"./bin/archer" line 62) |
| 00:14.05 |
starseeker |
prefix isn't
/usr/brlcad for this build either, but once I do a make install it
finds things OK |
| 00:14.15 |
brlcad |
it shouldn't
need to be /usr/brlcad |
| 00:14.21 |
starseeker |
right |
| 00:14.35 |
brlcad |
bu.h has the
search priority ordering |
| 00:14.46 |
starseeker |
checks... |
| 00:15.01 |
brlcad |
first step is
to make sure itk_redefines.tcl is actually in
/usr/brlcad/share/brlcad/version/tclscripts/itk_redefines.tcl (or
whatever your data root is) |
| 00:15.32 |
brlcad |
then can make
sure bu_brlcad_data "." is reporting the data root just by running
bwish |
| 00:15.48 |
brlcad |
then
bu_brlcad_data "tclscripts" to make sure it's there,
etc |
| 00:17.05 |
brlcad |
that looks
right to me, the archer logic might be wrong |
| 00:17.59 |
starseeker |
weird... from
the build directory it's returning /usr/brlcad/share/. but once
installed it's /Users/user/brlcad-install-svn/share/. |
| 00:18.17 |
starseeker |
will look into it later, not a huge deal |
| 00:18.26 |
starseeker |
dunno if
archer is even set up to run from the build dir at all |
| 00:18.59 |
brlcad |
if it cannot
find it pre-install, it will fall back on /usr/brlcad where it's
undoubtedly finding an old root |
| 00:19.13 |
starseeker |
ah |
| 00:19.17 |
brlcad |
http://pastebin.mozilla.org/930556 |
| 00:19.48 |
starseeker |
nods |
| 00:20.31 |
brlcad |
yeah, I'm not
seeing that file anywhere |
| 00:20.47 |
starseeker |
yep - if I
make a share directory, it finds it. That's also why that archer
CMakeLists.txt change played such havoc with mged - it found a data
dir with nothing in it |
| 00:21.17 |
starseeker |
brlcad: that
file is specific to the CMake branch so far - it's what allows
archer to run with vanilla Itcl/Itk |
| 00:21.31 |
brlcad |
ahh,
okay |
| 00:22.10 |
starseeker |
it looks like
if I want to do this right I'll have to fully populate the share
dir in the build dir |
| 00:22.11 |
brlcad |
if you're
working on pre-install build states and with partial empty install
trees, you probably should familiarize with the search path rules
it uses |
| 00:22.30 |
starseeker |
nods |
| 00:22.59 |
starseeker |
I don't
recall ever trying - does archer run from the build dir in
trunk? |
| 00:23.12 |
starseeker |
maybe I
should worry about this later |
| 00:23.26 |
brlcad |
it has for
me |
| 00:23.38 |
starseeker |
crud |
| 00:23.40 |
brlcad |
haven't
tested latestly |
| 00:29.00 |
CIA-43 |
BRL-CAD:
03starseeker * r42190 10/brlcad/branches/cmake/TODO.cmake: Update
TODO.cmake |
| 00:32.29 |
brlcad |
hm, looks
like trunk has problems running uninstalled, but it's due to ...
Tkhtml3 :) |
| 00:32.46 |
starseeker |
growl |
| 00:33.17 |
starseeker |
wonders what possessed him to ever fool with
tkhtml... |
| 00:33.39 |
brlcad |
ah, looks
like tktable too |
| 00:34.22 |
brlcad |
you can't
just add dependencies and everything gets found -- you have to tell
the code that looks for things where to look for the new things
when they're added |
| 00:35.01 |
starseeker |
wants the computer to be smart, doggone it |
| 00:36.01 |
brlcad |
royal you,
not you specifically :) |
| 00:36.11 |
brlcad |
not that you
aren't royal |
| 00:36.12 |
starseeker |
ah
:-) |
| 00:36.28 |
starseeker |
<- royal pain |
| 00:37.32 |
starseeker |
I'll dig into
this, but it looks like studying usage of bu_brlcad_data will be
the key - thanks! |
| 00:39.57 |
brlcad |
don't be shy
to fix archer |
| 00:40.46 |
starseeker |
brlcad: I'm
more concerned about the notion of a build-dir share directory and
how it fits (or doesn't fit) with how bu_brlcad_root and
bu_brlcad_data are working |
| 00:41.05 |
brlcad |
bu_brlcad_data/bu_brlcad_root *should* be
suitable for any use .. there are lots of places in archer that
probably don't use it yet or call it correctly |
| 00:42.12 |
brlcad |
there is no
such notion to bu_brlcad_root/bu_brlcad_data other than to check
the current directory |
| 00:42.20 |
starseeker |
the thing is,
I'm going to want bu_brlcad_root to return the build directory root
if I'm not running installed, but the installed root directory if I
am |
| 00:42.28 |
brlcad |
the package
require system is completely separate foo |
| 00:42.42 |
starseeker |
package
require I'm getting a handle on |
| 00:43.34 |
starseeker |
I can already
package require Tkhtml/tkpng/etc from ./bin/bwish |
| 00:44.16 |
brlcad |
an easy
solution is to make the resources locatable w.r.t.
archer |
| 00:44.41 |
starseeker |
nods |
| 00:45.15 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
| 00:45.16 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 00:45.19 |
starseeker |
that
itk_redefines.tcl file should probably fold straight into archer
itself |
| 00:45.21 |
brlcad |
so if
something does rely on bu_brlcad_data, calling bu_brlcad_data
"tclscripts/archer" is going to find src/archer/tclscripts/archer
or something similar |
| 00:45.57 |
starseeker |
um |
| 00:46.12 |
brlcad |
you build
instal an uninstalled install root? |
| 00:46.51 |
starseeker |
basically -
the build dir is a pseudo-install tree |
| 00:47.07 |
brlcad |
but are they
only binaries or also data files? |
| 00:47.18 |
brlcad |
like
tclscripts |
| 00:47.28 |
starseeker |
so far
binaries, libraries and whatever tcl/tk stuff I've needed to get
package require working |
| 00:47.48 |
starseeker |
I haven't
rebuilt the tclscripts install dir yet, but even if I did I'm not
sure it would work |
| 00:47.51 |
brlcad |
well that'd
be most of our tclscripts dir too then |
| 00:48.41 |
brlcad |
our
tclscripts dir has a slew of packages defined in there, package
require Archer for example, package require GeometryBrowser,
etc |
| 00:49.18 |
starseeker |
right - it
was trying to get those working that I ran into the problem with a
share dir in the toplevel build dir blowing up mged |
| 00:49.59 |
starseeker |
tclAutoPath
has a bunch of paths for the tclscript dirs - I figured I could
leverage that |
| 00:50.35 |
brlcad |
yeah, that's
the separate system |
| 00:51.02 |
brlcad |
what about
just making the build tree be an *exact* replica of the install
tree? |
| 00:51.04 |
starseeker |
even copying
the complete installed share dir from the install back into the
build dir didn't make mged happy, which worries me |
| 00:51.24 |
brlcad |
so installing
is literally the same as cp -R buildTree /usr/brlcad |
| 00:51.35 |
starseeker |
brlcad: that
gets back to the bu_brlcad_root - in that instance, it would have
to use the toplevel build dir as its root dir |
| 00:51.48 |
starseeker |
and it's not
set up to do that right now, unless I'm missing
something |
| 00:52.02 |
starseeker |
I could make
it do that, but I figured I'd get in trouble :-P |
| 00:52.32 |
brlcad |
no, that'd
definitely work if it's a full root |
| 00:52.49 |
brlcad |
the third
rule for bu_brlcad_root |
| 00:53.11 |
starseeker |
tries again... |
| 00:53.26 |
brlcad |
it searches
an env override if set first, then the compile-time install path if
it exists, then the current RUN TIME path if it doesn't .. that'd
match |
| 00:54.01 |
starseeker |
ah - what if
the compile-time install path exists but is empty? |
| 00:54.08 |
brlcad |
then that's a
problem |
| 00:54.16 |
brlcad |
it looks for
directories |
| 00:54.34 |
brlcad |
the code
calling bu_brlcad_root/data is then supposed to verify
files |
| 00:55.17 |
starseeker |
I always use
brlcad-install-svn for my target, so that directory already
exists |
| 00:55.33 |
brlcad |
delete the
dir? |
| 00:55.54 |
brlcad |
install
should create it |
| 00:55.56 |
starseeker |
I can, but
shouldn't it be robust enough to recognize that there is nothing in
there and try the next possibility? |
| 00:56.16 |
brlcad |
it has no
idea what you're looking for |
| 00:56.22 |
brlcad |
e.g.,
bu_brlcad_root . |
| 00:56.44 |
brlcad |
how do you
know if it found root or not, other than it exists? |
| 00:56.55 |
brlcad |
at least
maintainably without some random assumption |
| 00:56.59 |
starseeker |
sure, but a
totally empty root may as well not exist |
| 00:57.28 |
brlcad |
right, so
ideally, code calling bu_brlcad_root should be more specific than
"." |
| 00:57.35 |
brlcad |
and most
places are |
| 00:57.45 |
brlcad |
bu_brlcad_data tclscripts, for
example |
| 00:58.11 |
starseeker |
ok, but if it
doesn't find tclscripts in the first possiblity will it move on to
the second? |
| 00:58.18 |
brlcad |
yep |
| 00:58.33 |
brlcad |
bu_brlcad_root (subdir) |
| 00:58.57 |
brlcad |
it searches
for (subdir) in those search-order paths returning the first
found |
| 00:59.28 |
starseeker |
then how can
an empty share dir in the toplevel build make mged crash, and
removing it allows it to run? |
| 01:00.24 |
brlcad |
it wouldn't
make sense to assume if ROOT/some/subdir is empty, then skip it
(e.g., ROOT/.) .. because it just as easily could be a read/write
location we're using, (e.g., ROOT/caches/rt) |
| 01:00.58 |
brlcad |
you've got
the crash, debug it! :) |
| 01:01.05 |
brlcad |
shouldn't
crash regardless |
| 01:01.13 |
brlcad |
that should
be easy to stack trace fix |
| 01:02.06 |
starseeker |
package
require Itcl is failing |
| 01:02.58 |
*** join/#brlcad crazy_imp
(~mj@a89-182-24-66.net-htp.de) |
| 01:03.33 |
starseeker |
uh... why?
bwish and btclsh do fine... |
| 01:04.19 |
brlcad |
cutting a
narrow path through the forest just wide enough to slip through
isn't going to be safe route for travel |
| 01:05.56 |
starseeker |
hmm? Right
now I've got no path |
| 01:06.59 |
starseeker |
also has to get home |
| 01:09.55 |
brlcad |
right, but
the goal isn't just getting any path and then later widening it
too |
| 01:10.08 |
brlcad |
that's the
super-expensive way |
| 01:10.31 |
starseeker |
brlcad: oh,
I'm going to try and figure out what's going on and what the right
way is to handle it |
| 01:11.25 |
starseeker |
but this
seems to be right in that ugly underbelly of interaction between
data path searching, tcl/tk weirdness, and application
initialization from a build directory - that's pretty much a poster
child for "tangled web" |
| 01:11.32 |
brlcad |
I know, just
noting that you found a crash but aren't actually working on fixing
the crash :) |
| 01:12.07 |
starseeker |
<snort>
I will tomorrow - I've got a 6:30am gym session, and if I'm up late
tonight I might never make it in at all tomorrow :-P |
| 01:12.21 |
brlcad |
because even
if the right way masks the problem for now, it's almost guaranteed
to bite someone down the road |
| 01:12.28 |
brlcad |
and the older
a bug gets, the harder they bit |
| 01:12.39 |
brlcad |
even ones you
rediscover later |
| 01:13.12 |
brlcad |
mm.. gym is
the perfect excuse, stay healty ;) |
| 01:13.31 |
starseeker |
well, it
remains to be seen if this is truely a bug, since I'm in a very
different setup than the autotools build and I could quite easily
being doing Something Wrong with the build logic |
| 01:13.46 |
starseeker |
I doubt this
behavior has ever been observed with autotools |
| 01:13.53 |
brlcad |
I seem to be
having a lot of one-byte erors tonight :) |
| 01:14.15 |
starseeker |
ouch |
| 01:14.25 |
brlcad |
"something
wrong" that makes mged crash is still mged's fault |
| 01:14.29 |
brlcad |
and
preventable |
| 01:15.02 |
brlcad |
that just
means mged/archer/whatever was assuming something -- there should
be no assumptions, you test everything |
| 01:15.08 |
starseeker |
this is an
altered mged though - remember how I switched it from using Itcl's
C interface to using package require? |
| 01:15.29 |
starseeker |
so it's
almost certainly my fault |
| 01:15.54 |
brlcad |
the code is
still at fault for crashing -- you can catch the problem state in
code before crashes occur |
| 01:16.17 |
starseeker |
nods |
| 01:16.37 |
brlcad |
you may have
made it more brittle or just differently brittle, but the code is
still at fault for crashing |
| 01:17.03 |
starseeker |
was hoping that using package require instead of the C api
would make the migration to 8.6 easier, when it
comes |
| 01:17.12 |
brlcad |
even if you
feed it /dev/random, or bang on they keyboard and randomly move
files around while they're being read, it shouldn't
crash |
| 01:17.31 |
starseeker |
nods |
| 01:18.01 |
brlcad |
package
require should be better |
| 01:18.06 |
brlcad |
just means
you're not done :) |
| 01:18.22 |
brlcad |
though time
really is running out, GS is REALLY going to be hurting |
| 01:18.42 |
starseeker |
this can be
put on hold |
| 01:18.48 |
brlcad |
says to pot
to the kettle as I make some more size_t fixes |
| 01:19.07 |
brlcad |
s/to pot/the
pot/ |
| 01:19.28 |
starseeker |
last time I
talked to DaveLo, it sounded like the code wasn't in any shape to
be talking to any test harness... |
| 01:19.57 |
starseeker |
still, I
guess if that's the case step one will be to rewrite it until it
is... |
| 01:20.03 |
brlcad |
your test
harness should show that, it's fully independent effort |
| 01:20.19 |
brlcad |
and once you
get to the point where you see where it's not, you can help with
exactly that next step |
| 01:21.15 |
brlcad |
coupled
development is a major no-no for any project of value |
| 01:23.24 |
brlcad |
starseeker: I
see why archer is failing to load (at least current set of
problems) |
| 01:23.37 |
brlcad |
it is just
blindly setting the data root and trying to load |
| 01:24.04 |
brlcad |
the previous
code checked if it was running in a source configuration with a
neat bu_brlcad_data "src" trick :) |
| 01:24.16 |
brlcad |
see
src/archer/plugins/Wizards/humanwizard.tcl for an
example |
| 01:25.01 |
brlcad |
basically
it's falling back onto the last rule that bu_brlcad_data uses,
looking for paths relative to the current directory |
| 01:25.49 |
starseeker |
that doesn't
get hijacked by the presence of /usr/brlcad? |
| 01:26.36 |
brlcad |
sorry, second
to last rule ;) |
| 01:26.45 |
brlcad |
/usr/brlcad
is checked even if it's not the build dir |
| 01:26.50 |
brlcad |
er install
dir |
| 01:28.30 |
starseeker |
yeah - isn't
that kinda a bad idea? the presence of /usr/brlcad will kill any
possibility of the current directory being used |
| 01:29.43 |
CIA-43 |
BRL-CAD:
03starseeker * r42191 10/brlcad/branches/cmake/TODO.cmake: Few more
notes about current state of CMake - will probably have to leave
this for a while. |
| 01:29.48 |
starseeker |
ok, I really
do have to go |
| 01:33.36 |
brlcad |
starseeker:
no, it'll check current dir before it |
| 01:33.44 |
brlcad |
see the
search order rules in bu.h |
| 01:42.51 |
CIA-43 |
BRL-CAD:
03brlcad * r42192 10/brlcad/trunk/src/archer/archer: try a little
harder to find data resources so archer can run
uninstalled |
| 01:43.27 |
CIA-43 |
BRL-CAD:
03brlcad * r42193
10/brlcad/trunk/src/tclscripts/archer/LoadArcherLibs.tcl: if
hv3/tkhtml won't load, it's not the end of the world. |
| 01:45.28 |
brlcad |
aha, that is
the problem, looking for "." is not what you'd expect for a
multi-root install since it'll find the /usr/brlcad hail mary
case |
| 01:54.48 |
CIA-43 |
BRL-CAD:
03brlcad * r42194 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl:
search harder here too for aboutArcher.png and
mike-tux.png |
| 01:55.02 |
CIA-43 |
BRL-CAD:
03brlcad * r42195
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: look for src
dir too |
| 01:59.59 |
CIA-43 |
BRL-CAD:
03brlcad * r42196 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl:
hopefully not lost in the indentation cleanup, make bu_brlcad_data
only check for one subdir, then use [file join] on the
rest |
| 02:21.47 |
brlcad |
heh,
interesting |
| 02:22.05 |
brlcad |
src/tclscripts/nirt/prototype.sh <--
starseeker, you might find that amusing |
| 02:22.25 |
brlcad |
a prototype
interface around nirt by pjt |
| 02:22.30 |
brlcad |
check it out
before updating, because I'm killing it |
| 02:27.21 |
CIA-43 |
BRL-CAD:
03brlcad * r42197 10/brlcad/trunk/src/tclscripts/ (13 files in 3
dirs): |
| 02:27.21 |
CIA-43 |
BRL-CAD:
bu_brlcad_root should ideally only be called with one subdirectory
for |
| 02:27.22 |
CIA-43 |
BRL-CAD:
portability, then use tcl's [file join] on the rest of the path.
this is likely |
| 02:27.22 |
CIA-43 |
BRL-CAD: the
problem that necessitated adding '.exe' extensions to the binaries
for |
| 02:27.23 |
CIA-43 |
BRL-CAD:
windows because the lower-level C code was trying to stat the file.
this should |
| 02:27.23 |
CIA-43 |
BRL-CAD:
simplify things nicely. |
| 02:28.35 |
CIA-43 |
BRL-CAD:
03brlcad * r42198 10/brlcad/trunk/ (configure.ac
src/tclscripts/Makefile.am src/tclscripts/nirt/): |
| 02:28.35 |
CIA-43 |
BRL-CAD:
remove the nirt tclscripts directory. there was just one source
file in there, |
| 02:28.36 |
CIA-43 |
BRL-CAD:
prototype.sh, which was a prototype interface by pjt for nirt. long
since |
| 02:28.36 |
CIA-43 |
BRL-CAD:
overcome by events and not that great a prototype anyways... sorry
paul. :) |
| 02:30.25 |
CIA-43 |
BRL-CAD:
03brlcad * r42199 10/brlcad/trunk/src/tclscripts/rtwizard/lib/
(FbPage.itk PictureTypeE.itcl): unnecessary but
consistent |
| 02:31.14 |
CIA-43 |
BRL-CAD:
03brlcad * r42200
10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeF.itcl:
missed one, wrap in quotes for consistency |
| 02:42.41 |
CIA-43 |
BRL-CAD:
03brlcad * r42201 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): |
| 02:42.42 |
CIA-43 |
BRL-CAD:
remove brlcadDataPath since you really don't want to look for '.'
unless you |
| 02:42.42 |
CIA-43 |
BRL-CAD:
absolutely have to, otherwise you risk getting a non-usable
/usr/brlcad default. |
| 02:42.43 |
CIA-43 |
BRL-CAD:
looking for the subdirectories individually makes them try the
run-time relative |
| 02:42.43 |
CIA-43 |
BRL-CAD: path
first, which means we don't even need to try a separate 'src'
search unless |
| 02:42.44 |
CIA-43 |
BRL-CAD: it's
for items that are in a different place hierarchically in the
source tree |
| 02:42.45 |
CIA-43 |
BRL-CAD: than
they are after install. |
| 03:02.45 |
CIA-43 |
BRL-CAD:
03brlcad * r42202 10/brlcad/trunk/src/tclscripts/lib/Command.tcl:
gracefully handle a failure to create a slave
interpreter |
| 03:13.13 |
CIA-43 |
BRL-CAD:
03brlcad * r42203 10/brlcad/trunk/src/tclscripts/lib/Command.tcl:
catch the other place we create an interpreter too |
| 03:28.22 |
CIA-43 |
BRL-CAD:
03brlcad * r42204
10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: |
| 03:28.23 |
CIA-43 |
BRL-CAD: for
some reason, 'create interp' goes through a different
initialization process |
| 03:28.24 |
CIA-43 |
BRL-CAD:
which causes a failure to find init.tcl if we try to run
uninstalled. it checks |
| 03:28.25 |
CIA-43 |
BRL-CAD:
[tcl::pkgconfig get scriptdir,runtime] but does not respect
$tcl_library. it |
| 03:28.26 |
CIA-43 |
BRL-CAD:
DOES, however, respect env(TCL_LIBRARY) so make sure we set that
too when we're |
| 03:28.27 |
CIA-43 |
BRL-CAD:
initializing unless the user already has it set to
something. |
| 03:36.13 |
CIA-43 |
BRL-CAD:
03brlcad * r42205
10/brlcad/trunk/src/libtclcad/ged_obj.c: |
| 03:36.14 |
CIA-43 |
BRL-CAD:
error message is very obtuse. is the type printed not supported for
a given |
| 03:36.15 |
CIA-43 |
BRL-CAD: use,
or not supported because it wasn't compiled. the latter was meant
but not |
| 03:36.15 |
CIA-43 |
BRL-CAD:
stated. reword for clarity and provide some instruction for when
things go bad. |
| 03:36.18 |
brlcad |
there, that
should bring archer back into a working state |
| 03:36.24 |
brlcad |
uninstalled |
| 03:36.40 |
DX^ |
"Several
BRL-CAD developers are working on implementing a full STEP
converter." |
| 03:36.43 |
DX^ |
who are these
developers? |
| 03:37.40 |
brlcad |
DX^: http://www.ohloh.net/p/brlcad/contributors
<-- developers with activity in the past year |
| 03:38.39 |
brlcad |
there is
already initial support for import, with more work happening this
year to complete it |
| 03:39.04 |
brlcad |
there has
been rumbling talks about an exporter (which is WAY easier), but
nobody is working on it yet |
| 03:42.48 |
CIA-43 |
BRL-CAD:
03brlcad * r42206 10/brlcad/trunk/src/libbu/Makefile.am: wow, long
time since I've seen THIS particular build system bug.. heh. add
missing \ line continuation after timetester.c in EXTRA_DIST so
CMakeLists.txt isn't left out. |
| 03:49.45 |
DX^ |
brlcad: I did
minor modificiations to g_xxx-facets.c to output JSON
(javascript) |
| 03:50.25 |
DX^ |
I am very
interested in IGES/STEP import/export |
| 03:50.57 |
DX^ |
I also think
there should be a tool/script that takes one file format directly
to another, without having to do foo->g->newfoo, but haven't
really figured out how this would work yet |
| 03:51.13 |
DX^ |
the code is
massive and complicated, and I have difficulty understanding what
is going on most of the time to be honest |
| 03:52.09 |
brlcad |
DX^: you know
we have pretty extensive support for iges import/export |
| 03:52.34 |
DX^ |
I submitted
an IGES bug not too long ago |
| 03:52.35 |
brlcad |
it was (and
still is in some ways) our most extensive converter |
| 03:52.44 |
brlcad |
just quite
aged and lacking attentino |
| 03:52.59 |
DX^ |
it won't
import the 2011/2012 Autodesk versions of IGES for whatever
reason |
| 03:53.19 |
brlcad |
not
surprising, it was written around version 5.1 |
| 03:53.30 |
DX^ |
brl-cad or
autodesk? |
| 03:53.35 |
brlcad |
probably
something very very minor |
| 03:53.37 |
brlcad |
iges |
| 03:53.39 |
brlcad |
iges
5.1 |
| 03:54.03 |
brlcad |
current/last
iges is 5.3 or 6.0 draft if they were on the drafting committee
before it collapsed |
| 03:54.22 |
DX^ |
hmm |
| 03:54.42 |
brlcad |
so it could
be something as simple as a header having a 5.3 in it and our
converter choking on it |
| 03:54.43 |
DX^ |
I wonder the
amount of work required to support IGES 5.3 |
| 03:54.53 |
brlcad |
more than
likely a "little" more complicated than that, but probably not much
more |
| 03:55.21 |
brlcad |
there weren't
huge changes, the format itself is the same -- just slightly
different entity details |
| 03:55.57 |
brlcad |
the spec is
available: http://www.uspro.org/documents/IGES5-3_forDownload.pdf |
| 03:56.00 |
DX^ |
http://sourceforge.net/tracker/?func=detail&aid=3125119&group_id=105292&atid=640802 |
| 03:56.02 |
brlcad |
so you could
review and compare |
| 03:56.05 |
DX^ |
was what I
submitted |
| 03:56.10 |
DX^ |
Add_nurb_loop_to_face: Edgeuse/vertex
mixup! |
| 03:56.59 |
brlcad |
yeah, that's
not even format-related -- it parsed all of the entities as shown
in the summary |
| 03:57.31 |
DX^ |
yep, not sure
what the deal is |
| 03:57.41 |
brlcad |
it's some
deficiency or bug in importing that specific object
type |
| 03:57.56 |
DX^ |
but the same
file imported into older versions of inventor and exported as IGES
imported into BRL-CAD just fine |
| 03:58.09 |
DX^ |
so I think
they changed something (obviously) |
| 03:58.26 |
brlcad |
the method it
uses isn't the best because when the converter was written it had
to turn most iges entities into polygons during import -- so that's
what it's trying to do and failing on |
| 03:58.53 |
brlcad |
that's the
(eu == edge use) toplogy failure |
| 03:59.42 |
brlcad |
DX^: could be
LOTS of reasons why it failed really |
| 03:59.54 |
DX^ |
yeah |
| 04:00.02 |
brlcad |
simple subtle
changes in the floating point alone after reconverting could have
made it work |
| 04:00.16 |
brlcad |
would have to
compare the summary reports from the one that worked |
| 04:00.24 |
DX^ |
I need to
brush up on more advanced C before I can touch this code
base |
| 04:00.32 |
DX^ |
I'd love to
help but I'm afraid my meddling hands would break too
much |
| 04:00.52 |
brlcad |
anything you
did would get reviewed by others, so don't be too afraid to dig in
;) |
| 04:01.09 |
brlcad |
you're not
going to break anythign that will hurt anyone but yourself
:D |
| 04:01.12 |
DX^ |
thing is that
I just don't know what the hell is going on yet |
| 04:01.46 |
DX^ |
I'm more
focused on the converters.. I think a solid suite of geometry
converters would bring more attention to BRL-CAD |
| 04:01.48 |
brlcad |
you should
turn your g_xxx-facets.c work to a proper g-json tool |
| 04:02.11 |
DX^ |
I will make
it more robust and submit it |
| 04:02.21 |
brlcad |
it would, we
have more converters than anyone, and the hardest ones at that
(iges, step, dxf, etc) |
| 04:02.58 |
DX^ |
an export to
COLLADA would be immensely powerful, but that spec is confusing as
all hell |
| 04:03.36 |
brlcad |
for what it's
worth, your tracker item hasn't been commented on mostly because
the library that iges-g is using there is undergoing a massive
review for robustness/stability |
| 04:03.43 |
brlcad |
collada would
be easy |
| 04:04.39 |
DX^ |
think
so? |
| 04:04.54 |
brlcad |
there's an
MIT-licensed SDK, so it would just be a matter of wiring it
up |
| 04:05.02 |
brlcad |
no more
complicated than writing json really |
| 04:05.14 |
DX^ |
hmm I'll look
into the SDK |
| 04:05.21 |
DX^ |
another
problem I was having is finding the top level object |
| 04:05.33 |
DX^ |
I got it from
mged, but its kind of confusing that you have to type it in
manually at the command line |
| 04:05.48 |
brlcad |
common point
of confusion for new users |
| 04:05.58 |
DX^ |
I get the
robustness of having it typed in, but shouldn't it default to all
objects if the arg is omitted? |
| 04:06.11 |
brlcad |
there's a
todo-item to make all of the converters work on all top-level
objects by default, but that's pretty low priority |
| 04:06.47 |
brlcad |
one of the
reasons (though not the whole story) is that many formats only have
support for single object export |
| 04:06.51 |
brlcad |
e.g.,
stl |
| 04:07.32 |
brlcad |
so do you
export one of the top-levels, which one? combine all of them into
a new top-level and export that? it's not well-defined |
| 04:07.47 |
brlcad |
so the user
has to learn what their situation is and decide |
| 04:08.38 |
brlcad |
not great,
but not terrible -- everyone figures it out pretty quickly, even
faster if they go through any of the intro tutorials |
| 04:13.57 |
DX^ |
yeah I
certainly understand the dilemma |
| 04:14.06 |
DX^ |
perhaps list
all top level objects and allow the user to choose one |
| 04:14.07 |
DX^ |
? |
| 04:14.22 |
DX^ |
or write each
one to a separate file |
| 04:21.03 |
brlcad |
yeah, ideally
you'd just write each one to a separate file and make the usage
default to specifying a filename template so it's defined and not
surprising |
| 04:21.13 |
brlcad |
and
scriptable |
| 04:21.44 |
brlcad |
not an
insurmountable problem, just nobody working in that particular area
at the moment -- sounds like a great patch though ;) |
| 04:22.08 |
brlcad |
src/libged/tops.c shows how to get a list
of top-level objects |
| 04:22.23 |
brlcad |
plenty of
folks here to help walk through code |
| 04:23.41 |
brlcad |
``Erik: the
very first error on the mac issues file is a failure in metaball.c
saying parameter mismatch. they match here, so maybe not
up-to-date or something? many of the errors that followed were
just cascade failures from librt not compiling |
| 04:52.25 |
``Erik |
I looked at
it and the types all looked correct, I'd verified with svn revert
and svn diff before running that build... I just recall lots of
signed/unsigned, lots of %lu vs size_t, and lots of unused
parameter stuff showing up *shrug* I'll look at it some more
tomorrow after the GS meeting |
| 05:03.29 |
CIA-43 |
BRL-CAD:
03brlcad * r42207 10/brlcad/trunk/src/adrt/slave/slave.c: another
BU_STR_EQUAL() conversion |
| 05:03.54 |
brlcad |
the linux log
looks valid |
| 05:04.15 |
brlcad |
for whatever
reason, the machine I tested isn't kicking those out with my
build |
| 05:04.55 |
CIA-43 |
BRL-CAD:
03brlcad * r42208 10/brlcad/trunk/src/burst/ (burst.c error.c fb.c
ui.c): a lot more manual BU_STR_EQUAL conversions |
| 05:06.59 |
CIA-43 |
BRL-CAD:
03brlcad * r42209 10/brlcad/trunk/src/util/ (6 files): fix a slew
of warnings from erik's linux build log. don't ignore the return
values from fread/fwrite/read/write/scanf. |
| 05:07.58 |
CIA-43 |
BRL-CAD:
03brlcad * r42210 10/brlcad/trunk/src/fb/ (cat-fb.c fb-bw.c pl-fb.c
pp-fb.c): more fixing of warnings from erik's linux build log.
don't ignore the return values from
fread/fwrite/read/write/scanf. |
| 05:08.18 |
CIA-43 |
BRL-CAD:
03brlcad * r42211 10/brlcad/trunk/src/bwish/cmd.c:
BU_STR_EQUAL |
| 05:08.42 |
CIA-43 |
BRL-CAD:
03brlcad * r42212 10/brlcad/trunk/src/anim/chan_permute.c: strcmp
-> BU_STR_EQUAL |
| 05:09.45 |
CIA-43 |
BRL-CAD:
03brlcad * r42213 10/brlcad/trunk/src/util/Makefile.am: remove
strict flags until all i/o funcs have return values
checked |
| 05:37.34 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.16.143) |
| 05:37.34 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:38.23 |
CIA-43 |
BRL-CAD:
03brlcad * r42214 10/brlcad/trunk/src/util/ (29 files): fix the
remainder of the fread/fwrite/scanf/read/write return value
warnings, adding simple diagnostic perror() error reporting if a
failure is detected. |
| 05:42.42 |
brlcad |
awesome, only
about 3000 issues remaining (TOTAL) |
| 05:43.25 |
brlcad |
should
compile 7.0 to see how far we've come along |
| 05:44.06 |
brlcad |
``Erik: that
should be all of the linux error issues unless I missed
something |
| 05:46.32 |
CIA-43 |
BRL-CAD:
03brlcad * r42215 10/brlcad/trunk/src/conv/iges/readglobal.c:
another COMMA case |
| 06:33.46 |
CIA-43 |
BRL-CAD:
03brlcad * r42216 10/brlcad/trunk/src/ (77 files in 32 dirs): mass
conversion from \!strcmp() to rossberg's newly added bu_strcmp()
via the related BU_STR_EQUAL() macro. improved readability. 300+
calls modified. |
| 07:05.54 |
CIA-43 |
BRL-CAD:
03brlcad * r42217 10/brlcad/trunk/misc/win32-msvc8/Makefile.am:
pixcmp and pixblend missing from dist |
| 07:06.19 |
CIA-43 |
BRL-CAD:
03brlcad * r42218 10/brlcad/trunk/src/libbn/Makefile.am:
bntester.dat missing from dist |
| 07:08.11 |
CIA-43 |
BRL-CAD:
03brlcad * r42219 10/brlcad/trunk/src/other/tktable/Makefile.in:
misc directory is missing from dist |
| 07:10.50 |
CIA-43 |
BRL-CAD:
03brlcad * r42220 10/brlcad/trunk/src/other/libz/Makefile.am:
another trailing slash missing |
| 07:25.21 |
CIA-43 |
BRL-CAD:
03brlcad * r42221 10/brlcad/trunk/src/ (146 files in 29 dirs):
another even massiver conversion from strcmp()==0 to rossberg's
newly added bu_strcmp() via the related BU_STR_EQUAL() macro.
improved readability and consistency. 800+ calls
modified. |
| 07:39.06 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 07:44.28 |
CIA-43 |
BRL-CAD:
03brlcad * r42222 10/brlcad/trunk/src/ (27 files in 12 dirs): a
smaller conversion from strcmp()!=0 to rossberg's newly added
bu_strcmp() via the related BU_STR_EQUAL() macro. improved
readability and consistency. 70+ calls. |
| 07:56.47 |
CIA-43 |
BRL-CAD:
03brlcad * r42223 10/brlcad/trunk/src/ (9 files in 7 dirs): even
smaller conversion from strcmp()==0 to rossberg's newly added
bu_strcmp() via the related BU_STR_EQUAL() macro. improved
readability and consistency. 20+ calls. |
| 07:58.38 |
CIA-43 |
BRL-CAD:
03brlcad * r42224 10/brlcad/trunk/src/mged/tedit.c: what the hell..
!(!(!(really???))) |
| 08:09.53 |
CIA-43 |
BRL-CAD:
03brlcad * r42225 10/brlcad/trunk/src/ (17 files in 6 dirs): more
conversion from !strcmp() to rossbergs new bu_strcmp() func via the
related BU_STR_EQUAL() macro. improved readability and consistency.
30+calls. |
| 08:22.45 |
CIA-43 |
BRL-CAD:
03brlcad * r42226 10/brlcad/trunk/src/ (12 files in 8 dirs): handle
a few more strcmp cases where the value returned is indeed
important, so convert to bu_strcmp() intead of macro. |
| 08:33.56 |
CIA-43 |
BRL-CAD:
03brlcad * r42227 10/brlcad/trunk/src/ (38 files in 14 dirs): and
yet even more. set !BU_STR_EQUAL() for handling a few remaining
strcmp cases used to test for non-matching. |
| 08:36.12 |
CIA-43 |
BRL-CAD:
03brlcad * r42228 10/brlcad/trunk/HACKING: prevent null crashes and
improve readability. strcmp() gets added to the avoidance
list. |
| 08:40.17 |
CIA-43 |
BRL-CAD:
03brlcad * r42229 10/brlcad/trunk/TODO: add distribution test for
the HACKING-listed functions/globals to be avoided in favor of bu_*
routines |
| 08:44.14 |
CIA-43 |
BRL-CAD:
03brlcad * r42230 10/brlcad/trunk/src/other/ (Makefile.am
fonts/): |
| 08:44.15 |
CIA-43 |
BRL-CAD:
might as well disable the fonts for now until it's time for them to
be actively |
| 08:44.15 |
CIA-43 |
BRL-CAD:
worked on. hopefully by then cmake system will be up and running
and we won't |
| 08:44.16 |
CIA-43 |
BRL-CAD: have
to fix the distcheck failure due to spaces in names. otherwise,
revision |
| 08:44.16 |
CIA-43 |
BRL-CAD:
history will hold them in trust even if their web sources
asplode. |
| 08:54.30 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 08:59.54 |
*** join/#brlcad mafm
(~mafm@27.Red-83-45-72.dynamicIP.rima-tde.net) |
| 10:45.02 |
*** join/#brlcad mafm_
(~mafm@27.Red-83-45-72.dynamicIP.rima-tde.net) |
| 12:38.25 |
*** join/#brlcad mafm
(~mafm@27.Red-83-45-72.dynamicIP.rima-tde.net) |
| 13:34.09 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 13:36.21 |
d_rossberg |
compiler
error on debian squeeze: primitives/arbn/arbn.c:1026: error: format
'%lu' expects type 'long unsigned int', but argument 3 has type
'size_t' |
| 13:41.23 |
starseeker |
anybody know
if we can convert cline primitives to something else? |
| 13:47.34 |
brlcad |
d_rossberg:
short fix is just to cast since %z isn't really
portable |
| 13:49.50 |
d_rossberg |
starseeker:
cmake's INSTALL ignores BRLCAD_PREFIX, CMAKE_INSTALL_PREFIX is
empty |
| 13:50.26 |
brlcad |
d_rossberg:
or --disable-warnings if you have other things to deal with
:) |
| 14:06.04 |
brlcad |
looks like I
did quite a bang-up job last night .. and now I can reproduce
erik's failures on linux (had to be optimized, I think) |
| 14:06.20 |
brlcad |
kicks CIA-43 |
| 14:06.21 |
CIA-43 |
ow |
| 14:06.49 |
brlcad |
at least a
dozen commits its not reporting |
| 14:12.30 |
d_rossberg |
it looks like
CIA-43 is still asleep |
| 14:12.38 |
brlcad |
doing a
review on all of the %lu's now |
| 14:13.10 |
starseeker |
brlcad: what
about incorporating some printing logic that does handle %z into
libbu? |
| 14:13.25 |
brlcad |
starseeker:
we already handle %z in libbu |
| 14:13.57 |
brlcad |
I really
don't want to wrap every single call to
scanf/sscanf/printf/fprintf/... |
| 14:14.07 |
starseeker |
ah |
| 14:33.22 |
CIA-43 |
BRL-CAD:
03brlcad * r42231 10/brlcad/trunk/src/libpkg/pkg.c: libpkg doesn't
depend on libbu |
| 14:44.49 |
CIA-43 |
BRL-CAD:
03brlcad * r42232 10/brlcad/trunk/include/bu.h: error: macro
bu_strcmp passed 2 arguments, but takes just 1. now it takes
2. |
| 14:47.57 |
CIA-43 |
BRL-CAD:
03brlcad * r42233 10/brlcad/trunk/src/conv/fast4-g.c: oops, there
is no bu_strlen() |
| 14:50.52 |
CIA-43 |
BRL-CAD:
03brlcad * r42234 10/brlcad/trunk/src/irprep/irdisp.c: need
bu.h |
| 14:51.05 |
CIA-43 |
BRL-CAD:
03brlcad * r42235 10/brlcad/trunk/src/gtools/g_diff.c: renamed
everyone except the first, ret_eq. |
| 14:53.54 |
CIA-43 |
BRL-CAD:
03brlcad * r42236 10/brlcad/trunk/src/sig/ (d-a.c dwin.c ihist.c):
more that need bu.h |
| 14:54.27 |
CIA-43 |
BRL-CAD:
03brlcad * r42237 10/brlcad/trunk/src/util/pixrect.c: helps to
actually set the variable. |
| 14:54.37 |
brlcad |
heh, cia must
be really overloaded |
| 14:55.39 |
brlcad |
yeah, looks
like someone rebased a git repo (it ends up replaying all
commits) |
| 14:57.04 |
starseeker |
ow |
| 14:58.18 |
brlcad |
ah, fork of
mandriva linux |
| 15:03.06 |
CIA-43 |
BRL-CAD:
03d_rossberg * r42238
10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: export the new
bu_strcmpm() too |
| 15:06.01 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 15:07.53 |
CIA-43 |
BRL-CAD:
03d_rossberg * r42239 10/brlcad/trunk/src/libbu/CMakeLists.txt:
fixed CMake configuration for library-testing tools |
| 15:31.24 |
brlcad |
starseeker: I
just noticed your changes to the mged/bwish startup .. remind me
what was the issue was there? |
| 15:33.00 |
starseeker |
basically I
did a fair bit of reworking of how libtclcad was setting paths - I
don't know that I did the right thing, but the upshot for mged was
I made changes to bwish to accomidate my changes to tclcad but
never went back around and did it for mged |
| 15:33.13 |
CIA-43 |
BRL-CAD:
03starseeker * r42240 10/brlcad/branches/cmake/ (374 files in 75
dirs): Update cmake branch to trunk r42239 |
| 15:33.21 |
brlcad |
reason I ask
is because setting tclcad_auto_path() is a crutch, one that
shouldn't be needed, so the code was trying to start without it
before, then retrying if that fails -- new code seems to just
punt |
| 15:34.00 |
starseeker |
uh. maybe
I'm abusing the mechanism, but package require mechanisms need the
extra paths... |
| 15:34.48 |
starseeker |
except for
archer, it's working pretty reliably now |
| 15:34.56 |
brlcad |
package
require needs them because they've not been setup
correctly |
| 15:34.59 |
CIA-43 |
BRL-CAD:
03starseeker * r42241
10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: nirt
subdirectory is no more. |
| 15:35.32 |
starseeker |
by "set up
correctly" do you mean placed where Tcl will seem them by
default? |
| 15:35.53 |
brlcad |
something to
that effect, but not necessarily a system installed
path |
| 15:36.20 |
brlcad |
using one of
tcl's various searching rules, a means to specify beyond
auto_path |
| 15:36.40 |
starseeker |
where are
those rules defined? |
| 15:36.54 |
starseeker |
I had a heck
of a time trying to figure out what governed search
paths |
| 15:36.58 |
brlcad |
technically,
we should be able to get away with one init_mged.tcl and with the
right pkgIndex.tcl and tclIndex files, everything is
found |
| 15:37.29 |
brlcad |
tclcad_auto_path() is the painful way to
do all that in C code |
| 15:37.51 |
brlcad |
embedding
search dirs into C code isn't a good idea |
| 15:38.28 |
starseeker |
sure - I
thought about just having tclcad_autopath point to one guaranteed
to be there tcl file to do all the path extensions... |
| 15:38.56 |
starseeker |
but figured
I'd stay as close as i could to our current setup while doing what
I wanted to do with it |
| 15:41.00 |
brlcad |
as close to
current would have left the two-pass loop -- that seems unrelated
to any changes made in tclcad_auto_path() |
| 15:41.42 |
brlcad |
why was mged
failing as it was written? |
| 15:41.56 |
brlcad |
(that
prompted r42244) |
| 15:49.56 |
starseeker |
without
tclcad_auto_path, auto_path had only the install
directories |
| 15:50.56 |
starseeker |
it got as far
as trying to load libitcl.dylib from the install directory and
wiped out |
| 15:52.07 |
starseeker |
however those
initial pre-tccad_auto_path paths are being set, even running from
the build dir it was picking up the installed directory's
paths |
| 15:53.40 |
starseeker |
that's why it
succeeds if I remove the install dir - without the install dir in
place, auto_path ends up populated with the build dir
paths |
| 15:55.38 |
starseeker |
rather than
depend on the black magic that seems to be the Tcl paths, I used
the tclcad_auto_path mechanism to always ensure it was looking
where it needed to look, based on current conditions |
| 15:57.26 |
starseeker |
the question
of course is how a build dir execution of ./bin/mged was getting
the install paths - I've been searching |
| 15:58.46 |
starseeker |
my best guess
is the Tcl_FindExecutable("mged") line - if that's picking up the
system path mged, it's pulling in the wrong lib paths |
| 15:59.22 |
CIA-43 |
BRL-CAD:
03starseeker * r42242 10/brlcad/branches/cmake/src/conv/fast4-g.c:
bu_strlen undefined, not seeing it in libbu - probably something
going on, use strlen for now in cmake branch. |
| 16:02.05 |
brlcad |
starseeker:
but there's part of my confusion -- if init failed without
tclcad_auto_path() (e.g. libitcl.dylib not loading), the very next
thing it should have been trying was to run tclcad_auto_path() to
try again -- or are you saying the second pass also
failed? |
| 16:02.46 |
starseeker |
I'm saying
the first pass crashed - it never got to the second pass. It
crashed somewhere in Tcl itself |
| 16:03.55 |
brlcad |
that sounds
familiar, there was a bug in earlier versions of tcl that
necessitated a private Tcl library call in order to not
crash |
| 16:05.43 |
brlcad |
my biggest
concern is complacency because if it works, nobody is going to go
back and look at the init code until something breaks yet
again |
| 16:06.21 |
brlcad |
I don't have
a big problem with the change, but do want to make sure we are
moving closer towards no tclcad_auto_path and no btclsh/bwish ..
not tighter assumed/required coupling |
| 16:06.23 |
starseeker |
that's why I
thought the tclcad_auto_path approach might be worthwhile - then we
don't care what Tcl is doing, because we're feeding it exactly what
we know it needs |
| 16:06.32 |
starseeker |
oh |
| 16:07.07 |
brlcad |
what you
mentioned about calling a tcl init and having all the logic there
would be a great decoupling |
| 16:07.30 |
brlcad |
theoretically, we could embed a generic
Tcl_Interp(), load that file, and have everything we
need |
| 16:07.40 |
brlcad |
that's the
cleanliness goal |
| 16:07.40 |
starseeker |
nods |
| 16:08.00 |
starseeker |
OK, that's
probably doable - I had assumed there were reasons we weren't
trying that |
| 16:08.23 |
starseeker |
Bu_Init,
Bn_Init and friends are definitely C... |
| 16:08.43 |
starseeker |
although even
there we could probably make a package require mechanism that would
work |
| 16:08.47 |
brlcad |
those are one
step closer towards "package require bu", "package require
bn" |
| 16:08.50 |
starseeker |
did it for
isst after all |
| 16:08.55 |
starseeker |
nods |
| 16:09.10 |
starseeker |
I can work
towards package require bu if that's the goal - I'd vastly prefer
that |
| 16:09.12 |
brlcad |
I believe
they're actually sufficient, they just don't have a pkgIndex.tcl
file |
| 16:09.19 |
starseeker |
messing with
the C underbelly of Tcl is nasty |
| 16:10.42 |
brlcad |
mged should
just "package require brlcad" or something similar, and have our
core libs load up as sub-packages including bu, bn, rt, wdb,
ged |
| 16:12.02 |
starseeker |
yeah, $5
that's it - bu_getprogname is returning mged, which in turn is
causing Tcl_FindExecutable to find the installed mged (which is in
the path) and populate based on the installed exe name, not the
local one |
| 16:12.53 |
starseeker |
if mged isn't
installed, Tcl_FindExecutable isn't coming back with anything
usable (or possibly it's finding /usr/brlcad/bin/mged and is smart
enough not to use that, not sure which) |
| 16:13.29 |
starseeker |
since there's
nothing, Itcl fails to load and it comes back around for the
auto_path enhancements (which does work) |
| 16:15.57 |
starseeker |
bingo. If I
force-feed Tcl_FindExecutable the full path to the build-dir mged,
it works |
| 16:22.38 |
CIA-43 |
BRL-CAD:
03starseeker * r42243 10/brlcad/branches/cmake/src/
(gtools/g_diff.c tclscripts/archer/LoadArcherLibs.tcl): Restore
some CMake branch tweaks I wiped out with the previous
update. |
| 16:40.57 |
brlcad |
starseeker:
there's a separate bu routine to get the full path so perhaps the
bug is calling bu_getprogname() |
| 16:41.42 |
brlcad |
bu_argv0_full_path() |
| 16:42.50 |
brlcad |
I believe
bu_getprogname() was set up to mirror what getprogname() returns,
which is just the name instead of the full path |
| 16:47.00 |
brlcad |
<PROTECTED> |
| 16:47.00 |
brlcad |
<PROTECTED> |
| 16:47.01 |
brlcad |
Failures:
95595 NMG, 99486 BoT |
| 16:47.01 |
brlcad |
NMG
conversion: 84.2% (508474 of 604069 objects) |
| 16:47.01 |
brlcad |
BoT
conversion: 83.5% (504583 of 604069 objects) |
| 16:47.03 |
brlcad |
<PROTECTED> |
| 16:47.07 |
brlcad |
hehe, that's
just terrible :) |
| 17:00.14 |
CIA-43 |
BRL-CAD:
03starseeker * r42244
10/brlcad/branches/cmake/src/mged/setup.c: |
| 17:00.14 |
CIA-43 |
BRL-CAD:
<smack> why'd I fix the bwish startup to account for the
changes to the |
| 17:00.15 |
CIA-43 |
BRL-CAD:
libtclcad logic but not mged? Make mged init look more like the
bwish init - |
| 17:00.15 |
CIA-43 |
BRL-CAD: this
whole setup probably needs review but mged should at least behave
better |
| 17:00.16 |
CIA-43 |
BRL-CAD: now.
Archer still isn't happy yet. |
| 17:10.25 |
brlcad |
poor
CIA |
| 17:11.10 |
brlcad |
an hour and a
half behind |
| 17:34.32 |
*** join/#brlcad Elrohir
(~kvirc@p5B14B2AE.dip.t-dialin.net) |
| 17:39.10 |
brlcad |
downloads 7.0.2 |
| 18:05.06 |
CIA-43 |
BRL-CAD:
03starseeker * r42245 10/brlcad/branches/cmake/src/mged/setup.c:
OK, revert to the previous two pass code, but use
bu_argv0_full_path instead of bu_getprogname to prevent the build
dir mged from getting the path info from the installed
mged. |
| 18:07.04 |
starseeker |
returns from lunch |
| 18:07.28 |
starseeker |
brlcad: yeah,
stumbled onto argv0 and tested - works |
| 18:07.38 |
starseeker |
oh, heh -
there's the commit message |
| 18:30.50 |
CIA-43 |
BRL-CAD:
03brlcad * r42246 10/brlcad/trunk/src/halftone/main.c: fb.h for
fb_common_file_size() |
| 18:44.51 |
starseeker |
ah, there we
go - thanks Sean for the examples of how to do it right. Archer
now runs from the build dir |
| 18:52.57 |
brlcad |
awesome |
| 19:04.20 |
CIA-43 |
BRL-CAD:
03starseeker * r42247 10/brlcad/branches/cmake/src/bwish/
(cadAppInit.c main.c): |
| 19:04.24 |
CIA-43 |
BRL-CAD:
Migrate the btclsh/bwish logic back closer to the trunk. Of course,
if we get |
| 19:04.24 |
CIA-43 |
BRL-CAD:
proper package require handling working for all of BRL-CAD these
may reduce |
| 19:04.25 |
CIA-43 |
BRL-CAD:
entirely to setting up tcl and loading one .tcl file, but that's
for later. |
| 19:05.52 |
CIA-43 |
BRL-CAD:
03starseeker * r42248 10/brlcad/branches/cmake/src/archer/
(CMakeLists.txt archer): Follow Sean's lead with making Archer
better about looking for files - archer now runs successfully from
the build dir. |
| 19:14.34 |
brlcad |
ahh, I
remember those days... 7.0 built in about 2 min :) |
| 19:15.23 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r42249
10/rt^3/trunk/src/other/sqlite_3_7_4/CMakeLists.txt: conditionalize
libdl based on OS (should probably be an explicit test
eventually) |
| 19:24.41 |
CIA-43 |
BRL-CAD:
03brlcad * r42250 10/brlcad/trunk/NEWS: |
| 19:24.42 |
CIA-43 |
BRL-CAD:
myself, daniel, and cliff arrived at a(n unverified) fix for the
mged crash |
| 19:24.42 |
CIA-43 |
BRL-CAD:
reported by tom browder on the devel mailing list where it'd crash
if you didn't |
| 19:24.43 |
CIA-43 |
BRL-CAD: have
one of the default editors installed due to unreliable strcmp()
behavior |
| 19:24.43 |
CIA-43 |
BRL-CAD: when
provided NULL arguments. fix was propagated throughout brl-cad code
with |
| 19:24.50 |
CIA-43 |
BRL-CAD: new
bu_strcmp() interface from daniel. |
| 19:39.18 |
starseeker |
hmm... may
have spoken too soon |
| 19:40.57 |
starseeker |
archer is
using /usr/brlcad/ files |
| 19:52.46 |
starseeker |
brlcad: I
must still be doing something wrong :-( |
| 19:56.43 |
brlcad |
starseeker:
you can verify before by kicking of btclsh and running the same
commands, test bu_brlcad_data with the parameters provided, for
example |
| 19:58.53 |
starseeker |
<PROTECTED> |
| 19:58.54 |
starseeker |
btclsh>
bu_brlcad_data tclscripts |
| 19:58.54 |
starseeker |
/usr/brlcad/share/tclscripts |
| 19:58.54 |
starseeker |
btclsh>
bu_brlcad_data src |
| 19:58.54 |
starseeker |
./src |
| 19:59.13 |
brlcad |
yeah, that's
the issue |
| 19:59.21 |
brlcad |
bu_brlcad_data tclscripts on trunk doesn't
do that |
| 19:59.37 |
brlcad |
so
something's different |
| 20:00.01 |
starseeker |
gotta be me
messing with libtclcad |
| 20:00.04 |
brlcad |
sushi:~/brlcad morrison$
src/bwish/btclsh |
| 20:00.04 |
brlcad |
Using Tcl
library at /Users/morrison/brlcad/src/other/tcl/library |
| 20:00.04 |
brlcad |
btclsh>
bu_brlcad_data tclscripts |
| 20:00.07 |
brlcad |
./src/tclscripts |
| 20:07.44 |
brlcad |
starseeker:
you can set BU_DEBUG_PATHS to see the actual start-up search logic
being used |
| 20:08.14 |
starseeker |
is that a
compile flag? |
| 20:08.26 |
brlcad |
run-time
flag |
| 20:09.16 |
starseeker |
so just
export it into the environment? |
| 20:09.42 |
brlcad |
btclsh>
set bu_debug 0x1000 |
| 20:09.42 |
brlcad |
0x1000 |
| 20:09.42 |
brlcad |
btclsh>
bu_brlcad_root . |
| 20:09.42 |
brlcad |
bu_brlcad_root: searching for
[.] |
| 20:09.42 |
brlcad |
Does
[/usr/brlcad/dev-7.18.1] exist? NO |
| 20:09.44 |
brlcad |
Does
[lt-btclsh] exist? NO |
| 20:09.47 |
brlcad |
Does
[/usr/brlcad] exist? YES |
| 20:09.50 |
brlcad |
Does
[/usr/brlcad/.] exist? YES |
| 20:09.52 |
brlcad |
Found:
/usr/brlcad default path [/usr/brlcad/.] |
| 20:09.55 |
brlcad |
/usr/brlcad/. |
| 20:09.57 |
brlcad |
btclsh> |
| 20:10.12 |
starseeker |
O.o - would
never have thought of set bu_debug 0x1000 |
| 20:10.28 |
brlcad |
all the
bu_debug flags are listed in bu.h |
| 20:10.47 |
brlcad |
almost every
tool exposes debug flags through -x and -X command-line
options |
| 20:11.10 |
starseeker |
the 0x1000 is
a hex value? |
| 20:12.45 |
brlcad |
yeah |
| 20:12.57 |
brlcad |
-\! for bu
debugging on most commands |
| 20:13.14 |
starseeker |
brlcad:
what's the sequence in your build tree for the search? |
| 20:13.29 |
brlcad |
rt -\!0x1
sets coredumping, for example |
| 20:13.39 |
brlcad |
which
search? |
| 20:13.46 |
starseeker |
the
bu_debug |
| 20:13.52 |
starseeker |
root |
| 20:14.22 |
brlcad |
sequence for
what though? |
| 20:14.47 |
starseeker |
I guess it
finds lt-btclsh before /usr/brlcad? |
| 20:15.18 |
starseeker |
nevermind -
I'll build trunk |
| 20:18.46 |
brlcad |
http://pastebin.mozilla.org/937127 |
| 20:20.39 |
starseeker |
thanks
:-) |
| 20:21.16 |
starseeker |
ah - it's
using the version number of brlcad |
| 20:21.36 |
starseeker |
that could be
one of my problems |
| 20:22.23 |
starseeker |
checks to see whether he incorporated version numbers into
his data setup... |
| 20:22.25 |
brlcad |
/usr/brlcad/dev-7.18.1 is my prefix for
that build, but other prefixes should work too iirc |
| 20:23.12 |
brlcad |
the only
version incorporation are the tests on lines 3 and 53 |
| 20:23.20 |
brlcad |
the rest of
the version numbers are just part of prefix |
| 20:24.48 |
starseeker |
it's looking
for share/brlcad/7.18.1 though, not share/brlcad |
| 20:25.12 |
brlcad |
right |
| 20:25.43 |
brlcad |
src/libbu/brlcad_path.c |
| 20:27.52 |
brlcad |
uses
BRLCAD_DATA if set, or BRLCAD_ROOT/share/brlcad/VERSION if unset ..
those two should match, though since BRLCAD_DATA ==
${bc_prefix}/share/brlcad/${BRLCAD_VERSION} |
| 20:27.58 |
brlcad |
from
m4/prefix.m4 |
| 20:28.53 |
starseeker |
here's what
I'm seeing: |
| 20:28.54 |
starseeker |
http://pastebin.mozilla.org/937149 |
| 20:29.16 |
brlcad |
remember
intentionally configuring the search logic so that there was a
highly minimized chance of getting the wrong install of something,
unless there really was just nothing else left to try |
| 20:31.48 |
brlcad |
if you have a
/usr/brlcad/share/tclscripts then that sounds like that's a problem
-- it's already so far down the failure list that it thinks it
found a usable install |
| 20:32.47 |
brlcad |
s/a
problem/the problem/ .. if you actually have an install in the
standard install place, then it's going to prefer that before it
attempts to fall back on source installations |
| 20:33.06 |
starseeker |
great. I
can't do anything about that |
| 20:33.09 |
brlcad |
it has to do
that for proper user behavior, their paths come first, then
devs |
| 20:33.21 |
starseeker |
isn't sure he agrees |
| 20:33.39 |
starseeker |
would expect to try local files first, then
installed |
| 20:33.43 |
brlcad |
I'm not sure
I understand why you have a /usr/brlcad/share/tclscripts in the
first place.. |
| 20:34.24 |
brlcad |
that'd be a
security vulnerability |
| 20:34.35 |
brlcad |
applications
that try local files first can be easily exploited |
| 20:35.32 |
starseeker |
but if we're
running from a build directory, isn't using files in that build
directory first reasonable? |
| 20:36.04 |
starseeker |
I agree if
the binary is installed that makes sense, but if it's not
installed... |
| 20:36.05 |
brlcad |
sure, but
there's no reliable way to tell you're running from a build
directory or someone who actually installed into their build
directory |
| 20:36.21 |
brlcad |
your build
directory is another person's home directory |
| 20:37.13 |
starseeker |
huh? I've
never seen anyone build using their homem directory
toplevel |
| 20:37.32 |
brlcad |
build *into*
thier home somewhere |
| 20:38.05 |
starseeker |
sure - but if
the build path and the install path are both known to the program,
it knows exactly when it is installed and when it isn't |
| 20:38.07 |
brlcad |
I've done
that plenty of times, seen others do it where install dir is a
subdir under brlcad/src or brlcad/ or somewhere else |
| 20:39.04 |
brlcad |
only the
compile-time install path is known |
| 20:39.04 |
brlcad |
where the
application actually ends up is not known |
| 20:39.25 |
brlcad |
you have
absolutely no guarantee that it'll end up in the install location
and that's desirable (to the user) -- application
relocatability |
| 20:39.38 |
brlcad |
that's what
lets you drag a mac app all around and it just works |
| 20:40.25 |
brlcad |
a lot of work
went into the current setup so it similarly works in a
deterministic safe manner too |
| 20:40.46 |
starseeker |
that's really
a problem for development though - you can't develop on a machine
that has an installed BRL-CAD |
| 20:41.02 |
brlcad |
I do it all
the time without problem... :) |
| 20:42.02 |
brlcad |
the log I
showed you has an existing install and
/usr/brlcad/{bin|share|man|etc} symlinks |
| 20:42.53 |
brlcad |
so again, my
claim is that you should not have a /usr/brlcad/share/tclscripts
unless you modified the install paths from what autoconf
does |
| 20:44.52 |
brlcad |
if you think
the search logic should change, feel free to write it down .. but I
can pretty much guarantee a use case exposed to exploit if you look
for dev paths before the existing search ordering .. bu.h has the
high-level ordering |
| 20:46.10 |
starseeker |
OK, I'll buy
that |
| 20:46.22 |
starseeker |
but it means
I'm stymed for now |
| 20:48.51 |
brlcad |
not
necessarily |
| 20:49.03 |
brlcad |
the search
ordering provides several ways to override |
| 20:49.30 |
brlcad |
you still
haven't read the search ordering in bu.h yet have you?
:) |
| 20:49.47 |
starseeker |
I know, the
environment variables |
| 21:09.40 |
CIA-43 |
BRL-CAD:
03starseeker * r42251 10/brlcad/branches/cmake/CMakeLists.txt: We
need to append the BRL-CAD version to the data install
dir. |
| 21:14.42 |
brlcad |
not strictly
necessary -- the only requirement I think is that
BRLCAD_ROOT/share/* should not be the same as
BRLCAD_DATA/* |
| 21:15.02 |
brlcad |
though having
the version does match the autotools build presently |
| 21:15.47 |
brlcad |
it's on the
build-system-to-do list, though to sort out multi-version installs
vs single-version install defaults. right now it's a mix of the
two. |
| 21:17.40 |
starseeker |
well, if you
have a scheme in mind now's the time :-) |
| 21:17.51 |
starseeker |
is about ready to rip his hair out |
| 21:18.01 |
brlcad |
having a
build option so that it will default to
/usr/brlcad/{rel|dev}-VERSION for ROOT with DATA being simple
"ROOT/share/brlcad" ;; and another option that inverts the version
so you can install into ROOT as /usr/brlcad with DATA as
ROOT/share/brlcad/VERSION |
| 21:18.58 |
brlcad |
the latter
being the one that would allow multi-version installs into a /usr
prefix for example |
| 21:21.22 |
starseeker |
nods |
| 21:23.50 |
brlcad |
would be nice
to have a version management system like 'alternatives' where
there's a base root (e.g. /usr or /usr/brlcad) that has symlinks IN
/usr/bin or /usr/brlcad/bin to some other place like
/usr/share/brlcad/rel-7.20.2/bin/ and you could toggle the symlinks
to different versions installed in a given location |
| 21:24.40 |
starseeker |
could
probably add an option to add or not add the symlinks |
| 21:27.01 |
starseeker |
brlcad: if I
may, a stupid question - why do the debug flags require setting via
hex numbers? |
| 21:30.41 |
``Erik |
debug flags
are designed as bit masks, so it's easiest to refer to them in
hex... dunno if the parser can take decimal, but bitwise ANDing
32768 and 256 can be a bit tedious |
| 22:14.19 |
CIA-43 |
BRL-CAD:
03brlcad * r42252 10/brlcad/trunk/src/conv/nastran-g.c: replace
commas with a #define COMMA since multichar string literals are not
valid to the preprocessor and will be caught more easily during
compilation if they get expanded with a space. |
| 22:15.41 |
brlcad |
starseeker:
they are scanf("%x") iirc |
| 22:18.40 |
brlcad |
plus they are
recorded in bu.h and raytrace.h in hex format where they are
compact and it's easy to make sure there is no bitwise overlap --
so what you see in the public header is what you can feed to the
application |
| 22:41.59 |
starseeker |
combines environment variable overrides with a test of a
local share directory and sees (mostly) success |
| 22:42.32 |
starseeker |
so be it -
the build tree will become a duplicate of the install tree, insofar
as it's possible/sensible |
| 23:04.13 |
brlcad |
awesome,
that'll make it really easy to test out a BRL-CAD.app |
| 23:31.28 |
CIA-43 |
BRL-CAD:
03brlcad * r42253 10/brlcad/trunk/src/fb/ (cat-fb.c fbcolor.c
pl-fb.c): more COMMA preprocessor conversions for
safety |
| 23:32.19 |
CIA-43 |
BRL-CAD:
03brlcad * r42254 10/brlcad/trunk/src/ (21 files in 13 dirs): cast
size_t's to unsigned long ints during printing, use %zu if it's a
bu_log or other bu_* routine since they have support for the 'z'
size_t specifier. |
| 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 |
| 01:03.27 |
*** join/#brlcad crazy_imp
(~mj@a89-182-3-165.net-htp.de) |
| 01:05.27 |
CIA-29 |
BRL-CAD:
03johnranderson * r42350 10/brlcad/trunk/src/util/Makefile.am:
bwhist needs libbu. |
| 01:09.46 |
CIA-29 |
BRL-CAD:
03johnranderson * r42351 10/brlcad/trunk/ (26 files in 5 dirs):
fixed a bunch of size_t issues. |
| 01:55.21 |
CIA-29 |
BRL-CAD:
03johnranderson * r42352
10/brlcad/trunk/src/conv/asc/g2asc.c: |
| 01:55.21 |
CIA-29 |
BRL-CAD: The
region color table is no longer output as part of the GLOBAL
object. |
| 01:55.21 |
CIA-29 |
BRL-CAD: If
no attributes of the GLOBAL object are output, the GLOBAL object
itself is not output. |
| 01:55.21 |
CIA-29 |
BRL-CAD:
fixed some size_t issues. |
| 02:37.41 |
CIA-29 |
BRL-CAD:
03starseeker * r42353 10/brlcad/branches/cmake/ (30 files in 8
dirs): Update cmake to trunk r42352 |
| 02:44.15 |
brlcad |
starseeker: I
don't remember what the problem was beyond what's in the commit
log |
| 02:44.32 |
brlcad |
vague
recollection that tcl/tk had to be patched too so there might be a
commit log message there with more info |
| 03:52.51 |
CIA-29 |
BRL-CAD:
03johnranderson * r42354
10/brlcad/trunk/doc/docbook/log4j.properties: Added a configuration
for log4j to stop the constant blather about it not being
configured. |
| 04:49.52 |
CIA-29 |
BRL-CAD:
03starseeker * r42355 10/brlcad/trunk/src/other/incrTcl/ (4 files
in 4 dirs): Tcl 8.4 doesn't cut it anymore, so we shouldn't need
the compat headers. |
| 04:53.49 |
CIA-29 |
BRL-CAD:
03starseeker * r42356
10/brlcad/trunk/src/other/incrTcl/makefile.bc: makefile.bc isn't
present in cvs incrtcl anymore. |
| 05:23.33 |
CIA-29 |
BRL-CAD:
03starseeker * r42357 10/brlcad/trunk/src/other/incrTcl/ (13 files
in 5 dirs): Start merging in changes from latest cvs incrTcl - will
try to do this carefully, as there are a few changes that will need
to be preserved. |
| 05:27.58 |
starseeker |
hah -
itcl/itk upstream DID take the patch |
| 05:28.01 |
starseeker |
http://incrtcl.cvs.sourceforge.net/viewvc/incrtcl/incrTcl/itcl/generic/itcl_methods.c?r1=1.20&r2=1.21 |
| 05:28.13 |
starseeker |
sweet |
| 05:34.13 |
CIA-29 |
BRL-CAD:
03starseeker * r42358 10/brlcad/trunk/src/other/incrTcl/itcl/ (14
files in 5 dirs): Remainder of changes from itcl subdir - itcl/itk
upstream applied changes made to itcl_methods.c, so they are no
longer a local BRL-CAD mod. |
| 05:35.35 |
CIA-29 |
BRL-CAD:
03starseeker * r42359
10/brlcad/trunk/src/other/incrTcl/itcl/doc/Makefile.am: Add new man
pages to makefile.am |
| 05:37.18 |
CIA-29 |
BRL-CAD:
03starseeker * r42360 10/brlcad/trunk/src/other/incrTcl/itk/ (4
files in 3 dirs): Just a few changes in the itk subdir |
| 05:42.32 |
CIA-29 |
BRL-CAD:
03starseeker * r42361 10/brlcad/trunk/src/other/incrTcl/ (9 files
in 2 dirs): Most of the remaining changes should be captured
here. |
| 05:45.53 |
CIA-29 |
BRL-CAD:
03starseeker * r42362 10/brlcad/trunk/src/other/incrTcl/ (4 files
in 4 dirs): Files not present in cvs incrTcl |
| 05:48.49 |
CIA-29 |
BRL-CAD:
03starseeker * r42363
10/brlcad/trunk/src/other/incrTcl/itk/library/pkgIndex.tcl:
Probably need this pre-generated file for our current Windows
build... |
| 05:55.48 |
starseeker |
that must be
why my system setup is working... |
| 05:56.24 |
CIA-29 |
BRL-CAD:
03starseeker * r42364 10/brlcad/trunk/src/other/iwidgets/ (246
files in 11 dirs): Sync iwidgets with latest cvs - mostly
whitespace in this one. |
| 05:59.02 |
CIA-29 |
BRL-CAD:
03starseeker * r42365
10/brlcad/trunk/src/other/iwidgets/pkgIndex.tcl.in: Ah, right - use
our variable. |
| 06:01.02 |
CIA-29 |
BRL-CAD:
03starseeker * r42366
10/brlcad/trunk/src/other/iwidgets/iwidgets.tcl.in: Use our version
of iwidgets.tcl.in too |
| 06:03.25 |
CIA-29 |
BRL-CAD:
03starseeker * r42367 10/brlcad/trunk/src/other/iwidgets/
(Makefile.am tcl.m4): Remove tcl.m4 - no longer in cvs. |
| 06:09.55 |
CIA-29 |
BRL-CAD:
03starseeker * r42368 10/brlcad/branches/cmake/src/other/incrTcl/
(8 files in 6 dirs): Wipe the incrTcl slate clean in CMake branch.
Need to get trunk's version in here and working. |
| 06:18.25 |
CIA-29 |
BRL-CAD:
03starseeker * r42369
10/brlcad/trunk/src/other/incrTcl/itcl/generic/itclInt.h: We still
need common.h in itclInt.h |
| 06:24.20 |
CIA-29 |
BRL-CAD:
03starseeker * r42370 10/brlcad/branches/cmake/src/other/incrTcl/
(189 files in 22 dirs): Put trunk's version of incrTcl in cmake -
need to add back in CMake logic. |
| 06:29.36 |
CIA-29 |
BRL-CAD:
03starseeker * r42371 10/brlcad/branches/cmake/src/other/incrTcl/
(15 files in 4 dirs): Restore old CMake logic |
| 06:32.33 |
CIA-29 |
BRL-CAD:
03starseeker * r42372 10/brlcad/trunk/src/util/bw-imp.c: Cast
size_t to int for printing. |
| 06:37.08 |
CIA-29 |
BRL-CAD:
03starseeker * r42373 10/brlcad/trunk/src/other/incrTcl/
(Makefile.am itk/Makefile.am): Update incrTcl makefiles |
| 06:42.49 |
CIA-29 |
BRL-CAD:
03starseeker * r42374 10/brlcad/branches/cmake/src/other/ (346
files in 15 dirs): Add iwidgets dir from trunk |
| 06:50.05 |
CIA-29 |
BRL-CAD:
03starseeker * r42375
10/brlcad/branches/cmake/src/other/incrTcl/itcl/CMakeLists.txt:
Mutter - need the brlcad include dir due to common.h
inclusion |
| 06:58.31 |
CIA-29 |
BRL-CAD:
03starseeker * r42376
10/brlcad/branches/cmake/src/other/incrTcl/itk/CMakeLists.txt: itk
needs common.h too |
| 07:04.00 |
CIA-29 |
BRL-CAD:
03starseeker * r42377 10/brlcad/branches/cmake/ (6 files in 6
dirs): Update cmake branch to trunk r42376 |
| 07:27.22 |
*** join/#brlcad WhiteCalf
(MK@whitecalf.net) |
| 07:33.24 |
CIA-29 |
BRL-CAD:
03starseeker * r42378 10/brlcad/trunk/ (4 files in 3 dirs):
autotools build needs a pkgIndex.tcl for tkpng, provide
it. |
| 07:35.34 |
CIA-29 |
BRL-CAD:
03starseeker * r42379 10/brlcad/branches/cmake/ (6 files in 4
dirs): Sync cmake to trunk r42378 |
| 07:39.01 |
CIA-29 |
BRL-CAD:
03starseeker * r42380 10/brlcad/trunk/ (configure.ac
src/other/tkpng/generic/tkImgPNGInit.c): Go with 0.8, since that
was what was in the source file - bit confusing, since the
ChangeLog seems to have tagged 0.9? |
| 07:40.39 |
CIA-29 |
BRL-CAD:
03starseeker * r42381 10/brlcad/branches/cmake/ (4 files in 3
dirs): sync cmake to r42380 |
| 07:46.07 |
CIA-29 |
BRL-CAD:
03starseeker * r42382 10/brlcad/branches/cmake/AUTHORS: Thought I
got this - sync CMake copy of AUTHORS file. |
| 07:56.16 |
CIA-29 |
BRL-CAD:
03starseeker * r42383 10/brlcad/branches/cmake/src/gtools/g_diff.c:
Put the trunk version of g_diff back, now that we're using trunk's
tclcad |
| 07:57.01 |
starseeker |
ah, getting
down to the last pieces, mostly having to do with config header
files and using package require Itcl instead of C apis |
| 09:10.04 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 09:57.50 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 11:55.23 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:33.49 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 12:38.48 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 12:41.12 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 12:45.48 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 12:47.44 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 12:50.59 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 12:56.06 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 12:58.39 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:05.04 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:06.51 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:09.19 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:10.27 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:12.41 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:17.22 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:21.58 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:25.23 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:31.54 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 13:31.59 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:35.03 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:39.22 |
CIA-29 |
BRL-CAD:
03starseeker * r42384
10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: Typo. |
| 13:40.40 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:44.39 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:44.53 |
CIA-29 |
BRL-CAD:
03starseeker * r42385 10/brlcad/branches/cmake/src/mged/setup.c:
Try to move mged's setup.c closer to trunk version. |
| 13:50.13 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 13:54.50 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 14:00.25 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 14:07.06 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 14:08.19 |
CIA-29 |
BRL-CAD:
03starseeker * r42386 10/brlcad/trunk/src/mged/ (attach.c cmd.c
setup.c): Try using the package require statements for itcl/itk in
MGED. |
| 14:09.42 |
CIA-29 |
BRL-CAD:
03starseeker * r42387 10/brlcad/trunk/doc/docbook/Makefile.am: Add
log4j.properties to EXTRA_DIST |
| 14:10.25 |
*** join/#brlcad mafm
(~mafm@215.Red-88-18-68.staticIP.rima-tde.net) |
| 14:14.05 |
CIA-29 |
BRL-CAD:
03starseeker * r42388 10/brlcad/trunk/src/other/ (4 files in 4
dirs): Changes to allow CMake + Visual C++ to work on Windows -
should have zero impact on any build except CMake. |
| 14:15.02 |
CIA-29 |
BRL-CAD:
03starseeker * r42389 10/brlcad/branches/cmake/src/other/ (6 files
in 6 dirs): Wrap the CMake generated headers in a define that is
only set in the CMake build. |
| 14:28.02 |
CIA-29 |
BRL-CAD:
03starseeker * r42390 10/brlcad/branches/cmake/src/bwish/main.c:
Tweaks |
| 14:29.52 |
CIA-29 |
BRL-CAD:
03starseeker * r42391 10/brlcad/trunk/src/bwish/ (cadAppInit.c
main.c): Try using package require for itcl/itk in
bwish |
| 14:31.11 |
CIA-29 |
BRL-CAD:
03starseeker * r42392 10/brlcad/trunk/src/libtclcad/tclcad.c: Same
deal for tclcad.c - try using package require. |
| 14:35.40 |
CIA-29 |
BRL-CAD:
03starseeker * r42393 10/brlcad/branches/cmake/src/ (5 files in 2
dirs): Put itk_redefines.tcl with the other archer tcl
scripts |
| 14:37.37 |
CIA-29 |
BRL-CAD:
03starseeker * r42394
10/brlcad/branches/cmake/src/tclscripts/archer/CMakeLists.txt: Put
lower case at end, bit easier to find things. |
| 14:38.28 |
CIA-29 |
BRL-CAD:
03starseeker * r42395 10/brlcad/trunk/src/ (3 files in 2 dirs): Put
itk_redefines.tcl into trunk version of archer |
| 14:49.10 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.27.44) |
| 14:49.10 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:49.58 |
CIA-29 |
BRL-CAD:
03starseeker * r42396 10/brlcad/trunk/include/ (Makefile.am
config_win_cmake.h): Add a config_win header that will work with
cmake - for now this looks like the simplest way to make both
systems happy, but eventually config_win_cmake.h will become
config_win.h |
| 14:50.46 |
CIA-29 |
BRL-CAD:
03starseeker * r42397 10/brlcad/branches/cmake/ (4 files in 2
dirs): Use config_win_cmake.h for CMake build. |
| 14:54.03 |
CIA-29 |
BRL-CAD:
03starseeker * r42398 10/brlcad/branches/cmake/ (6 files in 6
dirs): Update cmake to trunk r42397 |
| 15:01.00 |
CIA-29 |
BRL-CAD:
03starseeker * r42399 10/brlcad/trunk/include/common.h: Tweak
common.h from CMake and add to trunk. |
| 15:03.30 |
CIA-29 |
BRL-CAD:
03starseeker * r42400 10/brlcad/branches/cmake/ (. CMakeLists.txt
include/common.h src/other/tkhtml/): Hopefully this will allow the
same common.h to be used in both cmake and autotools. |
| 15:05.41 |
starseeker |
and if
everything's working, that should do it |
| 15:06.00 |
starseeker |
except for
the CMake logic, that ought to sync both trees |
| 15:06.11 |
starseeker |
now for
distcheck, etc. |
| 15:34.29 |
CIA-29 |
BRL-CAD:
03starseeker * r42401
10/brlcad/trunk/src/tclscripts/archer/Makefile.am: need file
extension |
| 15:50.25 |
CIA-29 |
BRL-CAD:
03d_rossberg * r42402 10/brlcad/trunk/ (configure.ac
src/libbu/brlcad_path.c): there is no realpath() in MSVC, so
replaced it by a trivial string-copy then |
| 16:03.37 |
brlcad |
re 42382 --
you did get it but then you undid it with a subsequent commit
saying you didn't match trunk |
| 16:03.52 |
brlcad |
your diff was
probably not against an up-to-date checkout |
| 16:07.12 |
CIA-29 |
BRL-CAD:
03brlcad * r42403 10/brlcad/trunk/src/util/bw-imp.c: keep the cast
size as large as possible, fix the format |
| 16:08.34 |
starseeker |
ah,
whoops |
| 16:12.52 |
starseeker |
growls... apparently there is no good solution for something
like realpath on Windows |
| 16:16.08 |
starseeker |
oh
well |
| 16:19.14 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:19.26 |
starseeker |
yeah, these
guys pretty much punt:
https://www.securecoding.cert.org/confluence/display/seccode/FIO02-C.+Canonicalize+path+names+originating+from+untrusted+sources |
| 16:20.20 |
starseeker |
and the
closest thing isn't recommended for use in multithreaded
applications or shared library code by Microsoft: http://msdn.microsoft.com/en-us/library/aa364963%28VS.85%29.aspx |
| 16:20.21 |
``Erik |
looks like
there's a com idl for it |
| 16:20.34 |
starseeker |
hmm? |
| 16:20.34 |
``Erik |
IShellLink |
| 16:20.57 |
``Erik |
has a
GetPath() method, dunno what the C approach is |
| 16:22.23 |
``Erik |
I'm seeing c#
and delphi ways to do it without the com bridge to the 'power
shell' thingie |
| 16:23.03 |
starseeker |
give the
issue mainly shows up when running build dir binaries and that
other fallbacks should (mostly) cover the Windows cases, I'm
thinking a huge effort is probably not needed |
| 16:23.32 |
starseeker |
cygwin
command line might be the main issue, and I would guess they have a
realpath? |
| 16:24.13 |
``Erik |
there was a
patch to try to give it a better approach I saw googling, under the
mingw32 set I think |
| 16:28.07 |
CIA-29 |
BRL-CAD:
03starseeker * r42404 10/brlcad/branches/cmake/ (7 files in 5
dirs): Update cmake branch to r42403, add realpath check to
CMakeLists.txt |
| 16:35.39 |
starseeker |
hmm...
http://msdn.microsoft.com/en-us/library/aa364962%28v=VS.85%29.aspx |
| 16:38.19 |
starseeker |
or perhaps
http://msdn.microsoft.com/en-us/library/aa364966%28v=VS.85%29.aspx |
| 16:39.36 |
starseeker |
well, if we
need to we'll go there |
| 16:39.41 |
starseeker |
but only if
we need to |
| 16:42.27 |
brlcad |
you could
implement a bu_normalize() function |
| 16:42.53 |
brlcad |
which could
call realpath() or implement it if unavailable |
| 16:43.23 |
starseeker |
nods - that would be the way to go, if it's
needed |
| 16:43.56 |
starseeker |
give we were
surviving without the rule working at all, I'm thinking we should
expend that effort only when there's a clear need |
| 16:44.15 |
brlcad |
sure |
| 16:44.31 |
brlcad |
didn't know
if you were addressing an issue by adding realpath() in the first
palce |
| 16:44.59 |
starseeker |
was addressing the "I can't run my build dir archer script in
the CMake build" issue :-P |
| 16:45.27 |
brlcad |
how does
realpath fix that? |
| 16:45.47 |
brlcad |
gets the
absolute path of something? |
| 16:45.52 |
brlcad |
that was
relative |
| 16:45.56 |
starseeker |
yes |
| 16:46.17 |
starseeker |
if I ran
(say) ../../bin/bwish, the argv0 full path was that |
| 16:46.34 |
brlcad |
bu_argv0_full_path() shouldn't have been
that |
| 16:48.06 |
brlcad |
if it was,
it's a bug that needs to be fixed |
| 16:48.17 |
starseeker |
checks... |
| 16:49.53 |
brlcad |
now,
bu_argv0_full_path() could/should be calling realpath() in its
implementation, but it just appends relative to pwd now (punts, but
a valid absolute path) |
| 16:50.34 |
starseeker |
yeah,
launching "../../bin/bwish", bu_argv0_full_path returns
"../../bin/bwish" |
| 16:50.49 |
brlcad |
wow |
| 16:51.36 |
starseeker |
had figured getprogname was just "bwish", and argv0 was the
full string that invoked bwish, and if I wanted a canonical path it
was up to me to use argv0's results |
| 16:52.10 |
brlcad |
not sure how
that's even possible |
| 16:52.22 |
brlcad |
nah, that bu
function is specifically to get an absolute path |
| 16:54.11 |
starseeker |
so then the
realpath logic, if it really is needed, probably belongs there and
not in bu_brlcad_root |
| 16:57.02 |
brlcad |
probably, or
possibly both depending on which path is being tested (e.g., do we
support relative paths in BRLCAD_ROOT) |
| 16:57.42 |
starseeker |
what
the... |
| 16:57.58 |
brlcad |
inclination
is probably not support them |
| 16:58.02 |
starseeker |
in gdb, it
DOES look like it's returning full path |
| 16:58.18 |
starseeker |
what the
*BLEEP* was bu_log printing? |
| 17:01.38 |
starseeker |
O.O |
| 17:02.02 |
starseeker |
the result
changes depending on whether I'm launching bwish from within
gdb |
| 17:02.30 |
starseeker |
looks for a handy wall to bash his head
into... |
| 17:06.03 |
starseeker |
oh, looks
like gdb is expanding out the path before running it |
| 17:06.05 |
starseeker |
cute |
| 17:15.20 |
starseeker |
brlcad: as
near as I can trace this back, the sequence is: |
| 17:15.51 |
starseeker |
bwish/tcl.c -
bu_setprogname takes argv[0] and assignes it to
bu_progname |
| 17:16.11 |
starseeker |
argv[0] at
that time is ../../bin/bwish |
| 17:17.51 |
starseeker |
bu_argv0_full_path calls three functions:
_bu_argv0, _bu_ipwd and bu_which |
| 17:18.29 |
starseeker |
they return,
respectively, ../../bin/bwish . ../../bin/bwish |
| 17:21.07 |
starseeker |
because the
which result from bu_which is non-null and _bu_argv0's result does
not appear to be a full path, the which result is the returned
value |
| 17:21.19 |
starseeker |
there is no
check on whether which is a full path |
| 17:27.12 |
starseeker |
looking over
bu_which, it doesn't seem to be designed to return a full
path... |
| 17:29.02 |
starseeker |
yeah, once
that relative argv[0] was put into bu_progname, I don't see any
logic that would make it a full path... |
| 17:33.03 |
starseeker |
if the which
thing hasn't stopped the logic, it would have tried to use
ipwd |
| 17:33.19 |
starseeker |
but ipwd was
"." |
| 17:34.22 |
starseeker |
so I don't
think that would have worked even if which hadn't short circuited
the processs |
| 17:40.51 |
*** join/#brlcad Elrohir
(~kvirc@p5B14A3BB.dip.t-dialin.net) |
| 18:09.33 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 18:47.41 |
brlcad |
looks like
ipwd is wrong |
| 18:50.01 |
brlcad |
"." as an
initial (full) path to the current working directory sounds like a
fall-back path |
| 18:51.30 |
brlcad |
yeah, looks
like getenv() was probalby empty and HAVE_POPEN was not
defined |
| 18:52.04 |
brlcad |
realpath
would probably be good there |
| 18:53.17 |
brlcad |
realpath(getenv("PWD")) or even
realpath(".") |
| 19:31.01 |
*** part/#brlcad crazy_imp
(~mj@a89-182-3-165.net-htp.de) |
| 20:09.23 |
*** join/#brlcad Ralith
(~ralith@d142-058-094-139.wireless.sfu.ca) |
| 20:14.37 |
Ralith |
brlcad: do
you know anything about how jonored's gcode generator was going to
work, or where I could read up on that? Since he appears to have
disappeared for good, I may try to pick up where he left
off. |
| 20:16.04 |
Ralith |
hm, probably
should have asked that when I wasn't about to
disconnect. |
| 20:25.57 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 20:30.05 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 20:56.15 |
*** join/#brlcad mafm
(~mafm@171.Red-83-37-177.dynamicIP.rima-tde.net) |
| 21:13.20 |
CIA-29 |
BRL-CAD:
03brlcad * r42405 10/brlcad/trunk/TODO: preliminary stab at
current/next release plans: temp rt/rtedge/rtwizard colors, upgrade
repo, and more |
| 21:21.16 |
starseeker |
brlcad: what
about bu_which? that's the one that was actually responsible for
the bwish path I saw, although it looked like none of the possible
paths would actually have gotten us there... |
| 21:22.20 |
starseeker |
doesn't look
like most of these functions could have returned a full path if a
relative path was specified... |
| 22:08.38 |
brlcad |
starseeker:
bu_which attempts to mimic the 'which' command-line too |
| 22:08.55 |
brlcad |
which has
nothing to do with relative or absolute paths |
| 22:09.07 |
brlcad |
it attempts
to find a path to the object specified |
| 22:09.39 |
brlcad |
e.g. if you
run "mged" .. it does the search across the dirs in PATH to find it
(which can be relative dirs) and returns the match |
| 22:51.17 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 22:51.22 |
Ralith |
okay, back
for the day |
| 22:56.35 |
starseeker |
brlcad: then
for the purposes of bu_argv0_full_path the which results should be
wrapped in realpath too |
| 23:02.46 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 23:28.37 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 23:45.43 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 23:50.04 |
Ralith |
brlcad: you
didn't answer while I was pinging out, did you? |
| 23:54.55 |
starseeker |
no, he
didn't |
| 00:01.15 |
Ralith |
okay |
| 03:33.38 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 04:56.44 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.16.143) |
| 04:56.44 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:55.10 |
brlcad |
Ralith: was
waiting since you were gone and not away -- he didn't write up any
of his plans or work from anything written up |
| 07:55.38 |
brlcad |
if he made
any progress, it wasn't made publicly available that I'm aware
of |
| 07:56.10 |
Ralith |
brlcad: just
got ahold of him after a month of trying, actually. Will be
resuming his work. |
| 07:56.17 |
Ralith |
he sent me
his full git repo |
| 07:56.58 |
brlcad |
excellent |
| 07:57.07 |
brlcad |
I have a copy
of some python code he wrote |
| 07:57.20 |
brlcad |
don't know if
it's the same as what was in his repo |
| 07:57.35 |
Ralith |
nope, this is
C |
| 07:57.38 |
brlcad |
but at a
glance, it was mainly a way to do in python some of the things you
can do in mged |
| 07:57.45 |
brlcad |
k |
| 07:57.57 |
Ralith |
this is a
partly complete slicer based on the raytracer |
| 07:58.06 |
Ralith |
not sure how
partly; I suspect mostly. |
| 07:58.08 |
brlcad |
that's
good |
| 07:58.20 |
Ralith |
outputs a
sequence of line segments and circular arcs |
| 07:58.24 |
brlcad |
that's one of
two respectable approaches, the easier of the two |
| 07:58.33 |
Ralith |
what's the
other, out of curiosity? |
| 07:59.09 |
brlcad |
we'll, you're
either using ray-tracing and sampling the space to determine an
approximation for toolpaths |
| 07:59.57 |
brlcad |
or you're
projecting a contour image to 2D (either sampled or in parametric
form) and using that for toolpaths |
| 08:00.46 |
Ralith |
contour image
being something along the lines of the
sketch-from-plane-region-intersection thing I was asking about
earlier? |
| 08:00.54 |
Ralith |
projected
contour image* |
| 08:01.13 |
brlcad |
basically |
| 08:01.26 |
brlcad |
that'd be one
way to attempt it |
| 08:01.54 |
Ralith |
that was what
I was planning on doing had I not been able to recover this
code. |
| 08:02.04 |
brlcad |
three or four
come to mind but they all involve projecting an object onto a
viewing plane, not a simple thing to do |
| 08:02.05 |
Ralith |
looks like
that will be unnecessary, though |
| 08:02.28 |
brlcad |
the sampled
approach is MUCH much easier and doable today |
| 08:02.35 |
Ralith |
nod |
| 08:02.37 |
Ralith |
good to
know |
| 08:02.45 |
brlcad |
and only
limited by the resolution you're willing to sample |
| 08:03.05 |
Ralith |
and I have a
concrete upper limit to that: the precision of the target
machine. |
| 08:03.19 |
Ralith |
typically
worse than 0.1mm. |
| 08:03.32 |
brlcad |
you can
probably even sample below some specified machining tolerance and
it'd never matter |
| 08:03.37 |
brlcad |
yeah |
| 08:03.48 |
Ralith |
and a typical
build volume of 20cm means quite reasonable sample counts, I
believe. |
| 08:04.22 |
brlcad |
yeah, that'd
just be a 2k x 2k sample grid |
| 08:04.34 |
Ralith |
trickier on
ultraprecise CNC lathes and such, but my first priority is reprap
support, which means relatively low-res additive. |
| 08:04.42 |
brlcad |
that'd take
just a second or two to calculate them all |
| 08:04.47 |
Ralith |
sweet |
| 08:05.08 |
Ralith |
if the
line/arc approximation math jonored's already finished isn't too
heavy, this'll easily outstrip everything else people are
using |
| 08:05.29 |
Ralith |
all of which
are improvised STL processors |
| 08:05.54 |
brlcad |
crank that up
to a 200cm piece or 20cm at a 0.01mm tolerance, and you jack up the
grid to 20k x 20k |
| 08:06.11 |
brlcad |
which would
be a couple minutes (10x order of mag. increase) |
| 08:06.55 |
Ralith |
jonored also
mentioned that he was put off by some bug wherein the second
derivative of toroids was mis-reported? |
| 08:06.59 |
Ralith |
know anything
about that? |
| 08:07.14 |
brlcad |
nope |
| 08:07.41 |
Ralith |
okay, will
see about hunting it down if/when I encounter it myself |
| 08:07.41 |
brlcad |
first I've
heard of toroids having a problem |
| 08:08.03 |
Ralith |
it sounded
like a minor one: |
| 08:08.16 |
Ralith |
19:56:53
<jonored> Yep. Either puts them in the wrong slots, or gives
a direction of the larger curvature at right angles to what it
should, don't recall which. |
| 08:08.44 |
brlcad |
there is one
thing that comes to mind, but it's not second-derivative related.
it's failure to converge on a hit/miss if you perfectly graze a
torus under certain math conditions |
| 08:08.52 |
brlcad |
but then it
just counts it as a miss |
| 08:09.04 |
Ralith |
seems like a
pretty minor issue, at least for my purposes |
| 08:09.16 |
brlcad |
ah, curvature
is a different routine |
| 08:09.46 |
Ralith |
he referred
to it as having the "curvature flipped" |
| 08:09.51 |
brlcad |
not used by
much, so that would be a little less surprising -- but also trivial
to investigate -- one tiny func |
| 08:09.58 |
Ralith |
okay
then |
| 08:10.10 |
Ralith |
will mention
it if I find anything |
| 08:10.28 |
Ralith |
hopefully
with a patch in tow, though I'm still a bit worried about my
ability to keep up with the math |
| 08:10.35 |
brlcad |
src/librt/primitives/tor/tor.c:831 |
| 08:10.39 |
brlcad |
rt_tor_curve() |
| 08:10.45 |
Ralith |
thanks
:) |
| 08:10.52 |
brlcad |
if there's a
curvature bug, that's where it'd be |
| 08:11.45 |
brlcad |
it'd be easy
to get a sign wrong |
| 08:12.32 |
Ralith |
looks like
this might well be pretty straightforward. |
| 08:14.29 |
brlcad |
"rt -l4
-s1024 file.g object" will render 'object' in 'file.g' to a window
1024x1024 with a curvature visualization lighting model, so you can
see them in an image |
| 08:14.52 |
Ralith |
ooh,
fun! |
| 08:17.49 |
Ralith |
hm, behaves
oddly. |
| 08:17.54 |
Ralith |
perhaps I
should install a stable version |
| 08:18.50 |
Ralith |
frame buffers
are hanging around and not responding to close requests, and
display sharply skewed output despite it appearing normal
mid-render |
| 08:19.17 |
brlcad |
are you (or
your window manager) resizing the window? |
| 08:19.24 |
Ralith |
window
manager is. |
| 08:19.42 |
brlcad |
that'd be a
problem |
| 08:19.58 |
Ralith |
tiling wm;
tends to be more forceful about that than much code
expects |
| 08:20.05 |
Ralith |
not a very
well behaved tiling wm, though. |
| 08:20.20 |
brlcad |
fb windows
aren't resizable unfortunately |
| 08:20.23 |
Ralith |
will switch to something more compliant and with float
support in the near future |
| 08:20.28 |
brlcad |
sucks, but
nobody has fixed |
| 08:20.31 |
brlcad |
try fbserv
instead |
| 08:20.39 |
brlcad |
fbserv 0
/dev/X & |
| 08:20.49 |
brlcad |
rt -F0 -s1024
file.g object |
| 08:21.35 |
Ralith |
that works
nicely! |
| 08:21.36 |
Ralith |
thanks
:) |
| 08:22.47 |
brlcad |
manpage shows
other options if the need arises |
| 08:22.50 |
Ralith |
nod |
| 09:43.04 |
*** join/#brlcad mafm
(~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net) |
| 10:38.21 |
CIA-29 |
BRL-CAD:
03tbrowder2 * r42406 10/brlcad/trunk/src/libged/attr.c: modify and
rename attr sort comp function for extern use |
| 10:40.01 |
CIA-29 |
BRL-CAD:
03tbrowder2 * r42407 10/brlcad/trunk/src/libged/ged_private.h: add
extern for attr comp function; add flags for extension of mged tree
command args |
| 10:42.17 |
CIA-29 |
BRL-CAD:
03tbrowder2 * r42408 10/brlcad/trunk/src/libged/ls.c: cast to int
to quell compiler warnings about signed/unsigned
comparison |
| 10:44.21 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 11:13.47 |
*** join/#brlcad mafm
(~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net) |
| 11:14.02 |
CIA-29 |
BRL-CAD:
03tbrowder2 * r42409 10/brlcad/trunk/HACKING: list extensions for
Perl code |
| 11:44.18 |
DaveLo |
Mernin
all |
| 12:32.38 |
CIA-29 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2422 10/wiki/GeometryServiceNetworkProtocol: |
| 13:07.39 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 13:37.10 |
DaveLo |
opens a new can of Photoshop-fu. Will need lots
today. |
| 13:38.50 |
CIA-29 |
BRL-CAD:
03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded
"[[Image:GSNetProtocol.png]]" |
| 13:55.05 |
CIA-29 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2424 10/wiki/GeometryServiceNetworkProtocol: Added in specifics
about GSNet Header stufff. WIP still. |
| 13:57.11 |
CIA-29 |
BRL-CAD:
03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded
"[[Image:GSNetMsgBreakdown.png]]" |
| 13:59.45 |
CIA-29 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2426 10/wiki/GeometryServiceNetworkProtocol: New image name, down
size a bit. |
| 14:03.33 |
starseeker |
is probably going to end up volunteering to maintain a few
Find*.cmake modules |
| 14:09.06 |
DaveLo |
that'll be
fun! |
| 14:10.03 |
starseeker |
apparently
back in 07 they switched to a system where people volunteer to
maintain specific modules, on the (quite reasonable) theory that
Kitware didn't have the resources to properly test them
all |
| 14:10.59 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 14:11.04 |
starseeker |
submitted patches for Tcl, OpenGL and X11 anyway on the
theory that Kitware probably wouldn't want to trust them to a 3rd
party maintainer, give how core they were |
| 14:11.07 |
starseeker |
silly
me |
| 14:11.17 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 14:11.20 |
*** join/#brlcad 15SABD4WY
(~CIA@208.69.182.149) |
| 14:12.26 |
starseeker |
in one sense
though it's not too big a deal, since I'll either be maintaining
our local copy of those files as a "mini-fork" or doing it for
CMake proper |
| 14:13.28 |
*** join/#brlcad CIA-38
(~CIA@208.69.182.149) |
| 14:13.32 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 14:13.48 |
starseeker |
X11 and
OpenGL should be pretty mature anyway, but the FindTCL module is a
radical departure |
| 14:14.42 |
DaveLo |
Hows the
roads down there? |
| 14:15.45 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:GSNet
Symbol.png]]" |
| 14:15.53 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
| 14:15.53 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 14:17.59 |
*** join/#brlcad ``Erik_
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 14:18.33 |
*** join/#brlcad epileg1
(~epileg@188.119.210.222) |
| 14:20.36 |
*** join/#brlcad mafm
(~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net) |
| 14:21.53 |
starseeker |
grits his teeth and does a reboot into Windows for another
test round... |
| 14:22.49 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2428 10/wiki/GeometryServiceNetworkProtocol: Add in GSnet graphic
and align. |
| 14:23.13 |
DaveLo |
starseeker:
Hows the roads down there? made the trek in to work
yet? |
| 14:24.11 |
*** join/#brlcad Elrohir
(~kvirc@p5B14977D.dip.t-dialin.net) |
| 14:27.59 |
starseeker |
no, not yet -
they plowed but there is a lot of slush in our area |
| 14:28.13 |
starseeker |
just got done
scraping the driveway |
| 14:29.16 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2429 10/wiki/GSNet_String: Stub in GSNet String page. |
| 14:31.33 |
starseeker |
will head in once he sees what happens on
Windows... |
| 14:33.09 |
starseeker |
oooo - lot of
updates to pull |
| 14:37.44 |
*** join/#brlcad Elrohir
(~kvirc@p5B14977D.dip.t-dialin.net) |
| 14:59.43 |
DaveLo |
lotsa ice up
here as well. |
| 15:00.00 |
DaveLo |
just called
in to leave a telework notice. Heh, no one answered!
=D |
| 15:06.09 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 15:10.43 |
``Erik_ |
snow line
said post was closed until 9 |
| 15:13.05 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r42410 10/brlcad/trunk/src/librt/Makefile.am:
move nmg_junk to EXTRA_DIST |
| 15:28.03 |
CIA-38 |
BRL-CAD:
03starseeker * r42411 10/brlcad/branches/cmake/src/CMakeLists.txt:
Put the CMAKE_HEADERS variable in the src add_definitions (Windows
seems to like this better, needs more testing.) |
| 15:36.01 |
DaveLo |
``Erik:
righto, but I called at 10 and still no answer :) |
| 15:39.33 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r42412 10/brlcad/trunk/src/libged/ged.c: type
fix |
| 15:44.38 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.19.46) |
| 15:44.38 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:22.12 |
CIA-38 |
BRL-CAD:
03starseeker * r42413
10/brlcad/branches/cmake/CMakeLists.txt: |
| 16:22.12 |
CIA-38 |
BRL-CAD:
Successfully generate an NSIS installer, although it doesn't work
yet due to |
| 16:22.12 |
CIA-38 |
BRL-CAD:
src/other libraries being installed to the wrong dir - need to
correct the CMake |
| 16:22.12 |
CIA-38 |
BRL-CAD:
files in question or add additional logic in
src/other/CMakeLists.txt, whichever |
| 16:22.12 |
CIA-38 |
BRL-CAD:
makes sense. |
| 18:03.41 |
DaveLo |
whoooo doggy.
There's some serious ice out there! Im still chipping away at
getting clear. |
| 18:03.49 |
CIA-38 |
BRL-CAD:
03starseeker * r42414 10/brlcad/branches/cmake/ (11 files in 11
dirs): Make the CMake library target logic a bit more generic. A
lot of these files should probably be worked into being proper
stand-alone CMakeLists.txt files. |
| 18:03.56 |
DaveLo |
looks like
two layers of ice then snow. Blech |
| 18:04.12 |
starseeker |
nods - I'll be heading in soon, but yeah - figured the more
melted the better |
| 18:04.21 |
starseeker |
at least it's
above freezing, or moving would be out of the question |
| 18:04.37 |
DaveLo |
Temps up here
are cycling above then below here. |
| 18:04.45 |
starseeker |
ah, we're a
few degrees above |
| 18:04.59 |
DaveLo |
half the
stuff that melted and ran off the jeep refroze on the ground
:/ |
| 18:05.18 |
DaveLo |
We're getting
more this evening, right? i havent checked the forecast in a
bit. |
| 18:05.27 |
starseeker |
still had to shovel - if it had re-frozen tonight, would have
had 3/4 inch or better of ice all over the
driveway |
| 18:05.42 |
starseeker |
dunno -
haven't seen any indications of more, but perhaps that's
changed |
| 18:06.09 |
starseeker |
makes one file stab at Windows before heading
in |
| 18:07.02 |
DaveLo |
checks forecast |
| 18:07.56 |
DaveLo |
heh, yeah.
Starting around 10pm, more ice and snow... at least up
here. |
| 18:08.40 |
DaveLo |
looks like
mostly rain down your way, with temps never dipping below
freezing. |
| 18:08.53 |
DaveLo |
have a nice
day at work! muwahahaha =P |
| 18:09.35 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2430 10/wiki/GeometryServiceNetworkProtocol: Change links to start
eliminating the iBME references. |
| 18:10.01 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[IBME NETWORKPROTO STRING]]":
iBME references are antiquated and being updated. |
| 18:20.41 |
*** part/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 18:20.53 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 18:49.54 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 19:24.53 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2431 10/wiki/GeometryServiceNetworkProtocol: Spacing |
| 19:30.10 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2432 10/wiki/GeometryServiceNetworkProtocol: Specifics about the
libPKG header implementation |
| 19:48.20 |
brlcad |
starseeker:
note that the current nsis installer is "wrong" in several aspects
as to where files are placed |
| 19:49.22 |
brlcad |
you don't
need to accommodate the existing mistakes -- keep the install tree
like it is supposed to be so it's the same on all
platforms |
| 19:49.25 |
brlcad |
the nsis
installer can be fixed to accomodate |
| 19:52.00 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2433 10/wiki/GeometryServiceNetworkProtocol: Use CSS to make the
table purty. |
| 19:55.41 |
CIA-38 |
BRL-CAD:
03brlcad * r42415 10/brlcad/trunk/src/libged/ (attr.c ged.c
ged_private.h): |
| 19:55.41 |
CIA-38 |
BRL-CAD:
private functions used across commands should be in the _ged_
namespace, |
| 19:55.41 |
CIA-38 |
BRL-CAD:
otherwise, they don't need to be declared in ged_private.h and can
remain HIDDEN |
| 19:55.41 |
CIA-38 |
BRL-CAD:
_cmd_ prefixed. rename _attr_cmpstringp() to _ged_cmpattr() to
reflect that it |
| 19:55.41 |
CIA-38 |
BRL-CAD:
specifically compares bu_attribute_value_pair objects. |
| 20:12.27 |
CIA-38 |
BRL-CAD:
03brlcad * r42416 10/brlcad/trunk/src/libged/ (attr.c ged.c
ged_private.h): ws consistency update, elim forward
decls |
| 20:15.04 |
starseeker |
nods |
| 20:15.30 |
starseeker |
trying to
figure out why mged isn't finding anything on
Windows... |
| 20:15.47 |
starseeker |
needs to generalize the pkgIndex.tcl files a bit, doing that
first |
| 20:19.42 |
CIA-38 |
BRL-CAD:
03brlcad * r42417 10/brlcad/trunk/src/libged/ (ged_private.h ls.c):
convert up to size_t instead of down to int. |
| 20:56.07 |
CIA-38 |
BRL-CAD:
03brlcad * r42418 10/brlcad/trunk/src/librt/parse.c: quell
warnings, size_t upconversions |
| 20:58.54 |
CIA-38 |
BRL-CAD:
03brlcad * r42419
10/brlcad/trunk/src/librt/Makefile.am: |
| 20:58.55 |
CIA-38 |
BRL-CAD:
compile parse.c and nmg_junk.c so we make sure that they keep
compiling as the |
| 20:58.55 |
CIA-38 |
BRL-CAD:
library evolves. they don't need to be installed, but they should
still be |
| 20:58.55 |
CIA-38 |
BRL-CAD:
maintained until they're integrated or removed. (alas, they both
have useful |
| 20:58.55 |
CIA-38 |
BRL-CAD:
routines that should be integrated) |
| 20:59.38 |
brlcad |
starseeker:
be wary of #ifdef _WIN32 and if {$platform == "windows"} statements
in C/Tcl code that Bob added to override search paths |
| 21:00.33 |
brlcad |
some of them
are sprinkled in unsuspecting places, have to trace the logic when
something fails to load that should be loading to make sure it's
not a hack job screwing things up |
| 21:00.54 |
starseeker |
nods - will do |
| 21:22.42 |
CIA-38 |
BRL-CAD:
03starseeker * r42420 10/brlcad/branches/cmake/src/other/ (6 files
in 6 dirs): Fix/generalize pkgIndex.tcl logic, make incrTcl libs
follow convention. |
| 21:40.08 |
CIA-38 |
BRL-CAD:
03brlcad * r42421
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: |
| 21:40.09 |
CIA-38 |
BRL-CAD: not
entirely clear what the compiler is complaining about here with the
two |
| 21:40.09 |
CIA-38 |
BRL-CAD:
(const point_t *) parameters to rt_metaball_find_intersection().
the problem |
| 21:40.09 |
CIA-38 |
BRL-CAD: has
something to do with point_t being an array typedef. instead of
getting the |
| 21:40.09 |
CIA-38 |
BRL-CAD:
address during the call, get the point_t address beforehand with an
explicit |
| 21:40.09 |
CIA-38 |
BRL-CAD: cast
to keep things quiet. (gcc 4.2.1) |
| 21:49.15 |
``Erik |
hm, I
disabled nmg_junk.c last week due to 'defined but not used'
warnings stopping the compile |
| 22:08.28 |
brlcad |
everything in
librt_xxx.la is not used, so maybe it'll be quiet -- seems to work
here with 4.2.1 |
| 22:08.46 |
brlcad |
otherwise, I
can add some extern decls |
| 22:08.54 |
brlcad |
that'll
definitely make it shut up |
| 22:15.54 |
CIA-38 |
BRL-CAD:
03starseeker * r42422
10/brlcad/branches/cmake/src/libbu/brlcad_path.c: |
| 22:15.54 |
CIA-38 |
BRL-CAD:
Interesting... when launching bwish from the root install dir (e.g.
./bin/bwish) |
| 22:15.54 |
CIA-38 |
BRL-CAD: the
return of bu_brlcad_data was not a full path (or even strictly
speaking a |
| 22:15.54 |
CIA-38 |
BRL-CAD:
relative path unless you add an implicit '.') and archer didn't
start. This is |
| 22:15.54 |
CIA-38 |
BRL-CAD: a
bit of a corner case, but still should work - try to make it more
robust. |
| 22:29.09 |
CIA-38 |
BRL-CAD:
03starseeker * r42423
10/brlcad/branches/cmake/src/archer/plugins/Utility/botUtilityP.tcl:
shouldn't need brlcadDataPath variable here. |
| 22:38.48 |
CIA-38 |
BRL-CAD:
03starseeker * r42424
10/brlcad/branches/cmake/src/libbu/brlcad_path.c: Whoops, try to do
snprintf right |
| 22:47.42 |
starseeker |
mutter...
bwish starts, but it's auto_path is rather
underpopulated |
| 22:50.13 |
starseeker |
and
bu_brlcad_data doesn't know what's up on Windows (at least from
build-dir, which I suppose isn't too surprising) |
| 23:06.08 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 23:46.11 |
brlcad |
starseeker:
that could be related to path separator, or trying to mix one style
of separator with another |
| 00:09.53 |
``Erik |
votes for '>' :D (vms) |
| 00:11.25 |
CIA-38 |
BRL-CAD:
03brlcad * r42425 10/brlcad/trunk/BUGS: rt crashes when it
shouldn't |
| 00:41.22 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 00:44.36 |
``Erik |
http://brlcad.org/~erik/codenorris.jpg |
| 00:52.49 |
CIA-38 |
BRL-CAD:
03starseeker * r42426 10/brlcad/branches/cmake/src/libbu/dirname.c:
Don't hardcode '/' into bu_dirname, it's wrong on
Windows |
| 00:53.52 |
*** join/#brlcad merzo
(~merzo@94-43-108-20.dsl.utg.ge) |
| 01:20.56 |
CIA-38 |
BRL-CAD:
03brlcad * r42427 10/brlcad/trunk/ (4 files in 4 dirs): |
| 01:20.56 |
CIA-38 |
BRL-CAD:
enable a test for -std=c99 since we cannot compile glx/gl.h-using
code on Mac OS |
| 01:20.56 |
CIA-38 |
BRL-CAD: X
10.6 with -pedantic due to // comments in the gl.h header. use the
flag in |
| 01:20.56 |
CIA-38 |
BRL-CAD: the
dirs where we interface with glx (src/mged src/libdm
src/libfb) |
| 01:29.14 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 01:37.47 |
CIA-38 |
BRL-CAD:
03starseeker * r42428 10/brlcad/branches/cmake/src/
(libbu/brlcad_path.c mged/mged.c mged/setup.c): Use GetFullPathName
on Windows, and remove a couple of the Win32 specific bits in mged
- this results in mged launching successfully. Still a lot more to
do, including figuring out why archer silently crashes. |
| 01:48.41 |
starseeker |
hmm - I
wonder if the itcl/itk upgrade did something, or if it's just how
I'm building them with CMake |
| 02:01.23 |
brlcad |
<windows.h> .. system
header |
| 02:52.34 |
starseeker |
in common.h
then? |
| 03:17.28 |
starseeker |
huh - maxima
is in the top 25 projects on sourceforge |
| 03:31.13 |
Ralith |
didn't know
it was that active |
| 03:31.14 |
Ralith |
neat |
| 03:38.47 |
starseeker |
huh - another
cad project based on opencascade: http://sourceforge.net/projects/narocad/ |
| 03:41.44 |
starseeker |
woot -
someone is porting qcad to qt4 |
| 03:51.51 |
starseeker |
http://sourceforge.net/projects/librecad/ |
| 03:51.56 |
starseeker |
even
builds |
| 05:10.26 |
CIA-38 |
BRL-CAD:
03brlcad * r42429 10/brlcad/trunk/include/raytrace.h: remove
duplicate rt_dirbuild declaration |
| 06:01.42 |
Ralith |
opencascade
gets all the attention ._. |
| 07:48.02 |
CIA-38 |
BRL-CAD:
03brlcad * r42430 10/brlcad/trunk/ (include/raytrace.h
src/librt/db5_scan.c src/librt/db_open.c): rename db_get_version()
to simply db_version(). there's no need for the getter name
convention (inconsistent with api), especially when there's no
putter. |
| 07:59.23 |
CIA-38 |
BRL-CAD:
03brlcad * r42431 10/brlcad/trunk/src/libged/ (draw.c erase.c):
upcast argc iteration comparisons to size_t |
| 08:07.45 |
CIA-38 |
BRL-CAD:
03brlcad * r42432 10/brlcad/trunk/doc/deprecation.txt: renamed
db_get_version() to db_version() as a minimally impacting
change. |
| 08:10.55 |
CIA-38 |
BRL-CAD:
03brlcad * r42433 10/brlcad/trunk/ (6 files in 4 dirs): rename
db_get_directory_size() to just db_directory_size() for similar
motivations. there is no corresponding put routine, so
simplify. |
| 08:27.59 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 08:27.59 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 08:27.59 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 08:27.59 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 08:27.59 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 08:28.01 |
CIA-38 |
BRL-CAD:
03brlcad * r42434 10/brlcad/trunk/ (doc/deprecation.txt
include/raytrace.h src/librt/db_lookup.c): db_get_directory()
renamed to db_alloc_directory() to be a little more consistent with
other (non-macro) routines that don't do much except allocate
memory. |
| 08:29.27 |
CIA-38 |
BRL-CAD:
03brlcad * r42435 10/brlcad/trunk/src/librt/ (db_alloc.c
db_lookup.c): move the allocation routine into
db_alloc.c |
| 08:32.51 |
CIA-38 |
BRL-CAD:
03brlcad * r42436 10/brlcad/trunk/ (doc/deprecation.txt
include/raytrace.h src/librt/db_alloc.c): be more specific. match
the resource struct member name, allocating more than one
directory. |
| 08:35.03 |
CIA-38 |
BRL-CAD:
03brlcad * r42437 10/brlcad/trunk/include/raytrace.h: make it clear
that these affect one global timer |
| 08:41.10 |
CIA-38 |
BRL-CAD:
03brlcad * r42438 10/brlcad/trunk/ (doc/deprecation.txt
include/raytrace.h src/librt/storage.c): rename rt_get_set()
similarly to rt_alloc_seg_block() since it doesn't actually get
andthing or have an equivalent put/set. it's purpose is to allocate
a block of segs so just say that. |
| 08:46.17 |
CIA-38 |
BRL-CAD:
03brlcad * r42439 10/brlcad/trunk/include/raytrace.h: declare
db_alloc_directory_block() properly according to the
rename. |
| 08:49.15 |
CIA-38 |
BRL-CAD:
03brlcad * r42440 10/brlcad/trunk/include/raytrace.h: move the
related decls closer to each other for the two rt/db_alloc
routines |
| 08:50.33 |
CIA-38 |
BRL-CAD:
03brlcad * r42441 10/brlcad/trunk/src/librt/ (db_alloc.c
storage.c): move rt_alloc_seg_block from storage.c to db_alloc.c so
db_alloc_directory_bloc() doesn't get lonely. |
| 08:51.55 |
CIA-38 |
BRL-CAD:
03brlcad * r42442 10/brlcad/trunk/ (4 files in 2 dirs): storage.c
is no longer needed. |
| 08:57.36 |
Ralith |
I'd like to
find a series of line segments along a given line, within the
inside of a region, such that no point on any line segment is
closer than a certain to the surface. Anyone have any thoughts on
how this might be done? |
| 08:58.18 |
Ralith |
something
like the intersection between a line and a verison of the object
slightly shrunk along all surface normals, I think |
| 09:17.31 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 09:38.57 |
CIA-38 |
BRL-CAD:
03d_rossberg * r42443
10/brlcad/trunk/src/librt/CMakeLists.txt: |
| 09:38.58 |
CIA-38 |
BRL-CAD:
synced with Makefile.am: removed nmg_junk.c from the actual
build |
| 09:38.58 |
CIA-38 |
BRL-CAD:
nmg_junk.c is a resting place for unfinished subroutines that are
not a part of the current NMG library |
| 09:56.06 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 10:29.43 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 10:44.58 |
*** join/#brlcad mafm
(~mafm@62.Red-81-32-105.dynamicIP.rima-tde.net) |
| 11:18.32 |
*** join/#brlcad juanman
(~quassel@201.255.21.86) |
| 11:18.35 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:03.48 |
DaveLo |
Mernin
all! |
| 13:06.33 |
CIA-38 |
BRL-CAD:
03ronaldbowers * r42444
10/jbrlcad/trunk/src/main/java/org/brlcad/geometryservice/: Making
an interface |
| 13:08.03 |
``Erik |
now what the
heck is ron up to? I've been putting that in rt^3 |
| 13:09.32 |
DaveLo |
tee
hee |
| 13:39.02 |
brlcad |
<PROTECTED> |
| 13:39.26 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.19.79) |
| 13:39.26 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:55.11 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 14:00.35 |
CIA-38 |
BRL-CAD:
03brlcad * r42445 10/brlcad/trunk/src/librt/db5_scan.c: if the
database version has already been calculated, don't bother
recalculating it. avoids rewind+fseek. |
| 14:03.22 |
CIA-38 |
BRL-CAD:
03brlcad * r42446 10/brlcad/trunk/src/librt/db_open.c: make sure
db_version() calculates the version during db_open(), init to
zero. |
| 14:08.51 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Image:GSNetProtocol.png]]":
Incorrectly named image. Should have been named
GSNetMsgBreakdown |
| 14:29.48 |
CIA-38 |
BRL-CAD:
03davidloman * r42447 10/rt^3/trunk/docs/ (GS_Symbol.png
GS_Symbol.psd): Add in rough draft of GS graphic. |
| 14:37.47 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2434 10/wiki/Geometry_Service_Project_Main: Update
definitions |
| 14:38.26 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[IBME GeometryEngine]]":
Dropping antiquated definition as well as eliminating an iBME
reference. |
| 14:38.46 |
CIA-38 |
BRL-CAD:
03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[IBME GeometryService]]":
Dropping antiquated definition as well as eliminating an iBME
reference. |
| 15:10.15 |
*** join/#brlcad Elrohir
(~kvirc@p5B14BCFC.dip.t-dialin.net) |
| 15:11.21 |
CIA-38 |
BRL-CAD:
03brlcad * r42448 10/brlcad/trunk/include/raytrace.h: move the
alloc functions down with the other alloc functions |
| 15:25.37 |
starseeker |
O.O http://www.40fires.org/Wiki.jsp?page=Hyrban%20CAD%20models |
| 15:26.54 |
starseeker |
http://www.40fires.org/Wiki.jsp?page=TermsOfUse |
| 15:27.09 |
``Erik |
neat |
| 15:28.13 |
starseeker |
I thinke we
just found a test case for our iges convertor :-P |
| 15:28.55 |
starseeker |
waits for his headache to subside so he can go
in... |
| 15:30.22 |
``Erik |
hm, from
their blog, 9/10/09, "One day we'll have a wonderful, open source,
free or nearly free, collaborative, version controlling 2D/3D CAD
system (any suggestions?) and a wiki that you can all contribute to
but it's still early days." |
| 15:32.55 |
``Erik |
can't find
what CAD system they're using, and don't know 'nuff to guess from
the pictures |
| 15:33.19 |
starseeker |
CATIA, I
think |
| 15:33.24 |
starseeker |
newest blog
entry mentions it |
| 15:33.29 |
``Erik |
that was my
gut feeling heh |
| 15:33.46 |
``Erik |
the blue
gradient background in some p ics is catia style |
| 15:35.22 |
``Erik |
hm,
shuttleworth has talked to 'em |
| 15:45.00 |
CIA-38 |
BRL-CAD:
03brlcad * r42449 10/brlcad/trunk/src/ (52 files in 9 dirs): put
db_version() to use, particularly for callers outside of librt
since it's a private API member that isnt' supposed to be directly
accessed. this sets the stage for using dbi_version in other
ways. |
| 15:57.54 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:11.00 |
CIA-38 |
BRL-CAD:
03brlcad * r42450 10/brlcad/trunk/src/conv/dbupgrade.c: get the
version number just once, then reference it |
| 16:19.18 |
DaveLo |
Hrm, might be
a decent idea:
http://www.cnn.com/2011/TECH/innovation/01/19/smart.roads/index.html?eref=mrss_igoogle_cnn |
| 16:19.53 |
CIA-38 |
BRL-CAD:
03ronaldbowers * r42451
10/jbrlcad/trunk/src/main/java/org/brlcad/geometryservice/GeometryServiceSPI.java:
- Version 0.1 of the GeometryServiceSPI. Implementations should
match the behavior defined here. |
| 16:32.24 |
CIA-38 |
BRL-CAD:
03brlcad * r42452 10/brlcad/trunk/src/librt/db5_scan.c:
idiot |
| 16:32.45 |
CIA-38 |
BRL-CAD:
03brlcad * r42453 10/brlcad/trunk/src/librt/db5_io.c: can't call
db_version because the dbip is const |
| 16:37.09 |
CIA-38 |
BRL-CAD:
03brlcad * r42454 10/brlcad/trunk/src/ (10 files in 5 dirs):
improve consistency on how the version numbers are checked.
avoiding <= and >= where unnecessary. |
| 17:26.43 |
CIA-38 |
BRL-CAD:
03brlcad * r42456 10/brlcad/trunk/src/mged/ (cmd.c mged.c): rename
db_warn, db_upgrade, and db_version to have an mged_ prefix so they
don't collide with librt db_*() functions (e.g.,
db_version()) |
| 18:02.35 |
CIA-38 |
BRL-CAD:
03bob1961 * r42458
10/brlcad/trunk/src/tclscripts/lib/RtControl.tcl: Added a
configbody for the -color option. |
| 18:02.35 |
CIA-38 |
BRL-CAD:
03bob1961 * r42457 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl:
Tweaked cadwidgets::TkTable::toggleSelect to behave better after a
<Button-1> event occurs in a different cell. |
| 18:03.07 |
CIA-38 |
BRL-CAD:
03bob1961 * r42459 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Added a preference for the
framebuffer's background color. |
| 18:31.12 |
starseeker |
DaveLo:
problem with solar powered roads is 1) cost and 2) keeping 'em
clean |
| 18:31.58 |
DaveLo |
Well if a
state manages to get a leader in place that actually has LONG term
planning skills, cost may be less of a problem. |
| 18:32.17 |
DaveLo |
as for
cleaning, just wrap swiffer pads around tires :) |
| 18:32.24 |
starseeker |
heh |
| 18:33.14 |
starseeker |
might be more
workable to have the sides of the road be solar panels |
| 18:33.41 |
starseeker |
no car oil
and crap being dropped on them (or less, anyway) and they'll be
exposed to the sun more |
| 18:33.45 |
CIA-38 |
BRL-CAD:
03brlcad * r42460 10/brlcad/trunk/ (NEWS m4/patch.m4): (log message
trimmed) |
| 18:33.45 |
CIA-38 |
BRL-CAD: wow,
now that I can finally reproduce and investigate ... FIX
the |
| 18:33.45 |
CIA-38 |
BRL-CAD:
several-year-old bug where compilation would fail on some Mac OS X
systems |
| 18:33.45 |
CIA-38 |
BRL-CAD:
(10.6+?) with a 'dyld: Library not loaded: |
| 18:33.45 |
CIA-38 |
BRL-CAD:
/usr/brlcad/dev-7.18.1//lib/libwdb.19.dylib' message (and
subsequent crash |
| 18:33.46 |
CIA-38 |
BRL-CAD:
report). the problem is actually due to a bug in libtool where
their temp_rpath |
| 18:33.47 |
CIA-38 |
BRL-CAD:
variable was getting appended to another path variable but without
a : between |
| 18:34.52 |
starseeker |
also would
avoid the concerns mentioned about glass strength and
traction |
| 18:34.58 |
brlcad |
it's only a
matter of time, I can see it easily being cost effective for
cities |
| 18:36.57 |
brlcad |
very
'spensive to have a fleet of trucks rolling through city streets
scooping up snow and ice, took hundreds of trucks nearly a month to
clear baltimore last year working 24/7 |
| 18:37.30 |
starseeker |
nods - cities could also heat the roads using solar panels on
buildings and such (or even other sources of heat, once the heating
element infrastructure itself was in place) |
| 18:38.34 |
brlcad |
that's easily
a couple million in annual expenses just to cover salary,
double/triple to cover equipment, maintenance, supplies,
insurance |
| 18:39.38 |
brlcad |
city streets
get repaved regularly (there are just so many), so they'd just need
to be installable in sections as upgrades occur and be fault
tolerant to big trucks, pot holes, etc |
| 18:41.10 |
starseeker |
brlcad:
regarding windows.h - ``Erik was saying including it at the
common.h level causes conflicts |
| 18:41.51 |
``Erik |
may
cause |
| 18:42.12 |
``Erik |
many annoying
things come from windows.h, like #define near and #define far for
example |
| 18:42.26 |
``Erik |
and #define
DELETE more recently |
| 18:42.54 |
``Erik |
isn't happy about the #ifdef WIN32 #undef symbol #endif
pattern we have a few places :/ |
| 18:46.37 |
starseeker |
unless I'm
missing something, wouldn't the only way forward be to include
windows.h up front in config_win, and then undef everything that
may cause us trouble later? |
| 18:49.04 |
``Erik |
or rename our
stuff |
| 19:06.06 |
brlcad |
now with that
old bug fixed.. time for lunch! |
| 19:18.49 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 19:18.49 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 19:18.50 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 19:18.50 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 19:18.50 |
*** join/#brlcad DaveLo
(~claymore@BZ.BZFLAG.BZ) |
| 19:18.50 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
| 19:18.50 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 19:18.50 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 19:57.19 |
DaveLo |
heh, forgot
about this one: http://www.youtube.com/watch?v=u-6ph7NWoBM |
| 21:04.13 |
starseeker |
brlcad: thath
BU_STR_EQUAL thing seems to have broken search |
| 21:11.17 |
Ralith |
brlcad:
that's good for entry/exit points, but doesn't account for points
when a surface passes very close to but does not intersect the ray
while it's inside the region |
| 21:30.55 |
CIA-38 |
BRL-CAD:
03starseeker * r42461 10/brlcad/trunk/src/other/tkpng/Makefile.am:
I doubt we need the -module flag here - CMake build doesn't need
it, so try it without |
| 21:31.35 |
``Erik |
hah, now it
fails with the expected issue |
| 21:31.41 |
``Erik |
src/other/tkpng/Makefile.am:8: `tkpng.la'
is not a standard libtool library name |
| 21:31.41 |
``Erik |
src/other/tkpng/Makefile.am:8: did you
mean `libtkpng.la'? |
| 21:32.49 |
starseeker |
bah |
| 21:32.52 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r42462
10/brlcad/trunk/src/other/tkpng/Makefile.am: tkpng ->
libtkpng |
| 21:34.48 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r42463 10/brlcad/trunk/configure.ac: tkpng ->
libtkpng |
| 21:36.08 |
brlcad |
starseeker:
okay, I'll look into it (search) |
| 21:44.48 |
starseeker |
tried to
include bu.h in search.c, but so far that doesn't seem to have done
it... |
| 21:46.58 |
brlcad |
including a
header won't usually change behavior ... just declarations and
defines |
| 21:49.05 |
brlcad |
ah, that's
what did it |
| 21:49.26 |
brlcad |
typecompare()
is a callback, e.g. for qsort() |
| 21:49.56 |
brlcad |
needs to
return >=< 0, not boolean |
| 22:04.49 |
CIA-38 |
BRL-CAD:
03brlcad * r42464 10/brlcad/trunk/src/libged/search.c: the
typecompare() callback passed to bsearch() needs to return value
<0, ==0, >0 depending on the comparison, not just a boolean.
use bu_strcmp() instead of !BU_STR_EQUAL() |
| 22:07.50 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r42465 10/brlcad/trunk/src/burst/prnt.c: #ifdef,
not #if DEBUG |
| 22:32.57 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 22:32.57 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 22:32.58 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 22:32.58 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
| 22:32.58 |
*** join/#brlcad DaveLo
(~claymore@BZ.BZFLAG.BZ) |
| 22:38.18 |
CIA-38 |
BRL-CAD:
03brlcad * r42466 10/brlcad/trunk/src/libwdb/Makefile.am: libwdb
seems to be compiling cleanly on mac and linux, so enable
enforcement of strict build |
| 22:43.49 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
| 22:51.40 |
*** join/#brlcad mafm
(~mafm@62.Red-81-32-105.dynamicIP.rima-tde.net) |
| 22:56.57 |
CIA-38 |
BRL-CAD:
03brlcad * r42467 10/brlcad/trunk/src/libged/attr.c: er, so soon?
use the new bu_strcmp() function so we properly handle null
strings. |
| 23:03.26 |
CIA-38 |
BRL-CAD:
03brlcad * r42468 10/brlcad/trunk/configure.ac: er, STRICT_FLAGS
should match the flags we actually tested for. |
| 23:25.09 |
CIA-38 |
BRL-CAD:
03brlcad * r42469 10/brlcad/trunk/src/libged/search.c:
ws |
| 23:25.50 |
CIA-38 |
BRL-CAD:
03brlcad * r42470 10/brlcad/trunk/src/ (8 files in 4
dirs): |
| 23:25.50 |
CIA-38 |
BRL-CAD: more
cases similiar to the search failure (affecting a bunch of
commands |
| 23:25.50 |
CIA-38 |
BRL-CAD:
including the likes of ls, the tedit commands, tops, and others)
where we cannot |
| 23:25.50 |
CIA-38 |
BRL-CAD: use
BU_STR_EQUAL since we actually need to use the real return value
from |
| 23:25.50 |
CIA-38 |
BRL-CAD:
bu_strcmp() instead of !BU_STR_EQUAL(). nice early
catch. |
| 00:16.47 |
``Erik |
heh, yeah,
uh, the bottie merge there took a few hours |
| 00:17.51 |
``Erik |
I imagine
I'll have to do a quick followup tomorrow along with the
"number_of_triangles" hack and backing the ray up a micron, then
see how bad I screw trunk up |
| 00:20.54 |
starseeker |
hrm |
| 00:21.31 |
starseeker |
possible
issue... |
| 00:21.52 |
starseeker |
libbn/mat.c:54: error: MAT_INIT_IDN
undeclared here (not in a function) |
| 00:26.15 |
starseeker |
tries a clean build |
| 00:29.37 |
``Erik |
did any
conflicts list? |
| 00:29.52 |
starseeker |
not in CMake
(at least not that I saw) |
| 00:29.58 |
``Erik |
during the
merge |
| 00:30.10 |
starseeker |
yeah, didn't
see any |
| 00:30.31 |
``Erik |
funky, I
always seem to get at least one |
| 00:31.00 |
starseeker |
I do get some
on occasion, usually when I've done something in the cmake branch
first and then in trunk |
| 00:31.11 |
starseeker |
yeah, libbn
builds now |
| 00:31.34 |
starseeker |
oh, bet it
was using the old copy in the build directory's include
dir |
| 00:31.40 |
starseeker |
dur |
| 00:32.47 |
CIA-58 |
BRL-CAD:
03starseeker * r42610 10/brlcad/branches/cmake/ (249 files in 76
dirs): Update cmake branch to trunk r42609 |
| 00:34.12 |
CIA-58 |
BRL-CAD:
03starseeker * r42611 10/brlcad/branches/cmake/
(include/CMakeLists.txt src/mged/CMakeLists.txt): Remove files no
longer present from CMakeLists.txt files |
| 00:43.00 |
starseeker |
brlcad: is
that new rtuif.h header supposed to be installed? |
| 00:43.39 |
``Erik |
it's the new
rt_private.h, I don't think it is |
| 00:43.53 |
starseeker |
k |
| 00:44.08 |
starseeker |
ah,
right |
| 00:44.14 |
starseeker |
in src/rt,
not include |
| 00:45.53 |
brlcad |
it's a
private header, fixed a problem |
| 00:46.18 |
starseeker |
nods - yeah, was reading the list wrong, my
bad |
| 01:00.33 |
starseeker |
interesting
I'm getting a bu_ipwd crash with the cmake build on mac |
| 01:02.41 |
brlcad |
hm, entirely
possible -- I didn't get the chance to test my fix before heading
in to the meeting |
| 01:02.56 |
brlcad |
any
particular test sequence? |
| 01:03.01 |
starseeker |
Program
received signal EXC_BAD_ACCESS, Could not access
memory. |
| 01:03.01 |
starseeker |
Reason:
KERN_PROTECTION_FAILURE at address: 0x00000000 |
| 01:03.01 |
starseeker |
0x93a266b7 in
realpath$DARWIN_EXTSN () |
| 01:03.12 |
brlcad |
realpath was
given a null |
| 01:03.17 |
starseeker |
libbu/brlcad_path.c:100 |
| 01:03.34 |
starseeker |
I don't see
how, and gdb doesn't think ipwd is null... |
| 01:04.09 |
brlcad |
hm |
| 01:04.18 |
brlcad |
might be a
difference between bsd and linux realpath() |
| 01:04.27 |
brlcad |
what does
your manual page say for the second argument? |
| 01:05.09 |
brlcad |
I pass NULL
for the result since bsd realpath() will use that as a key to
malloc and pass the result back as the return value |
| 01:05.19 |
brlcad |
the first
param shouldn't be null.. |
| 01:05.39 |
brlcad |
oh, DARWIN ..
you're on mac too.. |
| 01:05.53 |
starseeker |
ah, that
could be why - I think the proper handling of second argument being
NULL in realpath is only guaranteed by POSIX 2008 |
| 01:08.31 |
starseeker |
considered snarfing GNU's canonicalize_file_name function and
putting that into libbu, but it kinda seemed like
overkill... |
| 01:10.37 |
CIA-58 |
BRL-CAD:
03brlcad * r42612 10/brlcad/trunk/include/bu.h: check for PATH_MAX
before _MAX_PATH |
| 01:13.17 |
CIA-58 |
BRL-CAD:
03starseeker * r42613
10/brlcad/branches/cmake/src/libbu/brlcad_path.c: realpath + NULL
is not happy on Mac, apparently - will this work? |
| 01:17.39 |
starseeker |
brlcad: that
seems to work here, if you don't mind the static solution - IIRC
realpath only runs into trouble on operating systems like HURD that
have unlimited path length, and somehow I doubt we'll be worried
about running on HURD anytime soon... |
| 01:17.54 |
starseeker |
heads out |
| 01:19.40 |
CIA-58 |
BRL-CAD:
03brlcad * r42614 10/brlcad/trunk/src/libbu/brlcad_path.c: unlike
10.6 and recent linux, realpath() on Mac OS X 10.5 is not set up to
take NULL for the second paramter so pass in our path buffer and
adjust logic accordingly. |
| 01:20.50 |
brlcad |
similar
solution |
| 01:24.20 |
brlcad |
usually best
to avoid function call return values as expressions unless the
function specifically returns a boolean (e.g., isspace());
unintentional pointers and integers are common logic
bugs |
| 01:59.22 |
CIA-58 |
BRL-CAD:
03brlcad * r42615 10/brlcad/trunk/TODO: promote plate mode nurbs
since it's scheduled for Q2, create a new project section for NURBS
with added tasks for implementing implicit CSG to NURBS CSG,
documenting the new primitive, and boolean evaluation. |
| 02:15.23 |
CIA-58 |
BRL-CAD:
03brlcad * r42616 10/brlcad/trunk/TODO: expand, consolidate and
clean up the section for NMG/BoT too |
| 02:43.53 |
*** join/#brlcad yukonbob
(~bch@S0106001cf044d085.ok.shawcable.net) |
| 02:43.54 |
yukonbob |
oh
hai |
| 03:08.31 |
DX^ |
Anyone alive
that could explain to me how NURBS are rendered |
| 03:08.40 |
DX^ |
does the
program break it up into triangles? |
| 03:08.52 |
DX^ |
I don't
understand how it could otherwise show smooth surfaces |
| 03:20.48 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 03:58.11 |
starseeker |
DX^: it
doesn't break it up into triangles |
| 03:58.40 |
starseeker |
it builds a
surface tree, which provides an initial guess for a hit point which
is then iterated to a solution |
| 03:59.15 |
starseeker |
we'll get
triangles eventually for tessellation and shaded displays, but the
are only an approximation - the NURBS surface itself is more
accurate |
| 04:21.38 |
starseeker |
brlcad:
doesn't that patch return the success/fail value of realpath
instead of the result in buffer? |
| 04:24.11 |
starseeker |
oh, nevermind
- I see |
| 04:29.31 |
starseeker |
nifty -
realpath returns what you need as the result. not bad |
| 04:30.53 |
CIA-58 |
BRL-CAD:
03starseeker * r42617 10/brlcad/branches/cmake/ (5 files in 4
dirs): Sync to trunk 42616 (mostly, brlcad_path.c patch is
approximate since the Windows version of realpath is unaddressed in
trunk). |
| 05:16.25 |
CIA-58 |
BRL-CAD:
03brlcad * r42618 10/brlcad/trunk/TODO: little section for
STEP-related tasks |
| 08:16.33 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 09:13.26 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.131.143) |
| 09:13.37 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:48.06 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 12:18.21 |
starseeker |
glares at falling snow and unplowed roads |
| 12:31.08 |
starseeker |
hmm...
slashdot redesigned again |
| 12:35.01 |
starseeker |
gets introduced to the Stylish Firefox plugin...
nifty |
| 13:12.24 |
CIA-58 |
BRL-CAD:
03starseeker * r42619 10/brlcad/trunk/src/tclscripts/
(archer/Archer.tcl mged/man.tcl): Tweak man page viewer to work
in-build-dir |
| 13:47.07 |
brlcad |
<PROTECTED> |
| 13:47.28 |
brlcad |
I'd think the
embedded path separators will cause problems on windows |
| 13:47.36 |
brlcad |
that's what
file join is supposed to resolve |
| 13:47.42 |
DaveLo |
Mernin
all |
| 13:47.53 |
brlcad |
howdy
DaveLo |
| 13:48.12 |
DaveLo |
Hows you?
take the test yet? |
| 13:49.40 |
brlcad |
not yet,
still have another week or two of studying |
| 13:49.55 |
DaveLo |
ah,
okie. |
| 13:50.02 |
CIA-58 |
BRL-CAD:
03davidloman * r42620 10/rt^3/trunk/docs/ (4 files): Adding in some
.psd's for the wiki graphics. |
| 13:50.24 |
DaveLo |
stares at the falling snow and is eager to get out there
later and make the Ultimate Snow Fortress |
| 14:01.48 |
starseeker |
brlcad: ok, I
can try that |
| 14:06.11 |
CIA-58 |
BRL-CAD:
03starseeker * r42621 10/brlcad/trunk/src/tclscripts/
(archer/Archer.tcl mged/man.tcl): Don't assume '/' for dir
separators |
| 14:08.39 |
starseeker |
ah, the mged
one was just a typo (not sure why it didn't show up before...)
archer wasn't using file join where it needed to |
| 14:09.29 |
CIA-58 |
BRL-CAD:
03starseeker * r42622 10/brlcad/branches/cmake/ (5 files in 4
dirs): Update cmake branch to trunk r42621 |
| 14:39.20 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.146.62) |
| 14:39.20 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:41.48 |
DaveLo |
``Erik: why
is TCL needed in rt3? |
| 14:45.33 |
brlcad |
DaveLo: tcl.h
is included by raytrace.h and bu.h |
| 14:46.09 |
brlcad |
hoping we can
eliminate that inclusion at some point in the future, but
decoupling from tcl in the public API is a job in
itself |
| 14:46.40 |
DaveLo |
ah, i
see. |
| 14:47.29 |
DaveLo |
is the tcl
libsj included in the windows brlcad binaries install?
|
| 14:47.49 |
brlcad |
should
be |
| 14:47.57 |
brlcad |
won't run
without em |
| 14:48.09 |
DaveLo |
thats what I
thought. |
| 14:48.29 |
DaveLo |
for
somereason, i was building rt3 just fine, but now that there is a
findTCL.cmake in the works, its failing. |
| 14:48.33 |
DaveLo |
:/ |
| 14:49.57 |
brlcad |
might have
been pulling some system tcl.h |
| 14:50.25 |
DaveLo |
not likely,
as i don't have tcl.h on my windows system ;) |
| 14:50.35 |
brlcad |
hm, that's
curious then |
| 14:51.12 |
brlcad |
not only why
it's now needing it, but how it worked before too |
| 14:51.34 |
DaveLo |
i know cmake
can find the brlcad include and libs, i just don't think the cmake
find is smart enough to dive down in to a subdir of
brlcad/include |
| 14:52.02 |
DaveLo |
I think it
was working before because if cmake can find bu.h, then bu.h knows
where the tcl headers |
| 14:52.05 |
DaveLo |
are |
| 14:52.28 |
DaveLo |
cmake,
however, doesn't use bu.h to gain a clue where the tcl headers
are. |
| 14:52.29 |
DaveLo |
:/ |
| 14:54.42 |
DaveLo |
bah, that's
too deep of a rabit hole to dive in atm :/, i'll leave windows till
later i guess. |
| 14:56.13 |
brlcad |
bu.h doesn't
know, it just does a #include "bu.h" |
| 14:56.16 |
brlcad |
er,
tcl.h |
| 14:58.07 |
brlcad |
so something
else, something really basic, is going on |
| 14:59.30 |
DaveLo |
likely
something else. :/ |
| 15:01.47 |
brlcad |
fwiw, include
paths are build system trivialities, any dev should be able to
diagnose/understand/override fix with ease |
| 15:02.39 |
brlcad |
otherwise
it's like a builder not knowing how a power drill works
:) |
| 15:03.48 |
DaveLo |
heh, well in
that case, Im still learning about the power drills, so don't make
fun =P |
| 15:04.31 |
brlcad |
not making
fun, just saying "don't fear the power drill" |
| 15:04.51 |
brlcad |
or treat it
like it's untouchable black magic that will take a long time to
figure out |
| 15:04.55 |
``Erik |
dlo: tcl is
required for bu.h |
| 15:05.16 |
``Erik |
when using a
system that doesn't have tcl.h in /usr/include or
/usr/brlcad/include, it was failing |
| 15:07.01 |
``Erik |
*readreadread* heh, yeh |
| 15:07.08 |
brlcad |
cmake adds a
little extra complexity, but it's akin to adding a pneumatic
compressor to your drill .. it's still a drill though
;) |
| 15:07.19 |
DaveLo |
well wait...
if tcl.h is installed into a non standard location, it was
failing? |
| 15:07.25 |
``Erik |
probably need
a -DTCL_INCLUDE_DIR=C:\some\path\to\brlcad\include |
| 15:07.48 |
DaveLo |
either of you
two going to be in on Friday? |
| 15:07.57 |
``Erik |
the problem
was that it was failing when tcl was installed to the standard
include path... not the path that linux and BRL-CAD
expect |
| 15:08.22 |
DaveLo |
what
'standard include path' are you talking about/ |
| 15:08.24 |
DaveLo |
? |
| 15:08.30 |
``Erik |
I have no
plans to not be in on friday... depends on weather |
| 15:08.33 |
``Erik |
/usr/local/ |
| 15:09.43 |
``Erik |
mac and linux
both abuse the system header directory for user packages like
package managed tcl |
| 15:14.11 |
``Erik |
O.O gtk3?
hmmm |
| 15:35.18 |
DaveLo |
configure
--enable-all or configure --enable-everything |
| 15:35.21 |
DaveLo |
i cannot
remember |
| 15:50.48 |
brlcad |
they're
aliases for the same flag if it was either of those |
| 17:27.39 |
DaveLo |
5" on the
ground so far. Second wave is coming in a few hours! |
| 17:45.25 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.143.147) |
| 17:45.25 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:26.48 |
DaveLo |
Okay, round
one is shoveled. Now, bring on round two! |
| 18:50.13 |
CIA-58 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2446 10/wiki/GSNet_String: |
| 18:55.03 |
CIA-58 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2447 10/wiki/GSNet_String: Update table styling |
| 18:56.10 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 18:57.43 |
CIA-58 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2448 10/wiki/GSNet_String: Adjust table width |
| 19:02.00 |
CIA-58 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2449 10/wiki/GeometryServiceNetworkProtocol: Fixed
headline |
| 19:30.12 |
CIA-58 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2450 10/wiki/NetMsgTypes: headline fixes and spacing. |
| 19:49.33 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.143.147) |
| 19:49.33 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:07.41 |
*** join/#brlcad CIA-53
(~CIA@208.69.182.149) |
| 20:15.24 |
CIA-53 |
BRL-CAD:
03brlcad * r42623 10/brlcad/trunk/src/libged/ls.c: eliminate dead
code |
| 20:18.57 |
*** join/#brlcad Ralith
(~ralith@d142-058-078-138.wireless.sfu.ca) |
| 20:22.52 |
CIA-53 |
BRL-CAD:
03brlcad * r42624 10/brlcad/trunk/src/librt/db_lookup.c: calloc our
ptbl so we're initialized to zero |
| 20:34.59 |
CIA-53 |
BRL-CAD:
03brlcad * r42625 10/brlcad/trunk/src/librt/db_lookup.c: v4
geometry database do not use d_major_type and d_minor_type, so
zero-set accordingly as a preventive measure. |
| 20:39.47 |
brlcad |
https://github.com/mcneel/rhinocommon |
| 20:40.04 |
brlcad |
(they just
released another sdk as open source) |
| 20:41.37 |
brlcad |
it's the C#
portion of Rhino 5.0's new cross-platform SDK |
| 20:47.06 |
CIA-53 |
BRL-CAD:
03brlcad * r42626 10/brlcad/trunk/src/conv/asc/g2asc.c: do not
check values directly. _GLOBAL is merely an attribute-only
object. |
| 22:17.18 |
*** join/#brlcad Ralith
(~ralith@142.58.92.37) |
| 22:20.43 |
*** join/#brlcad yukonbob_
(~bch@20-144.wireless.kamloops.net) |
| 22:20.49 |
yukonbob_ |
hello,
#brlcasd |
| 22:20.56 |
yukonbob_ |
#brlcad,
even. |
| 22:25.04 |
yukonbob_ |
png.h has 2
diff't prototypes for PNG_EXPORT(). |
| 22:25.44 |
yukonbob_ |
or... 1s; /me
reviews |
| 22:29.20 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
| 22:29.20 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 22:38.13 |
yukonbob_ |
:P nn ---
conflicting header files from diff't versions of
libpng. |
| 22:38.25 |
yukonbob_ |
*nm |
| 22:51.02 |
yukonbob_ |
q: how far
along in the build process is one if asc2g conversions are
running? |
| 23:16.10 |
brlcad |
http://itmanagement.earthweb.com/osrc/article.php/3922041/50-Open-Source-Applications-for-Sci-Tech-Education.htm |
| 23:16.22 |
brlcad |
yukonbob_:
basically the build is done |
| 23:16.39 |
brlcad |
all of the
sources have compiled by that point |
| 23:23.08 |
yukonbob_ |
brlcad:
congratulate me, then. I've got brlcad built on netbsd for first
time in ~2 years. |
| 23:23.28 |
yukonbob_ |
then fails,
but I think I know why. I'll have some patches
forthcoming. |
| 23:25.44 |
CIA-53 |
BRL-CAD:
03brlcad * r42627 10/brlcad/trunk/TODO: |
| 23:25.44 |
CIA-53 |
BRL-CAD: pull
up annotation primitive since it's soon. also relaly need to
upgrade the |
| 23:25.44 |
CIA-53 |
BRL-CAD:
back-end svn repo so branches can be tracked better (especially
since there is a |
| 23:25.44 |
CIA-53 |
BRL-CAD:
major merge coming soon). push down dbcp/merg and exporting all
top-level |
| 23:25.44 |
CIA-53 |
BRL-CAD:
objects in the converters. |
| 23:25.44 |
brlcad |
excellent |
| 23:25.53 |
brlcad |
it's been a
while since I've done a netbsd build myself |
| 23:27.07 |
yukonbob_ |
I've been
working on this now for last ~24 hours (not non-stop :) ) and think
I've got the roadblocks solved for this particlar case... which is
NetBSD -current, Tcl8.6b, and some other oddities. |
| 23:28.53 |
yukonbob_ |
runtime will
be another test itself... I'm not intimately familiar w/ itcl/itk,
and it's a major-version bump over what brl-cad ships with... so
that's be interesting. |
| 23:32.26 |
CIA-53 |
BRL-CAD:
03brlcad * r42628 10/brlcad/trunk/src/libged/ls.c: |
| 23:32.26 |
CIA-53 |
BRL-CAD: fix
a bug with the ls command where it was printing NULL or garbage for
the |
| 23:32.26 |
CIA-53 |
BRL-CAD:
object type if you requested an ls -la long listing. this only
occurred for v4 |
| 23:32.26 |
CIA-53 |
BRL-CAD:
geometry databases but was due to an assumption in the code that
d_minor_type is |
| 23:32.26 |
CIA-53 |
BRL-CAD: a
suitable index into the rt_functab[] (which it's not). other
commands need |
| 23:32.26 |
CIA-53 |
BRL-CAD:
fixing too. |
| 23:44.02 |
CIA-53 |
BRL-CAD:
03brlcad * r42629 10/brlcad/trunk/src/libged/attr.c: attributes
aren't valid for v4, but don't use d_minor_type as an index into
rt_functab[] regardless. |
| 23:53.55 |
yukonbob_ |
default
installation == /usr/local/*? |
| 23:58.09 |
yukonbob_ |
sees is /usr/brlcad |
| 00:05.48 |
CIA-53 |
BRL-CAD:
03brlcad * r42630 10/brlcad/trunk/src/libged/ls.c: simplify. even
though this is libged, there's no compelling reason to use
GED_DB_GET_INTERNAL() here since it assumes a GED_OK/ERROR return
value if the get fails. we don't actually care much if the get
fails. |
| 00:06.16 |
CIA-53 |
BRL-CAD:
03brlcad * r42631 10/brlcad/trunk/src/libged/wdb_obj.c: match ls.c
and attr.c files. ugh, duplication. when can this file
die? |
| 00:06.55 |
starseeker |
brlcad: hmm -
don't know how much use rhinocommon will be as C# - don't see a
license either, unless I'm missing something |
| 00:10.42 |
*** part/#brlcad yukonbob_
(~bch@20-144.wireless.kamloops.net) |
| 00:12.45 |
CIA-53 |
BRL-CAD:
03starseeker * r42632 10/brlcad/branches/cmake/ (8 files in 5
dirs): Update cmake branch to trunk r42631 |
| 00:18.58 |
starseeker |
brlcad: what
do you want to do about needing windows.h for that Win version of
the realpath functionality? |
| 00:29.25 |
brlcad |
starseeker:
rhinosommon didn't seem very useful to us at all, was just
interesting that they're expanding their opensourceness |
| 00:29.38 |
brlcad |
their press
release was emphasizing that angle |
| 00:29.59 |
brlcad |
starseeker:
condtionally include windows.h in the files that call
realpath? |
| 00:30.19 |
CIA-53 |
BRL-CAD:
03starseeker * r42633 10/brlcad/trunk/src/other/togl/ (336 files in
16 dirs): togl is extradisted in trunk anyway, so stick the cmake
branch version in to minimize differences |
| 00:34.11 |
starseeker |
brlcad: I
think that's what I did initially? unless I misread, you didn't
seem happy about a system header in libbu |
| 00:41.40 |
starseeker |
what the
heck... what happened to the togl directory? |
| 00:47.42 |
starseeker |
checks out other again... |
| 00:50.20 |
starseeker |
there we
go |
| 01:16.53 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 01:36.27 |
epileg |
brlcad:
ping |
| 02:08.48 |
*** join/#brlcad yukonbob
(~bch@S0106002129e399fc.ok.shawcable.net) |
| 02:08.54 |
yukonbob |
hello,
#brlcad |
| 02:09.24 |
CIA-53 |
BRL-CAD:
03starseeker * r42634 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/CompilerFlags.cmake): Start trying to hammer the C/CXX
flags logic into shape. More to do here, but getting better (should
actually be using more of the flags now...) |
| 02:09.27 |
starseeker |
yukonbob:
howdy :-) |
| 02:09.32 |
yukonbob |
starseeker:
:) |
| 02:09.40 |
starseeker |
so you have
things running with tcl/tk 8.6? |
| 02:09.45 |
yukonbob |
starseeker:
indeed. |
| 02:09.50 |
starseeker |
trunk? |
| 02:09.55 |
yukonbob |
first time
I've had brlcad running natively on this box in ~2years |
| 02:10.01 |
yukonbob |
<PROTECTED> |
| 02:10.06 |
starseeker |
heh |
| 02:10.16 |
starseeker |
are you using
trunk or an older version? |
| 02:10.20 |
yukonbob |
fwiw that
fscking *sucked* *sucked* *sucked* *sucked* *sucked*. |
| 02:10.45 |
starseeker |
8.5 gives us
modern stuff like the new tree widget |
| 02:11.02 |
yukonbob |
moving to 8.5
while it was in beta had me fall off the wagon. |
| 02:11.15 |
starseeker |
ah, back in
the day |
| 02:11.24 |
starseeker |
(was gonna
say, 8.5 has been stable for a while...) |
| 02:11.27 |
yukonbob |
not trying to be a drama queen, just stating the
facts. |
| 02:11.55 |
starseeker |
yukonbob: you
should be happy then we haven't gone leaping onto the 8.6 bandwagon
yet :-P |
| 02:12.01 |
yukonbob |
was helping push the boundaries of tcl 8.4 back in the day
:P |
| 02:12.16 |
yukonbob |
starseeker:
what's the holdup -- I'm here now!!!1! |
| 02:12.24 |
yukonbob |
;) |
| 02:12.30 |
starseeker |
what were the
issues with 8.6? |
| 02:12.37 |
starseeker |
the one
attempt I made didn't go so well |
| 02:13.06 |
yukonbob |
I *just*
fired up mged... and have done *some* runtime patching, but haven't
tested exhaustively. |
| 02:13.14 |
starseeker |
nods |
| 02:13.18 |
starseeker |
further than
I got |
| 02:13.24 |
starseeker |
are you using
trunk? |
| 02:13.27 |
yukonbob |
y |
| 02:13.42 |
yukonbob |
I've been
running trunk for.... maybe a year now? |
| 02:13.48 |
yukonbob |
on NetBSD cvs
-head. |
| 02:13.49 |
starseeker |
cool -
hopefully using only package require for things like itcl/itk
helped... |
| 02:14.04 |
yukonbob |
heh -- thats
one of the things I patched ;) |
| 02:14.17 |
starseeker |
hmm? you
went back to the C api? |
| 02:14.57 |
yukonbob |
no, but had
to adjust for version #s |
| 02:15.01 |
starseeker |
ah |
| 02:15.28 |
starseeker |
when I tried
8.6 we were still talking to itcl/itk at the C level... Something
Wasn't Happy |
| 02:15.52 |
yukonbob |
anyway...
it's literally been a few years since I've been in mged -- I'm
going to re-introduce myself to it, and shake-out bugs as they
present themselves |
| 02:16.05 |
starseeker |
wasn't urgent
enough for me to dig deep, since package require was obviously a
better way and the main benefit of 8.6 was the Cocoa backend on
Mac |
| 02:16.13 |
starseeker |
welcome back
:-) |
| 02:16.20 |
yukonbob |
ya, thanks
;) |
| 02:16.24 |
starseeker |
you might
check out archer - it's had a lot of work done |
| 02:16.46 |
yukonbob |
is going to get his name back into the
changelogs... |
| 02:17.00 |
yukonbob |
archer !=
tcl/tk, correct? |
| 02:17.28 |
yukonbob |
ya -- when I
was last using brlcad, I think archer was in design phase, or maybe
"Hey, I've got an idea' phase. |
| 02:18.39 |
starseeker |
no, archer is
tcl/tk |
| 02:18.46 |
CIA-53 |
BRL-CAD:
03starseeker * r42635 10/brlcad/branches/cmake/CMakeLists.txt: Uh,
whoops - add the flags if the build type IS set, not when it
isn't... |
| 02:18.48 |
starseeker |
one of the
drivers for using 8.5, actually |
| 02:19.12 |
starseeker |
it's not all
the way there yet, but there's some cool new stuff |
| 02:19.18 |
starseeker |
tree widget
is especially nifty |
| 02:19.36 |
yukonbob |
cool. |
| 02:20.41 |
yukonbob |
Tcl is what
brought me to brl-cad in the first place, and I haven't lost my
love of Tcl... the joy of brl-cad is what kept me hacking to get it
back working, but I'm exceptionally interested in Tcl/BRL-CAD, and
C/BRL-CAD |
| 02:21.37 |
yukonbob |
holy fsck, I
don't remember a single mged-specific command :P |
| 02:30.02 |
starseeker |
remember
where the quick reference card is? :-P |
| 02:30.03 |
CIA-53 |
BRL-CAD:
03starseeker * r42636
10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Better -
don't need if wrappers now, fix spacing |
| 02:31.46 |
yukonbob |
grabbing mged tutorial, documentation... |
| 02:32.30 |
CIA-53 |
BRL-CAD:
03starseeker * r42637
10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Er - wrap
the message so it doesn't blather every time |
| 02:36.21 |
yukonbob |
ahhhhhh...
nice. |
| 02:43.11 |
yukonbob |
thank $deity
there's restraint and good sense wrt display and interface on
brlcad... |
| 02:43.40 |
yukonbob |
my screen
happens to be slow, but the wireframe display and kb controls make
everything still so easy to manage... |
| 02:44.24 |
yukonbob |
computers may
be 100x faster than they were $x years ago, but there are always
"resource constrained" systems, or just people (like me) who want
to pretent they're one one... |
| 02:52.36 |
CIA-53 |
BRL-CAD:
03starseeker * r42638 10/brlcad/branches/cmake/CMakeLists.txt:
enable optimized flags for Release build, and warn if they are
disabled - also set up 64 bit flag for MSVC, although this is
untested and the CompilerFlags.cmake file doesn't yet incorporate
MSVC flags (it should, TODO) |
| 02:53.01 |
starseeker |
much
better |
| 03:08.08 |
CIA-53 |
BRL-CAD:
03starseeker * r42639 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/CompilerFlags.cmake): Get most of the remaining summary
report entries functioning, although need to check what compilation
progress means in configure.ac. Also will need to re-sync
warning/strict flag logic to match new autotools
settings. |
| 03:28.50 |
CIA-53 |
BRL-CAD:
03starseeker * r42640 10/brlcad/branches/cmake/CMakeLists.txt:
Enable the CMake counterpart to the verbose output option. Also,
finally turn off the static libraries when doing a debug build
unless they're specifically requested (non MSVC builds) |
| 03:34.04 |
yukonbob |
? no more
"tor" in mged? |
| 03:45.41 |
brlcad |
there's still
torii |
| 03:46.24 |
epileg |
hello
brlcad |
| 03:46.28 |
brlcad |
howdy
epileg |
| 03:47.14 |
yukonbob |
re-familiarizing self w/ mged... I think I'll have to work
through tutorial briefly front-> back :} |
| 03:47.47 |
yukonbob |
brlcad: I've
*finally* got a running instance here again... happy days
;) |
| 03:48.12 |
brlcad |
great |
| 03:48.20 |
brlcad |
going to
write some code then? |
| 03:48.29 |
yukonbob |
yes. |
| 03:48.33 |
brlcad |
fantastic |
| 03:48.38 |
yukonbob |
I've already
got some patches for 8.6 |
| 03:48.50 |
yukonbob |
...and some
cross-platform tweaks for consideration. |
| 03:49.23 |
brlcad |
can't wait to
see them |
| 03:49.57 |
yukonbob |
and some
features that I've had since 7.x that are still
applicable... |
| 03:50.19 |
brlcad |
there's now
also a slew of "contributor quickies" that are meant to be tiny
projects only lasting a few days, to help someone get
emmersed |
| 03:50.22 |
brlcad |
http://brlcad.org/wiki/Contributor_Quickies |
| 03:51.09 |
brlcad |
slowly
expanding that list as topics come up |
| 03:51.50 |
yukonbob |
nods. |
| 03:52.14 |
yukonbob |
well, looking
forward to working w/ you again :) it's been a long
time. |
| 03:52.28 |
brlcad |
yeah, it has
been a while |
| 03:53.20 |
yukonbob |
2 or three
years, off top of head :P |
| 03:54.54 |
yukonbob |
needs to update hub for new decade ;P |
| 03:57.08 |
CIA-53 |
BRL-CAD:
03brlcad * r42641 10/brlcad/trunk/src/librt/db_float.c:
ws |
| 03:58.59 |
yukonbob |
wow... rt is
fast |
| 04:00.13 |
yukonbob |
(though I
crashed it on first try; I'll try to remember (and bother)) to keep
logs/fixes of problems... |
| 04:02.40 |
CIA-53 |
BRL-CAD:
03starseeker * r42642 10/brlcad/branches/cmake/src/other/togl/
(src/CMakeLists.txt tools/genStubs.tcl): |
| 04:02.41 |
CIA-53 |
BRL-CAD: Fix
togl build to only re-build on re-run of CMake, which is inevitable
because |
| 04:02.41 |
CIA-53 |
BRL-CAD:
we're handling header template generation with CMake. This tweak,
however, |
| 04:02.41 |
CIA-53 |
BRL-CAD:
results in proper termination instead of regenerating the header
with every make |
| 04:02.41 |
CIA-53 |
BRL-CAD:
call. |
| 04:02.53 |
brlcad |
epileg: sure,
usually :) |
| 04:02.56 |
CIA-53 |
BRL-CAD:
03brlcad * r42643 10/brlcad/trunk/ (doc/deprecation.txt
include/db.h): rt_fastf_float(), rt_mat_dbmat() and rt_dbmat_mat()
are deprecated since they pertain to old v4 file i/o and are
platform endian dependent. |
| 04:04.33 |
CIA-53 |
BRL-CAD:
03brlcad * r42644 10/brlcad/trunk/doc/deprecation.txt: add the
version number for the other 7.18 deprecations |
| 04:06.27 |
epileg |
to build
debian packages with sh/make_deb.sh is not so dificult but there is
a problem, if You are in a 64 bit platform, it will create just hte
64 bit and non-architecture dependents packages |
| 04:07.53 |
epileg |
is this a
problem brlcad? |
| 04:07.55 |
brlcad |
epileg: well
right now it doesn't really do anything, right? ;) |
| 04:08.02 |
epileg |
yes |
| 04:08.11 |
brlcad |
so it's an
improvement ;) |
| 04:08.15 |
CIA-53 |
BRL-CAD:
03starseeker * r42645 10/brlcad/branches/cmake/TODO.cmake: Archer
now runs from the build dir. |
| 04:09.53 |
epileg |
ok, then, and
if You are agree, we can try to create the deb packages just in to
the /usr/brlcad/ directory |
| 04:10.54 |
brlcad |
yeah, the
make_deb.sh script should be like our other non-package-management
system binary distributions, just building an --enable-all
dependency-free build that can be posted up for users |
| 04:11.19 |
CIA-53 |
BRL-CAD:
03starseeker * r42646 10/brlcad/branches/cmake/ (5 files in 5
dirs): Update cmake branch to trunk r42645 |
| 04:11.53 |
brlcad |
ideally, we'd
post a 32-bit and 64-bit verison, but you've got a lot of room to
decide how to manage things best since you're maintaining that
platform |
| 04:13.00 |
brlcad |
epileg: if
you've not yet read it, you should read "NAMING A BINARY RELEASE"
and "MAKING A RELEASE" in the HACKING file |
| 04:13.14 |
epileg |
ok |
| 04:13.41 |
brlcad |
just to be
familiar with the usual release steps we take for other
builds |
| 04:13.54 |
epileg |
aha |
| 04:14.36 |
brlcad |
the only part
not documented there is that some platforms use a
--prefix=/usr/brlcad/rel-7.18.0 and symbolic links are created in
/usr/brlcad after install |
| 04:14.47 |
brlcad |
that way
multi-version installs work |
| 04:15.44 |
epileg |
so, to do
that in debian like systems, We must put the version as a par of
the name |
| 04:16.00 |
epileg |
part* |
| 04:16.23 |
brlcad |
what do you
mean? |
| 04:16.50 |
brlcad |
it's not the
same convention as /usr/brlcad-7.18.0 |
| 04:16.54 |
brlcad |
that'd
suck |
| 04:16.56 |
epileg |
ordinary
package: brlcad_7.18.0-1_i386.deb |
| 04:17.03 |
brlcad |
ah, the file
name, that's fine |
| 04:17.14 |
brlcad |
that's
actually what NAMING A BINARY RELEASE talks about |
| 04:17.24 |
brlcad |
there's a
specific format we try to make most of them match |
| 04:17.34 |
epileg |
not just the
file name but the project name |
| 04:18.17 |
brlcad |
are you
referring to what apt does or .deb files in general? |
| 04:18.30 |
brlcad |
I know apt
has it's own rules, but it didn't sound like you were trying to
address apt |
| 04:20.11 |
epileg |
exactly, in
debian You can only have installed one release of a project at the
same time |
| 04:23.03 |
brlcad |
mm,
okay |
| 04:23.08 |
brlcad |
that's fine,
the /usr/brlcad it is then |
| 04:23.18 |
brlcad |
s/the /then
/ |
| 04:25.42 |
epileg |
one question,
simbolic links are overwritten with the last
installation? |
| 04:27.49 |
CIA-53 |
BRL-CAD:
03starseeker * r42647 10/brlcad/trunk/ (4 files in 4 dirs): Put the
archer.ico file where it belongs |
| 04:28.27 |
brlcad |
with multiple
version installs, yes usually .. so the last installed is always
"default" yet you can get to any version |
| 04:29.03 |
epileg |
well, this is
not allowed by apt too :-/ |
| 04:29.04 |
brlcad |
note that the
symlinks wouldn't necessarily have to be bundled files, they could
be a post-install script |
| 04:29.56 |
epileg |
well, no
problem like this |
| 04:31.05 |
brlcad |
more
important to be reliably available and well integrated (like your
other usability improvements) |
| 04:31.40 |
brlcad |
multi-versions is for stand-alone binary
installs -- if people really want that behavior, they should be
able to download one of the other linux binaries |
| 04:31.52 |
brlcad |
so not a big
deal |
| 04:31.54 |
epileg |
sure |
| 04:33.38 |
epileg |
about the
package name, can I keep the debian style on it? :-) |
| 04:34.22 |
brlcad |
from what you
wrote, it already is almost a match |
| 04:34.56 |
brlcad |
only
difference would be to prefer the project long name instead of the
short name, unless there was a technical limitation |
| 04:35.50 |
brlcad |
i.e.,
BRL-CAD_7.18.0-1_i386.deb |
| 04:37.12 |
yukonbob |
brlcad: OK --
i'm being lazy -- what's cmd to select an obj from mged (using kb
cmds to mged prompt) |
| 04:37.15 |
yukonbob |
? |
| 04:37.52 |
brlcad |
yukonbob:
depends if it's a primitive or not, sed or oed |
| 04:38.08 |
yukonbob |
ah -- those
are familiar |
| 04:38.13 |
yukonbob |
brlcad: thx
;) |
| 04:38.15 |
brlcad |
those two
have different syntax |
| 04:38.21 |
yukonbob |
it'll all
come back. |
| 04:38.44 |
yukonbob |
is one of those guys who doesn't like to have to use
mouse. |
| 04:39.51 |
CIA-53 |
BRL-CAD:
03brlcad * r42648 10/brlcad/trunk/TODO: sed+oed, right hand
begone |
| 04:39.54 |
brlcad |
then you
should implement the 'select' command, it's on our todo list
:) |
| 04:40.04 |
brlcad |
highly useful
command for keyboard modelers |
| 04:40.40 |
yukonbob |
will look into it. |
| 04:41.03 |
yukonbob |
after he
finds out how to get out of 'sed' mode... (but not *immediately*
after) ;) |
| 04:41.14 |
brlcad |
"reject" |
| 04:41.18 |
brlcad |
"accept" |
| 04:42.20 |
yukonbob |
oh hey -- you
mentioned call for papers other week... did I ask if was for
something specific, or you're just collecting material? |
| 04:43.23 |
brlcad |
doesn't recall mentioning a call for papers
recently |
| 04:44.23 |
yukonbob |
you asked if
I'd write up something -- (but wasn't a specific request) --
must've been for general tutorial library or such... |
| 04:48.27 |
brlcad |
well, there
are the quickie documentation ideas |
| 04:48.58 |
brlcad |
and there is
http://brlcad.org/wiki/Community_Publication_Portal |
| 04:49.05 |
brlcad |
which has
more ideas pending publication |
| 04:50.44 |
yukonbob |
will familiarize self w/ outstanding issues/requests over
next few weeks... |
| 04:50.46 |
brlcad |
``Erik: on
that same note, any possibility you'd write up a brief draft on the
adrt/libtie integration work -- doesn't have to be fancy or
finished, I can wordsmith it, but something that describes what you
did, why, basic results .. the same stuff you were talking about
yesterday would be perfect |
| 04:50.50 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 04:51.32 |
brlcad |
yukonbob: I
wouldn't dwell too much on outstanding issues -- there are hundreds
-- more useful to just pick one issue and try to fix it |
| 04:52.21 |
brlcad |
otherwise,
you could be familiarizing for months and never actually get to
anything useful |
| 04:52.41 |
yukonbob |
oh indeed...
I won't dwell --- I'm familar w/ the project (and my interests), so
I'll marry the two -- I'm just rusty atm ;) |
| 04:53.00 |
brlcad |
pretty much
*anything* in the TODO or BUGS file or Quickies page or publication
page |
| 04:54.17 |
epileg |
brlcad: what
do You prefer, four packages or just one? |
| 04:54.48 |
brlcad |
epileg: which
four? |
| 04:55.06 |
CIA-53 |
BRL-CAD:
03starseeker * r42649 10/brlcad/branches/cmake/ (8 files in 7
dirs): Get cmake branch a bit closer to trunk |
| 04:55.55 |
epileg |
brlcad-data,
brlcad-bin, brlcad-dev and brlcad-doc |
| 04:56.02 |
CIA-53 |
BRL-CAD:
03starseeker * r42650 10/brlcad/trunk/src/libbu/dirname.c: Pull in
the change from cmake to make dirname a bit more cross
platform |
| 04:57.02 |
CIA-53 |
BRL-CAD:
03starseeker * r42651 10/brlcad/trunk/src/ (9 files in 6 dirs):
Various cmake branch tweaks to bat files, tcl scripts - also remove
some WIN32 hacks. |
| 04:59.26 |
brlcad |
yukonbob:
here's a great one to start with |
| 04:59.30 |
brlcad |
"let the cp
command take multiple arguments for simultaneously creating
multiple named copies" |
| 05:00.15 |
brlcad |
cp command is
src/libged/copy.c |
| 05:00.19 |
yukonbob |
ie: cp
existing1 new1 new2 new3 new4? |
| 05:00.36 |
brlcad |
exactly |
| 05:03.39 |
yukonbob |
oh noes ---
is there a reason "animate" cmd is spelled "animmate"? |
| 05:05.02 |
epileg |
brlcad:
brlcad-data, brlcad-bin, brlcad-dev and brlcad-doc |
| 05:06.00 |
epileg |
brlcad: this
is the actual deb packaging distribution made by Manuel |
| 05:18.33 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.40.92) |
| 05:18.37 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:19.05 |
CIA-53 |
BRL-CAD:
03starseeker * r42652 10/brlcad/trunk/configure.ac: manuals/archer
isn't there anymore |
| 05:22.23 |
CIA-53 |
BRL-CAD:
03starseeker * r42653 10/brlcad/trunk/doc/html/manuals/Makefile.am:
update manuals/Makefile.am too |
| 05:30.33 |
yukonbob |
is there a
[red] for editing params of a primitive? |
| 05:30.52 |
yukonbob |
(i.e.:
resetting a torus' radii, etc.) |
| 05:33.32 |
yukonbob |
sees ted... |
| 05:44.01 |
yukonbob |
ok -- why are
sed/ted not having the params "stick". |
| 05:44.03 |
yukonbob |
? |
| 06:38.40 |
*** join/#brlcad yukonbob
(~bch@S0106001cf044d085.ok.shawcable.net) |
| 06:38.59 |
epileg |
brlcad: I
understand that You prefer only one package, isn't it? |
| 08:48.30 |
CIA-53 |
BRL-CAD:
03ThedaHouser 07http://brlcad.org *
r2452 10/wiki/Help:Navigation: /* Sidebar */ |
| 12:19.10 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2453
10/wiki/Help:Navigation: Reverted edits by
[[Special:Contributions/ThedaHouser|ThedaHouser]] ([[User
talk:ThedaHouser|Talk]]); changed back to last version by
[[User:Sean|Sean]] |
| 12:19.29 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:ThedaHouser]] with an
expiry time of infinite (account creation disabled, e-mail
blocked): Spamming links to external sites |
| 12:21.29 |
brlcad |
epileg: that
only makes sense for managed integration, not for stand-alone .deb
files |
| 12:21.38 |
brlcad |
they can be
combined into one... |
| 12:45.54 |
epileg |
thanks
brlcad. I ask You all this things because I feel as a someone who's
nearly to "destroy" the previous deb work. That's all. |
| 12:46.28 |
epileg |
brlcad: but
if You are agree, me too. |
| 13:13.52 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 13:46.22 |
CIA-53 |
BRL-CAD:
03starseeker * r42654 10/brlcad/branches/cmake/src/ (CMakeLists.txt
libpc/CMakeLists.txt): Add CMakeLists.txt file for
libpc |
| 13:52.01 |
CIA-53 |
BRL-CAD:
03starseeker * r42655
10/brlcad/branches/cmake/src/tclscripts/mged/CMakeLists.txt: Add
botedit.tcl to the CMakeLists.txt file |
| 13:53.03 |
CIA-53 |
BRL-CAD:
03starseeker * r42656
10/brlcad/branches/cmake/src/tclscripts/archer/CMakeLists.txt: Add
DataUtils.tcl to CMakeLists.txt |
| 14:00.03 |
CIA-53 |
BRL-CAD:
03starseeker * r42657
10/brlcad/branches/cmake/include/CMakeLists.txt: Add fft.h to
header list. |
| 14:29.03 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 14:33.10 |
CIA-53 |
BRL-CAD:
03starseeker * r42658 10/brlcad/branches/cmake/src/other/ (7 files
in 7 dirs): add some headers and other files,
LIBTERM->TERMLIB |
| 14:38.53 |
CIA-53 |
BRL-CAD:
03starseeker * r42659 10/brlcad/branches/cmake/doc/docbook/lessons/
(en/CMakeLists.txt es/CMakeLists.txt): Fix a couple of docbook
target paths |
| 14:53.38 |
CIA-53 |
BRL-CAD:
03starseeker * r42660 10/brlcad/branches/cmake/sh/CMakeLists.txt:
Add conversion.sh to the scripts list |
| 14:58.03 |
CIA-53 |
BRL-CAD:
03starseeker * r42661
10/brlcad/branches/cmake/src/libpc/CMakeLists.txt: Copy/paste
error |
| 15:04.41 |
CIA-53 |
BRL-CAD:
03starseeker * r42662 10/brlcad/trunk/doc/ (4 files in 2 dirs): Not
sure how far it got, but VolIV in docbook now has a 'correct' place
to go, so put it there. |
| 15:07.13 |
CIA-53 |
BRL-CAD:
03starseeker * r42663 10/brlcad/trunk/ (configure.ac
doc/Makefile.am doc/book/): And remove the book
directory |
| 15:16.10 |
CIA-53 |
BRL-CAD:
03starseeker * r42664
10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeIV.xml:
Point to local docbook resources |
| 15:19.35 |
CIA-53 |
BRL-CAD:
03starseeker * r42665 10/brlcad/branches/cmake/ (6 files in 4
dirs): Update cmake branch to trunk r42664 |
| 17:03.32 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
| 17:39.25 |
CIA-53 |
BRL-CAD:
03tbrowder2 * r42666 10/brlcad/trunk/src/mged/setup.c:
ws |
| 19:22.59 |
*** join/#brlcad yukonbob_
(~bch@20-144.wireless.kamloops.net) |
| 19:23.01 |
yukonbob_ |
oh
hai |
| 19:28.04 |
yukonbob_ |
q: re:
sed/ted. when I'm presented w/ objects attibutes in ted-spawned
editor, none of my changes seem to take effect. Is something basic
I'm missing? |
| 19:32.57 |
starseeker |
yukonbob_:
auugh |
| 19:33.01 |
starseeker |
this is with
trunk? |
| 19:33.15 |
starseeker |
you're saving
the text file before closing the editor? |
| 19:36.26 |
yukonbob_ |
starseeker:
heh. I know you have to ask these questions. Yes. and my computer
is plugged in and turned on. |
| 19:36.38 |
yukonbob_ |
starseeker:
is 7.18.0 |
| 19:37.38 |
yukonbob_ |
fwiw, my
remember my platform is still "unique" in the sense I'm running tcl
8.6b, and itl/itk 4, among other things. |
| 19:37.49 |
yukonbob_ |
*itcl/itk |
| 19:45.06 |
yukonbob_ |
starseeker:
let me know if you can confirm bug... |
| 19:47.59 |
yukonbob_ |
starseeker:
ping? |
| 20:46.56 |
yukonbob_ |
starseeker:
ping |
| 21:58.57 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 22:18.06 |
yukonbob_ |
starseeker:
ping -- curious to know if you see same issues re:
sed/ted. |
| 22:22.27 |
starseeker |
yukonbob_:
sorry, passed out (lot of snow shoveling) |
| 22:22.44 |
yukonbob_ |
heh |
| 22:23.05 |
yukonbob_ |
starseeker:
curious --- do you see same effect on what you'd consider to be a
stable system? |
| 22:23.18 |
starseeker |
don't mean to
seem insulting - we've had problems with both ted and red in recent
history, but thought we had them fix |
| 22:23.21 |
starseeker |
ed |
| 22:23.22 |
starseeker |
tries... |
| 22:23.24 |
yukonbob_ |
I did
something like: |
| 22:23.34 |
yukonbob_ |
make x tor
... |
| 22:23.45 |
yukonbob_ |
then: sed x;
ted |
| 22:24.06 |
yukonbob_ |
[edit],
[save], [exit]. No changes. |
| 22:24.18 |
yukonbob_ |
subsequent
"ted" indicate no changes, too. |
| 22:24.46 |
yukonbob_ |
re: insulting
-- no offence taken; likewise, I hope :) |
| 22:24.53 |
starseeker |
ah - there
was a post 7.18.0 fix to ted |
| 22:25.09 |
yukonbob_ |
starseeker:
can you point me to diff? |
| 22:25.12 |
starseeker |
'course
not |
| 22:25.15 |
starseeker |
is looking |
| 22:25.28 |
yukonbob_ |
wants his super-dumb primitives!!!1! :) |
| 22:25.56 |
starseeker |
r42276 |
| 22:28.50 |
starseeker |
it seems to
work in my 7.18.1 build (ted) |
| 22:35.45 |
CIA-53 |
BRL-CAD:
03starseeker * r42667 10/brlcad/trunk/src/mged/tedit.c: Add nano to
the list of editors we know about |
| 22:36.18 |
starseeker |
yukonbob_:
any luck? |
| 23:14.58 |
CIA-53 |
BRL-CAD:
03starseeker * r42668 10/brlcad/branches/cmake/ (3 files in 3
dirs): fill in some of the variables pkgconfig files expect - once
CMake is the main build system, need to revisit the issue of
pkgconfig |
| 23:19.10 |
yukonbob_ |
starseeker:
I'll have to try later. |
| 23:19.32 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 23:20.00 |
yukonbob_ |
but r42276
has my changes ( or collection of changes ), correct? |
| 23:23.45 |
starseeker |
those are the
changes that made ted work forme |
| 23:31.45 |
yukonbob_ |
ok; did you
observe the broken behaviour I described above in prev. (7.18.0)
code? |
| 23:33.31 |
CIA-53 |
BRL-CAD:
03starseeker * r42669
10/brlcad/branches/cmake/src/brlman/CMakeLists.txt: Get cute with
brlman - write one version out for the build bin dir that will work
locally, and put the one to be installed in
src/brlman/brlman |
| 23:35.53 |
yukonbob_ |
starseeker:
----^ |
| 23:42.32 |
starseeker |
yukonbob_:
yes - we got a bug report of ted not applying changes |
| 23:42.50 |
starseeker |
the red thing
was a bit further back - let me see if red is
working... |
| 23:44.34 |
starseeker |
seems to
accept a change here in a quick test |
| 23:46.01 |
yukonbob_ |
starseeker:
re: bug -- ok -- that's good. I'm considering my whole system
"suspect" because it's 1) quite non-standard 2) using beta software
at it's core, so to corelate events/behaviour w/ other systems is
important for me... |
| 23:46.14 |
yukonbob_ |
s/re: bug/re:
bug report/ |
| 23:55.53 |
CIA-53 |
BRL-CAD:
03starseeker * r42670 10/brlcad/trunk/src/other/jove/ (Makefile.am
jove_main.c mkversion.sh): That's an aweful lot of logic just to
set a version number, which isn't particularly important for our
uses anyway - set it to 2.1 in jove_main.c (the only place that
appears to use it) and call it done. |
| 23:56.29 |
starseeker |
yukonbob_: to
be fair, it's quite possible our new editor logic isn't happy on
that particular OS |
| 23:58.05 |
yukonbob_ |
can't imagine that would be too difficult... it's basically
an exec to a tmpfile, no? |
| 23:58.41 |
starseeker |
yes, but it's
surprisingly annoying |
| 23:58.48 |
yukonbob_ |
ie: exec
"$env(editor) $tmpfile"; # blocking call to editor |
| 23:58.53 |
yukonbob_ |
read
$tmpfile. |
| 23:59.38 |
starseeker |
take a look
at tedit.c in mged and src/libged/editit.c |
| 00:00.46 |
CIA-53 |
BRL-CAD:
03starseeker * r42671 10/brlcad/branches/cmake/ (6 files in 3
dirs): Update cmake to trunk r42670 |
| 00:28.22 |
CIA-53 |
BRL-CAD:
03starseeker * r42672 10/brlcad/branches/cmake/ (3 files in 3
dirs): sigh. jove is explicitly referenced as the editor of last
resort in other code, so go ahead and build it. wonder if this
actually works on Windows... |
| 00:40.23 |
CIA-53 |
BRL-CAD:
03starseeker * r42673
10/brlcad/trunk/src/other/libz/zconf.h.cmakein: add the fix from
41902 to zconf.h.cmakein too |
| 00:48.45 |
yukonbob_ |
starseeker:
re: jove -- in case of ted, it says it'll run "ed" by
default. |
| 00:48.59 |
yukonbob_ |
<PROTECTED> |
| 00:49.21 |
starseeker |
nods |
| 00:52.57 |
CIA-53 |
BRL-CAD:
03starseeker * r42674 10/brlcad/trunk/src/other/step/src/ (7 files
in 3 dirs): Hmm - warning flags got passed to step, which isn't
happy - maybe could ignore, but since we're maintaining the code
anyway might as well... |
| 01:00.19 |
CIA-53 |
BRL-CAD:
03starseeker * r42675 10/brlcad/branches/cmake/ (11 files in 6
dirs): |
| 01:00.19 |
CIA-53 |
BRL-CAD: OK,
this should bring the compiler flags logic pretty darn close to the
latest |
| 01:00.19 |
CIA-53 |
BRL-CAD:
autotools, with this possible exception of not isolating the
src/other dir quite |
| 01:00.19 |
CIA-53 |
BRL-CAD: well
enough - on the other hand, may be OK since it built successfully
on gentoo |
| 01:00.19 |
CIA-53 |
BRL-CAD: with
these settings. |
| 01:22.56 |
CIA-53 |
BRL-CAD:
03starseeker * r42676 10/brlcad/trunk/src/mged/dm-rtgl.c:
interp->INTERP in rtgl |
| 01:23.35 |
CIA-53 |
BRL-CAD:
03starseeker * r42677 10/brlcad/branches/cmake/ (CMakeLists.txt
src/mged/CMakeLists.txt src/mged/dm-rtgl.c): Allow the enabling of
RTGL, although things look to be a tad broken at the moment - need
to check trunk. |
| 01:49.11 |
CIA-53 |
BRL-CAD:
03starseeker * r42678 10/brlcad/trunk/src/libdm/dm-rtgl.c: (log
message trimmed) |
| 01:49.11 |
CIA-53 |
BRL-CAD: This
gets past the initial bu_malloc error, but we've got some kind of
weirdness |
| 01:49.11 |
CIA-53 |
BRL-CAD:
going on here. The RT_CK_SEGS test in recordHit fails with what
looks like a |
| 01:49.11 |
CIA-53 |
BRL-CAD: bad
magic error - printing out the seg list in debug shows a lot of
strange |
| 01:49.11 |
CIA-53 |
BRL-CAD:
looking numbers, and commenting out the check shows a lot of one
hit reports and |
| 01:49.12 |
CIA-53 |
BRL-CAD: a
visible rtgl raytrace (e.g. aside from the errors it largely
succeeds.) rtgl |
| 01:49.13 |
CIA-53 |
BRL-CAD: code
hasn't changed in quite a while, so something must have changed out
from |
| 01:50.47 |
CIA-53 |
BRL-CAD:
03starseeker * r42679 10/brlcad/branches/cmake/src/libdm/dm-rtgl.c:
Might as well sync this from trunk... |
| 01:52.55 |
CIA-53 |
BRL-CAD:
03starseeker * r42680 10/brlcad/branches/cmake/TODO.cmake: Getting
down there - add note on opensolaris |
| 01:59.08 |
CIA-53 |
BRL-CAD:
03starseeker * r42681 10/brlcad/branches/cmake/TODO.cmake: add note
about library versions in src/other builds |
| 02:02.13 |
CIA-53 |
BRL-CAD:
03starseeker * r42682 10/brlcad/branches/cmake/TODO.cmake: note
wish exe on Windows needs work |
| 02:07.20 |
brlcad |
starseeker:
you threw in a new logic scope, but didn't fix the indentation in
dm-rtgl.c |
| 02:07.31 |
starseeker |
oh,
sorry |
| 02:07.33 |
starseeker |
fixes |
| 02:07.43 |
brlcad |
and if( isn't
the right style |
| 02:08.24 |
brlcad |
otherwise,
that looks like a good fix for a category of alloc
failures |
| 02:12.34 |
CIA-53 |
BRL-CAD:
03starseeker * r42683 10/brlcad/trunk/src/libdm/dm-rtgl.c: ws,
indent |
| 02:13.13 |
brlcad |
wow, that hit
a lot more than expected |
| 02:14.31 |
brlcad |
er, yeah..
that's not right |
| 02:15.15 |
brlcad |
starseeker:
how'd you auto-indent that? |
| 02:15.24 |
starseeker |
indent.sh and
ws.sh |
| 02:15.35 |
brlcad |
huh, it looks
like it's using 2-char indent |
| 02:16.19 |
brlcad |
odd,
indent.sh here reverts your changes |
| 02:16.29 |
starseeker |
blinks |
| 02:16.33 |
brlcad |
you might
have something in your .emacs |
| 02:16.40 |
starseeker |
or
.vimrc |
| 02:16.52 |
starseeker |
go ahead and
commit - I won't argue |
| 02:17.10 |
starseeker |
is more concerned about what's happening with the rtgl
raytrace |
| 02:18.11 |
brlcad |
try running
indent.sh on vers.c |
| 02:18.16 |
brlcad |
does it
modify the file? |
| 02:18.52 |
starseeker |
yes - just
the return brlcad_ident line |
| 02:19.10 |
starseeker |
which is the
only one there, of course... |
| 02:19.18 |
brlcad |
svn revert
vers.c, move your .emacs out of the way, and retry |
| 02:19.40 |
brlcad |
it shouldn't
modify |
| 02:20.12 |
starseeker |
still
did |
| 02:20.29 |
brlcad |
what platform
are you on? |
| 02:20.34 |
starseeker |
gentoo |
| 02:20.47 |
brlcad |
emacs
--version |
| 02:20.54 |
CIA-53 |
BRL-CAD:
03brlcad * r42684 10/brlcad/trunk/src/libdm/dm-rtgl.c: revert and
fix formatting. |
| 02:20.55 |
starseeker |
GNU Emacs
23.2.1 |
| 02:22.34 |
brlcad |
hm, okay --
so the indent.sh is unusable by you for some reason -- is there any
clue in the output when you run it? some warning or
error? |
| 02:26.10 |
starseeker |
no - just
"Loading vc-svn..." |
| 02:26.20 |
starseeker |
Indenting
region... |
| 02:26.23 |
starseeker |
Indenting
region... done |
| 02:26.30 |
brlcad |
hm,
darn |
| 02:26.31 |
starseeker |
saving and
wrote lines |
| 02:26.35 |
brlcad |
suspect
something in misc/batch-indent-region.el is getting interpreted
differently causing the variable block to be ignored |
| 02:26.51 |
brlcad |
well, so it's
just unusable for you until debugged |
| 02:26.57 |
starseeker |
nods |
| 02:27.16 |
brlcad |
you'll have
to stick with manually indenting or vim (the vi-line mode should be
respected if you turn it on) |
| 02:27.42 |
starseeker |
that's the
mode name? vi-line? |
| 02:27.47 |
brlcad |
only an issue
because that last edit is a prime example that can lead to a logic
bug later |
| 02:28.19 |
brlcad |
no, it's
not |
| 02:31.24 |
starseeker |
hmm - my
default vim setup doesn't work gg=G indents everything
wrong |
| 02:36.43 |
brlcad |
:help
'modeline' |
| 02:36.59 |
brlcad |
turning that
on should make it respect the modeline at the bottom of every
file |
| 02:37.32 |
brlcad |
otherwise,
you can set the style in your .vimrc with rules similar to this:
http://drupal.org/node/29325 |
| 02:37.52 |
brlcad |
except it's
shiftwidth=4 tabstop=8 |
| 02:48.42 |
starseeker |
the modeline
gets close |
| 03:13.49 |
brlcad |
there's
probably more variables that could/should be set for vim
users |
| 03:14.02 |
brlcad |
but the two
there are the critical ones for consistent indentation |
| 03:14.10 |
starseeker |
nods |
| 03:14.18 |
brlcad |
the stylistic
ones were left as an exercise to the reader :) |
| 03:14.26 |
starseeker |
heh |
| 03:14.33 |
brlcad |
continues working on rt_db_corrupt() |
| 03:16.19 |
CIA-53 |
BRL-CAD:
03starseeker * r42685 10/brlcad/branches/cmake/ (3 files in 3
dirs): Pick up sunmath if it's there for tcl/tk |
| 03:20.35 |
starseeker |
yow |
| 03:20.44 |
starseeker |
opennurbs and
sun studio don't get along at all |
| 03:22.03 |
starseeker |
hah -
actually, that's the same issue clang saw |
| 03:22.04 |
starseeker |
cool |
| 03:45.39 |
*** join/#brlcad yukonbob
(~bch@S0106002129e399fc.ok.shawcable.net) |
| 03:45.42 |
yukonbob |
oh
hai. |
| 03:46.38 |
yukonbob |
q: re
problems w/ sed/ted in 7.18.0 (apparently fixed in 7.18.1) -- does
anybody remember roughly (or better, acutely and accurately) what
the fix was? |
| 04:03.05 |
starseeker |
needed to
test for TCL_OK, as opposed to just using the return val for the if
statement (IIRC) |
| 04:03.26 |
starseeker |
return val of
editit in tedit.c I believe, but not sure |
| 04:04.10 |
starseeker |
yukonbob:
recommend setting up gdb, breaking just before the edit is to be
applied to disk (as a start) and tracing back where the failure
is |
| 04:04.20 |
starseeker |
grrrr |
| 04:04.52 |
starseeker |
sun stuido
gives this error: "The function "_finite" must have a
prototype" |
| 04:05.00 |
starseeker |
what on
earth... |
| 04:05.04 |
yukonbob |
starseeker:
thanks for the clues... I was going to try to get away w/
least-invasive patch possible. |
| 04:14.55 |
CIA-53 |
BRL-CAD:
03starseeker * r42686 10/brlcad/branches/cmake/src/libdm/dm-rtgl.c:
grab dm-rtgl ws/indent fixes |
| 04:37.40 |
CIA-53 |
BRL-CAD:
03starseeker * r42687 10/brlcad/branches/cmake/src/other/openNURBS/
(4 files): These are minimal 'get opennurbs compiling on sun
studio' hacks - commiting them because I accidently erased one last
go-around, but need cleanup and conditional wrappers |
| 04:53.11 |
brlcad |
starseeker:
sun studio is notorious for having drastically different
compilation behavior when you change standard compliance
levels |
| 04:54.00 |
brlcad |
the default
does not match gcc behavior but there is a mode that does match
pretty closely iirc |
| 05:06.11 |
yukonbob |
sees some interesting header changes in bwish -- stripping
itk.h and replacing w/ tk.h alone? |
| 05:07.46 |
yukonbob |
crosses fingers, configs 7.18.1 |
| 05:08.15 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.46.55) |
| 05:08.16 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:08.43 |
yukonbob |
feh --
immediate 'make' failure :P |
| 05:09.16 |
yukonbob |
missing
rtprivate.h |
| 05:26.41 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 05:36.45 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:00.19 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
| 06:00.19 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 06:00.52 |
*** join/#brlcad yukonbob
(~bch@S0106001cf044d085.ok.shawcable.net) |
| 06:49.23 |
yukonbob |
starseeker:
that TCL_OK on editit() was the problem/fix. Thx. |
| 07:15.24 |
yukonbob |
is there such
a process as a lathe yet, like povray? |
| 07:17.17 |
brlcad |
yukonbob:
yes, though much more general (and much less tested) :) |
| 07:17.24 |
brlcad |
'revolve'
primitive |
| 07:17.32 |
yukonbob |
brlcad: hello
:) |
| 07:17.37 |
brlcad |
takes a 2D
'sketch' object, and an axis of rotation |
| 07:17.47 |
yukonbob |
how old is
revolve? |
| 07:17.54 |
brlcad |
few
years |
| 07:17.55 |
yukonbob |
<2years |
| 07:17.57 |
yukonbob |
? |
| 07:18.08 |
yukonbob |
cool |
| 07:18.32 |
yukonbob |
brlcad:
how're things? |
| 07:18.33 |
brlcad |
r31599 |
pacman87 | 2008-06-24 13:34:05 -0400 (Tue, 24 Jun 2008) | 1
line |
| 07:18.33 |
brlcad |
beginning of
revolve primitive, with shot() algorithm for straigh line sketches
(untested) |
| 07:19.17 |
yukonbob |
that makes
sense -- probabably ~the time I became less involved... |
| 07:19.29 |
brlcad |
http://brlcad.org/wiki/Revolve_Primitive |
| 07:19.43 |
yukonbob |
povray
"lathe" operation is quite nice -- looking forward to playing w/
revolve... |
| 07:20.52 |
brlcad |
http://brlcad.org/tmp/revolve/
has a sample |
| 07:21.01 |
yukonbob |
brlcad: you
see the ted bug that shipped w/ 7.18.0 :P |
| 07:21.11 |
brlcad |
yep |
| 07:21.16 |
brlcad |
what about
it? |
| 07:21.42 |
yukonbob |
ted doesn't
work :P |
| 07:21.45 |
brlcad |
ted isn't
best practice |
| 07:21.54 |
brlcad |
more of a
crutch |
| 07:22.03 |
yukonbob |
the return
code is incorrectly checked, and the edits are effectively thrown
away. |
| 07:22.30 |
brlcad |
I'm aware of
what the bug is and how it was fixed -- I helped diagnose and fix
when it was reported |
| 07:22.32 |
yukonbob |
what do the
cool kids use instead of ted? |
| 07:23.09 |
brlcad |
it depends on
the type of edit, there are different commands for different
operations |
| 07:23.22 |
brlcad |
most of the
common ones are listed on the quick ref card |
| 07:23.49 |
yukonbob |
will have to get to a printer and print all these again... I
used to carry them with me ;) |
| 07:23.56 |
brlcad |
e.g., sca,
rot, tra |
| 07:24.45 |
yukonbob |
scale,
rotate, translate, sure... will those let one redefine the second
radius of a torus, though? |
| 07:24.55 |
brlcad |
the only
tricky edits are the refined parameter edits displaed on the Edit
menu when you go into edit mode, but even those are selectable on
the command line using the "press" command |
| 07:25.10 |
yukonbob |
ah |
| 07:26.24 |
yukonbob |
why is ted
considered !Best Practice ? |
| 07:26.52 |
brlcad |
press "Set
Radius 2" |
| 07:26.58 |
brlcad |
for that
specific action |
| 07:27.04 |
brlcad |
p
10 |
| 07:27.24 |
brlcad |
ted basically
punts on providing a user interface, kicking off a dump to a text
file |
| 07:27.54 |
yukonbob |
so is just
non-elegant, in at least one way... |
| 07:28.01 |
brlcad |
that's fine
for some things, like diagnostics, but a really crappy and
supremely error-prone way to go about things |
| 07:28.30 |
brlcad |
the errors it
causes tend to far outweigh the warm fuzzy feeling some people get
working in their favorite text editor |
| 07:28.46 |
brlcad |
it's a
crutch |
| 07:29.03 |
yukonbob |
nods |
| 07:29.39 |
yukonbob |
anyway, is
broken crutch in latest .tgz; I've got it working here, now, but
will train self to use alternatives. |
| 07:34.15 |
brlcad |
wow, my
corruption detection routine is actually working...
woot! |
| 07:59.48 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 08:51.07 |
CIA-53 |
BRL-CAD:
03brlcad * r42688 10/brlcad/trunk/src/librt/ (Makefile.am
db_corrupt.c): |
| 08:51.07 |
CIA-53 |
BRL-CAD: add
an initial working implementation of a routine to help detect when
a v4 |
| 08:51.07 |
CIA-53 |
BRL-CAD:
geometry file seems corrupt due to endianness. this walks over all
matrices of |
| 08:51.07 |
CIA-53 |
BRL-CAD:
combinatino members and tests whether they preserve axis
perpendicularity and |
| 08:51.07 |
CIA-53 |
BRL-CAD: that
scaling/rotation elements are unitized. if a matrix fails, it flips
it and |
| 08:51.08 |
CIA-53 |
BRL-CAD:
tries again to see if flipping fixes the problem. if ALL failures
were |
| 08:51.09 |
CIA-53 |
BRL-CAD:
successfully fixed by flipping, then true is returned. |
| 09:00.12 |
CIA-53 |
BRL-CAD:
03brlcad * r42689 10/brlcad/trunk/include/raytrace.h: provide
declaration and documentation for rt_db_flip_endian(), to be used
for detecting binary-incompatible v4 geometry database
files. |
| 10:38.42 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 12:18.19 |
epileg |
brlcad:
hello. I've made the needed changes in /misc/debian folder and in
sh/make_deb.sh file, to make it working. Now I've to
commit |
| 13:31.05 |
CIA-53 |
BRL-CAD:
03starseeker * r42690 10/brlcad/branches/cmake/src/other/openNURBS/
(4 files): Wrap sun studio stuff in conditionals |
| 13:41.47 |
CIA-53 |
BRL-CAD:
03starseeker * r42691 10/brlcad/branches/cmake/src/other/openNURBS/
(CMakeLists.txt opennurbs_system.h): Whoops - opennurbs build isn't
using the CONFIG_H_FILE at the moment, so add definitions
explicitly. Perhaps this is why ieeefp.h wasn't getting picked up,
so comment out the define - if this works remove it. |
| 13:44.50 |
CIA-53 |
BRL-CAD:
03starseeker * r42692
10/brlcad/branches/cmake/src/other/openNURBS/opennurbs_system.h:
Nope, HAVE_IEEEFP_H wasn't enough |
| 14:52.45 |
brlcad |
epileg: okay,
go for it :) |
| 14:53.13 |
brlcad |
you didn't
have to wait until you were done, you could/can commit
incrementally |
| 14:54.00 |
epileg |
brlcad: Do
have I commit acces to trunk/sh/ folder? |
| 15:34.43 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 15:39.47 |
CIA-53 |
BRL-CAD:
03brlcad * r42693 10/brlcad/trunk/src/libbu/mappedfile.c: checking
the wrong debug flag |
| 15:51.07 |
CIA-53 |
BRL-CAD:
03brlcad * r42694 10/brlcad/trunk/include/bu.h: BU_DEBUG_DB is no
longer used, mark as such to free up the slot. |
| 15:52.22 |
CIA-53 |
BRL-CAD:
03brlcad * r42695 10/brlcad/trunk/include/raytrace.h: mark the
private db_i members as such more explicitly, ws consistency
migration to keep names associated with their type for db_i and
directory structs. |
| 15:57.15 |
CIA-53 |
BRL-CAD:
03starseeker * r42696
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Don't mess with
jove on Windows |
| 15:59.02 |
CIA-53 |
BRL-CAD:
03starseeker * r42697
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Say something
about it instead of turning off silently |
| 16:06.35 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 16:06.59 |
brlcad |
epileg: the
only way to know that for sure is to try, right? |
| 16:07.12 |
epileg |
right
:-) |
| 16:07.40 |
epileg |
about the
commit comment. some rule to follow? |
| 16:08.09 |
brlcad |
sure, make it
something useful to the other developers and to yourself 5 years
from now |
| 16:09.01 |
brlcad |
briefly
describing what *and* why/impact/reasoning |
| 16:22.02 |
CIA-53 |
BRL-CAD:
03starseeker * r42698
10/brlcad/branches/cmake/src/bwish/CMakeLists.txt: tweak bwish
build logic |
| 16:24.13 |
CIA-53 |
BRL-CAD:
03brlcad * r42699 10/brlcad/trunk/src/librt/namegen.c: lots of dead
code, mostly dead code |
| 16:26.43 |
CIA-53 |
BRL-CAD:
03brlcad * r42700 10/brlcad/trunk/src/librt/db5_scan.c: |
| 16:26.43 |
CIA-53 |
BRL-CAD:
change db_dirbuild() to no longer directly check the file header
and calculate |
| 16:26.43 |
CIA-53 |
BRL-CAD: the
version. let db_version() be the (only) place that happens. should
reduce |
| 16:26.43 |
CIA-53 |
BRL-CAD: a
few petty file i/o operations but more importantly avoid
overriding |
| 16:26.44 |
CIA-53 |
BRL-CAD:
dbi_version since it needs to be negative for flipped v4
files. |
| 16:28.19 |
CIA-53 |
BRL-CAD:
03brlcad * r42701 10/brlcad/trunk/ (3 files in 2 dirs): enable
db_corrupt for librt compilation |
| 16:31.31 |
CIA-53 |
BRL-CAD:
03brlcad * r42702 10/brlcad/trunk/src/librt/db5_scan.c: right,
'header' is no longer used. |
| 16:37.11 |
CIA-53 |
BRL-CAD:
03starseeker * r42703 10/brlcad/branches/cmake/ (10 files in 10
dirs): Add version number logic for some of the src/other
libs |
| 16:47.31 |
CIA-53 |
BRL-CAD:
03brlcad * r42704 10/brlcad/trunk/src/fbserv/fbserv.c: return from
main instead of exiting |
| 16:49.20 |
CIA-53 |
BRL-CAD:
03brlcad * r42705
10/brlcad/trunk/src/other/tnt/tnt_fortran_array3d.h: quell warning
about having no space on the empty for loop before the
semicolon. |
| 17:09.51 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 18:21.39 |
CIA-53 |
BRL-CAD:
03starseeker * r42706 10/brlcad/branches/cmake/src/other/
(tcl/CMakeLists.txt tk/CMakeLists.txt): Hmm endian test isn't happy
with VC2010 |
| 18:27.59 |
CIA-53 |
BRL-CAD:
03starseeker * r42707 10/brlcad/branches/cmake/src/other/incrTcl/
(itcl/CMakeLists.txt itk/CMakeLists.txt): itcl/itk too |
| 18:28.30 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42708
10/brlcad/branches/cmake/src/libpc/CMakeLists.txt: add
TCL_INCLUDE_DIRS to make bu.h happy |
| 18:36.05 |
CIA-53 |
BRL-CAD:
03starseeker * r42709
10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Hmm - was
this the issue with the endian test? |
| 18:47.04 |
starseeker |
hmm.
nope |
| 18:47.10 |
starseeker |
does fix
another problem though |
| 18:48.09 |
starseeker |
sees other indications that TestBigEndian may be quirky with
VC2010... well, not likely to be needed anyhow with
MSVC |
| 19:18.20 |
CIA-53 |
BRL-CAD:
03starseeker * r42710
10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: More flag
tweaking... |
| 19:55.49 |
CIA-53 |
BRL-CAD:
03starseeker * r42711
10/brlcad/branches/cmake/misc/CMake/test_srcs/report_username.c.in:
Tweak WIN32 conditional define to _WIN32 |
| 20:06.53 |
CIA-53 |
BRL-CAD:
03bob1961 * r42712 10/brlcad/trunk/ (include/tclcad.h
src/libtclcad/ged_obj.c): Added a callback for when the view
changes to libtclcad. |
| 20:13.13 |
CIA-53 |
BRL-CAD:
03starseeker * r42713 10/brlcad/branches/cmake/src/other/step/ (11
files in 6 dirs): Simplify the SCL CMake logic, grab some of the
updates from newer BRL-CAD logic |
| 20:14.43 |
CIA-53 |
BRL-CAD:
03bob1961 * r42714 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Added methods to expose libtclcad's view_callback
function. |
| 20:18.38 |
CIA-53 |
BRL-CAD:
03starseeker * r42715
10/brlcad/branches/cmake/include/config_win_cmake.h: This is
defined in newer MSVC compilers - conditionalize to quell
warnings |
| 20:29.05 |
CIA-53 |
BRL-CAD:
03starseeker * r42716 10/brlcad/trunk/src/libbu/backtrace.c: Let's
not do the assignment in the if statement - quell MSVC
warning |
| 20:29.38 |
CIA-53 |
BRL-CAD:
03starseeker * r42717 10/brlcad/trunk/src/libbu/backtrace.c:
typo |
| 20:32.20 |
CIA-53 |
BRL-CAD:
03brlcad * r42718 10/brlcad/trunk/src/tclscripts/mged/text.tcl:
can't just directly call 'bind' since procedures might be called
without ::tk:: namespace loaded. catch any error. |
| 20:34.11 |
CIA-53 |
BRL-CAD:
03brlcad * r42719
10/brlcad/trunk/src/tclscripts/mged/dbupgrade.tcl: make dbupgrade
work once again in classic console mode where there is no
::tk |
| 20:36.10 |
CIA-53 |
BRL-CAD:
03starseeker * r42720
10/brlcad/branches/cmake/src/other/CMakeLists.txt: try adding xlib
to TCL_INCLUDE_DIRS (untested) |
| 20:38.19 |
CIA-53 |
BRL-CAD:
03starseeker * r42721
10/brlcad/branches/cmake/src/other/CMakeLists.txt: typo |
| 20:44.52 |
CIA-53 |
BRL-CAD:
03bob1961 * r42722
10/brlcad/trunk/src/tclscripts/archer/CombEditFrame.tcl: Fixed
CombEditFrame::updateGeometry. It's now able to turn off
inherit. |
| 20:52.06 |
CIA-53 |
BRL-CAD:
03brlcad * r42723 10/brlcad/trunk/src/conv/asc/g2asc.c: check ==0
instead of ==DB5_MINORTYPE_RESERVED since the value may change.
zero suffices for unset. |
| 20:53.03 |
CIA-53 |
BRL-CAD:
03brlcad * r42724 10/brlcad/trunk/src/conv/dbupgrade.c: |
| 20:53.04 |
CIA-53 |
BRL-CAD:
dbupgrade with a coredump flag makes the automatic endianness flip
test fail |
| 20:53.04 |
CIA-53 |
BRL-CAD:
since low-level libbn routines will bomb if they encounter a bad
matrix. |
| 20:53.04 |
CIA-53 |
BRL-CAD:
instead of bombing, let them return their error so we upgrade
cleanly. |
| 20:53.43 |
CIA-53 |
BRL-CAD:
03brlcad * r42725 10/brlcad/trunk/src/tclscripts/mged/help.tcl:
improve help, dbupgrade will begin processing if it's followed by
'upgrade' |
| 21:00.48 |
CIA-53 |
BRL-CAD:
03brlcad * r42726 10/brlcad/trunk/src/tclscripts/mged/help.tcl:
list all three upgrade commands |
| 21:01.38 |
CIA-53 |
BRL-CAD:
03brlcad * r42727
10/brlcad/trunk/src/tclscripts/mged/dbupgrade.tcl: display the
entire detailed help if the user requests help. 'help dbupgrade'
will still just report a brief usage message. |
| 21:03.17 |
CIA-53 |
BRL-CAD:
03jordisayol * r42728 10/brlcad/trunk/ (31 files in 2 dirs):
Upgraded the debian package build proccess. Added mged, archer,
rtwizard, documentation and examples menus. Added brlcad mime type.
Added brlcad mime file association. |
| 21:09.13 |
CIA-53 |
BRL-CAD:
03starseeker * r42729 10/brlcad/branches/cmake/src/ (CMakeLists.txt
irprep/subroutines.c other/CMakeLists.txt): more Windows
stuff... |
| 21:10.44 |
CIA-53 |
BRL-CAD:
03brlcad * r42730
10/brlcad/trunk/src/tclscripts/mged/dbupgrade.tcl: support all
variations of 'yes' and inform the user that upgrade was cancelled
and database is being reopened. this way, if it's a corrupt
database, the warning makes sense. |
| 21:10.56 |
brlcad |
epileg:
congratulations :) |
| 21:11.06 |
epileg |
thanks
brlcad |
| 21:11.29 |
epileg |
but it do not
compile on trunk |
| 21:11.46 |
epileg |
in 7.18.0
compile without problem |
| 21:12.30 |
brlcad |
you have to
be way more specific for that to mean anything |
| 21:13.06 |
epileg |
ok, just a
moment |
| 21:13.12 |
brlcad |
there are
dozens or even hundreds of commits nearly every day, and they won't
all work -- that's the nature of working on trunk |
| 21:14.08 |
brlcad |
first step is
to always check and see if there's an update, read the recent
commits from in here to see if the commit message says anything
about breaking things |
| 21:15.02 |
brlcad |
then just
read the failure to see what happened, because 90% of the time,
it's a very simple syntax mistake that can be easily fixed by
anyone |
| 21:15.38 |
brlcad |
then, if you
can't make sense of the error, you can paste your build log
somewhere and ask for help in here :) |
| 21:17.20 |
brlcad |
epileg: you
also need to update misc/Makefile.am to list all of the file
changes you made |
| 21:17.30 |
brlcad |
additions and
deletions |
| 21:17.34 |
brlcad |
it's a simple
list |
| 21:17.53 |
epileg |
ok, I'll do
right now |
| 21:21.33 |
CIA-53 |
BRL-CAD:
03brlcad * r42731 10/brlcad/trunk/src/librt/db_open.c: |
| 21:21.33 |
CIA-53 |
BRL-CAD:
enable automatic flipping of a binary-incompatible v4 geometry
database if |
| 21:21.33 |
CIA-53 |
BRL-CAD:
rt_db_flip_endian() returns true. this should only occur if
flipping the |
| 21:21.33 |
CIA-53 |
BRL-CAD:
database was observed to fix ALL matrix member failures during a
quick db_open() |
| 21:21.33 |
CIA-53 |
BRL-CAD: scan
of the file. the user should be able to force flipped values in
mged with |
| 21:21.34 |
CIA-53 |
BRL-CAD:
'opendb -f'. |
| 21:26.33 |
brlcad |
epileg: you
can check a build's suitability for distribution, particularly
whether you missed any files, with "make distcheck" |
| 21:28.16 |
epileg |
ok |
| 21:28.55 |
epileg |
now i'm
modifying misc/Makefile.am |
| 21:29.35 |
brlcad |
cool |
| 21:31.14 |
brlcad |
epileg: can
you describe what all the changes were -- new menus, mime type file
association, desktop icons, ... anything else? |
| 21:33.33 |
epileg |
brlcad: where
i've to describe this? |
| 21:34.04 |
brlcad |
heh, here --
just asking for general info |
| 21:34.11 |
epileg |
ah |
| 21:34.32 |
CIA-53 |
BRL-CAD:
03starseeker * r42732 10/brlcad/branches/cmake/misc/CMakeLists.txt:
whoopsie - to run in the build dir, need archer.ico in the build
dir... |
| 21:36.10 |
epileg |
configure was
changed from shared to build-in libraries |
| 21:37.20 |
epileg |
changed
--prefix from /usr/ to /usr/brlcad/ |
| 21:39.06 |
CIA-53 |
BRL-CAD:
03starseeker * r42733 10/brlcad/branches/cmake/TODO.cmake: Update
TODO.cmake |
| 21:39.06 |
brlcad |
anything
else? |
| 21:43.56 |
CIA-53 |
BRL-CAD:
03brlcad * r42734 10/brlcad/trunk/AUTHORS: add epileg's
aliases |
| 21:47.28 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
| 21:47.28 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 21:50.24 |
CIA-53 |
BRL-CAD:
03brlcad * r42735 10/brlcad/trunk/NEWS: |
| 21:50.24 |
CIA-53 |
BRL-CAD:
extensive work for the debian platform by jordi sayol (epileg).
there are new |
| 21:50.24 |
CIA-53 |
BRL-CAD:
application menus, icons, mime-type associations, and other
usability essentials |
| 21:50.24 |
CIA-53 |
BRL-CAD: for
a self-contained .deb installer. this should make it easier for a
platform |
| 21:50.24 |
CIA-53 |
BRL-CAD:
maintainer to publish .deb files on a more regular
basis. |
| 21:58.18 |
CIA-53 |
BRL-CAD:
03brlcad * r42736 10/brlcad/trunk/NEWS: |
| 21:58.18 |
CIA-53 |
BRL-CAD: you
can now run 'ls -la' on a v4 database and have it properly report
primitive |
| 21:58.18 |
CIA-53 |
BRL-CAD:
types. it was reporting NULL and even potential crash-inducing
garbage due to |
| 21:58.18 |
CIA-53 |
BRL-CAD:
directly indexing into the rt_functab based on an unset
d_minor_type. |
| 21:59.09 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42737
10/brlcad/branches/bottie/src/librt/primitives/bot/ (bot.c btg.c
btg.h btgf.c tie.c tie_kdtree.c): warning quellage |
| 22:20.08 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 22:22.16 |
CIA-53 |
BRL-CAD:
03jordisayol * r42738 10/brlcad/trunk/misc/Makefile.am: Updated
debian/ files list |
| 22:22.53 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 22:25.29 |
CIA-53 |
BRL-CAD:
03brlcad * r42739 10/brlcad/trunk/NEWS: |
| 22:25.29 |
CIA-53 |
BRL-CAD:
mged's opendb command now has a -f flip option for reading in
a |
| 22:25.29 |
CIA-53 |
BRL-CAD:
binary-incompatible v4 geometry database with a flipped endianness
translation. |
| 22:25.29 |
CIA-53 |
BRL-CAD: the
files are made read-only but may then be run through keep or
dbupgrade to |
| 22:25.29 |
CIA-53 |
BRL-CAD:
clean them up. this closes out a long-standing request from users
and a class |
| 22:25.30 |
CIA-53 |
BRL-CAD: of
modeling/rendering failures due to the platform-specific nature of
v4 files, |
| 22:25.31 |
CIA-53 |
BRL-CAD:
albeit only minimally tested with a few sample files. |
| 22:27.45 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 22:27.45 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source
Anniversary 2010-12-21 !!! Six years... |
| 22:29.07 |
CIA-53 |
BRL-CAD:
03starseeker * r42740
10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Doesn't look
like winMain.c belongs in libtk, but that's not the only
issue. |
| 22:29.23 |
CIA-53 |
BRL-CAD:
03brlcad * r42741 10/brlcad/trunk/NEWS: (log message
trimmed) |
| 22:29.23 |
CIA-53 |
BRL-CAD:
dbupgrade (along with ALL other BRL-CAD commands) now supports
reading in |
| 22:29.23 |
CIA-53 |
BRL-CAD:
binary-incompatible v4 files. the low-level librt db_open()
inteface for |
| 22:29.23 |
CIA-53 |
BRL-CAD:
reading in files will now auto-convert a v4 file to an alternate
endian format |
| 22:29.24 |
CIA-53 |
BRL-CAD: if
it finds that flipping all combination member matrices makes them
valid. for |
| 22:29.24 |
CIA-53 |
BRL-CAD:
safety, that means if an old v4 has even one actual bad matrix (so
that it's |
| 22:29.25 |
CIA-53 |
BRL-CAD:
invalid regardless of being flipped), then the dbupgrade cannot be
performed |
| 22:46.23 |
CIA-53 |
BRL-CAD:
03brlcad * r42742 10/brlcad/trunk/misc/Makefile.am: M-x
sort-lines |
| 22:46.53 |
epileg |
ops,
sorry |
| 22:47.01 |
brlcad |
no
problem |
| 22:51.04 |
CIA-53 |
BRL-CAD:
03brlcad * r42743 10/brlcad/trunk/TODO: dbupgrade support is
done |
| 22:53.39 |
CIA-53 |
BRL-CAD:
03brlcad * r42744 10/brlcad/trunk/src/tclscripts/mged/help.tcl:
document the new -f option to opendb |
| 23:02.47 |
CIA-53 |
BRL-CAD:
03brlcad * r42745
10/brlcad/trunk/doc/docbook/system/mann/en/opendb.xml: document the
opendb -f option |
| 23:11.05 |
CIA-53 |
BRL-CAD:
03r_weiss * r42746 10/brlcad/trunk/src/libbn/bntester.c: Added to
'bntester' support for testing function
'bn_isect_line3_line3'. |
| 23:15.18 |
CIA-53 |
BRL-CAD:
03brlcad * r42747 10/brlcad/trunk/include/ged.h: |
| 23:15.18 |
CIA-53 |
BRL-CAD:
refactor principle of DRY -- Don't Repeat Yourself. user usage
statements don't |
| 23:15.18 |
CIA-53 |
BRL-CAD:
belong in the public header regardless, but they're also already
listed in the |
| 23:15.18 |
CIA-53 |
BRL-CAD:
manual pages and src/tclscripts/mged/help.tcl and the bastard
replications for |
| 23:15.18 |
CIA-53 |
BRL-CAD:
archer and rtwizard (Db.tcl and Ged.tcl). approx 700 line
reduction. |
| 23:15.18 |
CIA-53 |
BRL-CAD:
ultimately, usage should be defined in the source C file directly
in src/libged |
| 23:17.33 |
brlcad |
hm, distcheck
does not like the misc/debian/brlcad-db.png symbolic
link |
| 23:18.48 |
epileg |
is this a
problem? |
| 23:19.05 |
epileg |
well, I can
make a copy of the png |
| 23:22.40 |
``Erik |
some os's
don't support symlinks, can it cp when running the makedeb script
shtuff? |
| 23:26.07 |
brlcad |
epileg: yeah,
a copy would be better |
| 23:26.35 |
CIA-53 |
BRL-CAD:
03jordisayol * r42748 10/brlcad/trunk/misc/debian/ (brlcad-db.png
brlcad-db.png): |
| 23:27.02 |
brlcad |
should always
have *some* comment message, at least say why :) |
| 23:27.30 |
epileg |
ok.
sorry |
| 23:28.33 |
brlcad |
could have
been "copy instead of symlink" or "distcheck hates symlinks or even
"sean complained so make a copy" .. all fine :) |
| 23:29.13 |
brlcad |
i.e., what
would be useful to someone looking at that change years from now
when the reason is no longer obvious |
| 23:30.06 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.0 is posted (20101209) ||
http://itmanagement.earthweb.com/osrc/article.php/3922041/50-Open-Source-Applications-for-Sci-Tech-Education.htm |
| 23:54.54 |
Ralith |
I'll be
needing to do inward polygon+arc offsetting in the gcode generator;
a bit of research has pointed me towards M. Held. "On the
Computational Geometry of Pocket Machining", LNCS500,
Springer-Verlag, 1991, which "uses a Voronoi Diagram (VD) to
produce rounded or constant-radius offset curves." I can get a
copy of this at my univ library. Sound like I'm on the right
track? |
| 23:55.13 |
Ralith |
... which
describes how to use "..., rather |
| 01:02.46 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 01:46.53 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 02:20.33 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 03:17.42 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 04:35.58 |
CIA-53 |
BRL-CAD:
03starseeker * r42816
10/brlcad/branches/cmake/CMakeLists.txt: |
| 04:35.58 |
CIA-53 |
BRL-CAD:
Going to have to use a global property for the build targets lists
- functions |
| 04:35.58 |
CIA-53 |
BRL-CAD: have
local variable scope, not sure why it ever worked originally. This
needs |
| 04:35.58 |
CIA-53 |
BRL-CAD: more
testing, not sure it stays constant over multiple cmake runs and
need to |
| 04:35.58 |
CIA-53 |
BRL-CAD:
verify it's doing 'the right things'. Also, test noprod
rule. |
| 05:07.48 |
CIA-53 |
BRL-CAD:
03brlcad * r42817 10/brlcad/trunk/src/librtserver/rtserver.c: add
missing footer |
| 05:08.39 |
CIA-53 |
BRL-CAD:
03brlcad * r42818 10/brlcad/trunk/src/librtserver/rtserver.c:
ws/indent consistency cleanup |
| 05:33.13 |
CIA-53 |
BRL-CAD:
03starseeker * r42819
10/brlcad/branches/cmake/CMakeLists.txt: |
| 05:33.14 |
CIA-53 |
BRL-CAD: This
is a long shot, but see if a per-directory noprod can be set up.
Just |
| 05:33.14 |
CIA-53 |
BRL-CAD:
exploring the preliminary steps as yet - if this does work it will
involve a |
| 05:33.14 |
CIA-53 |
BRL-CAD:
hideous abuse of the old CMP0002 policy allowing non-unique target
names, so not |
| 05:33.14 |
CIA-53 |
BRL-CAD:
ideal even if it does work... |
| 05:35.51 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 05:57.58 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 05:59.49 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.33.253) |
| 05:59.50 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:44.58 |
CIA-53 |
BRL-CAD:
03jordisayol * r42820 10/brlcad/trunk/ (misc/debian/control
misc/debian/rules sh/make_deb.sh): add the option to build debian
source packages and change debian configuration. |
| 09:14.39 |
CIA-53 |
BRL-CAD:
03jordisayol * r42821 10/brlcad/trunk/ (4 files in 2 dirs): add two
new doc menu entries |
| 09:58.29 |
cjdevlin |
!info
xubuntu-desktop |
| 11:19.43 |
dloman |
Well, i must
admit that this storm is rather disappointing :/ |
| 11:20.11 |
dloman |
snow was
supposed to start at 1700 yesterday and accumulate 5 inches.. so
far, just a dusting. |
| 11:20.34 |
dloman |
But the ice
has finally started..... yay. |
| 12:38.49 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:29.54 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.135.87) |
| 13:29.54 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:36.57 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:38.13 |
``Erik |
hm, the cul
de sac is a sheet of ice, no one else in my cul de sac has tried
venturing out, one of my neighbors said he heard about lots of
accidents on tv and was going to wait until it warms up later to
try |
| 13:38.17 |
``Erik |
O.O
wee |
| 13:48.35 |
dloman |
time to take
the M3 out for a 'spin' eh? =D |
| 13:51.29 |
``Erik |
heh, it
wouldn't be able to get out of the driveway, still too much snow
and ice |
| 13:59.09 |
dloman |
fun
fun! |
| 14:19.47 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 14:57.07 |
dloman |
Icy here, icy
there...but at least post is open! lol |
| 15:34.16 |
``Erik |
once I got
out of my neighborhood (I think about a mile?), it was all
good |
| 15:34.43 |
``Erik |
I don't think
they salt back in my development, or the one I have to go through
to get from mine to the highway |
| 15:35.43 |
``Erik |
0.7 miles
according to google maps heh |
| 15:41.40 |
CIA-53 |
BRL-CAD:
03starseeker * r42822 10/brlcad/branches/cmake/CMakeLists.txt: (log
message trimmed) |
| 15:41.40 |
CIA-53 |
BRL-CAD:
Eeek. This appears to be a working per-directory noprod solution.
Done the |
| 15:41.40 |
CIA-53 |
BRL-CAD: best
I can for convenience vs. policy - CMP0002 forbids non-unique
target names, |
| 15:41.40 |
CIA-53 |
BRL-CAD: and
hence excludes a 'make noprod' rule for each directory. Even
forcing that |
| 15:41.40 |
CIA-53 |
BRL-CAD: to
OLD, get some odd behavior with the toplevel 'make noprod' rule
(not |
| 15:41.41 |
CIA-53 |
BRL-CAD:
surprisingly, the policy is there for a reason). Hence, there is a
toplevel |
| 15:41.42 |
CIA-53 |
BRL-CAD: make
noprod command and in subdirectories 'make noprod' becomes 'cmake
-P |
| 15:42.56 |
starseeker |
brlcad: that
appears to be the best I can do for noprod - you can achieve (I
think) the effects of make noprod in a directory but you'll have to
do the cmake -P thing instead of make noprod |
| 16:11.14 |
CIA-53 |
BRL-CAD:
03starseeker * r42823 10/brlcad/branches/cmake/ (9 files in 5
dirs): Fix step build properly - surprise, surprise using scl_cf.h
correctly actually helped |
| 16:20.15 |
CIA-53 |
BRL-CAD:
03starseeker * r42824
10/brlcad/branches/cmake/src/conv/step/CMakeLists.txt: Add the
output include dir for step |
| 17:05.17 |
CIA-53 |
BRL-CAD:
03starseeker * r42825
10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Nevermind
the dash - this symlink logic is too fragile, so just go with CMake
standard practice |
| 17:08.52 |
CIA-53 |
BRL-CAD:
03jordisayol * r42826 10/brlcad/trunk/misc/Makefile.am: add two
debian doc menu entries |
| 17:53.08 |
CIA-53 |
BRL-CAD:
03starseeker * r42827 10/brlcad/branches/cmake/ (5 files in 5
dirs): Ah - remove files based on version number properties as well
for noprod. Start using the exec list to strip executables for
CPack |
| 18:28.15 |
*** join/#brlcad andrecastelo
(~andre@187.115.160.108) |
| 18:33.10 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42828
10/brlcad/trunk/src/librt/primitives/nmg/nmg_junk.c: Remove the
HIDDEN from these junk functions to avoid "unused symbol" failures
when debugging is off. |
| 18:43.21 |
CIA-53 |
BRL-CAD:
03starseeker * r42829
10/brlcad/branches/cmake/src/other/step/CMake/SCL_Utils.cmake:
Don't use absolute install paths |
| 18:54.28 |
CIA-53 |
BRL-CAD:
03starseeker * r42830 10/brlcad/branches/cmake/ (4 files in 4
dirs): another absolute install path |
| 19:12.52 |
``Erik |
http://punditkitchen.files.wordpress.com/2011/01/1fe680f4-203b-47af-bb23-8bb0e0f2a623.jpg |
| 19:20.16 |
CIA-53 |
BRL-CAD:
03starseeker * r42831 10/brlcad/branches/cmake/ (3 files in 2
dirs): Little more tweaking to mark variables as
advanced |
| 19:25.14 |
CIA-53 |
BRL-CAD:
03starseeker * r42832
10/brlcad/branches/cmake/src/tclscripts/ampi.tcl: verbose flag is
intentional to highlight problems - restore |
| 19:29.26 |
CIA-53 |
BRL-CAD:
03johnranderson * r42833 10/jbrlcad/trunk/ (10 files in 2 dirs):
Point and Vector3 now have a common base class (Triple) |
| 19:36.29 |
CIA-53 |
BRL-CAD:
03starseeker * r42834 10/brlcad/branches/cmake/ (25 files in 11
dirs): MFC 42833 |
| 19:43.05 |
CIA-53 |
BRL-CAD:
03starseeker * r42835 10/brlcad/trunk/src/libbu/brlcad_path.c:
realpath tweak, add ifdef wrapped Windows logic |
| 19:45.49 |
CIA-53 |
BRL-CAD:
03starseeker * r42836 10/brlcad/trunk/src/libbn/anim.c: initialize
dir (quiet a warning) |
| 19:57.47 |
starseeker |
um... |
| 19:57.49 |
starseeker |
cc1plus:
warnings being treated as errors |
| 19:57.49 |
starseeker |
src/other/openNURBS/opennurbs_array.h: In
function ?ON_Curve* brlcad::pullback_curve(ON_BrepFace*, const
ON_Curve*, brlcad::SurfaceTree*, double, double)?: |
| 19:57.52 |
starseeker |
src/other/openNURBS/opennurbs_array.h:353:
error: inlining failed in call to ?virtual
ON_2dPointArray::~ON_2dPointArray()?: call is unlikely and code
size would grow |
| 19:57.55 |
starseeker |
src/librt/opennurbs_ext.cpp:2400: error:
called from here |
| 19:58.12 |
starseeker |
huh? |
| 20:11.00 |
brlcad |
c++ should
not be compiling with strict |
| 20:11.29 |
brlcad |
though that
warning is a valid "issue" |
| 20:12.01 |
brlcad |
destructors
shouldn't be inline anyways |
| 20:12.27 |
starseeker |
doesn't see where it's being inlined |
| 20:33.08 |
CIA-53 |
BRL-CAD:
03brlcad * r42837 10/brlcad/trunk/misc/debian/ (7 files): switch to
text/plain and set eol-style to native |
| 20:42.24 |
CIA-53 |
BRL-CAD:
03brlcad * r42838 10/brlcad/trunk/src/libbn/anim.c: VINIT_ZERO
instead of {} |
| 20:50.00 |
CIA-53 |
BRL-CAD:
03starseeker * r42839
10/brlcad/branches/cmake/src/libfft/CMakeLists.txt: Yow - optimized
is what kills fft - don't go above 256 until there's a demonstrated
need |
| 20:51.28 |
brlcad |
hehe |
| 20:53.02 |
brlcad |
the autotools
build only goes up to 256 |
| 20:53.10 |
CIA-53 |
BRL-CAD:
03starseeker * r42840
10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Make
libtclcad strict |
| 20:53.31 |
brlcad |
those
generated sources get big fast |
| 20:53.37 |
starseeker |
indeed |
| 20:54.26 |
brlcad |
but it's
clever, iirc one of the fastest implementation methods |
| 20:54.43 |
starseeker |
neat |
| 20:54.54 |
starseeker |
hmm |
| 20:54.57 |
starseeker |
src/liboptical/sh_noise.c:174: error:
‘noise_render’ declared ‘static’ but never
defined |
| 20:54.58 |
brlcad |
would be
ineteresting to revisit some comparisons to see if we're still one
of the best |
| 20:55.56 |
brlcad |
the curse of
forward declarations |
| 20:56.17 |
brlcad |
there
shouldn't be any forward declarations |
| 20:59.26 |
starseeker |
must have
missed an update |
| 21:01.47 |
CIA-53 |
BRL-CAD:
03starseeker * r42841 10/brlcad/trunk/src/liboptical/sh_noise.c:
Forward declarations bad. - move mfuncs down and get rid of
them |
| 21:01.58 |
starseeker |
sh_points.c:79: error: useless storage
class specifier in empty declaration |
| 21:04.09 |
CIA-53 |
BRL-CAD:
03starseeker * r42842 10/brlcad/trunk/src/liboptical/sh_points.c:
Hidden causes a warning here about useless storage class
specification |
| 21:05.11 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
| 21:05.11 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
| 21:10.51 |
epileg |
I can not
create pdf files in Linux. is this normal? |
| 21:11.06 |
starseeker |
epileg: you
mean the build won't make them? |
| 21:11.14 |
epileg |
yes, this
is |
| 21:11.21 |
starseeker |
what is the
error? |
| 21:11.35 |
epileg |
no error, on
config says... |
| 21:11.39 |
epileg |
just a
moment |
| 21:11.46 |
starseeker |
oh - you need
to install Apache FOP |
| 21:13.03 |
epileg |
starseeker:
thanks! I'll check |
| 21:14.54 |
starseeker |
brlcad: uh,
this one has me puzzled... |
| 21:14.58 |
starseeker |
src/conv/g-vrml.c:821: error: variable
‘__stream’ might be clobbered by ‘longjmp’ or
‘vfor |
| 21:25.46 |
brlcad |
starseeker:
you didn't see all of those longjmp commits last week? |
| 21:26.20 |
brlcad |
or at least
read the commit messages .. I blathered quite a bit about that
:) |
| 21:26.27 |
starseeker |
thought he recalled something |
| 21:26.30 |
starseeker |
checks... |
| 21:30.28 |
starseeker |
brlcad:
r42544? |
| 22:00.51 |
starseeker |
cannot follow what this logic is doing |
| 22:01.06 |
starseeker |
q |
| 22:12.34 |
CIA-53 |
BRL-CAD:
03starseeker * r42844 10/brlcad/trunk/src/conv/dem-g.c: Compiler
doesn't like this inline |
| 22:19.40 |
CIA-53 |
BRL-CAD:
03starseeker * r42843 10/brlcad/trunk/src/liboptical/sh_text.c:
Need a little more careful look here, but this removes enough
forward decls to get it building |
| 22:20.39 |
CIA-53 |
BRL-CAD:
03brlcad * r42845 10/brlcad/trunk/ (4 files in 3 dirs): check for
GetFullPathName() and conditionalize on HAVE_GETFULLPATHNAME
instead of _WIN32 accordingly |
| 22:21.44 |
CIA-53 |
BRL-CAD:
03brlcad * r42846 10/brlcad/trunk/src/libbu/ (brlcad_path.c
timer.c): include bio.h instead of direclty including windows.h;
keying off _WIN32 is bad form |
| 22:21.44 |
CIA-53 |
BRL-CAD:
03brlcad * r42847 10/brlcad/trunk/src/mged/mged.c: ERR... really?
somehow this commit didn't make it through. give mged the ability
to forcibly flip the version number even if librt doesn't do it
automatically. |
| 22:21.44 |
CIA-53 |
BRL-CAD:
03brlcad * r42848 10/brlcad/trunk/src/bwish/ (consoleMain.c
winMain.c): another bio.h inclusion instead of
windows.h |
| 22:21.45 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42849 10/brlcad/branches/bottie/ (4 files in 3
dirs): mimic rt_bot_minpieces for TIE algorithm |
| 22:27.20 |
CIA-53 |
BRL-CAD:
03starseeker * r42850 10/brlcad/trunk/src/conv/g-vrml.c: work
around potential clobber in g-vrml |
| 22:27.20 |
CIA-53 |
BRL-CAD:
03starseeker * r42851 10/brlcad/trunk/src/conv/g-x3d.c: Same issue
with g-x3d |
| 22:28.37 |
CIA-53 |
BRL-CAD:
03starseeker * r42852 10/brlcad/trunk/src/libdm/ (dm-plot.c dm-ps.c
dm-tk.c): reorder to remove forward declarations |
| 22:39.41 |
CIA-53 |
BRL-CAD:
03starseeker * r42853
10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: Turn off
Werror when we see cpp files in a strict library, unless CXX_STRICT
is on. Leave the warnings unless the warnings option is
off. |
| 22:42.31 |
CIA-53 |
BRL-CAD:
03starseeker * r42854 10/brlcad/branches/cmake/CMakeLists.txt: Add
the BRLCAD-ENABLE_CXX_STRICT option |
| 22:44.30 |
CIA-53 |
BRL-CAD:
03brlcad * r42855 10/brlcad/trunk/src/mged/mged.c: tweak the
message to let the user know whether -f had any affect. only mark
as read-only and flip if we need to. |
| 22:45.16 |
CIA-53 |
BRL-CAD:
03starseeker * r42856 10/brlcad/trunk/src/ (4 files in 2 dirs): Few
misc tweaks - turn off some unused libged code, UNUSED in
brep.cpp |
| 22:46.55 |
CIA-53 |
BRL-CAD:
03starseeker * r42857 10/brlcad/branches/cmake/ (26 files in 10
dirs): Put various fixes into CMake branch |
| 22:46.57 |
CIA-53 |
BRL-CAD:
03brlcad * r42858 10/brlcad/trunk/include/config_win.h: file wasn't
saved for r42845. set HAVE_GETFULLPATHNAME |
| 22:49.11 |
CIA-53 |
BRL-CAD:
03starseeker * r42859 10/brlcad/trunk/src/libtclcad/ged_obj.c: not
defined |
| 22:50.05 |
CIA-53 |
BRL-CAD:
03starseeker * r42860 10/brlcad/branches/cmake/src/bwish/
(consoleMain.c winMain.c): More fixes from trunk |
| 22:50.36 |
CIA-53 |
BRL-CAD:
03starseeker * r42861
10/brlcad/branches/cmake/src/libtclcad/ged_obj.c: remove this on
cmake branch too |
| 22:50.54 |
brlcad |
should delete
unused code |
| 22:51.13 |
starseeker |
brlcad:
thought I'd check with Bob/Richard before nuking |
| 22:51.42 |
brlcad |
it's in
revision history |
| 22:51.49 |
starseeker |
true |
| 22:52.07 |
brlcad |
if there's no
comment, then there's definitely no reason to keep it |
| 22:52.07 |
CIA-53 |
BRL-CAD:
03starseeker * r42862 10/brlcad/branches/cmake/src/mged/mged.c:
update from trunk |
| 22:52.47 |
brlcad |
commented out
code, #if 0'd code |
| 22:53.41 |
brlcad |
it's a
maintenance burden and just makes the files messy and often error
prone, the code falls out of sync quickly and can cause bugs if
re-enabled |
| 22:57.02 |
CIA-53 |
BRL-CAD:
03starseeker * r42863 10/brlcad/trunk/src/libged/ (bigE.c human.c):
Go ahead and remove the code from libged, instead of commenting
itout |
| 22:57.45 |
brlcad |
ah yeah,
covered by HACKING under the refactoring section too :) |
| 23:00.50 |
CIA-53 |
BRL-CAD:
03starseeker * r42864 10/brlcad/trunk/src/ (4 files in 4
dirs): |
| 23:00.50 |
CIA-53 |
BRL-CAD:
Let's try this again - see if we can do without tclcad_tcl_library.
Using |
| 23:00.50 |
CIA-53 |
BRL-CAD:
private Tcl functions is Not Good, particularly when it's for debug
printing. |
| 23:00.50 |
CIA-53 |
BRL-CAD: also
removing the found_init_tcl call to TclSetLibraryPath - same basic
problem |
| 23:00.50 |
CIA-53 |
BRL-CAD: and
the comment says it doesn't do what we might expect it to
anyway. |
| 23:02.20 |
CIA-53 |
BRL-CAD:
03starseeker * r42865 10/brlcad/branches/cmake/src/ (4 files in 4
dirs): remove tclcad_tcl_library in CMake branch too |
| 23:02.37 |
starseeker |
brlcad: is
that alternative way to do the make noprod thing
acceptable? |
| 23:04.18 |
brlcad |
doing a "make
noprod" from the top-level would even probably work if you can
relink a given binary (e.g. "make mged") with one step |
| 23:05.57 |
brlcad |
hard to say
without trying it in practice really, wasn't clear what the final
step(s) needed were going to be |
| 23:06.29 |
starseeker |
uh... you
just do cmake -P ./cmake_noprod.cmake instead of make
noprod |
| 23:07.12 |
brlcad |
heh, might
just end up with an sh/noprod.sh script then that runs
that |
| 23:08.13 |
starseeker |
cmake will
relink the libraries required by mged before linking
mged |
| 23:08.23 |
starseeker |
following its
dependency logic |
| 23:09.13 |
brlcad |
so what about
a simple rule that wipes out all products? |
| 23:09.23 |
starseeker |
that's the
toplevel make noprod |
| 23:09.25 |
starseeker |
that
works |
| 23:09.41 |
starseeker |
it's just in
the subdirectories you need to run the specific script |
| 23:09.48 |
starseeker |
I can't
define a noprod target for every directory |
| 23:11.00 |
CIA-53 |
BRL-CAD:
03bob1961 * r42866
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Updated
Archer::constructor to properly set the view of the command window
(i.e. how much command window to display verses geometry window
etc. |
| 23:13.04 |
starseeker |
O.o the toy
jeep is giving out Bend radii errors |
| 23:15.10 |
brlcad |
the toplevel
make noprod sounds like it might end up being more practical than
cmake -P ./cmake_noprod.cmake |
| 23:15.31 |
starseeker |
well, they're
both there |
| 23:15.45 |
starseeker |
it's not an
either/or situation |
| 23:16.04 |
brlcad |
it just feels
way too long and prone to being forgotten |
| 23:16.19 |
starseeker |
what about
cmake -P noprod |
| 23:16.39 |
starseeker |
the last arg
is a file name, I can just call it noprod if that's
better |
| 23:16.40 |
brlcad |
that'd
probably be better |
| 23:17.01 |
brlcad |
no way to
inject custom make rules? |
| 23:17.26 |
brlcad |
some "if
target is makefile, #include Makefile.inc" |
| 23:17.44 |
brlcad |
similar to
what is done for "make fast" |
| 23:17.59 |
starseeker |
not that I've
found so far... |
| 23:18.00 |
brlcad |
and make
noprod for that matter, iirc |
| 23:20.00 |
brlcad |
my gut
feeling is if all products are unique, then cd'ing down into the
hierarchy isn't going to be as important |
| 23:20.31 |
brlcad |
since I can
"make noprod && make rt" and it'll relink rt (along with
all of rt's dependencies) |
| 23:20.37 |
starseeker |
nods |
| 23:20.50 |
starseeker |
well, the
cmake -P option is there if it's needed |
| 23:21.12 |
starseeker |
was quite the
operation to set up |
| 23:21.18 |
brlcad |
not quite as
ideally targetted as *only* relinking rt, but possibly
workable |
| 23:21.28 |
brlcad |
have to see
in practice, but it's a minor point |
| 23:21.55 |
brlcad |
I don't doubt
it |
| 23:22.56 |
brlcad |
unfortunately, cmake makes some things
much harder to do |
| 23:23.09 |
brlcad |
a known
limitation going into this |
| 23:23.29 |
starseeker |
a few maybe,
but I haven't had too much trouble on the whole... |
| 23:23.35 |
brlcad |
heh |
| 23:23.44 |
starseeker |
main trouble
was Tcl/Tk |
| 23:23.45 |
brlcad |
says you more
than 6 months later :) |
| 23:24.19 |
starseeker |
<snort>
If I'd been re-creating the autotools logic, I'd bet on a year easy
(for me, anyway) |
| 23:25.58 |
CIA-53 |
BRL-CAD:
03starseeker * r42867 10/brlcad/branches/cmake/CMakeLists.txt: no
reason to use cmake_noprod.cmake - just call it noprod so it's more
like a make target |
| 23:27.01 |
starseeker |
you super
scripting gurus are more comfortable with sh and friends - for me
it might as well be perl |
| 23:28.40 |
brlcad |
autotools was
a learning hurdle too |
| 23:29.03 |
brlcad |
both erik and
I put several months whipping configure.ac and friends into
shape |
| 23:30.55 |
brlcad |
the cmake
effort is probably on-par, seems like even a bit more given it's
not as mature and flexible |
| 23:31.29 |
brlcad |
but then
higher short-term with the hope that maintenance is lower in the
long-term |
| 23:31.48 |
starseeker |
nods |
| 23:33.11 |
brlcad |
realistically
speaking, there's undoubtedly months of work still remaining to
bring it on-par cross-platform in a low-maintenance fashion with
all the bugs squeezed out |
| 23:34.06 |
starseeker |
I suppose.
On the whole I'm rather happy with how it's turned out, but of
course I haven't done extensive options testing and
such |
| 23:34.21 |
starseeker |
knows turning off X11 won't quite work yet, for example - it
still builds Tk |
| 23:35.29 |
brlcad |
simple code
metrics -- no code is perfect, there will be bugs even aside from
incompleteness |
| 23:37.40 |
brlcad |
new code is
pretty consistently reliable to have bugs on the order as bad as 1%
to as good as 0.1% (on average) |
| 23:38.35 |
starseeker |
brlcad: what
are the remaining hurdles for me to be able to merge into
trunk? |
| 23:39.33 |
brlcad |
lines-of-code
of course isn't really strictly reliable, but it's pretty
reasonable to assume that if 10000 new lines of logic were written,
that there's at least a dozen bugs in there if not more |
| 23:42.45 |
brlcad |
starseeker:
well whenever you're confident that you're "done done", that should
mean that someone else should be able to do a code review to see if
there are any show-stopper code differences, things that were
turned on/off, that a release can be produced and verified, that
everything is properly documented (which is really part of release
verification) |
| 23:45.10 |
CIA-53 |
BRL-CAD:
03starseeker * r42868 10/brlcad/branches/cmake/src/
(bwish/CMakeLists.txt other/CMakeLists.txt): Don't enable Tk even
with ENABLE_ALL if we aren't supposed to build it |
| 23:45.39 |
starseeker |
brlcad: so I
need the equalivent to our documentation of the configure options
for the significant CMake variables |
| 23:46.27 |
starseeker |
ponders... hmm... |
| 23:46.41 |
brlcad |
ideally, yes
-- but more specifically, README, INSTALL, HACKING, doc/* have to
be updated |
| 23:47.24 |
brlcad |
places that
refer to "autogen.sh", or "configure", "make", "Makefile.am",
etc |
| 23:47.43 |
brlcad |
we have to be
able to push out a source release |
| 23:47.59 |
brlcad |
compilation
docs are part of that |
| 23:47.59 |
starseeker |
nods. |
| 23:52.04 |
brlcad |
notes that it's time to prepare a release |
| 23:53.00 |
brlcad |
how
extensively did you test r42864 ? |
| 23:53.18 |
brlcad |
tclcad_tcl_library() removal |
| 23:53.45 |
starseeker |
I've had it
gone in the CMake branch for a while, but less extensively than I'd
like |
| 23:54.15 |
starseeker |
unless its
documentation was wrong, it's a debug output function? |
| 23:54.26 |
brlcad |
it's
not |
| 23:54.43 |
brlcad |
it prevents a
runtime crash for some versions of tcl |
| 23:56.14 |
brlcad |
TclGetLibraryPath() initializes some
things internal to the Tcl library that were not otherwise getting
initialized by Tcl_Init or other calls and would result in a
non-catchable run-time crash |
| 23:56.59 |
brlcad |
iirc, not
visible during --enable-all but was reproducible if you used a
system tcl/tk |
| 23:57.51 |
brlcad |
don't know if
it was specific to any tcl version, 8.4 or 8.5 but it was a hard
show-stopper crash of mged |
| 23:58.32 |
brlcad |
it was a
while ago too, so if it works with --enable-all and --disable-all
now with 8.5+ for example, then we can just move
forward |
| 23:58.57 |
starseeker |
ok, I'll see
what happens with a system tcl/tk |
| 23:59.15 |
starseeker |
We can put it
back in if we have to, but I really don't like calling private
Tcl/Tk functions |
| 23:59.26 |
brlcad |
putting it
back isn't the issue |
| 23:59.34 |
brlcad |
given it's a
hard crash, we can't do a release until verifying |
| 23:59.40 |
starseeker |
ah |
| 23:59.43 |
brlcad |
because it's
otherwise DOA |
| 00:00.35 |
brlcad |
need to check
at least linux with and without system tcl, and mac (without of
course) |
| 00:01.37 |
brlcad |
fwiw, make
test and make distcheck aren't sufficient, have to kick off the
GUI |
| 00:01.46 |
starseeker |
nods |
| 00:06.57 |
brlcad |
I had
distchecks passing with all options on/off for 64-bit linux,
testing mac now |
| 00:31.44 |
CIA-53 |
BRL-CAD:
03starseeker * r42869 10/brlcad/branches/cmake/TODO.cmake: Add a
few more TODO items for CMake |
| 00:35.08 |
CIA-53 |
BRL-CAD:
03starseeker * r42870 10/brlcad/trunk/src/mged/mged.c:
dbip_filename -> dbi_filename |
| 00:50.59 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 00:53.33 |
starseeker |
brlcad: I
think I may have messed up. I am using BRLCAD_DATA as a relative
path from BRLCAD_ROOT, but I'm seeing in trunk that both
BRLCAD_DATA and BRLCAD_ROOT are full paths |
| 01:09.54 |
*** join/#brlcad DX^
(~DX@c-71-59-50-121.hsd1.ga.comcast.net) |
| 01:10.01 |
DX^ |
I can't find
the configure flag to disable compiling with X11 |
| 01:10.40 |
starseeker |
--disable-x11
? |
| 01:14.14 |
DX^ |
I tried
--disable-x |
| 01:14.19 |
DX^ |
but that
didn't work, I'll try that.. |
| 01:15.55 |
DX^ |
still says
its enabled |
| 01:16.40 |
starseeker |
--without-x11
? |
| 01:17.34 |
DX^ |
trying |
| 01:17.58 |
starseeker |
brlcad: my
apologies - I think I made my own trouble with the path logic,
after all |
| 01:22.19 |
DX^ |
that worked,
awesome |
| 01:22.38 |
CIA-53 |
BRL-CAD:
03starseeker * r42871 10/brlcad/trunk/src/libbu/brlcad_path.c: Dur.
BRLCAD_DATA is supposed to be a full path, but I had a relative
path in the CMake logic... hilarity ensued. Put it back the way it
should be and make CMake do it right. |
| 01:29.59 |
CIA-53 |
BRL-CAD:
03starseeker * r42872 10/brlcad/trunk/configure.ac: Add note that
BRLCAD_DATA must be a full path |
| 01:39.41 |
CIA-53 |
BRL-CAD:
03starseeker * r42873 10/brlcad/branches/cmake/ (CMakeLists.txt
configure.ac src/libbu/brlcad_path.c): Do BRLCAD_DATA the right way
in CMake. |
| 01:49.51 |
CIA-53 |
BRL-CAD:
03starseeker * r42874 10/brlcad/trunk/ (7 files in 4 dirs): Apply
42757 to trunk - without this, getting failures on gentoo with
warnings enabled. |
| 01:55.54 |
CIA-53 |
BRL-CAD:
03starseeker * r42875 10/brlcad/trunk/configure.ac: Whoops -
manuals/archer is still gone |
| 02:12.14 |
CIA-53 |
BRL-CAD:
03starseeker * r42876 10/brlcad/trunk/doc/docbook/Makefile.am:
catalog.xml is no more |
| 02:35.33 |
brlcad |
starseeker:
hm, yeah they should be full paths but it's an interesting
thought |
| 02:35.51 |
brlcad |
relative path
"should" work, but I can see how an assumption may be in
there |
| 02:36.40 |
starseeker |
relative is
already sort of there with the root/share/brlcad/version check -
that's what you get with a relative BRLCAD_DATA |
| 02:36.52 |
brlcad |
BRLCAD_ROOT
and BRLCAD_DATA are environment variables so they could conceivably
be relative if we allow it |
| 02:37.10 |
brlcad |
bu_brlcad_root() and bu_brlcad_data()
probably have assumptions otherwise |
| 02:37.27 |
brlcad |
ah, yeah,
that would work |
| 02:37.36 |
brlcad |
though
full-path root and relative data should work too |
| 02:37.58 |
brlcad |
or the
limitation should be documented |
| 02:38.04 |
starseeker |
that's what I
was doing with CMake (albeit accidentally) |
| 02:38.12 |
starseeker |
mentioned it in configure.ac |
| 02:38.22 |
brlcad |
yeah, i
saw |
| 02:38.39 |
brlcad |
I mean to
users though -- the environment variable isn't set by
configure |
| 02:38.46 |
brlcad |
it sets the
"hard wired" default |
| 02:38.48 |
starseeker |
wouldn't be
too hard to make it accept a relative path - I did it initially
before I realized |
| 02:38.59 |
starseeker |
ah,
point |
| 02:39.52 |
starseeker |
Windows might
be a problem if they stick a drive letter at the beginning of a
path though |
| 02:40.33 |
starseeker |
brlcad:
distcheck passes here |
| 02:41.00 |
starseeker |
although come
to think of it, it did work on Windows |
| 02:48.18 |
brlcad |
cool |
| 02:48.22 |
brlcad |
mged
runs? |
| 02:48.33 |
brlcad |
what
platform/settings? |
| 02:49.02 |
starseeker |
gentoo x86_64
with --enable-all |
| 02:49.11 |
starseeker |
mged seems to
run |
| 02:49.16 |
starseeker |
will build
again with system tcl/tk |
| 02:49.59 |
brlcad |
okay, testing
mac here |
| 02:50.08 |
brlcad |
10.6 |
| 02:56.38 |
brlcad |
everyone
ready for GSoC? |
| 02:57.09 |
starseeker |
ah, that's on
again? |
| 02:57.10 |
starseeker |
sweet |
| 03:06.21 |
starseeker |
brlcad: just
a thought - with the cmake build, all the final build products are
right there in lib or bin |
| 03:08.21 |
DX^ |
IGES/STEP
converters are segfaulting on me |
| 03:08.23 |
DX^ |
with the
newest code |
| 03:08.51 |
starseeker |
on files that
worked previously? |
| 03:09.02 |
DX^ |
no, but the
STEP file I'm trying is just a box |
| 03:09.06 |
DX^ |
don't think
it can get much simpler |
| 03:09.14 |
starseeker |
what's the
error? |
| 03:09.35 |
DX^ |
"Segmentation
fault" |
| 03:09.42 |
starseeker |
ah, that's
it? |
| 03:09.56 |
DX^ |
yep |
| 03:09.59 |
starseeker |
DX^: can you
post the file on a bug report at sourceforge? |
| 03:10.15 |
starseeker |
brlcad: local
tcl/tk seems to work too |
| 03:10.32 |
DX^ |
starseeker:
yeah |
| 03:10.47 |
starseeker |
cool - we'll
need to hook up a debugger to see what happened |
| 03:32.13 |
brlcad |
starseeker:
that's good to hear -- what version of tcl? |
| 03:32.16 |
CIA-53 |
BRL-CAD:
03brlcad * r42877 10/brlcad/trunk/misc/Makefile.am: include
debian/source/include-binaries in dist |
| 03:32.27 |
brlcad |
suspects the crashes were 8.4 specific |
| 03:33.24 |
starseeker |
8.5.9 |
| 03:37.28 |
brlcad |
starseeker:
that's a good point regarding cmake build -- noprod might be
obsolete via that alone since you could run targetted rm's and
remake |
| 03:37.58 |
brlcad |
have to put
it through the paces with use to see what's most
efficient |
| 03:39.41 |
CIA-53 |
BRL-CAD:
03starseeker * r42878
10/brlcad/branches/cmake/src/other/togl/CMakeLists.txt: Stray
character |
| 03:39.53 |
CIA-53 |
BRL-CAD:
03tbrowder2 * r42879 10/brlcad/trunk/HACKING: added info on using
in-tree executables without installing\nadded words about developer
responsibilities |
| 03:48.10 |
CIA-53 |
BRL-CAD:
03starseeker * r42880
10/brlcad/branches/cmake/src/other/togl/demo/gears.tcl: Just
package require Togl for the gears demo - don't need to manually
load anything if we're set up correctly. |
| 03:53.17 |
CIA-53 |
BRL-CAD:
03tbrowder2 * r42881 10/brlcad/trunk/INSTALL: added information
about where file check sums are to be found |
| 04:14.11 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 05:08.29 |
CIA-53 |
BRL-CAD:
03starseeker * r42882
10/brlcad/branches/cmake/bench/CMakeLists.txt: benchmark needs
pixcmp |
| 05:36.33 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:33.42 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.33.253) |
| 06:33.42 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:26.28 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 07:35.18 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 09:59.48 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:49.28 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:52.28 |
epileg |
brlcad:
what's better? build deb packages with or without pdf
files? |
| 12:52.28 |
epileg |
with (≃ 85
MB.), without (≃ 55 MB.) |
| 13:58.38 |
starseeker |
epileg: for
now I'd say without |
| 13:58.55 |
epileg |
ok,
thanks! |
| 13:58.55 |
starseeker |
we have some
work to do before the pdf output from most of our stuff is fit for
consumption |
| 14:21.00 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42883 10/brlcad/branches/bottie/ (1260 files in
90 dirs): MFC 42842 |
| 14:37.09 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release prep for 7.18.2 under way
(20110202) |
| 14:37.26 |
brlcad |
starseeker:
did "make test" pass for you? |
| 14:37.56 |
brlcad |
I'm getting
all sorts of failures here, but still have to look into
why |
| 14:42.33 |
starseeker |
hmm - it's
failing to create solids.rt, shaders.rt... |
| 14:44.42 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.140.121) |
| 14:44.42 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:46.21 |
CIA-53 |
BRL-CAD:
03brlcad * r42884 10/brlcad/trunk/src/halftone/main.c:
enable-optimized linux strictness failure, check fwrite() return
value |
| 14:47.15 |
starseeker |
brlcad:
opendb isn't creating solids.g |
| 14:48.02 |
starseeker |
when it runs
opendb solids.g y the command completes, but a database is not
opened |
| 14:48.28 |
brlcad |
okay, that
should be easy to fix |
| 14:48.37 |
brlcad |
maybe even my
doing with the -f flag |
| 14:48.48 |
starseeker |
that was my
first guess |
| 14:49.00 |
brlcad |
an argc check
off by one or something |
| 14:49.33 |
brlcad |
cool,
optimized and unoptimized distchecks now all passing on
linux |
| 14:56.54 |
starseeker |
brlcad: I'm
guessing it's in 42564 |
| 14:57.21 |
brlcad |
hah, looks
like the logic is just reversed |
| 14:57.34 |
brlcad |
opendb
files.g n creates a database :) |
| 14:57.42 |
starseeker |
lol |
| 14:58.11 |
starseeker |
ok, so
probably not that commit then |
| 15:01.21 |
``Erik |
well, damn, I
just spent the last 2 days trying to get things together and
working to move bottie to trunk O.o |
| 15:01.38 |
starseeker |
why is that a
problem? |
| 15:02.08 |
``Erik |
if we're in
the middle of release cycle, it might not be the best time to do
it |
| 15:02.08 |
brlcad |
it can be the
highlight feature for 7.18.4 or 7.20 even |
| 15:02.33 |
brlcad |
get more
attention that way anyways |
| 15:02.46 |
*** join/#brlcad mafm
(~mafm@72.Red-83-45-72.dynamicIP.rima-tde.net) |
| 15:02.51 |
``Erik |
apparently
some weirdness happened, or svn sucks for this kinda merge, royal
pain :/ |
| 15:03.28 |
brlcad |
``Erik: it
sucks until that last to-do item is dealt with, which I'm planning
as soon as release is posted |
| 15:03.44 |
brlcad |
our repo is
too old to support merge tracking |
| 15:03.52 |
``Erik |
ah,
--reintegrate? |
| 15:03.54 |
brlcad |
that's what
has been causing some of the merge headache |
| 15:03.56 |
``Erik |
fsfs 2 vs 3
or something |
| 15:04.07 |
brlcad |
1.5+ backend
repo |
| 15:04.12 |
brlcad |
we're a 1.4
repo or something iirc |
| 15:04.24 |
starseeker |
``Erik: were
you going to try and track down the big missing pieces in bottie
raytracing prior to merge? |
| 15:04.49 |
starseeker |
or just stick
with the insane high threshold for now |
| 15:05.23 |
``Erik |
starseeker:
was going to have an obnoxiously high # and work it after merge, I
seem to spend way more time merging and resolving conflicts to try
to track trunk than getting to actually work on it |
| 15:06.06 |
``Erik |
wonders if there's a darcs/svn bridge O.o |
| 15:09.56 |
starseeker |
``Erik: then
you should be pretty safe to merge, yes? |
| 15:11.14 |
``Erik |
probably
*shrug* |
| 15:16.13 |
brlcad |
I wouldn't
call that merge-safe in the least .. heh |
| 15:16.20 |
brlcad |
it's a huge
body of change to code and a new feature |
| 15:18.38 |
brlcad |
release safe
things are like minor bug fixes, updating documentation, tweaking a
bu_log, removing dead code, adding comments, ... |
| 15:21.13 |
brlcad |
that really
is great feature for the next release where it can be spoken to and
highlighted, maybe erik can write up a mini article about it all
even |
| 15:22.00 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42885 10/brlcad/trunk/src/halftone/main.c: more
missed size_t changes |
| 15:24.38 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42886 10/brlcad/trunk/src/libged/ (vdraw.c
wdb_vdraw.c): cast to long unsigned int to match
wdb_vdraw.clu |
| 15:25.05 |
``Erik |
ugh, tons of
those in src/conv |
| 15:26.01 |
brlcad |
want me to
disable strict or you going to hit em up? |
| 15:26.30 |
brlcad |
I don't have
a plat that warns on that one opt or non-opt |
| 15:26.37 |
``Erik |
I can hit
them, bit nervous about casting read pointers like that
blindly |
| 15:26.41 |
``Erik |
crit should
do it |
| 15:27.14 |
``Erik |
FreeBSD
8.2-PRERELEASE #3: Thu Dec 2 13:59:53 EST 2010 |
| 15:28.08 |
``Erik |
using system
tcl, tk, tnt, debug off (that seems to be a big one), optimized
on |
| 15:28.50 |
CIA-53 |
BRL-CAD:
03brlcad * r42887 10/brlcad/trunk/TODO: two release issues being
worked on now, opendb failure and strict failures on
fbsd |
| 15:28.57 |
brlcad |
ah, debug off
.. haven't tries that in a while |
| 15:29.52 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42888
10/brlcad/trunk/src/libtclcad/tkImgFmtPIX.c: more size_t
fixing |
| 15:40.57 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42889 10/brlcad/trunk/src/conv/ (6 files in 3
dirs): casts/changes to cope with size_t vs vprintf |
| 15:46.12 |
``Erik |
that seems to
be all the type warnings, there is still the tcl85 vs tcl8.5 link
error when building tcl with BRL-CAD, though :/ |
| 15:49.35 |
CIA-53 |
BRL-CAD:
03brlcad * r42890
10/brlcad/trunk/src/libbu/booleanize.c: |
| 15:49.36 |
CIA-53 |
BRL-CAD:
bu_booleanize() FAIL. several problems: 1) \!str == 0 means we
return false for |
| 15:49.36 |
CIA-53 |
BRL-CAD: all
non-null strings, 2) strtol() will return 0 if there are no numbers
(boo, |
| 15:49.36 |
CIA-53 |
BRL-CAD:
hiss), and 3) it wasn't taking whitespace into consideration. stash
the input |
| 15:49.36 |
CIA-53 |
BRL-CAD: into
a vls, trim whitespace, then perform our tests. |
| 15:49.49 |
starseeker |
brlcad: heh,
you just beat me to it |
| 15:49.53 |
starseeker |
was writting
my commit message |
| 15:50.55 |
CIA-53 |
BRL-CAD:
03brlcad * r42891 10/brlcad/trunk/src/libbu/booleanize.c: remove
debug statements |
| 15:51.35 |
brlcad |
starseeker:
ah, heh -- what was your change? |
| 15:51.41 |
brlcad |
there's
another problem in mged.c |
| 15:52.09 |
starseeker |
was doing str
== NULL instead of !str |
| 15:52.24 |
starseeker |
!str was
returning 0 here even for a valid string |
| 15:52.39 |
starseeker |
good call on
the whitespace |
| 15:53.34 |
CIA-53 |
BRL-CAD:
03brlcad * r42892 10/brlcad/trunk/src/mged/mged.c: logic is
reversed. if NOT true, i.e. the user responded 'n', then report
that no database is open. |
| 15:53.41 |
brlcad |
!str is 0 for
all valid strings ;) |
| 15:53.49 |
brlcad |
!str is only
true if str is null :) |
| 15:54.03 |
starseeker |
ah,
gotcha |
| 15:54.38 |
starseeker |
one possible
improvement I can still make... |
| 15:54.43 |
brlcad |
it should
have been "str == NULL" or "!str" .. but "!str == NULL" (i.e.,
"!str == 0") means that all valid strings will return
negative |
| 15:54.51 |
starseeker |
hehe |
| 15:54.53 |
CIA-53 |
BRL-CAD:
03starseeker * r42893 10/brlcad/trunk/src/libbu/booleanize.c: Can
still use strtol, but need to make sure endptr is '\0' (i.e., that
a valid number was actually processed). |
| 15:55.53 |
starseeker |
brlcad: if
I'm reading the strtol documentation right, that will
work |
| 15:56.23 |
brlcad |
hm |
| 15:56.25 |
brlcad |
"If there
were no digits at all, however, strtol() stores the original value
of str in *endptr. |
| 15:56.39 |
starseeker |
right |
| 15:56.48 |
brlcad |
okay, I think
I see it |
| 15:58.42 |
CIA-53 |
BRL-CAD:
03starseeker * r42894 10/brlcad/trunk/src/libbu/booleanize.c:
whoops - val is an int |
| 15:59.07 |
brlcad |
what do you
think about bu_true() instead of bu_booleanize() ? |
| 15:59.22 |
brlcad |
for
readability, if (bu_true(some_string)) ... |
| 15:59.43 |
starseeker |
it's a bit
shorter... does true imply anything that booleanize doesn't? (or
vice versa?) |
| 16:00.15 |
starseeker |
have expects bu_true to always return true, but that's just a
silly reflex |
| 16:00.21 |
starseeker |
s/have/half |
| 16:00.26 |
brlcad |
the name
bu_booleanize() doesn't imply a truth return value, so it's funky
to read and get the logic right |
| 16:00.46 |
brlcad |
the mged.c
change for example |
| 16:01.09 |
starseeker |
I'm cool with
bu_true |
| 16:01.13 |
brlcad |
bu_str_true() |
| 16:01.22 |
starseeker |
ah, yeah
that's better |
| 16:01.25 |
starseeker |
little more
specific |
| 16:04.08 |
CIA-53 |
BRL-CAD:
03starseeker * r42895 10/brlcad/trunk/src/libbu/booleanize.c: Let's
stay consistent - long, not int |
| 16:04.18 |
brlcad |
namingwise,
bu_str_to_rgb() is the only other bu_str_ along with the C wrappers
bu_strdup, bu_strcpy, etc |
| 16:05.02 |
starseeker |
well, either
way |
| 16:05.12 |
starseeker |
doesn't have a real strong opinion |
| 16:05.46 |
brlcad |
bu_str_to_bool() is no better than
bu_booleanize() |
| 16:06.13 |
brlcad |
heh,
bu_truthify() |
| 16:06.46 |
brlcad |
bu_test_whether_string_is_yes() |
| 16:07.00 |
*** join/#brlcad Zaebos
(~irc@217.91.127.94) |
| 16:07.10 |
``Erik |
why do I feel
like the description needs the phrase "and truthishly" in
it |
| 16:07.27 |
CIA-53 |
BRL-CAD:
03starseeker * r42896 10/brlcad/trunk/src/adrt/libtie/tie.c: tie.h
includes common.h, so don't need to include it twice - fixes
regress common.h inclusion order error. |
| 16:09.16 |
starseeker |
brlcad: we
still have bio.h in cmd.h - I guess the thing to do is take it out
and see what fails on Windows? |
| 16:11.25 |
brlcad |
sure, though
the comment says why it's there |
| 16:11.29 |
brlcad |
timeval from
windows.h |
| 16:11.31 |
starseeker |
was included
in 41077... if it does need to be there (and since some guy called
brlcad committed it I'm guessing we really do) we should probably
special case exempt that in the regression test |
| 16:12.12 |
brlcad |
so either
cmd.h needs the same windows wrapper logic like bio.h has or bio.h
has to be included before all instances of cmd.h |
| 16:12.35 |
starseeker |
or we tweak
the regression test... |
| 16:12.49 |
brlcad |
just because
I committed it does mean it's right.. looks wrong to me
:) |
| 16:13.18 |
brlcad |
having to put
exceptions usually implies something is wrong |
| 16:14.42 |
starseeker |
mutter...
mged has its own cmd.h file, clutters up grep |
| 16:14.49 |
starseeker |
tunes... |
| 16:16.12 |
starseeker |
wow, cmd.h is
popular |
| 16:17.00 |
brlcad |
to be a
self-contained header including what it needs, cmd.h should
probably just have the windows.h logic |
| 16:17.11 |
starseeker |
is doing that now... |
| 16:19.02 |
CIA-53 |
BRL-CAD:
03starseeker * r42897 10/brlcad/trunk/include/cmd.h: grab the
relevant part of bio.h's windows.h inclusion logic and put it in
cmd.h, rather than including bio.h (should fix regression test
failure. |
| 16:21.51 |
CIA-53 |
BRL-CAD:
03brlcad * r42898 10/brlcad/trunk/ (include/bu.h
src/libbu/booleanize.c src/mged/mged.c): |
| 16:21.51 |
CIA-53 |
BRL-CAD:
rename bu_booleanize() to bu_str_true() which is not only two chars
shorter but |
| 16:21.51 |
CIA-53 |
BRL-CAD:
reads much better within if-statements. not as cool a name, but
hopefully less |
| 16:21.51 |
CIA-53 |
BRL-CAD:
prone to logic errors. also add the counterpart bu_str_false() to
have a |
| 16:21.52 |
CIA-53 |
BRL-CAD:
matching set and for readability. |
| 16:24.13 |
CIA-53 |
BRL-CAD:
03starseeker * r42899 10/brlcad/branches/cmake/ (22 files in 14
dirs): Update cmake branch to trunk r42898 - need to do some manual
checking, probably missed a few things earlier when working in both
trees at once. |
| 16:42.20 |
CIA-53 |
BRL-CAD:
03starseeker * r42900 10/brlcad/trunk/regress/repository.sh: have
repository.sh look in TOPSRC for the INSTALL file too, not just
configure.ac. |
| 16:43.55 |
CIA-53 |
BRL-CAD:
03starseeker * r42901 10/brlcad/trunk/INSTALL: blt is no
more |
| 16:44.38 |
CIA-53 |
BRL-CAD:
03bob1961 * r42902
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Modified
ArcherCore::updateRtControl to call rtcntrl's updateControlPanel
instead of configuring -size. |
| 16:45.31 |
CIA-53 |
BRL-CAD:
03starseeker * r42903 10/brlcad/trunk/ (INSTALL configure.ac): It's
just tkhtml now |
| 16:47.03 |
CIA-53 |
BRL-CAD:
03bob1961 * r42904
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added code to
remember Archer's window size. |
| 16:48.00 |
CIA-53 |
BRL-CAD:
03starseeker * r42905 10/brlcad/trunk/INSTALL: tkimg ->
tkpng |
| 16:49.41 |
brlcad |
``Erik: ah, I
see what you're saying about the casts |
| 16:49.52 |
CIA-53 |
BRL-CAD:
03starseeker * r42906 10/brlcad/trunk/configure.ac: remove togl
logic from configure.ac altogether - togl CMake logic is
succeeding, and it is unlikely we will go back to do autotools
version. |
| 16:49.53 |
brlcad |
yeah, casting
a scanf probably isn't safe |
| 16:50.20 |
brlcad |
probably need
a temp var that can be set to the size_t after the
scanf |
| 16:52.00 |
brlcad |
printing
casts should be fine, scanning casts probably not |
| 16:52.08 |
brlcad |
reviewing
now |
| 16:52.30 |
CIA-53 |
BRL-CAD:
03starseeker * r42907 10/brlcad/trunk/configure.ac: add alias for
tktable |
| 16:52.48 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:54.13 |
CIA-53 |
BRL-CAD:
03starseeker * r42908 10/brlcad/trunk/ (INSTALL configure.ac): add
tkpng-build alias |
| 17:01.13 |
brlcad |
that alias
already exists |
| 17:01.15 |
brlcad |
"tktable-build" |
| 17:01.23 |
brlcad |
see the
comment before |
| 17:01.39 |
brlcad |
(it's not an
alias, it's the actual) |
| 17:01.52 |
brlcad |
same for
tkpng |
| 17:01.57 |
starseeker |
oh, ok -
sorry |
| 17:03.26 |
CIA-53 |
BRL-CAD:
03starseeker * r42909 10/brlcad/trunk/configure.ac: remove unneeded
alias lines |
| 17:10.11 |
*** join/#brlcad mafm_
(~mafm@72.Red-83-45-72.dynamicIP.rima-tde.net) |
| 17:17.42 |
CIA-53 |
BRL-CAD:
03starseeker * r42910 10/brlcad/trunk/configure.ac: I imagine there
are more of these issues, but it looks like rtgl should be a
'with', not an 'enable' in the build logic. |
| 17:20.05 |
CIA-53 |
BRL-CAD:
03starseeker * r42911 10/brlcad/trunk/INSTALL: remainder of INSTALL
documentation options - repository-regress should now
succeed. |
| 17:22.29 |
CIA-53 |
BRL-CAD:
03starseeker * r42912 10/brlcad/branches/cmake/ (5 files in 3
dirs): MFC 42911 |
| 17:35.50 |
CIA-53 |
BRL-CAD:
03starseeker * r42913
10/brlcad/branches/cmake/regress/CMakeLists.txt: Ah right, DEPENDS
can't tell if the target's done anything if it's set up this way -
just have regress run 'em all. Regression test fully
succeeded. |
| 17:35.52 |
starseeker |
woo-hoo! |
| 17:35.56 |
starseeker |
heads in |
| 17:41.09 |
dloman |
Ice clearing
up? |
| 17:42.31 |
brlcad |
starseeker:
awesome, thanks for fixing those! |
| 17:46.13 |
brlcad |
--enable-*
turns compilation of things on/off |
| 17:46.26 |
brlcad |
s/things/code/ |
| 17:46.53 |
brlcad |
--with-*
turns usage of system components on/off |
| 17:48.02 |
brlcad |
with/without
X11, OpenGL, Mac Frameworks, particular threading types,
etc |
| 17:50.09 |
brlcad |
enable/disable compiling things in our
code like building src/other, compilation modes, subcompiles,
etc |
| 17:50.46 |
brlcad |
another way
to think of it is --enable/--disable => internal and
--with/--without => external |
| 17:53.31 |
CIA-53 |
BRL-CAD:
03brlcad * r42914 10/brlcad/trunk/configure.ac: rtgl was okay as an
--enable flag. enable/disable for inward code selection,
with/without for outward system selection. |
| 17:53.50 |
``Erik |
mmm, pröst
coma |
| 17:54.57 |
brlcad |
mmm |
| 17:55.26 |
brlcad |
I need to
stop coding and get back to studying soon |
| 18:04.43 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42915 10/brlcad/trunk/bench/pixcmp.c: break help
message into two strings to bring it under 509 characters (ISO
C90) |
| 18:10.39 |
CIA-53 |
BRL-CAD:
03brlcad * r42916 10/brlcad/trunk/INSTALL: document rtgl and expand
the explanation of configuration options to detail what is
different between the enable and with options. reword a little for
clarity too. |
| 18:11.05 |
CIA-53 |
BRL-CAD:
03brlcad * r42917 10/brlcad/trunk/configure.ac: comment on rtgl
option |
| 18:30.29 |
CIA-53 |
BRL-CAD:
03brlcad * r42918 10/brlcad/trunk/src/libged/vdraw.c: scanning into
a coerced pointer probably isn't a good idea, so revert back down
to unsigned long for the scan and upconvert the comparisons
accordingly |
| 18:33.07 |
CIA-53 |
BRL-CAD:
03brlcad * r42919 10/brlcad/trunk/src/libged/wdb_vdraw.c: this
duplication of effort really sucks. fix the same size_t uind issues
that were in vdraw.c |
| 18:34.50 |
brlcad |
that should
do it, beginning another round of testing |
| 18:36.16 |
CIA-53 |
BRL-CAD:
03tbrowder2 * r42920 10/brlcad/trunk/HACKING: stick with rough
English translation--rest is covered in later parts |
| 18:39.15 |
brlcad |
mm, crit is
full |
| 18:40.05 |
``Erik |
in /home ?
there's some issue with rsync duping things or
something |
| 18:40.21 |
brlcad |
intentional |
| 18:40.27 |
brlcad |
not duping,
just not deleting |
| 18:40.34 |
brlcad |
i'm cleaning
up some space |
| 18:41.23 |
brlcad |
easy enough
to clear out the big offenders and let them re-rsync later ..
checking usage now |
| 18:51.45 |
dloman |
anything i
did? |
| 18:53.17 |
*** join/#brlcad Ralith
(~ralith@d142-058-094-230.wireless.sfu.ca) |
| 18:53.18 |
``Erik |
nah |
| 18:53.56 |
``Erik |
stuff like me
doing BRL-CAD builds, people collating/cleaning/deleting irc logs
on bz and having dups show up on crit, etc |
| 18:54.45 |
``Erik |
the way it's
set up, if I go on bz and decide to compress every text file in a
directory, crit will have both the compressed and uncompressed ones
sitting next to eachother |
| 18:57.11 |
CIA-53 |
BRL-CAD:
03brlcad * r42921 10/brlcad/trunk/HACKING: |
| 18:57.11 |
CIA-53 |
BRL-CAD:
split the difference. emphasize build breaking and maintainability
concern in |
| 18:57.11 |
CIA-53 |
BRL-CAD: the
second point as developer mantra. also, add a brief hint to the
first point |
| 18:57.11 |
CIA-53 |
BRL-CAD: that
it's speaking to people's character and the community, not just the
code. |
| 18:58.27 |
epileg |
is there
someone working on the creation of rpm package for
fedora? |
| 19:02.52 |
brlcad |
there, lots
of space |
| 19:03.11 |
brlcad |
``Erik: big
offender was a massive core dump that got syncd :) |
| 19:03.58 |
brlcad |
there's
40GB |
| 19:04.01 |
``Erik |
ahhh |
| 19:04.21 |
``Erik |
that'd do
it |
| 19:05.50 |
``Erik |
epileg: I
think starseeker tried to set up a fedora image to try to get the
spec.in up to date, it's not exactly a priority for us unless
someone wants to step up and take care of it |
| 19:06.33 |
brlcad |
epileg: go
for it ;) |
| 19:06.57 |
brlcad |
sh/make_rpm.sh :D |
| 19:12.59 |
epileg |
Ok, I'll try,
but in rpm systems the situation is different than in debian like
ones. They share the same packaging system (rpm), but the package
nomenclature is different between distributions. |
| 19:14.25 |
epileg |
so, the
fedora rpm package will be only for fedora, and not installable in
opensuse |
| 19:14.37 |
``Erik |
starseeker:
dm-rtgl is chock full of GLX stuff, allowing it to try to build on
winderz won't work |
| 19:16.57 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2454
10/wiki/Community_Publication_Portal: update date, still in
draft |
| 19:17.50 |
brlcad |
epileg: ah,
interesting -- didn't know that |
| 19:18.32 |
brlcad |
there can be
a --fedora or --generic flag to the script for making the other
type |
| 19:19.27 |
brlcad |
right now,
there is no rpm generation whatsoever, so it almost goes without
saying that anything you do will be an improvement ;) |
| 19:23.09 |
``Erik |
well,
brlcad.spec.in and just run rpm -someflag on it, iirc, but it needs
write access to like /usr/src/redhat/SOURCES/ and stuff,
iirc |
| 19:25.33 |
brlcad |
so the script
is probably a one-liner or maybe few-liner with error-checking on
environment assumptions |
| 19:25.49 |
brlcad |
that's still
one line I don't want to memorize :) |
| 19:26.43 |
``Erik |
yeh, I built
it into a make target a long time ago, um, dunno if it still exists
in BRL-CAD, but I can dig it up in other old projects (if it's
still even pertinent... I think the spec format changed, that's why
starseeker was trying to work on it) |
| 19:34.58 |
brlcad |
*shrug* |
| 19:35.36 |
brlcad |
I don't think
there's anything in brl-cad any more -- if something doesn't get
maintained and can't be verified that it works, I generally yank it
so it doesn't slow down the next guy |
| 19:48.59 |
``Erik |
misc/brlcad.spec.in is there and it's
still in the AC_OUTPUT *shrug* |
| 19:50.33 |
CIA-53 |
BRL-CAD:
03brlcad * r42922 10/brlcad/trunk/HACKING: set jordi up as the .deb
maintainer |
| 19:50.38 |
brlcad |
but no rpm
line hooking it in |
| 19:50.45 |
brlcad |
just there
for those that know what a spec file is |
| 19:51.09 |
``Erik |
line 159 of
/Makefile.am |
| 19:51.16 |
``Erik |
:D |
| 19:51.48 |
brlcad |
ah, okay very
good then |
| 19:51.57 |
brlcad |
probably
should move that up into the make_rpm.sh script |
| 19:52.17 |
brlcad |
hm, distcheck
is not happy on fbsd |
| 19:52.50 |
brlcad |
apparently
its doing a "make distdir" on something in src/other that doesn't
have that rule |
| 19:57.25 |
starseeker |
``Erik:
gaaaahhh. OK. |
| 19:57.33 |
starseeker |
rtgl is
busted anyway |
| 20:03.41 |
CIA-53 |
BRL-CAD:
03starseeker * r42923 10/brlcad/branches/cmake/CMakeLists.txt:
Don't try rtgl unless we've got X11 |
| 20:06.16 |
starseeker |
grrrrr....
now unistd.h and glxext.h are arguing on my Mac |
| 20:07.10 |
starseeker |
may be time
to upgrade this baby |
| 20:10.43 |
brlcad |
``Erik: soo,
guess what |
| 20:10.56 |
brlcad |
I'm upgrading
crit to better hardware :) |
| 20:11.16 |
brlcad |
they're going
to attach the current hard drive via USB to the new
hardware |
| 20:11.21 |
brlcad |
should more
than double the performance |
| 20:13.12 |
``Erik |
hah,
cool |
| 20:13.30 |
``Erik |
wonders how many hw iterations the 'new server' will go
through before migration O:-) |
| 20:14.09 |
``Erik |
might try
doing "gmake distcheck" instead of "make distcheck"? |
| 20:14.28 |
``Erik |
there're
still a couple flakey rough spots between bsdmake and
auto* |
| 20:18.18 |
brlcad |
I'm hoping
this motivates me since it's in context now |
| 20:18.30 |
brlcad |
plus hella
faster and bigger |
| 20:18.49 |
brlcad |
less
bandwidth, but even .bz will only consume about 50% on
average |
| 20:19.22 |
brlcad |
1TB disk,
dual P4 3.0, 2GB, 100Mbs |
| 20:19.45 |
brlcad |
500GB
transfer cap |
| 20:20.24 |
``Erik |
nice, enough
cpu that the load may drop below the number of cores
O.O |
| 20:21.17 |
``Erik |
and enough
memory that it won't be in swapland like bz |
| 20:23.43 |
*** join/#brlcad Ralith
(~ralith@d142-058-076-096.wireless.sfu.ca) |
| 20:29.04 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 20:37.01 |
*** join/#brlcad Ralith_
(~ralith@d142-058-076-096.wireless.sfu.ca) |
| 20:46.00 |
CIA-53 |
BRL-CAD:
03starseeker * r42924 10/brlcad/trunk/ (NEWS src/nirt/command.c):
Ow. nirt units command was reporting all unit changes as invalid
(even 'm') - this seems to fix it, but someone else should
verify. |
| 20:46.41 |
CIA-53 |
BRL-CAD:
03starseeker * r42925 10/brlcad/trunk/NEWS: # -> * |
| 20:57.54 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 21:08.34 |
CIA-53 |
BRL-CAD:
03bob1961 * r42926 10/brlcad/trunk/src/ (libged/rect.c
libtclcad/ged_obj.c): Call dm_draw_rect() only if grs_draw and
grs_line width are not zero. |
| 21:22.36 |
brlcad |
server
transfer under way |
| 21:25.41 |
epileg |
who's the
maintainer of "misc/brlcad.spec.in"? |
| 21:26.19 |
brlcad |
epileg: "svn
log misc/brlcad.spec.in" will say who all has edited the
file |
| 21:26.43 |
epileg |
thanks |
| 21:27.09 |
brlcad |
starseeker:
remember that the last comment is the one that will show up in the
configuraiton review report |
| 21:29.05 |
brlcad |
looks like
distcheck and release tests are passing on mac now with only one
test needing investigating |
| 21:29.24 |
brlcad |
fastgen test
is reporting "realpath: No such file or directory" several
times |
| 21:29.36 |
brlcad |
followed by a
Tcl_Init failure |
| 21:30.13 |
starseeker |
brlcad: oh,
sorry |
| 21:30.32 |
brlcad |
http://pastebin.mozilla.org/1015503 |
| 21:31.06 |
CIA-53 |
BRL-CAD:
03starseeker * r42927
10/brlcad/branches/cmake/src/other/step/CMake/SCL_Utils.cmake: Make
the SCL install commands more generic |
| 21:31.26 |
brlcad |
``Erik: 8.1
is no longer pre-release, stable okay? |
| 21:31.48 |
``Erik |
stable is
8.2RC3 right n ow |
| 21:32.01 |
``Erik |
once 8.2
comes out, I'll upgrade the system |
| 21:32.12 |
``Erik |
so any old
8.x, right? um |
| 21:32.22 |
brlcad |
crit is
presently 8.1-prerelease |
| 21:32.42 |
``Erik |
it's running
8.1-prerelease, it has 8.2rc2 installed iirc, I just haven't been
rebooting it |
| 21:32.44 |
brlcad |
you want
8.2RC3 or 8.1 stable? |
| 21:32.54 |
brlcad |
or doesn't
matter |
| 21:32.59 |
``Erik |
doesn't
matter |
| 21:33.02 |
brlcad |
k |
| 21:33.28 |
``Erik |
we'll upgrade
when 8.2 goes stable and lock on that branch for security updates
until 8.3 comes out, right? |
| 21:33.39 |
starseeker |
would be happy never to have to deal with path logic
again... |
| 21:33.45 |
starseeker |
brlcad:
that's on a 10.6 mac? |
| 21:33.51 |
``Erik |
http://www.freebsd.org/releases/8.2R/schedule.html |
| 21:38.32 |
CIA-53 |
BRL-CAD:
03starseeker * r42928 10/brlcad/trunk/NEWS: nirt units command was
reporting all units as invalid - fixed |
| 21:41.36 |
brlcad |
starseeker:
yes |
| 21:41.58 |
starseeker |
nevermind, I
see it here too. |
| 21:42.02 |
starseeker |
g_diff is
failing |
| 21:42.56 |
starseeker |
that may be
the tclcad_tcl_library() removal |
| 21:44.23 |
starseeker |
no,
wait... |
| 21:44.31 |
starseeker |
maybe not
g_diff... |
| 21:44.47 |
brlcad |
g_diff
probably has its own tcl interpreter |
| 21:45.00 |
brlcad |
so if a
change was made to bwish and mged, might need something there
too |
| 21:45.02 |
starseeker |
it does, but
running it in isolation succeeds |
| 21:47.22 |
starseeker |
ah, there we
go |
| 21:47.36 |
starseeker |
running it
from toplevel dir succeeds, not from regress |
| 21:47.40 |
starseeker |
digs... |
| 21:55.00 |
starseeker |
that's
why... |
| 21:55.05 |
brlcad |
realpath
blather found/fixed |
| 21:55.10 |
CIA-53 |
BRL-CAD:
03brlcad * r42929 10/brlcad/trunk/src/libbu/brlcad_path.c: there's
no need to perror() on realpath failure |
| 21:56.59 |
CIA-53 |
BRL-CAD:
03starseeker * r42930 10/brlcad/trunk/src/gtools/g_diff.c: By the
time g_diff was doing Tcl_FindExecutable, argv[0] referred to the
first file supplied and not the executable name. Instead, use the
'invoked_as' string |
| 21:57.00 |
starseeker |
brlcad: that
should do it. |
| 21:57.37 |
starseeker |
has to go take cats to vet... |
| 21:57.50 |
CIA-53 |
BRL-CAD:
03brlcad * r42931 10/brlcad/trunk/configure.ac: comment
tweak |
| 21:57.55 |
brlcad |
awesome,
thanks! |
| 21:58.13 |
brlcad |
enjoy your
delicious dinner ;) |
| 22:06.22 |
brlcad |
well now
that's really odd |
| 22:07.07 |
brlcad |
running
"../src/gtools/g_diff fastgen_unix.g fastgen_dos.g" stand-alone
works, but inside the script with the same pwd it blathers a tcl
failure |
| 22:09.46 |
brlcad |
er... someone
changed the fastgen regression script |
| 22:10.37 |
brlcad |
supposed to
create a unix line-ending fastgen conversion, create a dos
line-ending fast conversion, and compare the two |
| 22:10.51 |
brlcad |
it's creating
the dos version by simply copying the unix version! |
| 22:11.50 |
epileg |
@MAJOR_VERSION@, @MINOR_VERSION@ and
@PATCH_VERSION@ variables do not change when "misc/brlcad.spec" is
created |
| 22:14.10 |
brlcad |
ahh, my bad
.. was reading the script wrong .. turning my internal alarm
off |
| 22:15.27 |
brlcad |
epileg: those
don't sound like the right variables |
| 22:15.32 |
``Erik |
hm, not being
AC_SUBST'd anymore |
| 22:15.33 |
brlcad |
probably out
of date |
| 22:15.50 |
epileg |
aha |
| 22:15.52 |
``Erik |
probably
switch the version to @BRLCAD_VERSION@ and the release to '1' or
something, or take release out |
| 22:16.46 |
epileg |
yes. where
can i find the variable list? |
| 22:18.06 |
``Erik |
configure.ac |
| 22:18.12 |
epileg |
ok,
thanks! |
| 22:18.14 |
``Erik |
grep AC_SUBST
configure.ac |
| 22:31.30 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2455
10/wiki/Community_Publication_Portal: less is more. be
briefer. |
| 22:33.05 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2456
10/wiki/Community_Publication_Portal: move note down to publication
section |
| 22:35.19 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2457
10/wiki/Community_Publication_Portal: reduce intro
further |
| 23:34.44 |
starseeker |
growls... worst traffice I think I've ever run into on
22 |
| 23:34.50 |
starseeker |
missed the
appointment |
| 23:35.04 |
*** join/#brlcad Ralith
(~ralith@d142-058-094-230.wireless.sfu.ca) |
| 23:36.04 |
starseeker |
brlcad: it's
still failing? that should have fixed it... |
| 23:47.33 |
CIA-53 |
BRL-CAD:
03starseeker * r42932 10/brlcad/branches/cmake/ (15 files in 9
dirs): MFC r42931 |
| 23:50.26 |
CIA-53 |
BRL-CAD:
03starseeker * r42933 10/brlcad/branches/cmake/ (. src/other/step/
src/other/tkhtml/): mergeinfo property is annoying, not using it -
remove from cmake branch |
| 00:28.45 |
brlcad |
starseeker: I
just finished a clean recompile to test |
| 00:28.48 |
brlcad |
it's
working |
| 00:29.01 |
brlcad |
the problem
is running tcl applications without having installed BRL-CAD
first |
| 00:29.21 |
brlcad |
have to make
install BEFORE make test or it'll fail on OS X .. haven't figured
out how to fix that yet |
| 00:30.17 |
brlcad |
it finds the
system-installed Tcl at runtime |
| 00:31.37 |
starseeker |
ah |
| 00:32.21 |
starseeker |
yeah, I'll
usually test in CMake if I'm doing a non-installed
trial.. |
| 00:35.03 |
brlcad |
it should
fail in cmake just the same actually unless they modify the LD
paths accordingly |
| 00:36.33 |
starseeker |
I've got some
RPATH settings enabled that seem to do wonders |
| 00:37.24 |
starseeker |
you should
give it a try sometime :-P |
| 00:40.08 |
brlcad |
oh, I believe
ya -- another plus if they have better rpath management |
| 00:41.12 |
CIA-53 |
BRL-CAD:
03brlcad * r42934 10/brlcad/trunk/m4/patch.m4: (log message
trimmed) |
| 00:41.13 |
CIA-53 |
BRL-CAD:
sigh, no response from the libtool mailing list on this issue so
restore the |
| 00:41.13 |
CIA-53 |
BRL-CAD: hack
that makes libtool binary wrapper scripts work on Mac OS X. we
sneak in |
| 00:41.13 |
CIA-53 |
BRL-CAD:
paths to the Tcl/Tk compile-time lib directories so that they'll
get |
| 00:41.13 |
CIA-53 |
BRL-CAD:
automatically added to DYLD_LIBRARY_PATH. due to suck in the way
temp_rpath is |
| 00:41.13 |
CIA-53 |
BRL-CAD:
handled, the trailing ':' is required otherwise the path will get
munged with |
| 00:41.14 |
CIA-53 |
BRL-CAD: the
next pathlist incorrectly. document why this oddity is even in
here, why |
| 00:42.50 |
starseeker |
brlcad: about
the --enable-only-benchmark option... does that actively squash
other options and turn on just what's needed for the benchmark
build? |
| 00:43.04 |
starseeker |
(also, what's
the advantage of that over a normal configure and make
benchmark?) |
| 00:45.09 |
brlcad |
it only
enables and builds exactly enough to run the benchmark |
| 00:46.06 |
brlcad |
greatly
shortens the build time (by less than a 10th iirc) |
| 00:46.52 |
brlcad |
reduces the
configure tests and reduces compilation to approximately the
minimum |
| 00:47.37 |
starseeker |
so the
configure time is the difference between that and just doing a
normal configure + make benchmark? |
| 00:48.55 |
brlcad |
make
benchmark still builds everything, then runs cd bench &&
make bench |
| 00:49.15 |
brlcad |
"everything"
for an --enable-only-benchmark build is the bare
minimum |
| 00:49.26 |
brlcad |
mged, asc2g,
pixcmp, etc |
| 00:49.26 |
starseeker |
ah. |
| 00:50.00 |
starseeker |
The CMake
build is set up so that a normal configure + make benchmark will
build just what is needed for the benchmark and run it - is this an
acceptable alternative? |
| 00:50.13 |
brlcad |
in theory,
with cmake you should be able to describe a new benchmark rule that
has the proper minimal dependencies |
| 00:50.22 |
starseeker |
did :-) |
| 00:50.29 |
brlcad |
yep, that's
fine |
| 00:50.34 |
starseeker |
sweet |
| 00:51.12 |
brlcad |
the only
difference is probably that "make install" would only install the
benchmark too :) |
| 00:51.19 |
``Erik |
less than
1/10th... before opennurbs? :) |
| 00:51.54 |
brlcad |
heh, don't
know |
| 00:52.13 |
starseeker |
is betting yes - librt needs opennurbs, which is a large
percentage of time |
| 00:52.40 |
brlcad |
still gets to
avoid step dir, half of src/other, hundreds of other
utils |
| 00:52.58 |
starseeker |
true |
| 00:53.00 |
``Erik |
um, it
blindly does src/conv which has the step stuff, right? |
| 00:53.13 |
brlcad |
don't
recall |
| 00:53.18 |
brlcad |
it
might |
| 00:53.33 |
starseeker |
well, make
benchmark is pretty quick in CMake - that does avoid
step |
| 00:53.44 |
starseeker |
but there's
no escaping opennurbs :-P |
| 00:53.57 |
brlcad |
easy enough
for someone to test the difference if it mattered |
| 00:54.20 |
brlcad |
starseeker:
you have rough idea of how long a full build and benchmark-only
build take? |
| 00:57.32 |
starseeker |
with cmake or
autotools? |
| 00:57.55 |
starseeker |
also,
benchmark skips all the static libs which makes a big
difference |
| 00:58.21 |
brlcad |
either |
| 00:58.23 |
brlcad |
both |
| 00:58.29 |
brlcad |
<PROTECTED> |
| 00:58.29 |
brlcad |
<PROTECTED> |
| 00:58.52 |
brlcad |
ouch.. that's
a sad v4 flip case |
| 00:59.18 |
brlcad |
1 plithy
object that failed to validate whether flipped or not causing
trouble for everything else |
| 00:59.24 |
starseeker |
brlcad: let
me do some tests... |
| 00:59.31 |
starseeker |
ouch |
| 00:59.43 |
starseeker |
that reminds
me - does the flip routine handle ars primitives? |
| 01:00.02 |
brlcad |
I talked to
D, that's what I'm looking into |
| 01:01.09 |
starseeker |
ah,
cool |
| 01:03.02 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 01:14.14 |
starseeker |
CMake make
-j3 benchmark, from beginning to start of actually running the
benchmarks, not including configure time - ~2 minutes, maybe a bit
less |
| 01:18.33 |
starseeker |
hmm - pulled
in libpc on autotools... |
| 01:20.57 |
starseeker |
little over 4
minutes for the same thing with autotools |
| 01:21.24 |
starseeker |
appears it
did not pull in step in either case |
| 01:22.04 |
starseeker |
both of those
times used system libs instead of building local copies |
| 01:32.46 |
brlcad |
starseeker:
technically, librt needs libpc |
| 01:33.13 |
starseeker |
8.5 minutes
for an autotools build, no docbook |
| 01:33.44 |
brlcad |
full cmake
build takes how long? |
| 01:33.44 |
starseeker |
brlcad: ah -
I haven't set up that dependency in CMake yet - not a problem, just
haven't done so yet |
| 01:33.51 |
starseeker |
trying that
next |
| 01:34.00 |
starseeker |
(usually
leave docbook on, messes with numbers) |
| 01:34.10 |
brlcad |
sure |
| 01:34.57 |
CIA-53 |
BRL-CAD:
03brlcad * r42935 10/brlcad/trunk/regress/fastgen.sh: add
diagnostic 'command prompts' to let you know what the important
steps being taken are |
| 01:36.06 |
starseeker |
again, using
system libs for all builds (not enable-all) |
| 01:36.20 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 01:43.34 |
starseeker |
about 6.5
minutes for the cmake build |
| 01:45.15 |
starseeker |
so about half
the time for a benchmark build (once I throw libpc into the CMake
build) |
| 01:46.02 |
starseeker |
maybe a bit
less |
| 01:46.35 |
starseeker |
actually, the
autotools build reports exact time - 8 min, 33 seconds |
| 01:46.49 |
starseeker |
looks at CMake build... |
| 01:56.02 |
starseeker |
ah right,
only got it going for configure... |
| 01:59.05 |
brlcad |
you don't
calculate compilation time?! :) |
| 02:02.26 |
brlcad |
perhaps
ironic, but I actually think cleanly and clearly reporting build
time is very important for a variety of reasons |
| 02:03.55 |
brlcad |
passive vs
active metrics, interface feedback, completion
confirmation |
| 02:11.28 |
starseeker |
brlcad: it's
a little tricky... working on it now |
| 02:28.22 |
*** join/#brlcad yukonbob
(~bch@S0106002129e399fc.ok.shawcable.net) |
| 02:29.43 |
CIA-53 |
BRL-CAD:
03brlcad * r42936 10/brlcad/trunk/include/raytrace.h: note the
three unused debug bits remaining |
| 02:34.31 |
CIA-53 |
BRL-CAD:
03brlcad * r42937 10/brlcad/trunk/src/lgt/lgt.h: lgt should not
replicate raytrace.h debug values |
| 02:35.42 |
CIA-53 |
BRL-CAD:
03brlcad * r42938 10/brlcad/trunk/ (include/raytrace.h
src/librt/cut.c src/librt/prep.c): rename DEBUG_PLOTSOLIDS and
DEBUG_PLOTBOX to DEBUG_PL_SOLIDS and DEBUG_PL_BOX respectively just
because it's 1-char shorter and matches nmg.h |
| 02:51.56 |
CIA-53 |
BRL-CAD:
03brlcad * r42939 10/brlcad/trunk/src/librt/ (db_corrupt.c
librt.3): (log message trimmed) |
| 02:51.56 |
CIA-53 |
BRL-CAD: the
user needs SOME mechansim to override automatic behavior in case
there is |
| 02:51.56 |
CIA-53 |
BRL-CAD: some
pressing need, so provide for a LIBRT_V4FLIP boolean environment
variable. |
| 02:51.56 |
CIA-53 |
BRL-CAD: if
set, the value will be interpreted as an override to enable or
disable |
| 02:51.56 |
CIA-53 |
BRL-CAD:
flipping so you can flip a file irrespective of the automatic
detection. |
| 02:51.56 |
CIA-53 |
BRL-CAD:
setting the flag to false will revert to old behavior. setting to
true will |
| 02:51.57 |
CIA-53 |
BRL-CAD: flip
even if the application provided no override and automatic
detection would |
| 02:54.39 |
CIA-53 |
BRL-CAD:
03starseeker * r42940 10/brlcad/branches/cmake/CMakeLists.txt:
Remove the benchmark and rtserver-only options - benchmark is
handled by proper dependencies for make benchmark. rtserver will
also build minimally due to dependencies. |
| 03:11.09 |
CIA-53 |
BRL-CAD:
03starseeker * r42941 10/brlcad/branches/cmake/src/CMakeLists.txt:
Without the build options for benchmark and framework, the
src/CMakeLists.txt logic simplifies down nicely |
| 03:13.58 |
CIA-53 |
BRL-CAD:
03starseeker * r42942 10/brlcad/branches/cmake/ (4 files in 2
dirs): |
| 03:13.58 |
CIA-53 |
BRL-CAD: Add
a mechanism to print out the compilation time for CMake build.
Works only |
| 03:13.58 |
CIA-53 |
BRL-CAD: for
make (e.g. make all) which appears to be consistent with autotools.
Summary |
| 03:13.58 |
CIA-53 |
BRL-CAD:
information isn't as elaborate as the autotools output, but that
can be added if |
| 03:13.58 |
CIA-53 |
BRL-CAD: it's
needed. |
| 03:14.07 |
starseeker |
brlcad: there
we go |
| 03:48.56 |
brlcad |
example
output? |
| 03:49.25 |
brlcad |
omg, this is
delicious .. |
| 03:49.42 |
brlcad |
spam
musubi |
| 03:49.53 |
brlcad |
"hawaiian
sushi" |
| 04:17.06 |
CIA-53 |
BRL-CAD:
03brlcad * r42943 10/brlcad/trunk/configure.ac: still having woes
with debugging, perhaps the flip was to gstabs+ for
10.4+? |
| 04:52.44 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 05:21.34 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.33.253) |
| 05:21.34 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:51.29 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2458
10/wiki/Backstaff: backstaff beginnings |
| 06:58.41 |
CIA-53 |
BRL-CAD:
03brlcad * r42944 10/brlcad/trunk/src/librt/db_open.c: past tense
on endianness flippage |
| 07:03.35 |
CIA-53 |
BRL-CAD:
03brlcad * r42945
10/brlcad/trunk/src/librt/db_corrupt.c: |
| 07:03.35 |
CIA-53 |
BRL-CAD: be a
lot more eager to flip the endian interpretation of v4 files now
that |
| 07:03.35 |
CIA-53 |
BRL-CAD:
there's an environment variable override. if we merely detect that
it'll help a |
| 07:03.35 |
CIA-53 |
BRL-CAD:
majority of objects, let the flip occur. Moreover, report all
objects |
| 07:03.35 |
CIA-53 |
BRL-CAD:
containing matrices that are invalid regardless of flipping since
they may just |
| 07:03.35 |
CIA-53 |
BRL-CAD:
actually be invalid. summarize how many objects are like
that. |
| 07:13.07 |
CIA-53 |
BRL-CAD:
03brlcad * r42946 10/brlcad/trunk/TODO: confirmed that ARS has a
problem importing because it manages its own b-record serialization
of dbfloat_t data. looks like old POLY objects will have a similar
problem too. opendb is now fixed. |
| 07:18.59 |
CIA-53 |
BRL-CAD:
03brlcad * r42947 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
there is no reason for rt_ars_rd_curve() to be public api. rename
sans rt_ prefix and mark HIDDEN. |
| 07:30.54 |
CIA-53 |
BRL-CAD:
03brlcad * r42948 10/brlcad/trunk/include/db.h: B_solid records
don't actually seem to be used anywhere anymore. should be safe to
remove from the union. |
| 07:36.57 |
CIA-53 |
BRL-CAD:
03brlcad * r42949 10/brlcad/trunk/include/db.h: apparently not
true. nothing refers to struct B_solid, but the bspline primitive
does refer to and use the B union record. revert. |
| 07:41.20 |
CIA-53 |
BRL-CAD:
03brlcad * r42950 10/brlcad/trunk/include/db.h: rename the
B_resolution confusion starting point as it doesn't look to be
actually used (at least by bspline). update comment and name,
however, instead of changing the struct size just in case that
matters. |
| 07:43.41 |
CIA-53 |
BRL-CAD:
03brlcad * r42951 10/brlcad/trunk/TODO: that means bsplines won't
auto-flip either |
| 08:01.54 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 08:14.51 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 08:22.05 |
d_rossberg |
starseeker:
because of the CMake build: i set BRLCAD_PREFIX to something (in
the GUI) but "Prefix:" is empty in the configuration
summary |
| 09:07.17 |
*** join/#brlcad mafm_
(~mafm@193.153.53.189) |
| 13:06.05 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:21.28 |
starseeker |
d_rossberg:
you shouldn't need to use BRLCAD_PREFIX for anything
anymore |
| 13:21.44 |
starseeker |
CMAKE_INSTALL_PREFIX should be respected
now |
| 13:27.03 |
starseeker |
brlcad:
http://pastebin.mozilla.org/1018272 |
| 13:27.09 |
starseeker |
very simple
right now |
| 13:27.43 |
d_rossberg |
there is no
CMAKE_INSTALL_PREFIX declared, i can't access it via the CMake
GUI |
| 13:28.03 |
starseeker |
um |
| 13:28.11 |
starseeker |
this is on
Windows? |
| 13:29.58 |
starseeker |
updates his copy on windows to the
latest... |
| 13:30.31 |
CIA-53 |
BRL-CAD:
03d_rossberg * r42952 10/brlcad/trunk/include/common.h: there are
unused parameters which are asserted |
| 13:30.45 |
d_rossberg |
the cmake gui
should be similar on all systems |
| 13:31.08 |
starseeker |
yes, it
should |
| 13:31.28 |
starseeker |
but there is
conditional logic for path setup |
| 13:31.49 |
starseeker |
is checking |
| 13:32.05 |
starseeker |
I usually run
from the command line, so it's possible I missed
something |
| 13:32.45 |
d_rossberg |
following my
documentation CMAKE_INSTALL_PREFIX isn't a standard variable but
CMAKE_ROOT is |
| 13:35.28 |
starseeker |
uh...
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_INSTALL_PREFIX |
| 13:36.11 |
starseeker |
am I missing
something? |
| 13:36.58 |
starseeker |
I'm seeing
CMAKE_INSTALL_PREFIX as the last entry in my gui here |
| 13:40.54 |
CIA-53 |
BRL-CAD:
03d_rossberg * r42953
10/brlcad/trunk/src/conv/asc/g2asc.c: |
| 13:40.54 |
CIA-53 |
BRL-CAD:
B_resolution (now B_unused) seams to be unused |
| 13:40.54 |
CIA-53 |
BRL-CAD:
removed it |
| 13:44.13 |
d_rossberg |
i'm removing
all my cache, build etc. files ... |
| 13:44.50 |
starseeker |
is trying on Windows to see if CMAKE_INSTALL_PREFIX perhaps
isn't coming up there |
| 13:49.31 |
*** join/#brlcad mafm_
(~mafm@193.153.53.189) |
| 13:50.40 |
CIA-53 |
BRL-CAD:
03d_rossberg * r42954
10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: removed
disappeared function |
| 13:54.04 |
starseeker |
CMAKE_INSTALL_PREFIX is visible in my
Windows setup too |
| 13:57.58 |
d_rossberg |
now here too,
it was probable a problem with an outdated
configuration |
| 14:00.36 |
starseeker |
nods. Yeah, a lot has changed over the past
week |
| 14:01.23 |
``Erik |
brlcad: did
you take crit offline? |
| 14:04.09 |
CIA-53 |
BRL-CAD:
03starseeker * r42955 10/brlcad/trunk/src/conv/asc/g2asc.c: fix
formatting string |
| 14:10.21 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42956 10/brlcad/trunk/TODO: The 'freebsd'
(actually NDEBUG) strict issues are fixed. The metaball "shelling"
bug is, as well. |
| 14:35.17 |
CIA-53 |
BRL-CAD:
03starseeker * r42957
10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: Don't assume
-Wno-error will always work, check for it first |
| 14:57.31 |
CIA-53 |
BRL-CAD:
03starseeker * r42958 10/brlcad/trunk/src/liboptical/sh_toyota.c:
Hmm - gamma shadows something in math.h on OSX 10.5,
apparently... |
| 15:00.23 |
CIA-53 |
BRL-CAD:
03starseeker * r42959
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: These ARE used,
at least on Windows... |
| 15:04.54 |
CIA-53 |
BRL-CAD:
03starseeker * r42960 10/brlcad/branches/cmake/ (18 files in 11
dirs): MFC r42959 |
| 15:35.45 |
CIA-53 |
BRL-CAD:
03starseeker * r42961
10/brlcad/branches/cmake/src/util/CMakeLists.txt: Can't do libpc on
MSVC yet, so can't very well test it... |
| 15:44.05 |
d_rossberg |
starseeker *
r42955: ups :{ |
| 15:44.21 |
starseeker |
np,
happens |
| 15:53.10 |
brlcad |
``Erik: nope,
they did |
| 15:53.19 |
brlcad |
new server is
now online |
| 15:54.07 |
brlcad |
mounting the
drive and working on restoring passwd |
| 15:54.14 |
``Erik |
aight |
| 15:54.27 |
brlcad |
new
IP |
| 15:59.54 |
``Erik |
going to give
it a new name and remove the old one, or update? |
| 16:08.04 |
CIA-53 |
BRL-CAD:
03bob1961 * r42962 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Remember whether or not to show things
like the view axes, model axes, view params, scale etc. |
| 16:10.46 |
brlcad |
yes
:) |
| 16:11.15 |
brlcad |
just got the
drives mounted |
| 16:11.25 |
brlcad |
letting /home
copy now |
| 16:26.05 |
*** join/#brlcad yukonbob_
(~bch@20-144.wireless.kamloops.net) |
| 16:55.42 |
CIA-53 |
BRL-CAD:
03brlcad * r42963 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
this brings the ARS online with automatic v4 detection, though not
a final solution since htons() will do nothing on other
endian. |
| 18:11.59 |
CIA-53 |
BRL-CAD:
03starseeker * r42964
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Do a better job
of generalizing the exec search options |
| 18:14.33 |
CIA-53 |
BRL-CAD:
03starseeker * r42965 10/brlcad/branches/cmake/
(misc/CMake/FindTCL.cmake src/other/togl/CMake/FindTCL.cmake): ws,
update togl copy of FindTCL.cmake |
| 18:17.04 |
``Erik |
starseeker:
that did the trick |
| 18:17.21 |
starseeker |
cool |
| 18:17.26 |
starseeker |
is building now |
| 18:32.07 |
``Erik |
hm, more
failures on fbsd, linux, and osX.6 |
| 18:32.23 |
``Erik |
'src/other/tcl/unix/tclUnixPort.h:91:5:
error: "TIME_WITH_SYS_TIME" is not defined' seems
common |
| 18:32.38 |
starseeker |
CMake build
or autotools? |
| 18:32.51 |
``Erik |
cmkae |
| 18:48.19 |
``Erik |
weeee, osX.6
GL.h has // style comments, so ogl fb craps itself with strict
flags |
| 18:48.28 |
``Erik |
/System/Library/Frameworks/OpenGL.framework/Headers/gl.h:37:1:
error: C++ style comments are not allowed in ISO C90 |
| 19:06.20 |
CIA-53 |
BRL-CAD:
03brlcad * r42966 10/brlcad/trunk/src/libbu/xdr.c: group pairings
together. makes it more obvious that bu_glonglong() was never
implemented (though there is a macro) but doesn't matter since this
is all getting deprecated. |
| 19:06.40 |
CIA-53 |
BRL-CAD:
03starseeker * r42967
10/brlcad/branches/cmake/misc/CMake/FindGL.cmake: We're not doing
aqua based GL in these searches, so let's stay out of the
opt/graphics directory and try /usr/X11 |
| 19:10.16 |
CIA-53 |
BRL-CAD:
03brlcad * r42968 10/brlcad/trunk/ (doc/deprecation.txt
include/bu.h): deprecate the old eXternal Data Representation (xdr)
API. the byteorder libc functions became IEEE Std POSIX.1-200x
(with the exception of the long long pairing?) so set up the
migration path. |
| 19:14.14 |
CIA-53 |
BRL-CAD:
03brlcad * r42969 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
note the problem |
| 19:15.38 |
brlcad |
``Erik: yeah,
that sucks |
| 19:16.11 |
brlcad |
where are you
seeing it? |
| 19:16.29 |
brlcad |
I updated all
of the places that gl.h gets included with
${STD_C99_FLAGS} |
| 19:16.57 |
brlcad |
that should
squash that error |
| 19:17.10 |
brlcad |
libfb, libdm,
and I think mged already have it |
| 19:20.31 |
brlcad |
ahh, if
you're testing cmake build -- starseeker, you'll have to add
similar logic |
| 19:21.32 |
brlcad |
you could
actually just set c99 project-wide for cmake build since I'm close
to doing that for autotools -- was waiting to squash the few
remaining warnings after this release |
| 19:24.01 |
``Erik |
osX.6 using
cmake, grabbing OpenGL.framework instead of
/usr/X11R6/include/GL |
| 19:24.58 |
``Erik |
always
amusing hearing starseeker use words you never think he'd use
:> |
| 19:28.25 |
CIA-53 |
BRL-CAD:
03starseeker * r42970
10/brlcad/branches/cmake/misc/CMake/FindGL.cmake: Try the
CMAKE_FIND_FRAMEWORK variable in FindGL |
| 19:47.17 |
``Erik |
brlcad: using
htons in ars.c will require winderz to link winsock.dll to
librt |
| 19:47.41 |
``Erik |
and include
Winsock2.h apparently |
| 20:05.45 |
CIA-53 |
BRL-CAD:
03starseeker * r42971
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Need to reset
variables if results aren't valid |
| 20:08.50 |
``Erik |
(and
arpa/inet.h on *nix) |
| 20:26.52 |
starseeker |
``Erik:
here's why it's crashing: 0x00000001004ea2bb in _X11TransWritev
() |
| 20:29.09 |
starseeker |
ah, there's
no escape - /usr/X11R6/include/GL/gl.h includes the framework
gl.h |
| 20:31.06 |
starseeker |
that's trying
to display mac to mac |
| 20:31.20 |
starseeker |
mac to Linux,
wish itself gives up with a bad atom |
| 20:40.35 |
brlcad |
``Erik: that
htons is not going to stay there |
| 20:40.59 |
brlcad |
working on
replacing that with something that'll actually work on big endian
systems |
| 20:44.22 |
CIA-53 |
BRL-CAD:
03brlcad * r42972 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
switch over to the xdr functions while the FIXME is being fixed so
that we don't have windows build fail. don't want to hook up
winsock for windows. |
| 21:14.08 |
starseeker |
``Erik:
odd... runs on Windows for me here (VC++2010) |
| 21:32.50 |
brlcad |
``Erik: loads
of reallocated sectors on the old filesystem .. apparently a bad or
failing drive? |
| 21:32.58 |
brlcad |
they're
attempting a clone/recovery now |
| 21:33.38 |
brlcad |
it stalled
hard 22GB into the restore earlier today and had to go
diagnosing |
| 21:43.07 |
``Erik |
old fs? on
crit or bz? bz was falling apart hardcore |
| 21:43.08 |
``Erik |
is |
| 21:43.17 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r42973 10/brlcad/branches/cmake/src/other/tcl/ (5
files in 2 dirs): regex.h -> regextcl.h to avoid fighting with
/usr/include/regex.h |
| 22:09.59 |
CIA-53 |
BRL-CAD:
03brlcad * r42974 10/brlcad/trunk/src/libbu/convert.c: |
| 22:09.59 |
CIA-53 |
BRL-CAD:
address FIXME, make cv() be public API, so rename to bu_cv().
provides a |
| 22:09.59 |
CIA-53 |
BRL-CAD:
simplified API means for converting between two specified formats,
e.g. htons() |
| 22:09.59 |
CIA-53 |
BRL-CAD:
would be something like bu_cv(outbuf, "nss", sizeof(short), val,
"hss", 1); |
| 22:10.17 |
CIA-53 |
BRL-CAD:
03brlcad * r42975 10/brlcad/trunk/include/bu.h: expose the new
bu_cv() function. |
| 22:15.30 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 22:27.33 |
CIA-53 |
BRL-CAD:
03brlcad * r42976 10/brlcad/trunk/src/libbu/convert.c: no longer
vert.c |
| 22:39.42 |
CIA-53 |
BRL-CAD:
03starseeker * r42977
10/brlcad/branches/cmake/src/other/togl/src/CMakeLists.txt: Install
the headers as well |
| 22:45.30 |
*** join/#brlcad mafm_
(~mafm@203.Red-88-22-160.staticIP.rima-tde.net) |
| 23:04.38 |
CIA-53 |
BRL-CAD:
03brlcad * r42978 10/brlcad/trunk/src/librt/db_float.c: implement a
simple flip_short() routine for flipping the bytes of a short.
htons() isn't suitable because it won't flip bytes if host endain
is network (i.e. big endian). this is private API. |
| 23:05.44 |
CIA-53 |
BRL-CAD:
03brlcad * r42979 10/brlcad/trunk/src/librt/ (Makefile.am
librt_private.h): add a new private header, librt_private.h, so we
can have a common header for providing functions that can be used
within librt but that shouldn't be public API. |
| 23:09.04 |
CIA-53 |
BRL-CAD:
03brlcad * r42980 10/brlcad/trunk/src/librt/db_float.c: prepare for
a rename to db_flip.c |
| 23:10.50 |
CIA-53 |
BRL-CAD:
03brlcad * r42981 10/brlcad/trunk/ (5 files in 2 dirs): rename from
db_float.c to db_flip.c since the file is being expanded with a few
more flip functions that have nothing to do with floats |
| 23:16.41 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
| 23:25.34 |
CIA-53 |
BRL-CAD:
03starseeker * r42982 10/brlcad/branches/cmake/src/other/togl/ (12
files in 5 dirs): Let's see if glew can handle some of the cross
platform annoyances |
| 23:28.51 |
CIA-53 |
BRL-CAD:
03starseeker * r42983 10/brlcad/branches/cmake/CMakeLists.txt: Turn
Tk X11 requirement on if appropriate |
| 23:41.43 |
starseeker |
``Erik: hmm:
http://www.geodynamics.org/pipermail/cig-commits/2010-March/011594.html |
| 23:52.19 |
starseeker |
``Erik:
here's a backtrace, if that helps: http://pastebin.mozilla.org/1020171 |
| 23:57.06 |
CIA-53 |
BRL-CAD:
03brlcad * r42984
10/brlcad/trunk/src/librt/primitives/ars/ars.c: |
| 23:57.06 |
CIA-53 |
BRL-CAD: this
should fix interpretation for both big and little endian platforms.
if |
| 23:57.06 |
CIA-53 |
BRL-CAD:
flipping is requested, we need to flip the bytes regardless of
host/network |
| 23:57.06 |
CIA-53 |
BRL-CAD:
endianness. call the new private flip_short() function from
db_flip.c |
| 00:32.33 |
CIA-53 |
BRL-CAD:
03starseeker * r43103 10/brlcad/branches/cmake/TODO.cmake: Add todo
note for XCode |
| 01:14.48 |
CIA-53 |
BRL-CAD:
03starseeker * r43104 10/brlcad/branches/cmake/CMakeLists.txt: try
ORIGIN first - if the binary is running locally, pulling a system
lib would be both subtly unexpected and potentially subtly
wrong. |
| 01:47.14 |
*** part/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 01:52.31 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 02:03.14 |
CIA-53 |
BRL-CAD:
03starseeker * r43105 10/brlcad/branches/cmake/CMakeLists.txt:
quote the flag string - it's not a list in the CMake
sense |
| 02:05.11 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 02:10.02 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 02:12.37 |
CIA-53 |
BRL-CAD:
03starseeker * r43106 10/brlcad/branches/cmake/ (INSTALL README
configure.cmake.sh): Start working on docs - part way through
install, but there are a lot of options to cover... |
| 02:27.22 |
CIA-53 |
BRL-CAD:
03starseeker * r43107
10/brlcad/branches/cmake/CMakeLists.txt: |
| 02:27.23 |
CIA-53 |
BRL-CAD: Was
right the first time - can't be sure what impact symbolic links and
the |
| 02:27.23 |
CIA-53 |
BRL-CAD:
links may have on ORIGIN. Have to go with the install path first,
and just make |
| 02:27.23 |
CIA-53 |
BRL-CAD: sure
it doesn't conflict with a system path if the idea is to make
something |
| 02:27.23 |
CIA-53 |
BRL-CAD:
relocatable. |
| 03:53.51 |
brlcad |
starseeker:
that bug doesn't seem entirely relevant |
| 03:54.27 |
brlcad |
or did you
hit the "unimplemented" message? |
| 03:55.01 |
brlcad |
either way, a
different fix is likely going to be needed -- merging that back to
trunk will likely break optimized (strict) build |
| 03:59.01 |
brlcad |
s/likely/should/ |
| 03:59.22 |
brlcad |
that was
specifically added to fix an inline failure |
| 04:07.06 |
starseeker |
I hit the
unimplemented message |
| 04:07.11 |
starseeker |
refused to
compile at all |
| 04:38.38 |
*** join/#brlcad jmoore
(~jmoore@cpe-184-57-8-75.columbus.res.rr.com) |
| 04:45.24 |
jmoore |
Hi. Is their
a simple way to get a list of leaf's and combs using c? tying to
duplicate the functionality ls in mged for use in another function.
I found the tree walk function but they take a starting dir and I
am having truble figering out how to exrract all of the used ones
in dbi_Head |
| 04:56.27 |
brlcad |
starseeker:
goes without saying, though, that another fix will be needed -- you
just shifted the failure from one platform over to
another |
| 04:57.55 |
brlcad |
jmoore: there
are about a half dozen differen tree walkers for that purpose --
you can see how the ls command does it, for example, in
src/libged/ls.c (ged_ls()) |
| 04:59.34 |
brlcad |
the
src/libged commands build on top of the underlying librt
API |
| 05:01.01 |
brlcad |
jmoore:
probably more useful than the ls command, however, is the "l" aka
"list" command -- src/libged/list.c |
| 05:01.45 |
brlcad |
ends up
calling rt_functab[id].ft_describe() which writes the listing to a
string |
| 05:02.17 |
jmoore |
thanks |
| 05:03.29 |
brlcad |
jmoore: have
you seen this: http://brlcad.org/wiki/Example_db_walk_tree |
| 05:04.10 |
brlcad |
not entirely
what you're asking as you don't need to walk recursively to just
display members of a combinatino |
| 05:08.19 |
brlcad |
jmore:
db_lookup() + rt_db_get_internal() + db_flatten_tree() will give
you a simple array of the combination elements listing the CSG
operator and the name of the object |
| 05:08.50 |
jmoore |
No I had not.
I looks like a starting point good you all redy have a base shape's
name. |
| 05:10.00 |
brlcad |
a couple more
useful dev resources including a ray-shooting example at http://brlcad.org/wiki/Developing_applications |
| 05:10.08 |
jmoore |
been piling
threw http://brlcad.org/wiki/Example_db_walk_tree |
| 05:10.16 |
jmoore |
http://brlcad.org/xref/ident |
| 05:11.13 |
brlcad |
it's a huge
API to traverse that way -- encourage you to ask questions here or
on the devel mailing list |
| 05:16.08 |
brlcad |
2000+ public
functions across a dozen different libraries, numerics, generic
routines, ray tracing, geometry, image processing, .... it's easy
to get lost |
| 05:17.19 |
jmoore |
k
thanks. |
| 05:17.40 |
jmoore |
that is for
suer. |
| 08:40.49 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 08:42.53 |
d_rossberg |
starseeker:
first the good news: i was able to build ALL_BUILD in reasonable
time, INSTALL it, run mged, load a database there and raytrace into
a pupup window :) |
| 08:44.20 |
d_rossberg |
and i was
able to reproduce the OPENNURBS & UTAHRLE error: http://paste.ubuntu.com/564291/ |
| 08:45.45 |
d_rossberg |
after
removing all from the installation directory the configuration went
through |
| 11:24.45 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 11:40.28 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 12:31.24 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:03.39 |
starseeker |
d_rossberg:
what's happening there is the find routines are identifying
previously installed BRL-CAD files |
| 13:04.18 |
starseeker |
is your
CMAKE_INSTALL_PREFIX set to C:/brlcad.cmake/aInstall ? |
| 13:06.13 |
starseeker |
looks like
the summary thinks it is... |
| 13:10.01 |
CIA-53 |
BRL-CAD:
03starseeker * r43108
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Don't try
getting properties from openNURBS unless we're actually building
it. |
| 13:10.28 |
starseeker |
that may fix
the error (and was legit enough) but the real issue is why it's
looking in the install path |
| 13:11.04 |
starseeker |
logic in the
root CMakeLists.txt file starting line 116 is intended to prevent
that |
| 13:49.46 |
d_rossberg |
right: my
CMAKE_INSTALL_PREFIX is set to C:/brlcad.cmake/aInstall |
| 13:50.31 |
d_rossberg |
my build
directory is C:/brlcad.cmake/aBuild |
| 13:51.11 |
d_rossberg |
my brlcad
checkout directory is C:/brlcad.cmake (for the cmake
build) |
| 14:32.19 |
CIA-53 |
BRL-CAD:
03starseeker * r43109 10/geomcore/: Since parts of rt^3 are being
used, make a branch of it to thrash around in. |
| 14:36.06 |
CIA-53 |
BRL-CAD:
03starseeker * r43110 10/geomcore/trunk/src/other/ (CMakeLists.txt
ogre/ ois/): Don't need ogre and ois in here right now, dated
anyway |
| 14:36.55 |
CIA-53 |
BRL-CAD:
03starseeker * r43111 10/geomcore/trunk/src/g3d/: This is in the
other branch, not the focus of current efforts - remove from this
one |
| 14:38.17 |
CIA-53 |
BRL-CAD:
03starseeker * r43112 10/geomcore/trunk/src/ (rt^3/ rt^3d/ rt^3dbd/
scratch/): Not added by CMakeLists.txt, confusingly named -
remove |
| 15:01.11 |
CIA-53 |
BRL-CAD:
03jordisayol * r43113 10/brlcad/trunk/sh/ (make_deb.sh
make_rpm.sh): add the option to build openSUSE rpm
packages |
| 15:12.20 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 15:39.45 |
dloman |
oh, one last
thing starseeker and ``Erik : No laughing at my code, I have thin
skin and a violent temper! |
| 15:39.49 |
dloman |
=D |
| 15:39.56 |
starseeker |
you
too? |
| 15:40.06 |
``Erik |
I laugh at
everyones code, even my own :D |
| 15:41.16 |
starseeker |
dloman: is
the signals and slots TODO taken care of? |
| 15:41.39 |
dloman |
quite
likely |
| 15:41.48 |
starseeker |
k - rewording
to make more general |
| 15:41.53 |
dloman |
i haven't
been keeping that file uptodate |
| 15:43.36 |
dloman |
checks out Geomcore.... |
| 15:43.43 |
dloman |
...slowly,
lol |
| 15:43.53 |
starseeker |
should be
faster without ogre in there... |
| 15:44.27 |
dloman |
yeah, it is.
Network pipe or SF is slow though. |
| 15:44.46 |
dloman |
I keep my
personal projects/code on a friends server... svn is wiked fast.
|
| 15:44.57 |
dloman |
only has to
deal with 10 or so projects, nothing like SF's load |
| 15:44.57 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2462
10/wiki/Community_Publication_Portal: article on rpm/deb efforts by
jordi |
| 15:45.12 |
dloman |
so.... Im
super spoiled and think that SF svn is wicked slow |
| 15:45.18 |
starseeker |
heh |
| 15:45.28 |
starseeker |
it is a bit
slow, must admit |
| 15:45.53 |
brlcad |
svn from
sf.net is slow, but it still far beats having to manage it
ourselves |
| 15:47.14 |
brlcad |
server
availability, svn upgrades, security, web services, hardware backup
recovery, ... lots of "one less thing" to worry about at the cost
of a little waiting during update/checkin |
| 15:47.39 |
dloman |
roger that.
Just sayin' =D |
| 15:48.00 |
CIA-53 |
BRL-CAD:
03starseeker * r43114 10/geomcore/trunk/ (AUTHORS COPYING HACKING
INSTALL NEWS README TODO): Lot more to do here - quick scrub to set
up focus on geometry engine and geometry server. |
| 15:48.28 |
brlcad |
it actually
encourages better commit practices, since the delay is worse with
bigger commits |
| 15:48.54 |
brlcad |
smaller
frequent commits and the delays aren't really an issue, especially
svn commit -m "asdf" & |
| 15:49.10 |
starseeker |
true |
| 15:49.15 |
starseeker |
hadn't
thought of that |
| 15:51.39 |
dloman |
brlcad: I'm
spreading the infection. Got a friend in WA hooked on Zombie
Trailer Park now :) |
| 15:51.55 |
brlcad |
excellent |
| 15:52.01 |
dloman |
and he works
at MS with a bunch of guys, so lets see how viral it will
go! |
| 15:52.06 |
brlcad |
dloman: beat
level 4 yet? |
| 15:52.11 |
dloman |
ha,
nope. |
| 15:52.39 |
dloman |
verizon
started screwing with the lines in my development yesterday
afternoon. Internet and phone dropped out around 3pm
:/ |
| 15:54.52 |
starseeker |
dloman: are
the docs you've been working on the last couple weeks in the docs
subdirectory, or just on the wiki? |
| 15:56.03 |
dloman |
been keeping
thr graphics in the docs dir, text on the wiki |
| 15:56.10 |
dloman |
s/thr/the/ |
| 15:56.37 |
starseeker |
dloman: k. I
may snarf it and stick in docbook, if that's OK |
| 15:56.57 |
dloman |
sure, they
were quickei photochop's, so take that for what it is
:) |
| 15:57.15 |
starseeker |
no problem
:-) |
| 15:57.38 |
CIA-53 |
BRL-CAD:
03ronaldbowers * r43115
10/jbrlcad/trunk/src/main/java/org/brlcad/geometryservice/ (5
files): - splitting GeometryService into basic functionality and a
caching layer. The caching will be relocated to Gomez. |
| 16:02.56 |
dloman |
``Erik: would
it be good/bad practice to make a dir (save level as src/) to hold
all the 'interface' libs? |
| 16:03.21 |
``Erik |
um, ya mean
src/client/{c,java,python,ruby}/ ? |
| 16:03.43 |
dloman |
ya
those |
| 16:03.54 |
dloman |
or would
src/interfaces/* be better? |
| 16:05.02 |
``Erik |
d'no
*shrug* |
| 16:05.53 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43116 10/geomcore/trunk/src/client/
(CMakeLists.txt c/ c/CMakeLists.txt c/gsclient.c c/gsclient.h): C
stuff stubbed |
| 16:12.32 |
dloman |
preference? |
| 16:12.48 |
starseeker |
likes interfaces |
| 16:30.08 |
dloman |
``Erik:
preference? |
| 17:45.35 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 17:56.13 |
``Erik |
have
none |
| 17:57.52 |
CIA-53 |
BRL-CAD:
03starseeker * r43117 10/geomcore/trunk/src/ (client/ interfaces/):
move client to interfaces |
| 17:58.49 |
CIA-53 |
BRL-CAD:
03starseeker * r43118 10/geomcore/trunk/src/CMakeLists.txt: Update
build reference |
| 18:10.08 |
CIA-53 |
BRL-CAD:
03starseeker * r43119
10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Try
finline-limit expansion instead of the always_inline attribute -
perhaps this will be more portable |
| 18:10.28 |
dloman |
okie
then |
| 18:10.53 |
dloman |
starseeker:
we dropping coreInterface out of Geomcore? |
| 18:14.27 |
starseeker |
dloman: uh,
whoops - did I chop too much? |
| 18:15.05 |
dloman |
nope. Just
saw coreInterface in geomcore/src and figured i'd ask. |
| 18:15.19 |
starseeker |
are we using
it? |
| 18:15.31 |
dloman |
not to my
knowledge |
| 18:16.06 |
starseeker |
um... not
sure about that one yet. It's not a slam dunk the way ogre
was |
| 18:16.30 |
dloman |
okie, no
worries. like I said, just askin. |
| 18:16.47 |
starseeker |
nods - fair question, I just don't know enough to answer it
yet |
| 18:23.34 |
CIA-53 |
BRL-CAD:
03davidloman * r43120 10/geomcore/trunk/src/interfaces/java/README:
Add README with small blurb about intent and design |
| 18:23.58 |
CIA-53 |
BRL-CAD:
03davidloman * r43121
10/geomcore/trunk/src/interfaces/java/CMakeLists.txt: Removed iBME
verbage. Stopped using that acronym a while ago as it doesn't
describe the GS project correctly. |
| 18:25.18 |
CIA-53 |
BRL-CAD:
03davidloman * r43122 10/geomcore/trunk/src/interfaces/java/src/ (.
org/ org/brlcad/ org/brlcad/geometryservice/): Add in
packages |
| 18:25.39 |
dloman |
Hrm. Should
the interfaces ALL bewired into cmake? That might make the cmake
build a living hell.... |
| 18:26.02 |
starseeker |
dloman: how
so? |
| 18:26.38 |
dloman |
ruby, java,
etc... wouldn't cmake need to know how to compile all of those
languages? ...or does it already? |
| 18:26.55 |
``Erik |
ruby isn't
compiled, there're hacks to call javac for java |
| 18:27.08 |
``Erik |
(but not all
machines necessarily have java) |
| 18:27.16 |
dloman |
well that's
my point. |
| 18:27.28 |
starseeker |
you
conditionalize on finding java - BRL-CAD cmake build already does
that |
| 18:27.33 |
dloman |
plus, those
that do might not have the same java.... but thats a different can
of worms. |
| 18:28.02 |
starseeker |
dloman: don't
worry too much - we have to do SOMETHING to build them all, and
CMake is probably as good as any |
| 18:28.04 |
``Erik |
well, I'd
hope the implementation would be in java 1.4, which should be an ok
baseline for everywhere |
| 18:28.26 |
dloman |
the other
angle i was thinking about was: if someone is looking for an
interface to the GS, they might not be interested building the rest
of hte code. |
| 18:29.05 |
``Erik |
so'z they
copy the file(s) and wire them into their own build systems?
:) |
| 18:29.14 |
starseeker |
OPTION(ENABLE_INTERFACES "Enable external
language interfaces" OFF) |
| 18:29.24 |
dloman |
okie. |
| 18:29.58 |
dloman |
just thinking
about 'should the interfaces be wired into the main build or not'
...thats all :) |
| 18:30.09 |
starseeker |
nods - it's OK if they aren't initially |
| 18:30.48 |
CIA-53 |
BRL-CAD:
03davidloman * r43123 10/geomcore/trunk/src/interfaces/java/ (.
GSClient.java src/org/brlcad/geometryservice/GSClient.java): Move
GSClient into proper package structure. |
| 18:31.00 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43124 10/geomcore/trunk/src/GE/CMakeLists.txt:
no QT used here, remove flags for it |
| 18:38.29 |
CIA-53 |
BRL-CAD:
03davidloman * r43125 10/geomcore/trunk/src/interfaces/java/README:
Keep it simple and, rather than copy classes that are under
development, make jBRLCAD an dependency. Hopefully this will change
in the near future. |
| 18:40.36 |
CIA-53 |
BRL-CAD:
03davidloman * r43126 10/geomcore/trunk/src/interfaces/java/test/
(. org/ org/brlcad/ org/brlcad/geometryservice/): Add in test dir
structure |
| 18:42.14 |
CIA-53 |
BRL-CAD:
03davidloman * r43127
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/
(. msg/): Add in net and net.msg packages for upcoming work on
implementing the GSNet protocol in java. |
| 18:58.06 |
CIA-53 |
BRL-CAD:
03davidloman * r43128
10/geomcore/trunk/src/interfaces/java/auto-props.cfg: Add an
autoprops file |
| 19:08.03 |
CIA-53 |
BRL-CAD:
03davidloman * r43129
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/
(GSClient.java GSStatics.java): Create dedicated statics class.
Move statics into it. |
| 19:13.01 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43130 10/geomcore/trunk/src/
(date/CMakeLists.txt libPkgCpp/CMakeLists.txt): remove unnecessary
QT references |
| 19:26.39 |
CIA-53 |
BRL-CAD:
03bob1961 * r43131
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Override
ArcherCore::zap |
| 19:28.28 |
CIA-53 |
BRL-CAD:
03starseeker * r43132 10/geomcore/trunk/src/date/: Remove date -
not been used in a while, and if it's for build config we have
other approaches |
| 19:32.05 |
CIA-53 |
BRL-CAD:
03davidloman * r43133
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/
(3 files): Add in ByteBuffer helper classes. These will be needed
for serialization/deserialization of AbstractNetMsg
subclasses. |
| 19:36.10 |
CIA-53 |
BRL-CAD:
03davidloman * r43134
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/
(ByteBufferReader.java ByteBufferWriter.java): Add read/write
support for java's UUID to ByteBuffer helper classes. |
| 19:37.10 |
CIA-53 |
BRL-CAD:
03starseeker * r43135 10/geomcore/trunk/src/other/ (CMakeLists.txt
sqlite/ sqlite_3_7_4/): Let's not use the version number in the
directory name |
| 19:40.22 |
CIA-53 |
BRL-CAD:
03davidloman * r43136
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/
(ByteBufferReader.java ByteBufferWriter.java): Add explicit
read/write support for java's Boolean to ByteBuffer helper
classes. |
| 19:40.23 |
CIA-53 |
BRL-CAD:
03starseeker * r43137 10/geomcore/trunk/src/other/sqlite/ (shell.c
sqlite3.c sqlite3.h): Update sqlite to
sqlite-amalgamation-201101281703, add sqlite3.h |
| 19:55.16 |
CIA-53 |
BRL-CAD:
03davidloman * r43138
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/
(GSClient.java net/msg/NetMsgTypes.java): Move NetMsg types out of
GSClient and into a dedicated class in the .net.msg
package. |
| 19:56.21 |
CIA-53 |
BRL-CAD:
03davidloman * r43139
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java:
First cut at implementation of AbstractNetMsg in java. |
| 20:02.00 |
CIA-53 |
BRL-CAD:
03davidloman * r43140
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferReader.java:
Add helper cstr to ByteBufferReader that defaults endian flip to
false. |
| 20:02.14 |
*** join/#brlcad PrezKennedy
(MK@2607:f0d0:3001:68::2) |
| 20:04.46 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43141 10/geomcore/trunk/src/CMakeLists.txt: date
is gone |
| 20:09.18 |
CIA-53 |
BRL-CAD:
03davidloman * r43142
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java:
Stub in the skeleton for a simple netMsg factory. |
| 20:43.08 |
CIA-53 |
BRL-CAD:
03davidloman * r43143
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java:
Stub in the first round of GSConnection work. Nowhere near
functional yet, still building infrastructure. |
| 20:43.56 |
CIA-53 |
BRL-CAD:
03davidloman * r43144
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java:
Import cleanup. |
| 21:35.26 |
``Erik |
cd
src/libNe |
| 21:35.28 |
``Erik |
woops |
| 21:38.15 |
CIA-53 |
BRL-CAD:
03starseeker * r43145 10/geomcore/trunk/ (41 files in 14 dirs):
Start rework of the CMake build - no longer generating libutility.h
and friends, so update the code accordingly |
| 21:47.10 |
CIA-53 |
BRL-CAD:
03starseeker * r43146 10/brlcad/branches/cmake/ (6 files in 5
dirs): MFC 43145 |
| 22:16.15 |
brlcad |
outstanding,
looks like distcheck is clean 32-bit and 64-bit now |
| 22:16.26 |
brlcad |
starting
release |
| 22:41.08 |
CIA-53 |
BRL-CAD:
03starseeker * r43147 10/geomcore/trunk/src/other/uuid/ (50 files):
Preliminary steps to getting off of using Qt's uuid feature - use
ossp uuid, but there's a complex test for va_copy that I haven't
reproduced in CMake yet. |
| 22:46.16 |
CIA-53 |
BRL-CAD:
03starseeker * r43148
10/geomcore/trunk/src/other/uuid/CMakeLists.txt: give uuid a
project setting. Also note that there was a change to the source of
uuid_str.c - a couple of #if statements were changed to
#ifdef |
| 23:07.01 |
CIA-53 |
BRL-CAD:
03starseeker * r43149 10/geomcore/trunk/src/other/ (CMakeLists.txt
uuid/CMakeLists.txt uuid/uuid_ac.h): Add uuid to build, also switch
uuid's config.h to uuid_config.h to avoid conflicts with the main
config file |
| 01:00.15 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 01:45.21 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 01:53.11 |
starseeker |
``Erik:
unless BSD has done some serious hacking, APR and APR-util are
mandatory for subversion |
| 02:01.49 |
*** join/#brlcad dli (~dli@66.49.141.114) |
| 02:07.28 |
dli |
hi, I wonder
whether it's possible to add openGL support for brlcad, so
rendering, can be in real time |
| 02:11.30 |
starseeker |
that depends
on what you mean by rendering |
| 02:11.51 |
starseeker |
if you mean
3D shaded display, the hard part is converting our geometry to the
triangles needed to feed OpenGL |
| 02:12.15 |
starseeker |
if you mean
raytracing, you may want to take a look at adrt |
| 02:12.55 |
dli |
starseeker,
raytracing is still slow, I know this part. I just mean to use more
features from modern video cards |
| 02:13.35 |
starseeker |
robust
tessellation is a foundation for any shaded display using OpenGL,
unless you're talking about raytracing using the GPL |
| 02:13.39 |
starseeker |
er
GPU |
| 02:13.59 |
starseeker |
we haven't
done much in the raytracing with GPU direction |
| 02:14.22 |
dli |
starseeker,
no, I don't expect raytracing on GPU, too much work :( |
| 02:15.21 |
dli |
starseeker,
so, you think it's possible. if true, it would very much exciting,
CAD can be a real time simulator then |
| 02:15.50 |
starseeker |
it's
certainly possible, but robust tessellation of CSG geometry is not
a simple problem |
| 02:17.04 |
dli |
starseeker,
which level is the cause of problems? conceptual, algorithm, or
just have to rewrite a lot? |
| 02:19.07 |
CIA-53 |
BRL-CAD:
03starseeker * r43150
10/geomcore/trunk/src/other/subversion/COPYING: Whoops - add the
subversion COPYING file |
| 02:19.22 |
starseeker |
dli: both
algorithmic and lot of code to wrangle |
| 02:19.33 |
starseeker |
take a look
at the nmg code in librt to get an idea |
| 02:20.47 |
dli |
starseeker, I
will try. I hope I can understand something first |
| 02:21.23 |
starseeker |
dli: brlcad
may be able to give you a better overview of the various options
and where a good starting point is |
| 02:21.53 |
starseeker |
most of the
issues I'm familiar with involving tessellation and shaded displays
involve "diving off the deep end" |
| 02:22.44 |
dli |
starseeker,
yes, long time ago, I wanted to contribute to this project, but too
busy at that time. now, I have should have some time for algorithm
and coding |
| 02:23.22 |
dli |
starseeker,
thanks a lot, I will talk to brlcad later |
| 02:23.33 |
starseeker |
dli: awesome
:-) |
| 02:24.09 |
starseeker |
dli: one good
starting point might be to look at one of the convertors in
src/conv |
| 02:24.21 |
starseeker |
most of them
invoke tessellation logic |
| 02:24.50 |
dli |
starseeker,
sure, I will try to read as much as possible, to help
understanding |
| 02:33.36 |
starseeker |
looks at the apr configure process and turns
white |
| 02:36.56 |
starseeker |
checks the subversion code a little... |
| 02:41.07 |
starseeker |
``Erik: yeah,
there's no way they've avoided requiring apr - the entire code base
is thick with apr types and calls |
| 02:41.20 |
starseeker |
removing apr
would amount to a total rewrite |
| 03:35.52 |
brlcad |
dli:
technically, we already have opengl support -- you can see it in
action with a private debug setting on an opengl-enabled
build |
| 03:36.54 |
brlcad |
the problem
is that the way it's currently implemented is at least np-hard,
error-prone to numeric drift, slow as balls, and not robust
(because it's np-hard) |
| 03:37.25 |
dli |
brlcad, I
see, so, it's not really useful as is |
| 03:37.32 |
brlcad |
so you can
either work on making it more robust (which would be fantastic, but
hard) then make it faster (probably the easiest part) |
| 03:38.10 |
brlcad |
the problem
is mostly algorithmic |
| 03:39.12 |
brlcad |
consider two
overlapping spheres, for example, simply defined by a point and a
radius, unioned together |
| 03:39.16 |
dli |
brlcad, I
will read the code first :) |
| 03:40.21 |
brlcad |
current
approach basically turns each of the two spheres into a set of
polygons (trivial) then evaluates interior, exterior, and
overlapping polygons |
| 03:40.36 |
starseeker |
reluctantly concludes libgit2 is too immature feature wise to
be an option for some time, even if we could switch horses now
(which we can't) |
| 03:40.36 |
brlcad |
that's also
trivial/easy |
| 03:41.04 |
dli |
brlcad, how
could this be NP? |
| 03:41.06 |
brlcad |
since it's a
union, it throws away the interior polygons, keeps the exterior,
and stitches together the overlapping ones trimming away and
splicing together correctly |
| 03:41.33 |
brlcad |
dli: I'm
showing you one of the very most simple cases just for
understanding of the basic algorithm |
| 03:42.00 |
brlcad |
it's actually
a relatively simple algorithm, but the devil is in the
details |
| 03:42.53 |
dli |
brlcad,
because we build the geometry part by part, I suppose the
complexity of adding one more primitive is O(N), for N existing
primitives |
| 03:42.57 |
brlcad |
it's not
robust for a variety of problems, including floating point drift
during the trimming/splicing stage but also because we're
evaluating the boolean AFTER tessellating all primitives where
we're no longer matching the original surface |
| 03:43.30 |
brlcad |
that'd be
linear complexity, which it is not :) |
| 03:43.52 |
brlcad |
it's
exponential to evaluate the N+1 primitive against the previous N
set |
| 03:45.24 |
brlcad |
there are
tons of optimizations possible, you could get the performance down
to reasonable levels with some basic space partitioning -- in fact
the current code does this for some cases |
| 03:45.31 |
dli |
brlcad, the
complexity of voronoi cell analysis is N log(N), I feel it's
similar |
| 03:45.57 |
brlcad |
the problem
with the approach, however, is that it's still basically a lossy
approach |
| 03:46.47 |
brlcad |
so even if
you solved the robustness problem with careful numerics and
consistently handling all edge cases, there are STILL going to be
some comparisons that fundamentally cannot be solved without making
a blind guess |
| 03:47.00 |
brlcad |
that's where
NURBS comes in |
| 03:47.26 |
brlcad |
it's the new
approach that will eventually make the current approach obsolete --
the boolean is evaluated prior to tessellation |
| 03:48.49 |
brlcad |
instead of
converting each primitive to a mesh, each is converted to a spline
surface, surface-surface intersection calculations are performed
(just like done with meshes, marking interior/exterior/overlapping
surfaces), surfaces are trimmed according to the boolean, and the
resulting *evaluated* surfaces are then trivially
tessellated |
| 03:48.51 |
dli |
brlcad,
sounds very interesting to me, I feel I could contribute something
here. I did molecular dynamics, genetic aglorithm, voronoi cells,
and have some time for coding now |
| 03:49.54 |
brlcad |
dli: that's
fantastic, there are plenty of places you could jump in |
| 03:50.47 |
dli |
brlcad, give
me some clues :) |
| 03:51.12 |
brlcad |
basically you
can either work on our mesh support (i.e., the current approach,
which will still be needed even with nurbs, for polygonal surfaces)
or.. |
| 03:51.37 |
brlcad |
you can work
on the various outstanding issues with our new nurbs
support |
| 03:52.36 |
brlcad |
surface-surface intersection calculations
to derive an intersection curve is one problem still TBD --
robustly tessellating a nurbs surface is another |
| 03:53.07 |
dli |
brlcad, under
src/others/openNURBS/ ? |
| 03:53.10 |
brlcad |
the mesh
processing is much more approachable but will require
systematically reviewing thousands and thousands of lines of code,
hundreds of functions |
| 03:53.46 |
brlcad |
depends what
your exact goal is :) |
| 03:54.33 |
brlcad |
I'd set a
specific small goal and then it'll be easier to point you in the
right direction towards implementing that goal |
| 03:55.09 |
dli |
brlcad, I
think I would try the surface-surface intersection
first |
| 03:55.59 |
brlcad |
okay |
| 03:56.34 |
brlcad |
then your
starting point is probably:
http://en.wikipedia.org/wiki/Surface-to-surface_intersection_problem |
| 03:57.13 |
brlcad |
there are
tons of approaches and research on the subject, but that's a good
primer |
| 03:57.55 |
starseeker |
dli: I have a
few links to papers I can dig up tomorrow |
| 03:57.57 |
brlcad |
code-wise,
src/other/openNURBS is a good starting point along with where we
hook openNURBS into our code for ray-tracing at
src/librt/primitives/brep |
| 03:58.24 |
dli |
starseeker,
thanks |
| 03:58.54 |
brlcad |
you're
basically writing a function that takes two ON_Brep objects and
returns an ON_Curve |
| 03:59.11 |
brlcad |
or an
ON_Surface or similar "intersection result" |
| 03:59.19 |
starseeker |
dli: ah, wait
- found it :-)
http://www.cs.berkeley.edu/~hling/research/paper/intersection.htm |
| 03:59.47 |
dli |
brlcad, nice,
quite specific at this stage |
| 04:00.13 |
brlcad |
dli: you can
start with src/proc-db/brep_simple.cpp |
| 04:00.29 |
brlcad |
that shows
how one manually creates a b-rep box using openNURBS |
| 04:01.04 |
brlcad |
you could
easily extend that example to just create two surfaces, then
evaluate their intersection |
| 04:02.03 |
brlcad |
a summer
student attempt this about a year and a half ago, their effort is
in src/proc-db/surfaceintersect.cpp |
| 04:02.20 |
CIA-53 |
BRL-CAD:
03starseeker * r43151
10/geomcore/trunk/src/other/subversion/CMake/ThirdParty.cmake: |
| 04:02.20 |
CIA-53 |
BRL-CAD: Chop
third party macro stuff down to just autoconf - need to sync with
the newer |
| 04:02.20 |
CIA-53 |
BRL-CAD: one
in BRL-CAD, but this has specific improvements to the autoconf
routines that |
| 04:02.20 |
CIA-53 |
BRL-CAD: will
need to be merged back into the main version (BRL-CAD trunk no
longer does |
| 04:02.20 |
CIA-53 |
BRL-CAD:
third party builds with autoconf, but apr and friends look to be
very difficult |
| 04:02.21 |
CIA-53 |
BRL-CAD:
conversion prospects for CMake.) |
| 04:03.09 |
dli |
brlcad, good
enough :) so, I will read the brep_simple.cpp, and figure out the
data structures, then, write a function to to find intersection of
two ON_Brep objects |
| 04:03.30 |
starseeker |
brlcad: we
may have to settle for building apr using their Visual Studio files
on Windows as a precursor to building our subversion stuff - I
don't know that I've found any successful examples of external
projects in Visual Studio, although I can't yet say that for
certain |
| 04:08.55 |
brlcad |
more info at
http://mae.ucdavis.edu/~farouki/foils.pdf
or with more rigor
ftp://ftp.cs.unc.edu/pub/users/manocha/PAPERS/INTERSECT/IJCGA.pdf
(he's published an update in 1997, but don't have a link for
it) |
| 04:09.53 |
brlcad |
starseeker:
not worried about external deps for GS until it's fully implemented
-- dev rule can simply be "install it first" in the
meantime |
| 04:10.06 |
dli |
brlcad, got
them. some reading time now |
| 04:10.26 |
brlcad |
run cmake
test(s), if not found -- print a message saying they need to
install it |
| 04:11.30 |
brlcad |
build system
integration isn't an issue until it's time for public deployment
(which isn't on the table this year) |
| 04:11.38 |
brlcad |
dli:
great |
| 04:17.37 |
brlcad |
dli, if you
start making progress on code, let me know and we can get you set
up with commit access so your efforts can be incrementally visible
to others, traceable, and easier to understand the
end-result |
| 04:18.31 |
dli |
brlcad, sure,
we will see :) |
| 04:25.55 |
*** join/#brlcad jmoore
(~jmoore@cpe-184-57-8-75.columbus.res.rr.com) |
| 04:25.55 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 04:25.55 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 04:25.55 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 04:25.55 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
| 04:25.55 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 04:25.55 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 04:25.55 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
| 04:25.55 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 04:30.27 |
*** join/#brlcad IriX64
(~IriX64@70.52.228.89) |
| 04:32.38 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 05:26.40 |
CIA-53 |
BRL-CAD:
03brlcad * r43152 10/brlcad/trunk/NEWS: include write-up highlights
for 7.18.2 emphasizing the v4 compatibility work along with the
platform integration efforts from new contributor jordi
sayol. |
| 05:28.08 |
CIA-53 |
BRL-CAD:
03brlcad * r43153 10/brlcad/trunk/NEWS: jordi also improved
platform support on Fedora, so call it out. leave openSUSE for the
next release since it's not as well-tested. |
| 05:31.51 |
CIA-53 |
BRL-CAD:
03brlcad * r43154 10/brlcad/trunk/include/conf/PATCH: bump patch to
.2 for release 7.18.2, final stages |
| 05:32.23 |
CIA-53 |
BRL-CAD:
03brlcad * r43155 10/brlcad/trunk/ChangeLog: update ChangeLog for
release 7.18.2 |
| 05:42.04 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2463
10/wiki/Community_Publication_Portal: initial notes for
7.18.2 |
| 05:44.38 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2464
10/wiki/Community_Publication_Portal: not a pre section |
| 06:09.59 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 06:15.41 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2465
10/wiki/Community_Publication_Portal: /* Sean Morrison: Release
7.18.2 */ expand, reorganize, and reword accordingly |
| 06:15.58 |
brlcad |
gah, svn:
Revision 43155 doesn't match existing revision 43150 in
'src/other/togl' |
| 06:17.28 |
brlcad |
that's why
it's bad to delete and readd directories, even when updating
revisions -- they have to be merged |
| 06:20.06 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2466
10/wiki/Community_Publication_Portal: /* Sean Morrison: Release
7.18.2 */ |
| 06:27.01 |
CIA-53 |
BRL-CAD:
03Sean 07http://brlcad.org * r2467
10/wiki/Community_Publication_Portal: final draft, ready for
posting as soon as merge completes |
| 06:37.07 |
brlcad |
apparently a
problem that was fixed in a later 1.4 version of
subversion |
| 06:40.09 |
*** join/#brlcad jmoore
(~jmoore@cpe-184-57-8-75.columbus.res.rr.com) |
| 11:47.51 |
dloman |
Merning
all! |
| 11:57.01 |
dloman |
*readreadread* |
| 12:10.52 |
dloman |
starseeker /
``Erik either of you good with threading? I just remembered that
GS's JobManagement system is backed by QThread objects |
| 12:37.48 |
CIA-53 |
BRL-CAD:
03davidloman * r43156 10/jbrlcad/trunk/libs/ (. jscience-4.3.1.jar
junit-4.1.jar): Added a libs dir with the two required .jars for
compilation. jScience 4.3.1 is antiquated and no longer available
to the general public but we still want the average jBRLCAD to be
able to jump in, compile and help out. |
| 12:38.53 |
CIA-53 |
BRL-CAD:
03davidloman * r43157
10/jbrlcad/trunk/src/test/java/org/brlcad/ShootTest.java: Add in
missing package statement. |
| 12:40.33 |
CIA-53 |
BRL-CAD:
03davidloman * r43158
10/jbrlcad/trunk/src/test/java/org/brlcad/geometry/HitTest.java:
Import cleanup. |
| 12:54.23 |
starseeker |
dloman:
probably want to look at pthread-win32 + system pthreads on other
platforms |
| 12:54.38 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:10.42 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 13:37.19 |
dloman |
Yeah, but
isn't that swapping the dep on QT for a dep on something
else? |
| 13:38.35 |
dloman |
hangs a Chicken Bone Necklace on his
monitor. |
| 13:38.40 |
dloman |
go go slow
network! |
| 13:41.31 |
dloman |
finishes 1.5 hours of timesheets and other red tape
:/ |
| 14:02.42 |
brlcad |
finishes resolving his first tree conflict |
| 14:04.11 |
brlcad |
at least one
of the new svn 1.6 variety |
| 14:05.17 |
starseeker |
dloman:
pthread-win32 is much smaller than Qt |
| 14:07.15 |
brlcad |
dloman: you
know that jbrlcad doesn't have support for all object / primitive
types? |
| 14:07.24 |
brlcad |
it has
support for just four of them |
| 14:07.29 |
dloman |
yuppers
:) |
| 14:07.50 |
brlcad |
k |
| 14:08.07 |
dloman |
the OCD in me
couldn't stand the fact that jbrlcad is linked against libraries
that are only stored in 'their' private repositories |
| 14:08.46 |
dloman |
so i pulled
the antiquated version of jScience (4.3.1) and checked it into the
jBRLCAD module. |
| 14:09.02 |
brlcad |
saw that but
was more referring to a commit I saw yesterday |
| 14:09.08 |
dloman |
this way,
'anyone' can compile jbrlcad properly. |
| 14:09.10 |
dloman |
which
one? |
| 14:09.15 |
brlcad |
looked like
you're using jbrlcad in the java bridge to GS? |
| 14:09.36 |
dloman |
...not to my
knowledge. That's not my intent. Likely bad wordage on my part
then. |
| 14:09.46 |
dloman |
Im not very
good at engrish |
| 14:10.29 |
brlcad |
r43125 |
| 14:10.38 |
brlcad |
"Keep it
simple and, rather than copy classes that are under development,
make jBRLCAD an dependency. Hopefully this will change in the near
future." |
| 14:11.31 |
dloman |
was talking
about the interface that Ron created in
jbrlcad/src/geometryservice |
| 14:11.47 |
dloman |
thats the
'interface' we are both coding to. |
| 14:12.10 |
dloman |
since its
likely going to change, i figured copy/paste from jbrlcad into rt3
was a maintenance issue. |
| 14:12.30 |
dloman |
I need to
work with Ron on getting all the java source into one
place. |
| 14:13.03 |
brlcad |
where the
java code lives isn't really a major concern |
| 14:13.34 |
dloman |
true, but if
its living in two places, that's annoying and makes life harder.
But that's my problem =D |
| 14:13.36 |
brlcad |
it's the
reliance on there basically needing to be a librt written in java
(which is basically what jbrlcad is) |
| 14:14.37 |
dloman |
... that's
'their' issue... right? |
| 14:15.55 |
brlcad |
well, yes and
no -- more than likely a misuse of the geometry service since it's
supposed to avoid managing geometry on their end |
| 14:16.05 |
brlcad |
geomcore/trunk/src/interfaces/java |
| 14:16.12 |
brlcad |
is that what
ron is working on? |
| 14:16.24 |
brlcad |
or is that
the bridge you're working on? |
| 14:21.38 |
dloman |
sorry, got
attacked by red tape again |
| 14:21.52 |
dloman |
geomcore/trunk/src/interfaces/java is what
I/we are working on |
| 14:22.16 |
dloman |
Ron checked
his 'bridge definition' into jbrlcad |
| 14:22.31 |
brlcad |
so r43125
applied to that path and is where you have the comment about it
using jbrlcad |
| 14:23.05 |
dloman |
correct. in
jbrlcad/src/main/org/brlcad/geometryservice |
| 14:23.27 |
dloman |
there is a
java Interface (aka pure virtual class) called
GeometryService.java |
| 14:23.31 |
brlcad |
if it's using
jbrlcad, then it sounds like there's a problem -- what's it
using? |
| 14:24.20 |
dloman |
rather than
copying that file over to geomcore/src/interfaces/java, i chose to
simply make jbrlcad an ext dep untill we can get all the java code
into one place. |
| 14:24.22 |
brlcad |
the issue is
the dev path forward -- if it's using it for geometry management,
while only supporting 10% of geometry, then there's a future cost
that will have to be realized before it's complete |
| 14:24.29 |
dloman |
its a
temporary thing for now. |
| 14:24.46 |
dloman |
heh, you're
way over thinking it :) |
| 14:24.52 |
brlcad |
probably |
| 14:25.13 |
dloman |
i just need
that file and don't want to (possibly) dev against antiquated
Interface |
| 14:25.29 |
brlcad |
just trying
to understand what's going on, since this is potentially a low risk
/ high risk changer that I'd have to report on and/or
address |
| 14:25.41 |
dloman |
its a
non-factor |
| 14:25.48 |
brlcad |
so if it's
just that one interface, why not move it? |
| 14:26.11 |
dloman |
cause 'they'
need it to, and 'they' are developing in jbrlcad module |
| 14:26.19 |
dloman |
s/to/too/ |
| 14:29.02 |
brlcad |
sounds like
something that will need to be discussed in more detail |
| 14:29.19 |
brlcad |
that's their
perrogative, but implies the GS isn't doing something they
need |
| 14:30.32 |
brlcad |
or that
they're crossing over into geometry management land on the java
side, which they're not supposed to be doing |
| 14:31.53 |
brlcad |
either way --
a "GeometryService" class makes no sense in jbrlcad other than as a
commit location for all java code |
| 14:32.52 |
brlcad |
it'd imply
either moving the java code you're working on over to the jbrlcad
module or moving that class out of jbrlcad into where you're using
it and providing it as an interface from there |
| 14:33.32 |
brlcad |
I suspect it
was just added just as a dumping ground for all geometry-related
java code, not because it made sense |
| 14:34.57 |
dloman |
naming-wise,
I agree. GeometryService is a rather incorrect name for an
Interface that will be sitting in their code base |
| 14:36.05 |
dloman |
GSAccessPoint
perhaps |
| 14:36.45 |
brlcad |
even with
that name, that doesn't really have anything to do with
"jbrlcad" |
| 14:36.54 |
dloman |
true
:) |
| 14:37.08 |
brlcad |
it's a GS
thing so it should live with the GS code |
| 14:37.57 |
dloman |
i think i am
going to 'out-dev' them rather rapidly, so I'll likely just take
any/all GS related java code out of jBRLCAD module
anyways. |
| 14:38.58 |
brlcad |
it's basic
"separation of concerns" |
| 14:39.18 |
brlcad |
sounds like a
communication needing to be had regardless |
| 14:39.42 |
dloman |
agreed. I'll
zip an email up to Ron John (*snicker*) or walk up there
later |
| 14:40.24 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 14:41.43 |
CIA-53 |
BRL-CAD:
03brlcad * r43159
10/brlcad/trunk/misc/debian/application-x-brlcad-extension.xml: set
eol-style |
| 14:42.02 |
brlcad |
15 minute
commit ruined by a single line ending failure |
| 14:42.52 |
dloman |
http://assets.head-fi.org/f/fd/fd9be1b5_fuuuuuuuu.jpg
=D |
| 14:43.50 |
CIA-53 |
BRL-CAD:
03davidloman * r43160
10/geomcore/trunk/src/interfaces/java/.settings/ (.
org.eclipse.jdt.ui.prefs): Putting in Eclipse .settings directory.
Contains project settings that are not machine specific, but allows
for auto insertion of BRLCAD header. |
| 14:45.21 |
dloman |
FYI, Ed's in
today. |
| 14:47.04 |
CIA-53 |
BRL-CAD:
03davidloman * r43161
10/geomcore/trunk/src/interfaces/java/auto-props.cfg: Update sample
auto-props file with more mime-types. |
| 14:49.53 |
CIA-53 |
BRL-CAD:
03davidloman * r43162
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/
(9 files in 3 dirs): Clean up existing and add missing
headers. |
| 14:59.35 |
brlcad |
dloman: heh,
what's with the sample auto-props? |
| 15:00.47 |
dloman |
getting
autoprops on winderz is a PITA, especially here at work. so i
figgered i'd put in a file to help |
| 15:00.52 |
brlcad |
much more
extensive "sample" on the website: http://brlcad.org/wiki/Mime-types |
| 15:01.55 |
dloman |
kk, i'll link
that. danke. |
| 15:03.48 |
brlcad |
begins final release distcheck |
| 15:04.37 |
dloman |
the word
'distcheck' still makes me take look twice |
| 15:06.33 |
brlcad |
you have to
look twice to find it? |
| 15:06.45 |
brlcad |
oh SNAP! no
he didn't |
| 15:07.17 |
dloman |
ohnoe u dint!
(repeat x4) |
| 15:09.23 |
CIA-53 |
BRL-CAD:
03brlcad * r43163 10/brlcad/branches/STABLE/ (4855 files in 354
dirs): merge trunk to STABLE from r41558 to HEAD r43158 |
| 15:18.04 |
starseeker |
brlcad: heh -
ruined commits due to prop issues suck - I still wish svn let us
check that before we go through the network process... |
| 15:18.18 |
starseeker |
especially
fun when upgrading tcl/tk |
| 15:21.55 |
``Erik |
*readreadread* np my ass |
| 15:23.39 |
dloman |
eh? |
| 15:25.03 |
``Erik |
dlo: I think,
uh, we'll move GS to bu, then fix win32 bu threading |
| 15:25.20 |
dloman |
okie. |
| 15:25.33 |
dloman |
I was just
thinking about all the areas that QT is in |
| 15:25.41 |
dloman |
and realized
its in the threading also. |
| 15:25.51 |
``Erik |
jbrlcad is,
uh, ... probably not very relevant |
| 15:28.42 |
``Erik |
aight, all
caught up |
| 15:29.10 |
``Erik |
yeh, I'm
de-qt'ing it pretty heavily, it winds all up and down, but we'll
get there :) 'sall good |
| 15:30.22 |
``Erik |
(the np
comment was about tesselation, I'm fairly certain it's not np, I'm
thinking more in the n^2 or nlgn if done right... we have a feeble
implementation) |
| 15:38.58 |
CIA-53 |
BRL-CAD:
03starseeker * r43164 10/geomcore/trunk/src/other/sqlite/ (CMake/
CMake/ResolveCompilerPaths.cmake CMakeLists.txt): Try looking for
dl for sqlite |
| 15:41.26 |
starseeker |
dloman: does
that help? |
| 15:41.33 |
dloman |
one
sec |
| 15:42.43 |
dloman |
Sure does!
*thumbs up* |
| 15:47.52 |
CIA-53 |
BRL-CAD:
03starseeker * r43165
10/geomcore/trunk/cmake/FindTCL.cmake: |
| 15:47.52 |
CIA-53 |
BRL-CAD:
Ironically, our new FindTCL isn't suitable for finding BRL-CAD's
tcl/tk, since |
| 15:47.52 |
CIA-53 |
BRL-CAD: it
requires the .sh config files from Tcl and the new CMake build
isn't |
| 15:47.52 |
CIA-53 |
BRL-CAD:
generating or installing them (did our autotools build, for that
matter?). Need |
| 15:47.52 |
CIA-53 |
BRL-CAD: to
have the CMake build for tcl/tk generate those .sh
files |
| 15:55.38 |
``Erik |
heh |
| 16:08.03 |
CIA-53 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2468 10/wiki/NetMsgTypes: Update MsgType chart with accurate
info. |
| 16:09.12 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43166 10/geomcore/trunk/ (89 files in 9 dirs):
removal of some unnecessary QT-isms |
| 16:09.17 |
CIA-53 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2469 10/wiki/NetMsgTypes: Changed verbage and added 8byte generic
msgtype |
| 16:34.09 |
CIA-53 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2470 10/wiki/NetMsgTypes: Typo fix |
| 16:39.52 |
CIA-53 |
BRL-CAD:
03davidloman * r43167
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/
(NetMsgFactory.java msg/NetMsgTypes.java): Sync msgTypes with
GeomCore module. |
| 17:15.22 |
*** join/#brlcad jay_ (~jay@212.96.10.253) |
| 17:18.00 |
jay_ |
hello |
| 17:19.35 |
jay_ |
you guys know
of any linux architectural CAD app? |
| 17:55.36 |
starseeker |
jay_: depends
on what you're after - commercially, there's this http://www.cycas.de/ |
| 17:56.24 |
starseeker |
maybe this is
of interest? http://sourceforge.net/projects/sweethome3d/ |
| 17:59.16 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43168
10/geomcore/trunk/src/utility/DataStreamUtils.cxx: fix ambiguous
overload error |
| 18:03.28 |
brlcad |
``Erik: with
floating point math, solving boolean evaluation for polygonal
topology is not just n^2 even though the core algorithm
is |
| 18:03.31 |
starseeker |
``Erik:
that's got it on the mac |
| 18:04.45 |
brlcad |
it becomes a
search problem, you have to make blind guess decisions at which
point there's no longer a single "final solution" .. there's a set
of solutions and you're looking for a valid solution, which is not
easy |
| 18:05.19 |
starseeker |
still one in
Linux - GenericEightBytesMsg.c:31: prototype not
matching |
| 18:05.45 |
starseeker |
error:
prototype for 'GenericEightBytesMsg::GenericEightBytesMsg(uint32_t,
quint64)' does not match any in class
'GenericEightBytesMsg' |
| 18:06.33 |
starseeker |
few
others... |
| 18:07.55 |
brlcad |
consider the
simple example of the subset sum problem, which is np-complete --
it states given a set of integers, do any non-empty subset of them
add up to zero |
| 18:08.49 |
brlcad |
that same
characterization can be made of vertices during evaluation, given a
set of points, do any non-empty subset of them coincide (i.e., are
the same point) |
| 18:09.55 |
brlcad |
that and
other hard questions get repeatedly asked, a decision is made, and
the underlying O(N^2) algorithm continues to the next
edge/vertex/face/shell/object |
| 18:12.58 |
CIA-53 |
BRL-CAD:
03davidloman * r43169
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/RemoteNodeNameSetMsg.java:
Implement RemoteNodeNameSetMsg in java. |
| 18:14.54 |
jay_ |
starseeker:
thnx |
| 18:21.01 |
dli |
brlcad, do
you mean any repeated point? |
| 18:21.22 |
dli |
brlcad, or
give a list of subsets, any repeated? |
| 18:21.30 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43170
10/geomcore/trunk/src/libNet/PortalManager.cxx: add missing
parameter |
| 18:25.05 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43171 10/geomcore/trunk/src/ (3 files in 2
dirs): snprintf type fixes |
| 18:32.49 |
brlcad |
dli: given a
set of points, which are equal to other points within a given
tolerance |
| 18:34.45 |
brlcad |
even with
exact non-floating point computation, if you add a "within
tolerance" qualifier, you suddenly have np-hard decision
searching |
| 18:35.04 |
brlcad |
floating
point just adds an implicit tolerance on top of a geometric
tolerance |
| 18:36.03 |
dli |
brlcad,
partition the coordinates according the tolerance, so, from real x
-> integer i_x = [ x/dr +0.5], now, you only have to search
within i_x plus/minus 1, j_y plus/minus 1, etc. O(N) |
| 18:40.16 |
dli |
brlcad, if we
can waste on memory, partition points to a 3d array, search is
still O(N) |
| 18:42.19 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43172 10/geomcore/trunk/ (40 files in 9 dirs):
switch from QT typedefs to standard typedefs |
| 18:43.12 |
dli |
brlcad,
suppose the wanted tolerance is tiny, partitioning to 1/dr is
impractical, we can simply use an intermediate (dr0), now, only
have to search within neighbours of (dr0), divide and
conquer |
| 18:57.11 |
CIA-53 |
BRL-CAD:
03starseeker * r43173 10/geomcore/trunk/cmake/ (10 files): Clean
out some of the unneeded .cmake files - may be more scrubbing to do
here. |
| 18:57.28 |
brlcad |
dli: the
tolerance is generally very very tiny in relation to the
value |
| 18:57.53 |
brlcad |
moreover,
depending on how you group points will affect the resulting
decision |
| 18:57.58 |
dli |
brlcad, then,
use a reasonable intermediate dr0 |
| 18:58.29 |
brlcad |
there is no
definition of reasonable that applies to arbitrary
geometry |
| 18:58.36 |
dli |
brlcad, only
search within neighborhood of dr0 |
| 18:58.46 |
CIA-53 |
BRL-CAD:
03starseeker * r43174 10/geomcore/trunk/ (12 files in 9 dirs):
Start working on getting the tests running again - leave them off
for now, as there's a fair bit of work to do. |
| 18:58.47 |
brlcad |
define
neighborhood |
| 18:58.55 |
dli |
brlcad, no,
but as far as it's fast for most cases |
| 18:59.13 |
brlcad |
so you get a
wrong answer fast .. that's not very useful :) |
| 18:59.31 |
dli |
brlcad, no,
this algorithm doesn't get any wrong answer |
| 18:59.41 |
brlcad |
this is a
problem best explained with a white board |
| 18:59.50 |
dli |
brlcad,
anything outside of dr0 wont be within dr |
| 19:00.17 |
brlcad |
if you have a
proof, then you'd have a ground-breaking research paper -- the
geometry is nowhere near as rigorous or clean as it sounds like
you're presuming |
| 19:00.46 |
brlcad |
the tolerance
has to be big enough so points will merge together, this is a good
thing |
| 19:01.01 |
brlcad |
but too big,
and it'll join topology that should not be joined |
| 19:01.34 |
brlcad |
in practice
that is a weighted local tolerance that might take curvature,
topology, and other factors into account |
| 19:01.48 |
brlcad |
just assuming
a hard 0.000# tolerance just doesn't work |
| 19:01.56 |
brlcad |
no matter how
small you make it |
| 19:03.07 |
brlcad |
and it STILL
doesn't address the impact of deciding a coinciding point that are
within tolerance |
| 19:03.22 |
brlcad |
consider
three points: A, B, C |
| 19:03.24 |
dli |
brlcad,
http://num-meth.srcc.msu.ru/english/zhurnal/tom_2010/v11r135.html |
| 19:03.42 |
brlcad |
A is within
tolernace of B, B is within tolerance of C, but A is not within
tolerance of C |
| 19:04.37 |
brlcad |
how you join
those will result in different topology, and there is no knowledge
about which choice is right other than the final geometry being
considered "valid" or not |
| 19:04.49 |
dli |
brlcad, I'm
still not clear whether voronoi cell is relevant here, voronoi is n
log(n), more robust than neighbor searching algorithms |
| 19:06.37 |
brlcad |
dli: not sure
what you're trying to show with that paper, but at a glance it
looks like a simple spatial partitioning of your comparisons --
that's merely optimization (and not particularly relevant since
you're generally not comparing that many neighboring
points) |
| 19:07.17 |
dli |
brlcad,
neighbor searching is not robust, I know that, but voronoi is
robust |
| 19:07.19 |
brlcad |
it's the same
problem even if you try to carve up voronoi
neighborhoods |
| 19:07.47 |
brlcad |
you have to
decide where to split and there is no definition of how/where to
split |
| 19:07.58 |
brlcad |
take that
three-point example -- that's about as basic as it gets |
| 19:08.34 |
dli |
brlcad,
original voronoi problem doesn't require definition of neighbors,
http://en.wikipedia.org/wiki/Voronoi_diagram |
| 19:09.14 |
brlcad |
how is that
helping? |
| 19:09.24 |
dli |
brlcad, it
will generate voronoi diagram on any 3 points on plane, I'm not
clear how the algorithm with behavior with repeated
points |
| 19:09.42 |
brlcad |
how is that
helping? |
| 19:09.59 |
dli |
brlcad, let's
suppose no repeated points, all points a different by tiny
distance |
| 19:10.24 |
brlcad |
sure |
| 19:10.31 |
dli |
brlcad, then,
generate voronoi cells, find the small cells, test the points with
its neighbors (as defined by voronoi) |
| 19:11.02 |
brlcad |
test them for
what? |
| 19:11.31 |
brlcad |
take the
simple ABC case, what's being tested? |
| 19:11.32 |
dli |
brlcad, for
each point, get the distance to its voronoi neighbors |
| 19:11.46 |
brlcad |
okay, that's
distance AB, BC, and AC |
| 19:11.54 |
brlcad |
now
what? |
| 19:12.10 |
dli |
brlcad, now,
decide whether within tolerance |
| 19:12.26 |
brlcad |
okay, AB are
within tol, BC are within tol, AC are not |
| 19:12.26 |
dli |
brlcad, the
good thing is that, after voronoi, it's O(N) |
| 19:12.28 |
brlcad |
now
what? |
| 19:12.54 |
dli |
brlcad, oh,
that's another question :( |
| 19:13.12 |
brlcad |
follow this
through, you're still not getting the problem -- I know what
voronoi are and do, but finding neighbors isn't the
problem |
| 19:13.44 |
dli |
brlcad, I
thought the problem is finding neighbor, now, it's the definition
of neighbor |
| 19:13.52 |
brlcad |
bingo |
| 19:15.28 |
brlcad |
topologically
with A, B, and C, you might want to join A+B and keep C separate ..
or join B+C and leave A separate .. or loosen the tolerance and
join A+B+C |
| 19:15.34 |
dli |
so, what
about just give it tighter tolerance? then, just randomly combine
points, until no overlap exists |
| 19:16.07 |
brlcad |
tighten the
tolerance, and you avoid joining A B and C altogether, and your
topology is broken/invalid |
| 19:16.52 |
brlcad |
in practice,
you'll want either [A+B, C] or [A, B+C] .. but you just don't know
which one is right (or if either of them is right) |
| 19:17.13 |
brlcad |
generally one
of them is right, the other is not but it becomes a decision
tree |
| 19:17.20 |
dli |
brlcad, no, I
don't understand this. tighter tolerance shouldn't break
anything |
| 19:17.56 |
brlcad |
understandable, hard to see with just
three points |
| 19:18.17 |
brlcad |
topologically, you're stitching together
geometry -- polygon faces or spline surfaces |
| 19:18.37 |
brlcad |
you're trying
to decide whether polygon 1 attaches to polygon 2 |
| 19:18.53 |
brlcad |
so you might
compare the vertices of 1 with the vertices of 2 |
| 19:19.35 |
brlcad |
for solid
geometry, all meshes must enclose space |
| 19:19.44 |
brlcad |
otherwise
they are just infinitely thin dangling faces |
| 19:20.37 |
dli |
brlcad, yes,
I see the rough picture now |
| 19:20.41 |
brlcad |
if you
tightened your tolerance to .. 0 .. then only vertices that are
exact-exact matches join (which isn't practical with floating
point), so it basically won't think those two faces are
topologically connected when they should be |
| 19:21.18 |
brlcad |
loosen the
tolerance too much and you end up joining faces that are "close"
but shouldn't be joined _toplogically_ |
| 19:21.52 |
brlcad |
it really is
a pretty fucking hard problem (pardon my language) to make
robust |
| 19:22.29 |
dli |
brlcad, I
suppose to write a function to generate intersection, so, I have to
handle this problem |
| 19:22.47 |
brlcad |
in an ideal
world, you'd keep track of your decision tree as you progress
through the evaluations, use a floating/variable tolerance that
adjusts to topology, and have a means to unroll back through
decisions when you end up with invalid results |
| 19:23.22 |
brlcad |
strictly
speaking yes you will, but it's not nearly as bad for surface
surface evaluations |
| 19:23.53 |
brlcad |
it's a
problem for the code that will USE your surface-surface function
:) |
| 19:24.30 |
dli |
brlcad, let
try and see how it works out |
| 19:24.35 |
CIA-53 |
BRL-CAD:
03starseeker * r43175
10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: Make a stab at
GeometryServiceTest |
| 19:25.48 |
brlcad |
dli: mind
you, in practice, you can generally find a "sweet spot" tolerance
or set of tolerances that will make it all work and evaluate
correctly for a given input -- my ranting is merely addressing the
np-hardness of the underlying decision problem |
| 19:26.06 |
brlcad |
you can make
AB/BC/AC decisions for 99% of geometry just fine |
| 19:26.48 |
brlcad |
the issue is
usually error accumulation, that's where NMG (our polygon library)
has problems |
| 19:27.10 |
dli |
brlcad, if
so, can we use integer instead? |
| 19:27.14 |
brlcad |
like I said
earlier with the [A+B, C] or [A, B+C] decision case, you'll
probably pick one of those two results |
| 19:27.32 |
brlcad |
but whether
you join A+B or B+C .. what value do you actually use? |
| 19:27.48 |
dli |
brlcad, 64bit
integer would be good enough |
| 19:27.52 |
brlcad |
A+B -> A's
value? B's value? the midpoint of A+B? |
| 19:28.09 |
brlcad |
all three
options results in point drift |
| 19:28.54 |
dli |
brlcad, still
error accumulating |
| 19:31.52 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43176 10/geomcore/trunk/tests/
(libEvent/BasicEventTest.cxx utility/configTest.cxx): de-QT some
more |
| 19:34.05 |
brlcad |
dli: yep, the
all _potentially_ accumulate error |
| 19:34.55 |
brlcad |
if "A" is
right, then C won't be merged ... if you pick B's value or midpoint
of A+B, then you might actually even now be within tolerance of C
.. which effectively collapses to A+B+C |
| 19:36.13 |
brlcad |
whether you
use floating point or integer comparisons won't really make much of
a difference is my gut feeling. it might give you locally stable
behavior but not algorithmic stability |
| 19:36.56 |
brlcad |
the best
results I've seen use interval arithmetic, which can be done with
floating just fine |
| 19:37.12 |
brlcad |
it's
basically a way to track the error |
| 19:38.30 |
brlcad |
you can get
the same result by recording a ULP and the local per-vertex
error |
| 19:44.17 |
dli |
brlcad,
instead of seeing error accumulating, I feel it can be
self-healing, to adjust points according to the direction/side of
solid |
| 19:45.03 |
dli |
brlcad,
whatever the adjustment, it never gives broken topology |
| 19:46.30 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43177
10/geomcore/trunk/tests/utility/CMakeLists.txt: copy test config
file to bin dir |
| 19:51.01 |
CIA-53 |
BRL-CAD:
03starseeker * r43178 10/geomcore/trunk/ (6 files in 4 dirs): Gets
the tests almost building, although not sure how correct the
changes are. |
| 19:51.19 |
brlcad |
dli: that's
not a bad idea, and probably possible, but definitely not
easy |
| 19:51.41 |
brlcad |
our NMG
library does something like that now, trying to make sure it's
never broken as evaluation progresses |
| 19:52.34 |
dli |
brlcad, nice,
good enough for me to try |
| 19:52.40 |
brlcad |
the problem
is that it's still a decision tree and there are invalid decision
nodes that might lead to valid (desireable) final states, or
numerous competing valid states ( like [A+B, C] or [A, B+C]
) |
| 19:53.55 |
CIA-53 |
BRL-CAD:
03starseeker * r43179
10/geomcore/trunk/tests/libEvent/BasicEventTest.cxx: There we go -
get BasicEventTest compiling too. |
| 19:56.49 |
CIA-53 |
BRL-CAD:
03davidloman * r43180
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/
(AbstractNetMsg.java RemoteNodeNameSetMsg.java): Updated
AbstractNetMsg's deserial cstr to take the msg type. Type will be
deserialized in order to determine how to construct an
AbstractNetMsg object anyways, so it needs to be set by a
subclass. |
| 19:59.43 |
CIA-53 |
BRL-CAD:
03brlcad * r43181 10/brlcad/trunk/src/libfb/if_ogl.c: linux is
using __USE_BSD and __USE_XOPEN_EXTENDED in order to get to the
getpagesize() declaration. |
| 20:00.35 |
CIA-53 |
BRL-CAD:
03davidloman * r43182
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java:
Add a static for libpkg's header size. |
| 20:00.55 |
starseeker |
GenericEightBytesMsg.cxx:44: error: no
match for 'operator>>' in '* ds >>
((GenericEightBytesMsg*)this)->GenericEightBytesMsg::data' |
| 20:01.55 |
CIA-53 |
BRL-CAD:
03brlcad * r43183 10/brlcad/branches/STABLE/src/libfb/if_ogl.c:
merge r43181 from trunk |
| 20:02.26 |
CIA-53 |
BRL-CAD:
03erikgreenwald * r43184 10/geomcore/trunk/src/utility/Config.cxx:
simplify and correct line parsing logic |
| 20:03.26 |
brlcad |
bah |
| 20:20.56 |
CIA-53 |
BRL-CAD:
03brlcad * r43185 10/brlcad/trunk/src/libfb/if_ogl.c: it actually
needs __USE_XOPEN and __USE_BSD to get to the decl, so add them
both with ifndef protection. this suckage belongs in
libbu. |
| 20:21.54 |
CIA-53 |
BRL-CAD:
03brlcad * r43186 10/brlcad/branches/STABLE/src/libfb/if_ogl.c:
merge r43183 from trunk for the getpagesize() fix when compiling
with ogl enabled on linux |
| 20:22.23 |
epileg |
I want to
improve the brlcad mime type on Linux. It appears that all geometry
db files begin with "76 01 00 00 00 00 01 35 76". Is this
correct? |
| 20:24.02 |
CIA-53 |
BRL-CAD:
03davidloman * r43187
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NewSessionReqMsg.java:
Implement NewSessionReqMsg in java. |
| 20:26.29 |
``Erik |
not
necessarily... 0x76 is the magic for our version 5 db, but the
second byte is flag information |
| 20:26.38 |
``Erik |
um,
include/db5.h shows the on disk header |
| 20:26.56 |
brlcad |
the first 8
bytes should be right |
| 20:27.22 |
CIA-53 |
BRL-CAD:
03davidloman * r43188
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/SessionInfoMsg.java:
Implement SessionInfoMsg in java. |
| 20:27.28 |
brlcad |
but yeah,
that only applies v5 too -- v4 looks rather different |
| 20:28.43 |
epileg |
but the db
version is so variant? |
| 20:29.28 |
epileg |
and what's
the header bytes on v4? |
| 20:30.00 |
brlcad |
don't worry
about v4, they're older files |
| 20:30.58 |
epileg |
just for
people who has some db v4 files |
| 20:32.45 |
brlcad |
if you really
want to be flexible, you can only count on the first byte being 76
and the eigth byte being 35 for v5 |
| 20:35.12 |
``Erik |
I don't think
there is head magic for v4 |
| 20:35.31 |
epileg |
hmmmm, I'll
try just for v5. |
| 20:37.46 |
brlcad |
v4 files
start with an 'ident' record |
| 20:38.12 |
brlcad |
so it'll be
something like 'I?v4' 49 01 76 34 |
| 20:38.44 |
brlcad |
version key
again being 76 and 34 |
| 20:39.22 |
``Erik |
should
probably have a bit more magic for v6 O.o |
| 20:39.22 |
epileg |
aha |
| 20:40.35 |
brlcad |
yeah, [0]==76
[7]==36 :) |
| 20:41.02 |
epileg |
for
v4? |
| 20:41.09 |
brlcad |
that'd be
"v6" :) |
| 20:41.14 |
brlcad |
which doesn't
exist yet |
| 20:41.33 |
epileg |
ops,
ok |
| 20:43.52 |
CIA-53 |
BRL-CAD:
03davidloman * r43189
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: |
| 20:43.52 |
CIA-53 |
BRL-CAD:
Implement first pass at a GSConnection object. GSConnection
contains a static |
| 20:43.53 |
CIA-53 |
BRL-CAD:
factory method that will create a GSConnection, handshake and
authenticate with |
| 20:43.53 |
CIA-53 |
BRL-CAD: a GS
Server. Socketing is blocking as the responsibility for
polling/selecting |
| 20:43.53 |
CIA-53 |
BRL-CAD: is
tossed to the user of this interface. |
| 20:47.16 |
brlcad |
initial
release build seems to work |
| 20:47.57 |
brlcad |
funkyness in
archer (rt crashes, display doesn't update on start) but rtwizard
and mged seem to be doing alright |
| 20:57.08 |
CIA-53 |
BRL-CAD:
03starseeker * r43190
10/brlcad/branches/cmake/include/config_win_cmake.h: This should be
coming from src/other now... |
| 21:37.19 |
CIA-53 |
BRL-CAD:
03brlcad * r43191 10/brlcad/tags/rel-7-18-2/: tagging release
7.18.2 |
| 21:53.26 |
CIA-53 |
BRL-CAD:
03brlcad * r43192 10/brlcad/trunk/include/conf/PATCH: release is
tagged, bump to 7.18.3 |
| 21:53.57 |
CIA-53 |
BRL-CAD:
03brlcad * r43193 10/brlcad/trunk/ (NEWS README): prepare for next
expected 7.18.4 release |
| 21:58.55 |
brlcad |
would someone
else mind sanity testing the 7.18.2 tag? |
| 21:59.11 |
brlcad |
BRL-CAD Open
Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.2 is posted (20110209) |
| 22:06.56 |
brlcad |
have at it
``Erik |
| 22:07.09 |
starseeker |
brlcad: I'm
compiling now |
| 22:09.43 |
brlcad |
thx |
| 22:15.38 |
``Erik |
hm, solids.sh
regress 3 off by many |
| 22:15.55 |
``Erik |
on 32b fbsd,
but not on 64b linux |
| 22:16.00 |
``Erik |
interesting |
| 22:17.42 |
brlcad |
yeah, I've
seen that one before too |
| 22:18.33 |
brlcad |
I put a note
in the BUGS file for it, been failing with an (one) off-by-many
error on an optimized mac build |
| 22:18.57 |
brlcad |
iirc it was
grazing the edge of an arb8 |
| 22:22.18 |
CIA-53 |
BRL-CAD:
03starseeker * r43194 10/brlcad/branches/cmake/src/other/
(tcl/CMakeLists.txt tk/CMakeLists.txt): Looks like these flags may
be causing trouble - comment out for now... |
| 22:27.38 |
starseeker |
urm. Getting
Itcl_Init ERROR |
| 22:28.30 |
starseeker |
looks like
libitcl3.4.la is there, but not the .so |
| 22:31.13 |
starseeker |
installed
version does OK though |
| 22:31.17 |
starseeker |
just build
dir |
| 22:31.43 |
``Erik |
does a fresh checkout to see how bad he broke
it |
| 22:32.13 |
*** join/#brlcad CIA-62
(~CIA@208.69.182.149) |
| 22:43.19 |
CIA-62 |
BRL-CAD:
03starseeker * r43196 10/brlcad/branches/cmake/src/other/
(tcl/CMakeLists.txt tk/CMakeLists.txt): Let's try this again
without nuking all the TK_FLAGS in the process... |
| 01:26.52 |
louipc |
hmm step
files are text eh |
| 01:31.54 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 01:43.24 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
| 02:58.15 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 03:05.09 |
*** join/#brlcad juan_man
(~quassel@unaffiliated/juanman) |
| 05:07.39 |
CIA-6 |
BRL-CAD:
03Sean 07http://brlcad.org * r2478
10/wiki/NURBS_TODO: stub in the rest |
| 05:35.22 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:50.38 |
CIA-6 |
BRL-CAD:
03Sean 07http://brlcad.org * r2479
10/wiki/NURBS_TODO: expand time estimates, references, and benefits
on most tasks |
| 07:18.40 |
CIA-6 |
BRL-CAD:
03brlcad * r43308 10/brlcad/trunk/src/irprep/firpass.c: |
| 07:18.40 |
CIA-6 |
BRL-CAD:
replace all of the NEAR_*() calls with an arbitrary FLT_MIN (which
is basically |
| 07:18.40 |
CIA-6 |
BRL-CAD: one
ulp step up from 0) to their corresponding ZERO() and EQUAL()
calls. |
| 07:18.40 |
CIA-6 |
BRL-CAD:
FLT_MIN shouldn't be used anyways unless 1ulp is the goal (in which
case there's |
| 07:18.40 |
CIA-6 |
BRL-CAD: a
libbn function for it), SMALL_FASTF is our base computation
tolerance. |
| 07:19.44 |
CIA-6 |
BRL-CAD:
03brlcad * r43309 10/brlcad/trunk/src/sig/dmod.c: prefer ZERO()
over NEAR_ZERO() when the tol is merely FLT_MIN or (better)
SMALL_FASTF. |
| 07:23.03 |
CIA-6 |
BRL-CAD:
03brlcad * r43310 10/brlcad/trunk/src/rt/heatgraph.c: <= and
>= are still comparing floating point values for equality, which
is not reliable. call EQUAL() and ZERO() accordingly. |
| 07:25.52 |
CIA-6 |
BRL-CAD:
03brlcad * r43311 10/brlcad/trunk/src/rt/heatgraph.c: technically
more simple to just test for less than zero .. though unsafe. (some
comparisons need to compare against +-SMALL_FASTF instead of
0) |
| 11:48.40 |
dloman |
Mernin! |
| 11:52.37 |
dloman |
Question to
anyone in the know: Has anyone taken a deep look into how/if
current GPU processing techniques could benefit our
raytracer? |
| 12:26.34 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:31.56 |
*** join/#brlcad WhiteCalf
(MK@2607:f0d0:3001:68::2) |
| 12:33.06 |
*** join/#brlcad kanzure_
(~kanzure@bioinformatics.org) |
| 12:38.30 |
CIA-6 |
BRL-CAD:
03davidloman * r43312
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java:
Add null check for the GSClient's GSConnection to ensure a 1:1
GSConnection per GSClient ratio. |
| 12:46.08 |
CIA-6 |
BRL-CAD:
03davidloman * r43313
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClientGUI.java:
Breakout GUI elements into their own class. Keeps things clean and
easier to manage. |
| 12:47.56 |
CIA-6 |
BRL-CAD:
03davidloman * r43314
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/
(Main.java MinimalGSClient.java): Implement new MinimalGSClient
class (without gui components) and roll down the changes to the
main() method. |
| 12:56.59 |
CIA-6 |
BRL-CAD:
03d_rossberg * r43315
10/brlcad/trunk/src/libged/CMakeLists.txt: |
| 12:56.59 |
CIA-6 |
BRL-CAD:
there are references to libregex here |
| 12:56.59 |
CIA-6 |
BRL-CAD:
added libregex headers search path |
| 12:59.50 |
CIA-6 |
BRL-CAD:
03d_rossberg * r43316 10/brlcad/trunk/src/librt/CMakeLists.txt:
synced with Makefile.am: "bottie modifications moved to
trunk" |
| 13:24.13 |
CIA-6 |
BRL-CAD:
03davidloman * r43317
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/Main.java:
Removed stray debugging statement. |
| 13:26.08 |
CIA-6 |
BRL-CAD:
03davidloman * r43318
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/AbstractCmd.java:
Put in usage and help printing methods. Keeps formatting consistent
and removes potential future formatting bug points. |
| 13:26.46 |
CIA-6 |
BRL-CAD:
03davidloman * r43319
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java:
Quick Comment... |
| 13:27.14 |
CIA-6 |
BRL-CAD:
03davidloman * r43320
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java:
Add tabs and newlines for this lib. More efforts to promote
consistency. |
| 13:27.45 |
CIA-6 |
BRL-CAD:
03davidloman * r43321
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/
(CmdManager.java HelpCmd.java LoginCmd.java): Clean up console
printing formats. Use helper methods and statics. |
| 13:32.30 |
CIA-6 |
BRL-CAD:
03davidloman * r43322
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java:
Import cleanup. |
| 14:17.36 |
CIA-6 |
BRL-CAD:
03davidloman * r43323
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java:
Create GSJavaInterface, the class that implements the interface
'GeometryService' as defined in jBRLCAD. This will be the public
API for this GS interface |
| 14:31.49 |
CIA-6 |
BRL-CAD:
03davidloman * r43324
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/
(7 files in 2 dirs): Propagate use of GSJavaInterface throughout.
Allow for AbstractCmd subclasses to gain access to the associated
GSJavaInterface, so as to be able to act upon it. |
| 15:09.12 |
CIA-6 |
BRL-CAD:
03erikgreenwald * r43325 10/geomcore/trunk/ (include/Logger.h
src/utility/Logger.cxx): simplify, atomicize, remove mutex
stuff |
| 15:10.28 |
CIA-6 |
BRL-CAD:
03erikgreenwald * r43326 10/geomcore/trunk/ (25 files in 13 dirs):
remove some mutex stuff. remove redundant sleep wrapping. adjust to
cope with new include paths sent from FindBRLCAD.cmake |
| 15:54.59 |
CIA-6 |
BRL-CAD:
03davidloman * r43327
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java:
Implement minimal client's ability to login to a gs |
| 16:09.24 |
dloman |
starseeker:
you around? |
| 16:10.04 |
dloman |
in
geomcore/src/other/uuid, there are two headers being generated:
uuid_config and uuid.h |
| 16:10.19 |
dloman |
should those
be svn:ignored? |
| 16:12.17 |
CIA-6 |
BRL-CAD:
03davidloman * r43328 10/geomcore/trunk/src/interfaces/ (. c/
java/): Modified SVN:IGNORE to exclude configure and build
byproducts. |
| 16:13.44 |
CIA-6 |
BRL-CAD:
03davidloman * r43329 10/geomcore/trunk/src/other/uuid/: Modified
SVN:IGNORE to exclude configure and build byproducts. |
| 16:47.38 |
dloman |
starseeker:
Since you are endeavoring for an out of build setup, would it be
desireable for me to go and remove all the cmake related entries in
svn:ignore |
| 16:49.09 |
starseeker |
dloman: yeah,
that'd be good |
| 16:49.15 |
starseeker |
I can do it
if you like |
| 16:50.45 |
dloman |
nah, I need a
few mins break from what I am doin anyways :) |
| 16:51.56 |
dloman |
looking at
the svn:ignore list, is there anything besides cmake_install.cmake,
CMakeCache.txt and CMakeFiles that you think sould be
removed? |
| 16:52.17 |
starseeker |
dloman:
I' |
| 16:52.26 |
starseeker |
I've been
clearing it entirely |
| 17:00.35 |
dloman |
prepares nuklar bomb for svn:ignore.... |
| 17:01.50 |
CIA-6 |
BRL-CAD:
03davidloman * r43330 10/geomcore/trunk/ (36 files in 36 dirs):
Drop a nuklar bomb on svn:ignore. Pushing for out of source
builds. |
| 17:02.02 |
dloman |
boom |
| 17:02.08 |
starseeker |
heh |
| 17:03.20 |
dloman |
starseeker:
cmake's INSTALL cmd should be used for copying a file to the
install bin dir? |
| 17:03.32 |
dloman |
aka, I have
two .configure files i need copied over with the build |
| 17:03.58 |
starseeker |
no, INSTALL
is for the final make install |
| 17:04.22 |
starseeker |
if you want
something copied over with the build, used either configure_file,
FILE(COPY or |
| 17:04.40 |
starseeker |
(if you want
it to be copied by make and not the cmake configure) make a custom
command and custom target |
| 17:05.01 |
starseeker |
the latter is
a bit more complex because you're essentially telling CMake how to
tell Make/Visual Studio/etc. to do it |
| 17:05.38 |
dloman |
okay, so
making cmake tell make == hard, using cmake to do it == easymode
? |
| 17:06.57 |
starseeker |
it's worth it
if the file is one you want to edit and copy over to the build tree
a lot |
| 17:07.19 |
starseeker |
it's not that
hard, just a few more lines |
| 17:07.29 |
dloman |
its a default
.configure file, thats all. |
| 17:13.01 |
dloman |
using
FILE(COPY src dest) |
| 17:13.04 |
dloman |
awesome
thanks :) |
| 17:16.36 |
starseeker |
np
:-) |
| 17:19.07 |
dloman |
crud, i ran
into a brlcad install problem, but i cant remember how to fix
it. |
| 17:21.21 |
dloman |
nm, stale
build |
| 17:39.29 |
dloman |
installs! |
| 18:10.28 |
*** join/#brlcad indianla1ry
(~indianlar@63.246.136.16) |
| 18:10.28 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
| 18:10.28 |
*** join/#brlcad kanzure_
(~kanzure@bioinformatics.org) |
| 18:10.28 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 18:10.28 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 18:10.28 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 18:10.28 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 18:10.28 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 18:10.28 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 18:10.28 |
*** join/#brlcad poolio_
(~poolio@BZ.BZFLAG.BZ) |
| 18:10.28 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 18:10.28 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 18:10.28 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 18:10.28 |
*** join/#brlcad WhiteCalf
(MK@2607:f0d0:3001:68::2) |
| 18:10.28 |
*** join/#brlcad juan_man
(~quassel@186.136.168.73) |
| 18:10.28 |
*** join/#brlcad yukonbob_
(~bch@20-144.wireless.kamloops.net) |
| 18:10.28 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 18:10.28 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
| 18:10.28 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 18:10.31 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 18:10.31 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 18:10.31 |
*** join/#brlcad 45PABR1J4
(~CIA@208.69.182.149) |
| 18:10.31 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 18:10.31 |
*** mode/#brlcad [+o ChanServ] by
anthony.freenode.net |
| 18:24.06 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 18:24.07 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 18:24.07 |
*** mode/#brlcad [+o ChanServ] by
anthony.freenode.net |
| 18:34.53 |
CIA-77 |
BRL-CAD:
03davidloman * r43331 10/geomcore/trunk/src/GS/CMakeLists.txt:
CMake needs to copy over the template config files during its
run. |
| 18:37.56 |
CIA-77 |
BRL-CAD:
03starseeker * r43332 10/geomcore/trunk/ (11 files in 10 dirs):
More changes to geomcore CMake logic. Need to handle BRLCAD_FOUND
properly, conditionally look for things like terminal library based
on WIN32 and check for libbrlcad again but getting
closer. |
| 18:54.05 |
brlcad |
dloman:
System.getProperty("line.separator"); unless it's a JTextArea...
then it's just \n .. or %n if it's in a String.format() |
| 18:55.03 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 18:57.03 |
CIA-77 |
BRL-CAD:
03davidloman * r43333 10/geomcore/trunk/include/GeometryService.h:
Default listening addy should be 127.0.0.1 not 0.0.0.0 |
| 19:01.21 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43334 10/geomcore/trunk/ (src/GS/CMakeLists.txt
tests/utility/CMakeLists.txt): add TCL_INCLUDE_PATHS |
| 19:02.23 |
CIA-77 |
BRL-CAD:
03davidloman * r43335 10/geomcore/trunk/include/PortalManager.h:
Default listening addy should be 127.0.0.1 not 0.0.0.0
(again) |
| 19:02.32 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43336 10/geomcore/trunk/ (3 files in 2 dirs):
add GSUuid wrapper |
| 19:11.03 |
CIA-77 |
BRL-CAD:
03davidloman * r43337 10/geomcore/trunk/ (include/GeometryService.h
src/GS/GeometryService.cxx): Remove GeometryService class fields
for listenPort and listenAddy. Pass both to GeometryService's
PortalManager. |
| 19:13.42 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43338 10/geomcore/trunk/ (26 files in 7 dirs):
eliminate QUuid in favor of local GSUuid wrapper |
| 19:16.52 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43339
10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: last QUuid is
gone |
| 19:19.23 |
dloman |
``Erik:
/GSUuid.h:32:19: error: uuid.h: No such file or
directory |
| 19:22.05 |
CIA-77 |
BRL-CAD:
03brlcad * r43340 10/geomcore/trunk/src/utility/Logger.cxx: if it's
a stack trace you want, a stack trace ye shall have. uhm,
why? |
| 19:23.45 |
``Erik |
on which
OS? |
| 19:24.10 |
dloman |
Linux |
| 19:24.28 |
``Erik |
hm, the one
OS I can't test on due to horribly out of date QT stuff,
heh |
| 19:24.52 |
dloman |
it was
compling fine over here till that last ci of yours. |
| 19:24.57 |
dloman |
...if that
helps :) |
| 19:25.50 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43341 10/geomcore/trunk/include/GSUuid.h:
disable the #include for now |
| 19:27.31 |
dloman |
Im doing an
out of source build. that .h was a file I noticed earlier today
that was being generated by CMake |
| 19:28.18 |
``Erik |
there is one
made from src/other/uuid/, but I'm trying to use the system
ones |
| 19:28.31 |
dloman |
okie! |
| 19:37.12 |
CIA-77 |
BRL-CAD:
03starseeker * r43342 10/geomcore/trunk/ (3 files in 3 dirs):
Include uuid directory for all the source paths, now that it's
being (potentially) used. |
| 19:37.21 |
starseeker |
dloman: does
that work? |
| 19:41.19 |
dloman |
netMsgSerialText.cxx->NetMsg.h->GSUuid.h->uuid.h
still fails. |
| 19:45.00 |
``Erik |
O.o um, does
0 != 0 on linux? |
| 19:45.12 |
``Erik |
ah,
starseeker is mucking things up |
| 19:47.26 |
CIA-77 |
BRL-CAD:
03starseeker * r43343 10/geomcore/trunk/tests/CMakeLists.txt: Give
tests the include dirs too. |
| 19:48.09 |
dloman |
werkin! |
| 19:59.25 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43344 10/geomcore/trunk/src/GS/geoserv.cxx:
remove the random failure... |
| 20:00.19 |
dloman |
ack, you suck
``Erik |
| 20:00.26 |
dloman |
i was just
about to commit those fixes |
| 20:04.09 |
``Erik |
hrm? |
| 20:04.33 |
starseeker |
hehe |
| 20:04.34 |
``Erik |
ponders grinding indent on thos |
| 20:05.02 |
starseeker |
dloman: he
beat you to the draw huh? |
| 20:05.06 |
dloman |
yeah
:( |
| 20:09.51 |
CIA-77 |
BRL-CAD:
03davidloman * r43345 10/geomcore/trunk/src/GS/geoserv.cxx: Make
port value pulled from config file validate correctly. |
| 20:11.27 |
``Erik |
sok, I put !
instead of ~, so he'll dump my changes and put his own in *shrug*
then I'll "simplify" his later |
| 20:12.05 |
dloman |
That was a
neat trick though :) |
| 20:12.18 |
dloman |
proves that I
don't think bitwise :) |
| 20:14.52 |
CIA-77 |
BRL-CAD:
03davidloman * r43346 10/geomcore/trunk/src/utility/Config.cxx: Fix
config parser bug so that parser detects EOF correctly and
exits. |
| 20:22.59 |
*** join/#brlcad roberthl_
(~robert@v001.rhl.me.uk) |
| 20:34.55 |
CIA-77 |
BRL-CAD:
03bob1961 * r43347 10/brlcad/trunk/src/ (3 files in 3 dirs): Tweaks
to get the windows batch files working better. That is, they can
handle filenames with spaces and the windows prompt gets removed
from the screen. |
| 21:17.27 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
| 21:20.34 |
*** join/#brlcad kanzure__
(~kanzure@bioinformatics.org) |
| 21:57.51 |
CIA-77 |
BRL-CAD:
03starseeker * r43348 10/geomcore/trunk/ (9 files in 7 dirs):
Optionally enable the subversion build and subversion test, move
svntest into the geomcore tests dir. |
| 22:03.52 |
*** join/#brlcad _psilva
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
| 22:04.01 |
_psilva |
hey
brlcad |
| 22:04.22 |
_psilva |
u
there? |
| 22:31.37 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43349 10/geomcore/trunk/tests/utility/
(CMakeLists.txt threadTest.cxx): add simple threading test for
GSThread |
| 22:33.20 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43350 10/geomcore/trunk/ (include/GSThread.h
src/utility/GSThread.cxx): basic threading class
implementation |
| 22:34.05 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43351 10/geomcore/trunk/ (11 files in 4 dirs):
QThread -> GSThread |
| 22:53.22 |
*** join/#brlcad IriX64
(~IriX64@bas2-sudbury98-1177593317.dsl.bell.ca) |
| 22:55.18 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43352 10/geomcore/trunk/ (23 files in 7 dirs):
stub in GSMutex and GSMutexLocker, still need impl |
| 22:59.40 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43353 10/geomcore/trunk/ (12 files in 10 dirs):
remove references to QT libs |
| 23:03.40 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43354 10/geomcore/trunk/TODO: notes |
| 23:14.42 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43355 10/geomcore/trunk/ (include/GSThread.h
src/utility/GSThread.cxx): implement GSMutex and GSMutexLocker on
pthreads |
| 00:06.18 |
CIA-77 |
BRL-CAD:
03starseeker * r43356 10/geomcore/trunk/ (3 files in 2 dirs): Proof
of concept code to chop the toplevel objects out of a .g file,
write them to individual .g files in the svn repository, and commit
them. |
| 01:08.04 |
brlcad |
_psilva:
nope |
| 01:22.17 |
*** join/#brlcad WhiteCalf
(MK@whitecalf.net) |
| 01:36.04 |
CIA-77 |
BRL-CAD:
03brlcad * r43357 10/brlcad/trunk/TODO: list the slew of requested
and useful converters including step export, dae, x3d, g-code, u3d,
3D pdf, sat, ply, json, and xml formats |
| 02:23.25 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 02:34.22 |
brlcad |
starseeker:
nice proof of concept chop-blocking |
| 02:34.58 |
brlcad |
would be good
exercise to convert to db_walk_tree or one of the other walkers
since the next step is probably to stop at the region
level |
| 03:05.56 |
starseeker |
brlcad: ah,
from what dloman was saying it sounded like we would break out
every object in the first round |
| 03:07.09 |
starseeker |
also, if we
stop at the region level, does that mean we do a full keep of each
tree below the region level, even if it means duplicating
geometry? |
| 03:09.27 |
``Erik |
json?
really? |
| 03:09.46 |
brlcad |
about as
useful as xml ;) |
| 03:11.02 |
brlcad |
starseeker:
either way but I think it's pretty much inevitable, also makes us
parallel other cad packages (a region is a part) |
| 03:12.10 |
brlcad |
intermediate
dev would be fine, but we probably shouldn't deploy down to the
prim level since we haven't yet sorted out database
upgrades |
| 03:12.24 |
brlcad |
and our next
step given the new timeline is pretty much deployment
;) |
| 03:16.04 |
brlcad |
as for the
duplication issue, i've had a plan in place to address that for
about 7 years now -- effectively instantiating a more robust
concept of a part (one with and without the region bit
set) |
| 03:18.55 |
starseeker |
brlcad: so...
first step is full keep and eat the duplication, then follow on
later with the proper solution? |
| 03:19.10 |
brlcad |
and even
without that concept, the duplication issue can become a non-issue
by inverting the region-parent relationships (instead of
C1->R1,R2,R3->subC1, you have
C1->subC1,subC2,subC3->R1) |
| 03:19.55 |
brlcad |
basically,
but it fortunately doesn't really require changes under the hood,
just changes how geometry is managed on import |
| 03:20.35 |
starseeker |
kinda - but
we'll have to migrate broken-out-at-region setups to the final
solution |
| 03:20.51 |
starseeker |
is fine with it, just wants to be sure he's hacking the right
thing |
| 03:21.00 |
brlcad |
not
necessarily, it'll just be duplicate data |
| 03:21.16 |
brlcad |
we could
automate remerging duplication later as a backend job |
| 03:21.22 |
starseeker |
nods |
| 03:21.46 |
starseeker |
all rightie,
tree walking it is |
| 03:22.43 |
brlcad |
there would
be one benefit of going all the way down to the primitive level, if
you actually calculate the call overhead on a full vehicle with a
checkin->breakout->commit->checkout->recombine
scenario, see what the numbers look like, then redo stopping at
region level |
| 03:23.19 |
brlcad |
see if it's
actually a significant issue in practice on given arch, like
macosx, that has bad i/o performance |
| 03:23.54 |
brlcad |
if it's not,
then we could reasonably punt with confidence that it doesn't
matter and let all objects get tracked uniformly |
| 03:24.04 |
starseeker |
nods |
| 03:24.20 |
starseeker |
it would
simplify re-constructing a .g file - just dbconcat all the
pieces |
| 03:24.39 |
starseeker |
building a
bunch of regions with full trees back into the original .g is a bit
of a chore |
| 03:24.52 |
brlcad |
without the
metrics, though, I would definitely just stop at regions since
there is pretty significant data overhead at the primitive level:
104 bytes per object |
| 03:25.20 |
starseeker |
nods - at least until we can get our own custom svn backend,
anyway |
| 03:25.34 |
brlcad |
most objects
in implicit form aren't even 104 bytes ;) |
| 03:26.18 |
brlcad |
the metrics
are critical, though .. because the performance could be an
outright show-stopper for a full vehicle |
| 03:26.22 |
starseeker |
overheads
probably higher than that in the proof of concept code - I'm making
everything its own .g file |
| 03:26.32 |
brlcad |
.g overhead
is 104 bytes |
| 03:26.36 |
starseeker |
oh,
gotcha |
| 03:26.47 |
brlcad |
and most of
that is _GLOBAL, so there are other ways to optimize
too |
| 03:27.12 |
starseeker |
the other
approach is to do a more custom write - I took the quick and simple
way to write out object data, but I could customize a routine to
write JUST the object info |
| 03:27.29 |
brlcad |
though file
ops likely dominate on files that small |
| 03:28.23 |
starseeker |
('course if I
do custom IO I might as well start looking at an FS-G backend now,
and that's not the priority) |
| 03:28.38 |
starseeker |
will see if he can get the tree walker going and do the
metrics |
| 03:28.59 |
brlcad |
the other
benefit of constructing this region/non-region organization is that
we can enforce proper DAG structures more easily -- CSG recipes
would only be valid at/below region level, for example |
| 03:29.09 |
brlcad |
above,
they're just assemblies, groups |
| 03:29.25 |
brlcad |
unions |
| 03:30.16 |
brlcad |
would
effectively make it not possible to subtract assemblies from
assemblies without pushing the operations down to the region
level |
| 03:31.16 |
starseeker |
how would we
combine region files of that type back into one .g file? scan for
duplicate primitives and selectively import the ones not already
present? |
| 03:31.35 |
starseeker |
what about
changes to a multiply referenced primitive? how do we make sure we
hit all the copies? |
| 03:35.35 |
brlcad |
the region
file stored would already be the pushed result |
| 03:35.50 |
brlcad |
so the file
being combined back on read is just cat-able |
| 03:36.03 |
starseeker |
you mean we
wouldn't support unpushed geometry? |
| 03:36.12 |
starseeker |
ouch |
| 03:36.16 |
brlcad |
not
following |
| 03:36.22 |
brlcad |
no
no |
| 03:37.02 |
brlcad |
the ONE
high-level operation (subtract assemb1 (with r1, r2) from assemb2
(with r3, r4)) |
| 03:37.16 |
brlcad |
would result
in r3 and r4 getting modified |
| 03:38.02 |
starseeker |
right... I'm
thinking a little lower level. let's say r3 and r4 both include
sph1, and I change sph1 |
| 03:38.05 |
brlcad |
a "dumb"
implementation would simply import r1/r2 into r3 and r4 and
subtract them |
| 03:38.31 |
starseeker |
if r3 and r4
are both full tree copies in the repository, there are two
independent copies of sph1 |
| 03:38.37 |
starseeker |
both of which
need to be updated |
| 03:40.11 |
brlcad |
for example,
you mean two 'sph1' instances in r3 ? |
| 03:40.52 |
starseeker |
no - I'm
thinking I "break" model.g with two regions r1 and r2 into the
repository: |
| 03:41.07 |
starseeker |
model.g
(toplevel object) and two region files r1.g and r2.g |
| 03:41.28 |
starseeker |
both r1 and
r2 union in the same primitive, sph1 |
| 03:41.45 |
starseeker |
if I'm doing
a deep keep to create r1.g and r2.g, BOTH files have identical
copies of sph1 |
| 03:42.06 |
starseeker |
if I then
edit sph1 in my modeler, the implication is I'm changing both r1.g
and r2.g |
| 03:42.13 |
brlcad |
that's not
possible in the stop-at-region-level setup, the sph1 would be
duplicated across the two regions |
| 03:42.30 |
brlcad |
if it needs
to be reusable, then the definition of the region
changes |
| 03:43.08 |
starseeker |
so you're
saying that by definition a region does not contain any geometry
objects that are used in any other regions? |
| 03:43.11 |
brlcad |
and you have
model.g (toplevel), c1.g (was r1.g), c2.g (was r2.g) and a new r.g
(containing the one sph1 instance) |
| 03:43.42 |
brlcad |
yes, all
regions become fully self-contained namespaces |
| 03:44.06 |
starseeker |
shakes his head - I highly doubt that's how things work out
in practice |
| 03:44.11 |
brlcad |
you can
convert any existing model to that structure with the flip
inversion I mentioned without loss of generality |
| 03:44.27 |
starseeker |
I'm not quite
parsing the flip inversion |
| 03:45.03 |
brlcad |
I'll
draw |
| 03:47.29 |
starseeker |
oh, wait -
you're turning regions that are not self contained into assemblies,
and creating regions below them of the shared subset? |
| 03:47.44 |
brlcad |
yes |
| 03:47.57 |
starseeker |
won't that
really mess with region_id information>? |
| 03:48.23 |
starseeker |
if a geometry
was set up with r1 and r2 having different region ids and shared
geometry... |
| 03:48.47 |
brlcad |
not
necessarily |
| 03:50.30 |
brlcad |
important
note, though, that the progression is towards the minimization of
region ids -- S2 will need updating to accommodate, but M3 uses
different tracking mechanisms |
| 03:51.23 |
starseeker |
that
definition of a region strikes me as a bit limiting - let's say I
have a model of a screw, and I want to make 10 different regions
using the same geometry but different material properties (aluminum
screw, steel screw, etc...) - intentionally the same size and
geometry but different regions, and the desire to have any change
to screw dimensions propogate to all regions |
| 03:51.37 |
brlcad |
region id's
in this new system become mostly irrelevant -- it's just attribute
data |
| 03:51.47 |
starseeker |
brlcad: OK,
we're assuming S2 changes as well - that's different |
| 03:52.23 |
brlcad |
the concept
of a "part" is more that there's a point where they're no longer
assemblies and become self-contained part data |
| 03:52.59 |
brlcad |
I really
probably just need to write all this up in a document since it's a
discussion that's come up before |
| 03:53.23 |
starseeker |
what happens
to the different-materials same-geometry sceario? |
| 03:55.30 |
brlcad |
that's either
multiple parts (which is what most cad packages do and matches our
current "region" concept), or we have to implement support for
multiple-segment regions |
| 03:55.57 |
brlcad |
the latter
would be great for things like the vol primitive |
| 03:57.50 |
brlcad |
at this
point, most of the issues on regions/materials/ids/etc can be
punted so long as the routine that breaks up a .g has a means to
stop at some level in the hierarchy -- whether at prim, region, one
below region, one above, etc |
| 03:58.36 |
brlcad |
one solution
to the multiply reference region was to invert downwards instead of
upwards |
| 04:00.20 |
brlcad |
so every
region becomes a region comb containing just one member, the former
region hierarchy -- basically injects a comb node and pushes the
region bit up and the "part" becomes a non-region |
| 04:00.41 |
starseeker |
nods |
| 04:01.20 |
brlcad |
so then S2
keeps doing what they're doing -- regions are
unaffected |
| 04:01.27 |
brlcad |
region count
is unchanged |
| 04:02.18 |
brlcad |
lil harder to
ensure database integrity, so every region has one and only one
member, a part |
| 04:03.27 |
starseeker |
hmm. Well,
regardless it sounds like the first stage is to get a tree walker
going and be able to control the break points |
| 04:05.26 |
starseeker |
likes the sound of multiple-segment regions, even if he
doesn't know exactly what that would entail |
| 04:06.20 |
starseeker |
must sleep - early morning gym appointment
(ugh) |
| 04:07.58 |
brlcad |
yeah,
definitely |
| 04:39.55 |
CIA-77 |
BRL-CAD:
03brlcad * r43358 10/brlcad/trunk/TODO: consolidate the other
conversion tasks |
| 06:33.18 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.151) |
| 06:33.18 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:07.49 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 09:31.11 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.151) |
| 09:31.11 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 09:44.05 |
dloman |
starseeker:
brlcad: I'm not quite grasping at what problem we are solving by
stopping the disassembly of the .g file at the region
level.... |
| 09:44.26 |
dloman |
it seems to
me it would cause much more problems than is worth the gain in
simplicity... |
| 09:45.10 |
dloman |
Modelers
frequently use a single prim from a region (r1) to subtract from
another region (r2) for overlaps. |
| 09:46.27 |
dloman |
so, but
keeping all the prims in the region level file, the GS would have
to load two region .g's (entirely with all their geometry) just to
get at the solid in r1 for r2... seems a bit clunky and
complex |
| 09:46.57 |
dloman |
what was the
'gain' for keeping the geometry in the region level .g
file? |
| 11:50.37 |
``Erik |
hm, there's
been argument that subtracting a region itself is incorrect, the
proper way for that hack would be to make a subregion group, have
the region contain the group, and subtract the group from other
geometry O.o |
| 11:52.47 |
``Erik |
dlo: I'm not
making it in today, I'll be at upper chesapeake most of the day, I
think the last fugly wart I left is the UUID shtuff if it's a show
stopper and you want to regain functionality... my intent is to try
to use the system uuid (e2fs or ossp, depending on os) with some
cmake checks and #if e2fs #if ossp fu, if you need something
rolling today |
| 11:53.43 |
dloman |
not likely,
I'll probably be leaving early today... |
| 11:54.12 |
dloman |
the senario I
am talking about is: r1 = s1 u s2 u s3 u s4 |
| 11:54.26 |
dloman |
r2 = s5 u s6
- s1 |
| 11:55.13 |
dloman |
I don't see
why we would want to keep all the prims in the r1.g and r2.g file,
such that we have a duplicate of s1 |
| 11:55.51 |
``Erik |
hasn't read backlog and is getting ready to head to the
hospital, will catch it all later O.o |
| 11:56.00 |
dloman |
ack,
everything okay? |
| 11:56.20 |
``Erik |
it's not for
me |
| 13:19.56 |
starseeker |
dloman: if I
understand correctly, the notion is that each region would be a
fully independent piece of geometry |
| 13:20.31 |
starseeker |
by
definition, there would be no shared geometry between regions, so
subtractions to avoid overlaps would become a somewhat problematic
way to handle things |
| 13:22.02 |
starseeker |
The main
practical concern with breaking up the entire .g file into all its
objects is IO performance (lots and lots of small
files) |
| 13:23.03 |
starseeker |
brlcad also
seems to have some ideas about enforcing region policy and .g
structure |
| 13:23.31 |
starseeker |
isn't sure if that logic should live at the svn level or
above it |
| 13:24.40 |
starseeker |
as far as the
policy stuff, what I understand of it sounds OK but I'm not sure
current modeling practices like you describe are really compatible
with it |
| 13:27.02 |
starseeker |
e.g.
subtracting parts of one interfering region from another region
will result in a copy of the subcomponents needed for the
subtraction appearing in the region being subtracted from, and
those components will lose their relationship to the region being
subtracted |
| 13:28.02 |
starseeker |
so if you
have r1 and r2, and need to subtract c2 that is part of r2 from r1
to avoid an overlap, r1 would get a copy of c2 |
| 13:29.01 |
starseeker |
and changes
to the original c2 in r2 would not be automatically propogated back
to r1, unless we implement something to do that (which kinda
violates the notion of each region being its own independent
entity) |
| 13:42.21 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 13:44.04 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 14:15.23 |
_psilva |
hiyo |
| 14:31.07 |
CIA-77 |
BRL-CAD:
03brlcad * r43359 10/brlcad/trunk/src/irprep/ir-sgi.c: HAS_SGIGL ..
isn't going to be around much longer. but test for it being set
instead of being true until it's gone. |
| 14:32.23 |
CIA-77 |
BRL-CAD:
03brlcad * r43360 10/brlcad/trunk/src/irprep/ (firpass.c ir-X.c
secpass.c shapefact.c): quell verbose warnings. mark unused params,
size_t signage promotions, index shadows, and exact floating point
comparisons. |
| 14:36.56 |
CIA-77 |
BRL-CAD:
03brlcad * r43361 10/brlcad/trunk/src/lgt/ (do_options.c
execshell.c): need to include unistd.h |
| 14:47.22 |
dloman |
Hrm, well,
putting a combination between a region and its prims doesn't solve
the problem. |
| 14:48.14 |
dloman |
I can 99.99%
gurantee that dupicating geometry (in the example, s1) will be
*adding* a substantial maintenance burden on the
modelers |
| 14:48.24 |
dloman |
especially if
s1 is a somewhat sizable bot. |
| 14:50.19 |
dloman |
additionally,
although diskspace is 'cheap' and we should only solve problems
when they become a problem |
| 14:51.07 |
dloman |
wouldn't
duplicating s1 in two spots actually end up as a net negative
performance on IO, since we would technically have to read that
prim twice? |
| 14:51.32 |
dloman |
We can't
ignore overlaps, as the are GOING to happen. Of this, I am 110%
certain. |
| 14:52.15 |
starseeker |
dloman: I may
be missing some of the implications of what brlcad is describing,
so he should weigh in |
| 14:52.27 |
dloman |
add in the
increasing data sizes due to bots and the impending complex nurbs,
and I don't see 'each region as its own, idependent, entity' as
being a good idea. |
| 14:52.35 |
dloman |
sure
thing. |
| 14:53.12 |
dloman |
I am just
trying to understand how brlcad and i got our wires crossed....
cause this is not the impression i got, walking away from our last
discussion on the subject :/ |
| 14:53.27 |
dloman |
or more
specificly, what brlcad's notion is. |
| 14:53.59 |
dloman |
is remote today, so Im not in office. |
| 14:54.07 |
starseeker |
dloman: did
you read the scrollback from last night? |
| 14:54.33 |
dloman |
yuppers. |
| 14:54.37 |
starseeker |
you might be
able to follow it better than me |
| 14:54.58 |
CIA-77 |
BRL-CAD:
03brlcad * r43362 10/brlcad/trunk/src/nirt/ (command.c interact.c
nirt.c nirt.h parse_fmt.c read_mat.c): eliminate the rtip global.
propagate api changes throughout. |
| 14:55.09 |
dloman |
and keeping
the prims in the region .g's is, in my opinion, going to cause a
****-ton of issues. |
| 14:56.12 |
dloman |
keeping all
the solids in their own file, just like the c's and r's, but in a
directory named after the associated r, is what i understood our
approach was. |
| 14:57.05 |
dloman |
yes, it
creates many more files, but i honestly think its more flexible and
will be lower IO in the long run. |
| 14:58.35 |
CIA-77 |
BRL-CAD:
03brlcad * r43363 10/brlcad/trunk/src/nirt/showshot.c: convert %F
to %lf. not optimal, but gefn |
| 14:58.38 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.151) |
| 14:58.38 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 15:20.43 |
dloman |
starseeker:
do you know if its bad to change an #include <string> to
#include <string.h> ? |
| 15:21.08 |
starseeker |
uh. isn't
the first one C++ and the second one C? |
| 15:21.29 |
dloman |
thats what i
thought too. just checking. |
| 15:21.55 |
dloman |
hard to
google things with a 13 month old in one arm :) |
| 15:23.14 |
starseeker |
heh |
| 15:23.21 |
starseeker |
winces |
| 15:23.54 |
starseeker |
havoc
checkout takes 35 megs doing the write-out-every-object
scheme |
| 15:24.31 |
CIA-77 |
BRL-CAD:
03brlcad * r43364 10/brlcad/trunk/src/proc-db/ (brickwall.c
masonry.c): quell warnings, exact floating point
comparisons |
| 15:24.37 |
starseeker |
guess the
every-object-is-a-g-database thing isn't so hot |
| 15:24.53 |
starseeker |
commits anyway... |
| 15:25.10 |
starseeker |
oh, took
several minutes to commit and checkout, too |
| 15:25.18 |
dloman |
why is that
bad? whats the original filesize? |
| 15:25.37 |
CIA-77 |
BRL-CAD:
03brlcad * r43365 10/brlcad/trunk/src/proc-db/kurt.c: !EQUAL
instead of != for floating point comparison |
| 15:25.37 |
starseeker |
580K |
| 15:26.25 |
dloman |
looks like
the per file overhead is a bit more than 104 bytes eh? |
| 15:26.36 |
dloman |
or are there
a bajillion files? |
| 15:26.55 |
starseeker |
yeah, there's
a lot of files |
| 15:26.55 |
CIA-77 |
BRL-CAD:
03brlcad * r43366 10/brlcad/trunk/src/proc-db/ (16 files): quell
verbose compilation warnings mostly related to unused params and
vars, shadowings, and checking usage. |
| 15:27.16 |
starseeker |
plus the .svn
checkout keeps a baseline copy of each file and a properties file
for each file |
| 15:27.28 |
starseeker |
.svn is 23
Megs, rest is checkout |
| 15:28.43 |
dloman |
idealisticly,
we could boil the whole repo down to one or two baseline versions
of each prim, and just use a ton of matricies :) |
| 15:28.45 |
CIA-77 |
BRL-CAD:
03starseeker * r43367 10/geomcore/trunk/tests/svntest/main.c: Try
writing out every object, and directory organization. Use havoc for
more of a stress test - performance doesn't look
promising |
| 15:29.10 |
starseeker |
somewhat
amusingly, the actual repository (as opposed to the checkouts) is
1.7 megs |
| 15:31.06 |
dloman |
thought: if
we are using dbobject names to link to other files, why can't a
region contain all its own prims, but still be able to link to
other region .g's for prims too ? whats wrong with
that? |
| 15:31.34 |
starseeker |
uh... |
| 15:31.50 |
starseeker |
that gets
back to the whole "redefine what a region means"
problem |
| 15:34.52 |
dloman |
Well, what
ever the solution is, having two copies of the same solid, one to
construct r1, one to be a overlap subtraction for r2, is going to
make a bunch of people really upset. |
| 15:35.09 |
starseeker |
hmm... so if
the count is right, there were just shy of 3000 objects, which
means counting the base files and props files just shy of 9000
files for havoc, not counting any other svn files in the
checkout |
| 15:36.34 |
dloman |
as in 9000 in
the repo and 3000 end user visible? |
| 15:36.41 |
starseeker |
yep |
| 15:37.16 |
dloman |
well, thats
better than I thought :) brlcad and I were thinking an average of
10k per model. |
| 15:37.25 |
dloman |
granted, its
just havoc |
| 15:37.31 |
starseeker |
nods |
| 15:37.37 |
starseeker |
simple
model |
| 15:37.47 |
dloman |
but converted
geometry is like to have less objects, but larger size
per |
| 15:38.18 |
dloman |
i think the
last conversion i worked with had about 1500 db objects, but the .g
file size was 280 mges |
| 15:38.24 |
starseeker |
I suppose
committing and checking out an entire model in one gulp could also
be regarded as worst case |
| 15:38.24 |
dloman |
megs |
| 15:38.41 |
dloman |
yeah, untill
the multi-system projects start hooking in :) |
| 15:39.15 |
starseeker |
"checking
out" in this case is also creating the repository on
disk |
| 15:39.29 |
brlcad |
that overhead
is pretty much what I expected |
| 15:39.48 |
brlcad |
so the
checkout is 1.7, repo is 23 .. original was? |
| 15:39.49 |
starseeker |
it might be
worth investigating if there are ways to talk to the repo without
an explicit checkout to disk |
| 15:40.11 |
starseeker |
no, checkout
is 35, repo is 1.7, original was 580K |
| 15:40.21 |
starseeker |
35 Meg, 1.7
Meg |
| 15:40.39 |
brlcad |
checkout
includes .svn dir data |
| 15:40.42 |
brlcad |
what's the
export size? |
| 15:40.45 |
starseeker |
running the
test as currently committed on the Mac takes 4.5
minutes |
| 15:41.02 |
starseeker |
about 12
Megs, I think... |
| 15:41.10 |
brlcad |
figure the
mac should be worst case performance, so it's a good
baseline |
| 15:42.07 |
brlcad |
the reason
for stopping at the region level was to fight some of that
performance, I expect it to knock that at least in half if not
more |
| 15:42.47 |
dloman |
so with
stopping at the r level, how does one handle using s1 from r1 as a
subtraction in r2? |
| 15:43.04 |
brlcad |
putting the
repo more on par with the .g size (maybe 25% expansion, minor), and
checkout around an order larger |
| 15:43.40 |
brlcad |
in the short
term or long term? :) |
| 15:43.59 |
brlcad |
and under the
hood, or exposed-to-user? |
| 15:44.05 |
dloman |
exposed to
user |
| 15:45.10 |
brlcad |
going to take
a sec to write |
| 15:51.27 |
dloman |
gets his grub on while he waits. Grilled Cheeze == nom nom
nom |
| 15:52.57 |
brlcad |
so "s1" is
some member of this 'part' object "r1", which I'm going to
intentionally avoid calling a region for reasons that will
hopefully become evident. so this piece of solid part r1 is being
used as a subtraction shape on solid part r2. previously both in
their same namespace, but no longer with this new 'part' concept --
each part is a unique namespace. so the subtraction of r1/s1 from
r2 becomes a cross-namespace reference for the overlapping portions
( |
| 15:53.41 |
CIA-77 |
BRL-CAD:
03r_weiss * r43368 10/brlcad/trunk/src/libbn/bntester.c: Added to
'bntester' support for testing function
'bn_isect_lseg3_lseg3'. |
| 15:54.01 |
brlcad |
cross-reference namespace then become a
conscious decision of modelers to import data (breaking the need
for a cross-namespace reference), or refactor into a new base part
that both r1 and r2 reference |
| 15:54.36 |
brlcad |
basically
what they do now, just with an implicit single
namespace |
| 15:55.02 |
brlcad |
I'll have to
revisit our notes from that half-day discussion we had -- because
we had it pretty lock solid then |
| 15:55.43 |
brlcad |
I might have
a minor detail off, but shouldn't be far off .. but then it was a
couple months ago :) |
| 15:56.14 |
dloman |
okay, will
the end user have to maintain two 's1's or just one? |
| 15:56.15 |
brlcad |
the whole
problem revolved around solving mergability of .g files |
| 15:56.31 |
brlcad |
they get to
decide -- default would be just one s1 |
| 15:57.07 |
brlcad |
an s1 from
the r1 namespace, r1::s1 |
| 15:57.27 |
brlcad |
if imported
as r1::s1 and r2::s1, then they have to make a decision whether
those are mergable or not |
| 15:57.52 |
dloman |
so a modeler
uses s1 from part1, or part1::s1, in part2 as a subtraction, or
part2 = part2::s1 - part1::s1 |
| 15:57.53 |
brlcad |
but then we
can provide tools to assist with that decision process --
auto-merge identical geometry, for instance |
| 15:58.10 |
brlcad |
right |
| 15:58.16 |
dloman |
and the
modeler doesn't want to make a new part.... how do we store that on
our end? |
| 15:58.41 |
starseeker |
if I'm going
to sort assemblies out from combinations, I'll probably have to get
search set up to return a list of directory pointers - the ged
results string won't cut it |
| 15:58.42 |
brlcad |
then it's a
configuration option as to what they might want to auto-do with
that type of operation -- auto-import/copy, keep the reference,
etc |
| 15:59.13 |
brlcad |
it literally
just becomes a named reference, part1::s1 in part2 |
| 16:00.27 |
brlcad |
part2 was
just "u s1" with s1 being an implicit part2::s1 -- with the
subtraction and absent any automerging, it becomes: "u s1 -
part1::s1" as string data in the .g file |
| 16:00.53 |
brlcad |
the part
that's escaping me at the moment (no pun intended) is how we solved
the "where's my namespace" problem |
| 16:01.02 |
dloman |
so we wont be
storing two copies of part1::s1 ? |
| 16:01.11 |
brlcad |
nope |
| 16:01.27 |
dloman |
okay
then. |
| 16:01.53 |
dloman |
so by this
logic, the overall svn dir structure wont ever exceed two dirs
deep? (but be very wide) ? |
| 16:01.53 |
brlcad |
only if they
request exactly that as an operation -- "cut my external refs" ..
"import external refs", etc |
| 16:02.09 |
brlcad |
that's the
part that I'm not remembering without our notes |
| 16:02.20 |
brlcad |
we'd solved
that issue |
| 16:02.35 |
brlcad |
I think it
was with top-level namespacing |
| 16:02.53 |
brlcad |
so not a
part1 namespace, but some higher tank1 namespace and tank2
namespace |
| 16:03.16 |
dloman |
right, per my
understanding and notes and diagrams, we left our last talk
thinking the repo will be three layers deep:
projects->combs/regs->prims |
| 16:03.31 |
dloman |
now i'm
hearing different, hence my confusion :) |
| 16:03.57 |
brlcad |
s/projects/namespaces/ and I can see that
:) |
| 16:04.26 |
brlcad |
yeah, I
wasn't being entirely precise last night as the focus was more just
that there needs to be "some" mechanism to halt traversal part-way
down the DAG |
| 16:04.45 |
brlcad |
because of
the horrid performance impact I was anticipating |
| 16:04.50 |
dloman |
namespaces->regions/combs .... thats
it, since all the prims will be stored in the files in the
regions/combs level |
| 16:05.54 |
dloman |
..if I am
understanding correctly. |
| 16:05.55 |
brlcad |
yeah, the
details are starting to come back to me now :) |
| 16:06.12 |
starseeker |
I can
probably get a rough idea of how expensive writing out regions will
be, but it won't be meaningful until I can sort out the assemblies
and that's not so straightforward |
| 16:06.59 |
*** join/#brlcad roberthl
(~robert@v001.rhl.me.uk) |
| 16:06.59 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 16:07.18 |
starseeker |
almost feels
like the search logic needs to move from ged to somewhere
else |
| 16:07.23 |
starseeker |
and have ged
wrap it |
| 16:07.27 |
starseeker |
but not sure
where to move it |
| 16:07.30 |
brlcad |
yep,
librt |
| 16:07.38 |
starseeker |
heh, that
works |
| 16:07.43 |
brlcad |
mged ->
libged -> librt is the progression of logic |
| 16:07.52 |
brlcad |
there's a lot
in libged that belongs in librt |
| 16:08.14 |
starseeker |
ok, I'm gonna
have to move that as a first step - I need the search filters to do
an intelligent breakout |
| 16:08.19 |
brlcad |
libged in a
final state would actually end up with very little, just state
container wrappers and string parsing really |
| 16:09.37 |
brlcad |
daniel's
comment was a good one, libged isn't really optimal underneath the
GE -- it's at the same level, so most of the geometry manipulation
it performs is logic that should be in librt (and is, in a
way) |
| 16:10.19 |
brlcad |
it becomes
more of a transaction management interface that bridges and
simplifies all that's possible with librt |
| 16:13.07 |
brlcad |
dloman: will
have to revisit the notepad next time I'm in the office (maybe
friday) to make sure we're fresh on the solution we came up with,
it was pretty tight and there are a few particulars I'm not
remembering at the moment |
| 16:13.18 |
dloman |
so GE *isn't*
a C++ wrapper for libged? |
| 16:13.29 |
dloman |
I likely
won't be back in the office till next Wednesday |
| 16:13.57 |
brlcad |
it could be
as an interim solution, but really shouldn't be |
| 16:14.56 |
brlcad |
libged is
really a transactional command parsing library .. that string
parsing foo is major suck for any sort of performance geometry
processing |
| 16:15.02 |
brlcad |
GE is more
akin to ACIS |
| 16:15.05 |
dloman |
so if the GE
is side by side with ged, then any/all common functionality needs
to be pushed down into librt (and possibly elsewhere too) otherwise
we're duplicating code? (Did i capture the concept
correctly?) |
| 16:15.19 |
brlcad |
you got
it |
| 16:15.55 |
brlcad |
alternatively, pushed into GE and libged
sits on top of GE .. but librt makes more sense at the
moment |
| 16:16.29 |
dloman |
isn't libged
primarily c? |
| 16:16.38 |
brlcad |
basically
"libged > GE > librt" or "libged,GE > librt" (current
plan) |
| 16:16.53 |
brlcad |
right, that's
why it makes more sense to stay that way |
| 16:17.24 |
brlcad |
it could
easily be an encapsulated wrapper, where the GE c++ness would be
mere implementation detail like opennurbs in librt |
| 16:17.42 |
dloman |
in order to
keep the code from getting wicked stupid, then GE would also need
to be c, not C++ ...? |
| 16:17.52 |
brlcad |
not at
all |
| 16:18.25 |
brlcad |
because
libged's api is presently a single data container and argc/argv
string data |
| 16:18.41 |
brlcad |
what goes on
under the hood stays under the hood |
| 16:18.50 |
brlcad |
(bom chika
wah wah) |
| 16:21.59 |
CIA-77 |
BRL-CAD:
03brlcad * r43369 10/brlcad/trunk/src/remrt/ihost.c: if DEFINED,
not if NOT defined |
| 16:22.04 |
brlcad |
oof, that
took a while to see... |
| 16:30.11 |
dloman |
alright, Im
going afk for a few days. I expect the GS to be finished when I
return. Hop to it! :P |
| 16:31.26 |
dloman-afk |
(I only say
that cause its now very apparent to me that I have (and had) no
idea what I'm doing, heh ) |
| 16:41.24 |
brlcad |
we need to
get rolling on gsoc preparations if you all are interested in
mentoring again -- the ideas page needs major updating |
| 16:51.45 |
CIA-77 |
BRL-CAD:
03brlcad * r43370 10/brlcad/trunk/src/remrt/ihost.h: include the
headers this header requires, self containment |
| 16:52.26 |
starseeker |
sounds like
fun |
| 16:52.33 |
CIA-77 |
BRL-CAD:
03brlcad * r43371 10/brlcad/trunk/src/remrt/ (remrt.c rtsrv.c):
mark unused params, check argc params, terminal sentinel with NULL
instead of 0, and other quellage |
| 17:21.15 |
_psilva |
hey
brlcad |
| 17:21.20 |
_psilva |
got some news
for you |
| 17:24.42 |
brlcad |
sup? |
| 17:25.16 |
brlcad |
you spawned a
child process? :) |
| 18:25.45 |
_psilva |
then it's two
thing |
| 18:25.48 |
_psilva |
hah |
| 18:25.54 |
_psilva |
due march 16
ish |
| 18:26.08 |
_psilva |
but even
bigger and more relevant |
| 18:26.20 |
_psilva |
we got bought
by autocad |
| 18:26.23 |
_psilva |
er |
| 18:26.25 |
_psilva |
autodesk |
| 18:26.55 |
_psilva |
http://usa.autodesk.com/adsk/servlet/index?id=16284057&siteID=123112 |
| 18:27.11 |
_psilva |
is now autodesk employee |
| 19:31.35 |
starseeker |
_psilva: do
we offer condolances? |
| 20:05.30 |
brlcad |
_psilva: heh,
well congrats on the 16th and condolences on the 30th
(april) |
| 20:09.46 |
_psilva |
heh |
| 20:10.23 |
_psilva |
at least
we're not being relocated |
| 20:10.30 |
_psilva |
:) |
| 20:15.10 |
_psilva |
we'll
see |
| 20:15.19 |
_psilva |
gonna stick
around until something more interesting pops up |
| 20:31.35 |
CIA-77 |
BRL-CAD:
03jordisayol * r43372 10/brlcad/trunk/ (misc/debian/control
sh/make_deb.sh): modify dependencies to build deb
packages |
| 21:01.58 |
CIA-77 |
BRL-CAD:
03starseeker * r43373 10/brlcad/trunk/ (7 files in 3 dirs): Make a
stab at moving search logic to librt |
| 21:22.17 |
CIA-77 |
BRL-CAD:
03starseeker * r43374 10/brlcad/branches/cmake/ (56 files in 18
dirs): MFC r43373 |
| 21:33.37 |
CIA-77 |
BRL-CAD:
03starseeker * r43375 10/brlcad/trunk/src/librt/search.c: Fix order
of inputs, UNUSED some inputs |
| 21:37.27 |
CIA-77 |
BRL-CAD:
03starseeker * r43376 10/brlcad/branches/cmake/src/librt/search.c:
MFC r43375 |
| 21:38.15 |
CIA-77 |
BRL-CAD:
03brlcad * r43377 10/brlcad/trunk/src/librt/bool.c: |
| 21:38.15 |
CIA-77 |
BRL-CAD: call
NEAR_EQUAL() with a 0.001 tolerance instead of rt_fdiff() since
that |
| 21:38.15 |
CIA-77 |
BRL-CAD:
function is deprecated. this potentially affects fastgen platemode
overlap |
| 21:38.15 |
CIA-77 |
BRL-CAD:
reporting since it's no longer performing a relative tolerance
comparison, but |
| 21:38.16 |
CIA-77 |
BRL-CAD: the
impact shouldn't be too significant since the absolute tolerance is
rather |
| 21:38.16 |
CIA-77 |
BRL-CAD:
loose at 0.001 |
| 21:40.26 |
CIA-77 |
BRL-CAD:
03starseeker * r43378 10/brlcad/branches/cmake/src/
(libged/CMakeLists.txt librt/CMakeLists.txt): Fix CMake logic for
search file changes |
| 21:41.25 |
CIA-77 |
BRL-CAD:
03brlcad * r43379 10/brlcad/trunk/src/librt/db_flip.c: |
| 21:41.25 |
CIA-77 |
BRL-CAD: use
a bridge pattern to separate the deprecated function logic into new
private |
| 21:41.25 |
CIA-77 |
BRL-CAD:
functions. this lets us continue to be able to flip v4 files, even
after the |
| 21:41.25 |
CIA-77 |
BRL-CAD:
deprecated rt_* functions become obsolete, yet allows for the API
to continue |
| 21:41.25 |
CIA-77 |
BRL-CAD:
working for now. |
| 21:41.35 |
CIA-77 |
BRL-CAD:
03brlcad * r43380 10/brlcad/trunk/src/librt/librt_private.h:
declare the new flip functions |
| 21:42.24 |
CIA-77 |
BRL-CAD:
03brlcad * r43381 10/brlcad/trunk/src/librt/binunif/db5_bin.c: call
ntohl() and htonl() instead of the deprecated libbu
functions. |
| 21:42.53 |
CIA-77 |
BRL-CAD:
03brlcad * r43382 10/brlcad/trunk/src/librt/comb/db_comb.c: call
the new private flip funcs instead of the deprecated
api. |
| 22:33.32 |
brlcad |
starseeker:
librt api should not have argc/argv parameters |
| 22:34.29 |
starseeker |
brlcad: all
right, I'll have to revert then - reworking the code to not use
them could be a significant effort |
| 22:34.39 |
brlcad |
yeah, moving
search to librt is not going to be a simple move |
| 22:34.45 |
brlcad |
it needs to
work on data |
| 22:35.22 |
starseeker |
well, that's
a days work down the drain |
| 22:35.29 |
brlcad |
data in, data
out -- no printing to console (except diagnostic) |
| 22:36.03 |
starseeker |
uh... it's
not printing to console |
| 22:36.10 |
brlcad |
so you'd get
back, for example, an array of rt_db_internal pointer's from a
given query -- the search front-end would iterate over a result and
print their names |
| 22:37.09 |
starseeker |
that's edging
dangerously close to a complete rework |
| 22:37.28 |
brlcad |
I was
surprised that you were heading down that road :) |
| 22:37.42 |
starseeker |
well, is
there another way to spot assemblies? |
| 22:37.45 |
brlcad |
it's doable,
not necessarily a rewrite |
| 22:38.10 |
brlcad |
the hardest
part of search is building up that query filtering logic, stopping
criteria -- that all stays the same |
| 22:38.31 |
starseeker |
if I'm going
to do the one .g per region, I have to be able to identify the
assembly combinations - they will need to be written out as their
own objects, since the region .g files won't handle
them |
| 22:40.05 |
brlcad |
search still
sounds like a good approach for that |
| 22:40.27 |
brlcad |
you just have
to split things up some |
| 22:40.47 |
CIA-77 |
BRL-CAD:
03starseeker * r43383
10/brlcad/trunk/src/librt/search.c: |
| 22:40.47 |
CIA-77 |
BRL-CAD: Add
logic to append directory pointer entries to a list - will allow
for |
| 22:40.47 |
CIA-77 |
BRL-CAD:
manipulation of objects found in C code without having to re-parse
string. For |
| 22:40.47 |
CIA-77 |
BRL-CAD: now,
only return pointer to leaf node of path - could conceivably be
expanded if |
| 22:40.47 |
CIA-77 |
BRL-CAD:
there is a need. |
| 22:40.50 |
brlcad |
somewhere in
search, I'm sure it's taking the input argc/argv and turning that
into an in-memory expression of some sort |
| 22:41.08 |
starseeker |
brlcad: it
is. I'm quite sure it can be done, but it's... tangled |
| 22:41.27 |
brlcad |
that logic
stays in libged's search front-end, librt takes that in-memory
expression as a parameter to rt_search() |
| 22:41.45 |
brlcad |
layers, like
an onion ;) |
| 22:41.56 |
starseeker |
brlcad: what
should I do - full revert, put everything back in
libged? |
| 22:42.23 |
starseeker |
I'm pretty
sure I won't have time until next month to do that kind of sorting
out of the search logic |
| 22:46.26 |
brlcad |
might as
well |
| 22:46.39 |
starseeker |
k |
| 22:46.59 |
CIA-77 |
BRL-CAD:
03starseeker * r43384 10/brlcad/branches/cmake/src/librt/ (6 files
in 3 dirs): MFC r43383 |
| 22:48.17 |
brlcad |
at a glance,
looks like it's pretty close already -- find_formplan() would
become something like rt_search_plan(), find_execute() would
probably become something like rt_search(). that'd be your two new
api hooks |
| 22:48.59 |
brlcad |
ged_search()
looks rather peculiar to me.. how does it know how many expression
arguments there are?? |
| 22:50.00 |
starseeker |
what, the
altered one or the original? |
| 22:50.47 |
starseeker |
OK,
everything should be back in place |
| 22:51.03 |
brlcad |
I don't know
-- I'm just looking at my current checkout with is
r42551 |
| 22:51.22 |
starseeker |
oh, yeah
that's the original |
| 22:51.42 |
brlcad |
Oh.. is the
entire expression in argv[1]?? |
| 22:51.45 |
brlcad |
heh |
| 22:51.47 |
starseeker |
yeah |
| 22:51.49 |
brlcad |
wow |
| 22:51.55 |
starseeker |
it's up to
the search functions to make sense of it |
| 22:52.21 |
brlcad |
so yeah.. a
few changes |
| 22:53.59 |
brlcad |
ged_search()
should take variable argc/argv, one per actual argument .. that
would get parsed into an "rt_search_plan" struct of some sort
(basically a custom "PLAN *"), that'd get passed to
rt_search() |
| 22:54.29 |
CIA-77 |
BRL-CAD:
03starseeker * r43385
10/geomcore/trunk/tests/svntest/main.c: |
| 22:54.30 |
CIA-77 |
BRL-CAD: Add
some commented out code based on the test code used in ged_search
to test |
| 22:54.30 |
CIA-77 |
BRL-CAD:
directory pointer list printing. Will need to construct argc/argv
input for |
| 22:54.30 |
CIA-77 |
BRL-CAD:
rt_search, but this should in principle allow the identification in
C code of |
| 22:54.30 |
CIA-77 |
BRL-CAD:
assemblies. |
| 22:54.55 |
brlcad |
librt could
provide rt_search_plan() as a helper function to turn the string
data into an rt_search_plan, but you'd be able to bypass that and
do it all string-less with rt_search() then if you
wanted |
| 22:54.57 |
starseeker |
brlcad: we
need to be careful there - the find command has its own option
handling logic, I don't know how similar it is to our normal
stuff |
| 22:56.16 |
brlcad |
not too
careful -- at worse, ged_search() and/or rt_search_plan() would
just join all of the argv parameters together into one bit string
and pass to find's plan making code |
| 22:56.45 |
starseeker |
uh... if
we're doing that, why bother splitting them up in the first
place? |
| 22:57.02 |
brlcad |
ahh, I see --
it's not one big string |
| 22:57.12 |
brlcad |
it's
iterating afterall |
| 22:57.20 |
brlcad |
but requires
a NULL-terminated argv |
| 22:57.46 |
brlcad |
you're not
splitting them up, they start out split up |
| 22:58.18 |
starseeker |
sort of -
formplan gets argv[2] |
| 22:59.10 |
brlcad |
but as a char
**, it then iterates over the argv elements
individually |
| 22:59.18 |
starseeker |
right |
| 22:59.35 |
brlcad |
so it's not
all in argv[1]/argv[2] |
| 22:59.43 |
brlcad |
it's already
a proper argv list |
| 22:59.57 |
starseeker |
brlcad: as
long as we're at this... is there a function somewhere to do for
bu_lists or some other bu data structure what uniq does on the unix
command line? |
| 23:00.53 |
starseeker |
you hand
mentioned wanting to fix some search behavior that was unexpected,
and iirc it required always doing a full path iteration, so to
simulate searching through ls results we would need to do some kind
of uniq filtering |
| 23:00.57 |
CIA-77 |
BRL-CAD:
03starseeker * r43386 10/brlcad/trunk/ (7 files in 3 dirs): Sigh.
Put search back in libged for now - need to split out the argument
parsing logic into libged and the backend logic into librt
first. |
| 23:01.03 |
brlcad |
bu_ptbl's
have unique awareness for pointer tracking |
| 23:01.30 |
brlcad |
bu_ptbl_ins_unique() |
| 23:01.34 |
starseeker |
hmm... can I
stash directory pointers in a bu_ptbl? |
| 23:01.45 |
brlcad |
ptbl ==
pointer table |
| 23:01.48 |
brlcad |
arbitrary
pointer container |
| 23:02.19 |
starseeker |
ok, that
might do then |
| 23:02.23 |
brlcad |
redblack
trees have similar uniqueness insertion routines |
| 23:02.39 |
brlcad |
depends what
sort of O behavior you need |
| 23:03.21 |
brlcad |
so search is
already pretty close to what you'd need for librt from what I'm
seeing here |
| 23:03.58 |
brlcad |
the biggest
change is just fixing the routine names, creating corresponding rt_
prefix names for the api |
| 23:04.26 |
starseeker |
and making
sure everything functions in libged/librt respectively |
| 23:04.29 |
brlcad |
the code
already has that separation I referred to |
| 23:05.07 |
starseeker |
ah, good
:-) |
| 23:05.19 |
brlcad |
think of it
as only migrating find_formplan() and find_execute() to librt, but
not with those names |
| 23:05.48 |
brlcad |
ged_search()
stays in libged exactly as it is, just pointing to the new names
instead of find_formplan() and find_execute() |
| 23:06.02 |
starseeker |
well, I've
got tomorrow so I'll do what I can |
| 23:06.14 |
brlcad |
instead of
find_formplan() returning a PLAN*, it should be some rt_plan_t or
somesuch |
| 23:06.57 |
starseeker |
hmm -
db_plan_t maybe? |
| 23:07.01 |
brlcad |
find_formplan() would get renamed to
something like rt_search_plan(); find_execute() would get renamed
to something like rt_search() |
| 23:07.13 |
starseeker |
doesn't
really have much to do with raytracing - db_ prefix may make more
sense |
| 23:07.17 |
brlcad |
it could be
db_ api instead of rt_ api |
| 23:07.18 |
brlcad |
sure |
| 23:07.31 |
brlcad |
unless it's
going to return rt_db_internal objects |
| 23:07.34 |
brlcad |
then it's rt_
api |
| 23:07.47 |
brlcad |
I
think |
| 23:07.51 |
brlcad |
have to check
on that one |
| 23:08.11 |
brlcad |
ah, yes,
find_execute() would have to be refactored to not have a gedp
parameter |
| 23:08.23 |
brlcad |
same with
findplan |
| 23:08.49 |
starseeker |
will probably
return a list of db_full_path structs and a bu_ptbl of directory
pointers |
| 23:09.07 |
starseeker |
yeah, ged
structs are everywhere in there |
| 23:09.20 |
starseeker |
I got those
out once, so I'm not too worried about that - just takes
time |
| 23:10.30 |
starseeker |
or if
directory pointers make it rt_ specific, could just return
db_full_path list and let the calling function sort it
out |
| 23:11.18 |
starseeker |
that's
probably cleaner |
| 01:30.01 |
*** join/#brlcad Elrohir
(~kvirc@p5B14BB8B.dip.t-dialin.net) |
| 01:47.35 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 02:50.55 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 04:51.06 |
CIA-77 |
BRL-CAD:
03brlcad * r43478 10/brlcad/trunk/src/libfb/if_remote.c: convert
libfb's remote framebuffer from using libbu's xdr routines to using
the posix.1 byteorder functions, using hton*/ntoh* |
| 05:10.56 |
CIA-77 |
BRL-CAD:
03brlcad * r43479 10/brlcad/trunk/src/conv/ (asc/asc2g.c
asc/g2asc.c poly-bot.c stl/g-stl.c stl/stl-g.c): convert converters
using the libbu xdr routines to using the posix.1 byteorder
functions, using hton*/ntoh* |
| 05:20.42 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:21.00 |
CIA-77 |
BRL-CAD:
03brlcad * r43480 10/brlcad/trunk/src/rt/viewray.c: call
NEAR_EQUAL() instead of rt_fdiff() |
| 05:21.35 |
*** join/#brlcad Stattrav_
(~Stattrav@122.172.159.245) |
| 05:24.06 |
CIA-77 |
BRL-CAD:
03brlcad * r43481 10/brlcad/trunk/src/librtserver/rtserver.c: more
xdr to posix.1 byteorder function conversions, bu_plong to
htonl |
| 05:32.04 |
CIA-77 |
BRL-CAD:
03brlcad * r43482 10/brlcad/trunk/src/ (gtools/g_transfer.c
remrt/rtsrv.c): since ext_buf buffers are now uint8_t*'s we need to
cast them to char*'s for libpkg (until libpkg is
upgraded). |
| 05:49.32 |
CIA-77 |
BRL-CAD:
03brlcad * r43483 10/brlcad/trunk/src/libged/bot_dump.c: convert
from xdr bu_plong() to byteorder htonl() |
| 05:51.29 |
CIA-77 |
BRL-CAD:
03brlcad * r43484 10/brlcad/trunk/include/raytrace.h: |
| 05:51.29 |
CIA-77 |
BRL-CAD: now
that all usages should be weeded out, formally deprecate rt_fdiff()
and |
| 05:51.29 |
CIA-77 |
BRL-CAD:
rt_reldiff() in the header. not 100% equivalent, so use with
caution, but |
| 05:51.29 |
CIA-77 |
BRL-CAD:
recommend most conversions change to NEAR_EQUAL(a,b,0.001) and
EQUAL(a,b) |
| 05:51.29 |
CIA-77 |
BRL-CAD:
respectively. |
| 05:55.23 |
CIA-77 |
BRL-CAD:
03brlcad * r43485 10/brlcad/trunk/ (include/bu.h
src/librt/db5_io.c): |
| 05:55.24 |
CIA-77 |
BRL-CAD:
formally deprecate the old eXternal Data Representation (XDR)
functions via API |
| 05:55.24 |
CIA-77 |
BRL-CAD:
markers. all of the bu_p(long|short|etc) and bu_g(long|short|etc)
functions |
| 05:55.24 |
CIA-77 |
BRL-CAD: have
comparable byteorder functions provided standard via posix.1 as
hton(l|s) |
| 05:55.24 |
CIA-77 |
BRL-CAD: and
ntoh(l|s). the one exception is support for converting 64-bit long
long |
| 05:55.24 |
CIA-77 |
BRL-CAD:
types, so use the recently added configure.ac tests and define
htonll() and |
| 05:55.25 |
CIA-77 |
BRL-CAD:
ntohll() respectively as macros supporting big and little endian
platforms. |
| 06:04.19 |
CIA-77 |
BRL-CAD:
03brlcad * r43486
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: convert
from xdr to standard byteorder functions casting
accordingly. |
| 06:05.26 |
CIA-77 |
BRL-CAD:
03brlcad * r43487 10/brlcad/trunk/doc/deprecation.txt: minimally
impacting change, renaming V2APPROXEQUAL() to V2NEAR_EQUAL() in
order to match the other *NEAR_EQUAL() macros. |
| 06:10.49 |
CIA-77 |
BRL-CAD:
03brlcad * r43488 10/brlcad/trunk/ (include/vmath.h
src/proc-db/surfaceintersect.cpp): minimally impacting API change,
rename V2APPROXEQUAL to V2NEAR_EQUAL so the api is more
self-consistent. |
| 10:12.29 |
starseeker |
brlcad:
you're referring to the C JSON library jansson? |
| 10:16.18 |
dloman-a1k |
Mernin
all |
| 10:16.49 |
starseeker |
dloman-a1k:
morning! |
| 10:20.16 |
dloman |
ugh, lots to
read, heh |
| 10:20.33 |
starseeker |
hehe |
| 10:20.47 |
dloman |
so, in my
interwebz wandering, i found a QT wrapper for the svn libs
:) |
| 10:20.56 |
dloman |
bookmarked
it, didnt have time to look at it. |
| 10:21.18 |
dloman |
just thought
it was funny since erik is mostly done with the ripout |
| 10:22.55 |
dloman |
starseeker:
what version of cmake are you using? |
| 10:23.04 |
starseeker |
2.8.3 |
| 10:23.11 |
dloman |
just got a 'new' used laptop and am re-installing
*everything* |
| 10:23.18 |
starseeker |
I think 2.8.4
is out |
| 10:23.43 |
dloman |
kk, so 2.8.2
won't cause the world to end then. |
| 10:24.03 |
starseeker |
*probably*
not, but there do tend to be legitimate bug fixes/improvements in
each release |
| 10:24.10 |
starseeker |
particularly
with respect to VS2010 |
| 10:24.12 |
dloman |
right
on |
| 10:24.33 |
starseeker |
If 2.8.2 is
the easy install, go for it |
| 10:24.41 |
dloman |
exactly
:) |
| 10:24.48 |
dloman |
one click ==
my kinda install |
| 10:24.54 |
starseeker |
the only
thing I know that has issues with 2.8.2 is the Windows visual
studio stuff |
| 10:25.16 |
starseeker |
there may be
others though - I'd have to check |
| 10:25.54 |
dloman |
that fine by
me. I dont have any plans on doing anything with
VS2xxx |
| 10:26.01 |
dloman |
in the
immediate future that is.. |
| 10:26.09 |
dloman |
eventually,
I'll have to deal with it |
| 10:26.10 |
starseeker |
If possible,
I tend to prefer fixing CMake as opposed to ugly workarounds in our
logic, and we do do some fairly funky stuff in a few cases, so let
me know if you see any issues |
| 10:26.22 |
dloman |
kk |
| 10:26.33 |
starseeker |
CMake is
pretty easy to install if it comes to that |
| 10:26.35 |
dloman |
verizon dsl
sucks, so the checkout will take time :/ |
| 10:26.41 |
starseeker |
nods |
| 10:27.17 |
starseeker |
dloman: of
course, if you're just doing geomcore and not all of BRL-CAD that
should be simpler |
| 10:27.42 |
dloman |
I am soooooo
going with xfinity or fios when they hit my area... |
| 10:27.53 |
starseeker |
mmmm,
fiber |
| 10:27.53 |
dloman |
I think I
will get and try cmake on both of those. |
| 10:28.18 |
dloman |
I have
resigned myself to the fact that a bulk of today will be spent
downloading/config-ing/t-shooting |
| 10:28.24 |
starseeker |
heh |
| 10:28.35 |
starseeker |
has a week of email to read |
| 10:28.49 |
dloman |
you take last
week off as well? |
| 10:28.54 |
starseeker |
honeymoon |
| 10:29.23 |
starseeker |
that's why
I'm awake right now |
| 10:29.33 |
dloman |
right
on! |
| 10:29.35 |
dloman |
have
fun? |
| 10:29.36 |
starseeker |
time zones
are still messed up |
| 10:29.47 |
dloman |
oh, you are
currently ON your honeymoon? |
| 10:29.56 |
starseeker |
it was
awesome, aside from me being an idiot and losing my ticket for one
event |
| 10:30.01 |
starseeker |
nope, got
back last night |
| 10:30.06 |
dloman |
nice. |
| 10:30.12 |
dloman |
mind if I ask
where u went? |
| 10:30.19 |
starseeker |
got yelled at
by the cats... oh boy |
| 10:30.22 |
starseeker |
Spain |
| 10:30.32 |
dloman |
sweet! |
| 10:30.41 |
dloman |
fun
then? |
| 10:30.45 |
starseeker |
yep |
| 10:30.49 |
starseeker |
did a lot of
tours |
| 10:30.53 |
dloman |
nice
:) |
| 10:31.25 |
starseeker |
getting put
back together - will have to hit the store on the way home
tonight |
| 10:32.26 |
dloman |
watch the
weather. somehow a big nasty t-storm snuck up on me/PA/MD without
me noticing it on the weather map :) |
| 10:32.30 |
starseeker |
dloman: was
this the binding you found? |
| 10:32.32 |
starseeker |
http://kdesvn.alwins-world.de/ |
| 10:32.39 |
starseeker |
ow |
| 10:33.12 |
dloman |
no, i don';t
think that was it. |
| 10:33.38 |
dloman |
let me dig
really quick |
| 10:34.50 |
dloman |
libsvnqt4 |
| 10:34.54 |
dloman |
me thinks it
was |
| 10:35.06 |
dloman |
like i said.
I saw it, bookmarked it... and that's it. |
| 10:35.08 |
starseeker |
that sounds
like debian packaging of a subset of kdesvn |
| 10:35.11 |
dloman |
didn't take a
look. |
| 10:36.38 |
starseeker |
we'll
probably be talking directly to the C api of the various subversion
sub-libraries |
| 10:37.26 |
starseeker |
I'm pondering
whether the best approach would be to actually "port" both the svn
fs-fs backend and the checkout logic itself to work inside of a .g
instead of files |
| 10:38.16 |
starseeker |
that's
probably one *bleeping* lot of work, particularly the checkout
(which I expect makes lots of assumptions about files on a
filesystem being the intended checkout output) |
| 10:38.50 |
dloman |
might be the
best, but def not the fastest. |
| 10:39.07 |
starseeker |
doesn't
matter too much right now, since most of the work needed for the
break it down to regions and make files approach is still needed
for other approaches |
| 10:39.16 |
dloman |
right
on. |
| 10:39.26 |
dloman |
I plan on
diving headlong into that very aspect asap |
| 10:39.48 |
starseeker |
dloman: I
need to get search to behave as proper db functions
first |
| 10:40.07 |
starseeker |
that'll be
the best/only(?) way to get a list of assemblies (combinations
above regions) |
| 10:40.08 |
dloman |
first...
meaning before what? |
| 10:40.37 |
starseeker |
once I have
that list, and a list of regions, I can keep each into its own
file |
| 10:40.39 |
dloman |
def not the
only. a tree/dag walk would be one. |
| 10:40.58 |
starseeker |
shakes head - we need to write out the assemblies as their
own files |
| 10:41.09 |
dloman |
ya |
| 10:41.20 |
starseeker |
they aren't
below regions (in a proper .g anyway) and won't be kept by a "save
the regions" approach |
| 10:41.40 |
starseeker |
we need to
identify the subset of combs that aren't below any regions and save
those |
| 10:41.42 |
dloman |
okay, i think
I am missing something then. |
| 10:41.48 |
starseeker |
hmm? |
| 10:42.18 |
dloman |
if we do a
depth first search, everything in the path leading up to the region
*must* be a combination..... yes? |
| 10:42.27 |
dloman |
s/search/walk/ |
| 10:42.51 |
starseeker |
oh, you mean
take the tops list and work with that as the starting
point? |
| 10:42.56 |
dloman |
ya |
| 10:43.14 |
starseeker |
ponders... |
| 10:43.19 |
dloman |
since this is
sometihng that will only be run once per file, speed shouldn't be a
major concern |
| 10:44.17 |
starseeker |
yeah, that
would probably work, but the search approach is still worthwhile
because it can also be used to spot problems |
| 10:44.31 |
starseeker |
(regions
under regions, non-union operations in assemblies) |
| 10:44.43 |
dloman |
sure. Im
thinking timeline wise though, since end of march is our
target |
| 10:45.15 |
starseeker |
dloman: I
actually got search working as a C function just before I left, but
I didn't do it "right" from an API standpoint |
| 10:45.45 |
starseeker |
and since
we're supposed to be "done" at end of march, I want search's
ability to identify near-arbitrary subsets of things |
| 10:45.56 |
starseeker |
that power
may be necessary for robustness |
| 10:46.20 |
dloman |
oh it will
:) |
| 10:46.37 |
dloman |
but
robustness isn't on the list of things needed for the deliverable
:P |
| 10:46.41 |
dloman |
(that was a
joke btw) |
| 10:46.45 |
starseeker |
hehe |
| 10:47.14 |
dloman |
go go gadget
timesheet :/ |
| 10:48.24 |
starseeker |
dloman: one
thing that would help quite a lot is if you and brlcad could
summarize the "finalize" approach you two cooked up |
| 10:48.44 |
dloman |
heh, well, we
have to sit down and powwow again. |
| 10:48.45 |
starseeker |
the
functionality needed for that is essentially the TODO
lsit |
| 10:48.50 |
starseeker |
s/lsit/list/ |
| 10:49.16 |
dloman |
what I have
the notes for and what was 'understood' by both parties is not in
sync. |
| 10:49.31 |
starseeker |
nods |
| 10:49.33 |
dloman |
i think maybe
brlcad ``Erik you and i should all sit in |
| 10:49.51 |
dloman |
perhaps later
this week if our schedules align |
| 10:51.05 |
starseeker |
sure - I'd
mainly be listening, because it sounds like most of the major
problems were conceptually resolved - what we need now is a "do
this to librt to support namespaces, hook this up to svn, do this
to combine invidual .g region files into an assembly .g object to
satisfy a geomclient request, etc |
| 10:52.20 |
starseeker |
we also need
to decide what has to be in GE (if anything) to achieve basic
functionality |
| 10:52.23 |
dloman |
exactly. task
breakdown! |
| 10:52.55 |
dloman |
heh, I don't
know why I ever said yes to the gs project... it was waaaay over my
head for a newbie :/ |
| 10:53.05 |
starseeker |
hehe |
| 10:53.10 |
starseeker |
trial by
fire |
| 10:53.40 |
starseeker |
probably
would have been less tramatizing to do it the way I did - spend a
month making tires :-P |
| 10:53.54 |
dloman |
nice |
| 10:54.08 |
dloman |
i still want
to make the proc-db for making houses. |
| 10:54.14 |
dloman |
that'd be
fuuuun |
| 10:54.53 |
dloman |
curses at the vpn |
| 10:55.23 |
starseeker |
puts stuff together and heads out... the rumble you will hear
soon will be me being buried under email |
| 11:16.56 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.254.137) |
| 11:16.56 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 11:34.16 |
dloman |
so... offsite
is posponed? |
| 11:55.13 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.254.137) |
| 11:55.13 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:12.26 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:12.46 |
CIA-77 |
BRL-CAD:
03davidloman * r43489 10/jbrlcad/trunk/: Modify svn:ignore to
ignore .settings directory (generated by eclipse) |
| 12:14.59 |
CIA-77 |
BRL-CAD:
03davidloman * r43490 10/geomcore/trunk/src/interfaces/java/:
Modify svn:ignore to ignore .classpath and .project files
(generated by eclipse) |
| 12:24.15 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:25.09 |
dloman |
Xi is the x
lib's input lib, right? |
| 12:29.05 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.254.137) |
| 12:29.05 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:42.36 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 12:54.06 |
dloman |
Noob
question: brlcad's config can't seem to find libXi, but i know its
installed and where its at. How do i tell brlcad's config where it
is? |
| 13:12.35 |
starseeker |
--with-x and
the X11 location may work |
| 13:13.01 |
starseeker |
also, if you
just installed libXi-dev you may need to clear cache and
reconfigure |
| 13:15.50 |
dloman |
awesome,
tanks! |
| 13:19.47 |
starseeker |
Does anyone
remember if gecode (http://www.gecode.org/) was discussed
back when the parametric constraint Google Summer of Code project
was being worked? |
| 13:21.11 |
starseeker |
also,
http://www.g12.cs.mu.oz.au/minizinc/ |
| 13:23.42 |
dloman |
is there a
standard lex that we should use for brlcad? |
| 13:24.11 |
starseeker |
uh... not
really, but I'd be very surprised if you've got anything except
flex |
| 13:25.43 |
dloman |
thanks, you
answered my quetion indirectly =D |
| 13:39.40 |
starseeker |
confesses he is not up on the constraint stuff, but geocode
and friends sound at first glance like they are quite relevant and
interesting |
| 13:50.06 |
CIA-77 |
BRL-CAD:
03starseeker * r43491 10/brlcad/branches/cmake/ (114 files in 60
dirs): MFC r43490 |
| 13:54.32 |
dloman |
starseeker:
the TERMLIB cmake flag.... is it looking for libterm? |
| 13:55.26 |
starseeker |
dloman: not
just libterm - it's supposed to look for a whole bunch of possible
suppliers for the subset of termlib we need, and if it's not found
enable our local copy |
| 13:55.31 |
starseeker |
what's the
error? |
| 13:56.00 |
dloman |
config is
saying 'Could NOT find TERMLIB' |
| 13:56.10 |
starseeker |
autotools? |
| 13:56.12 |
dloman |
just trying
to figure out what i should install. |
| 13:56.14 |
dloman |
cmake |
| 13:56.28 |
starseeker |
that's
surprising |
| 13:56.38 |
starseeker |
if it's not
found it should just fall back on src/other |
| 13:57.02 |
dloman |
its not
erroring out, im just trying to fill out as many libs as
possible. |
| 13:57.05 |
starseeker |
just install
the ncurses dev package if you want something on the
system |
| 13:57.08 |
dloman |
this is a
brandy new install of ubuntu |
| 14:05.49 |
CIA-77 |
BRL-CAD:
03starseeker * r43492
10/brlcad/branches/cmake/src/tab/CMakeLists.txt: Clear out txyz-pl
from src/tab CMakeLists.txt file |
| 14:30.22 |
CIA-77 |
BRL-CAD:
03starseeker * r43493
10/brlcad/branches/cmake/misc/enigma/CMakeLists.txt: enigma is not,
properly speaking, a BRL-CAD program - don't use BRLCAD_ADDEXEC
macro (we don't want to hit it with the strict flags, same as
src/other |
| 14:33.38 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.254.137) |
| 14:33.48 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:37.40 |
CIA-77 |
BRL-CAD:
03starseeker * r43494 10/brlcad/branches/cmake/src/tclscripts/
(archer/CMakeLists.txt lib/CMakeLists.txt): cursor.tcl
moved |
| 14:48.45 |
starseeker |
hmm...
http://www.cs.washington.edu/research/constraints/cassowary/ |
| 14:49.51 |
starseeker |
needs this
http://www.fim.uni-passau.de/fileadmin/files/lehrstuhl/brandenburg/projekte/gtl/GTL-1.2.4-lgpl.tar.gz |
| 14:51.27 |
starseeker |
geocode
sounds more modern and supported, if the domains overlap
properly |
| 15:53.04 |
CIA-77 |
BRL-CAD:
03starseeker * r43495
10/brlcad/branches/cmake/src/tab/CMakeLists.txt: Problem - the lex
generated output is triggering warnings. Gonna have to go with
-Wno-error until we get a flex/byacc solution in place we can rely
on/tweak to generate error free code. |
| 15:56.24 |
brlcad |
starseeker:
what were the warnings? during my cleanup a couple weeks ago,
several of the lex-generated output warnings were controlled by
settings in the lex/yacc files |
| 15:56.32 |
brlcad |
i.e., they
were easily quellable |
| 15:56.40 |
brlcad |
welcome back
too :) |
| 15:58.44 |
starseeker |
brlcad:
thanks :-) |
| 15:58.46 |
starseeker |
script.c:34:5: warning: "__STDC_VERSION__"
is not defined |
| 15:59.01 |
starseeker |
script.c:1020: warning: label
‘find_rule’ defined but not used |
| 15:59.14 |
starseeker |
script.c:1439: warning: comparison between
signed and unsigned |
| 15:59.23 |
starseeker |
script.c:2138: warning:
‘yy_flex_strlen’ defined but not used |
| 16:01.21 |
CIA-77 |
BRL-CAD:
03starseeker * r43496 10/brlcad/trunk/src/ (canon/canonize.c
librtserver/rtserver.c rt/view.c sig/fhor.c): Various
quellage |
| 16:04.13 |
CIA-77 |
BRL-CAD:
03d_rossberg * r43497 10/brlcad/trunk/src/ (conv/CMakeLists.txt
conv/stl/stl-g.c librt/CMakeLists.txt): ntohl(): missing includes
and libraries for the MSVC CMake build (needs WinSock
2) |
| 16:04.21 |
CIA-77 |
BRL-CAD:
03starseeker * r43498 10/brlcad/branches/cmake/ (32 files in 31
dirs): There we go - strict compile flags are now the default
throughout the BRL-CAD src directories, with the exception of
src/other |
| 16:09.07 |
brlcad |
thanks,
interesting diff set of warnings |
| 16:10.47 |
starseeker |
brlcad: do
you recall if gecode was ever mentioned in the parametric
constraint lib discussions? |
| 16:11.43 |
dloman |
starseeker:
the cmake command to find x was: cmake --with-x <pathToSrc>
?? |
| 16:11.44 |
brlcad |
nah, I don't
really recall |
| 16:11.49 |
brlcad |
starseeker:
what's the gain? |
| 16:12.36 |
starseeker |
i'm thinking
it might actually have a working constraint solver on top of which
we would define our constraints |
| 16:12.49 |
brlcad |
isn't keen on bio.h having networking, that expands the scope
a bit.. |
| 16:12.53 |
starseeker |
(i.e. it
sounds kind of like what the gsoc project was trying to
develop) |
| 16:13.04 |
dloman |
tryin to fix
a linker error: cannot find -lXss (-lXft and
-lXrender) |
| 16:13.42 |
starseeker |
um. Ubuntu
might break those out into separate packages... |
| 16:14.03 |
dloman |
did a find
and I have them... so how do I supply paths to cmake? |
| 16:14.08 |
brlcad |
starseeker:
it's definitely related -- there are dozens of constraint solver
libraries out there |
| 16:14.21 |
brlcad |
each with
their merits and deficiencies.. |
| 16:15.15 |
starseeker |
brlcad:
that's what I was wondering - presumably there must have been a
review of those before we went for writing our own... |
| 16:16.04 |
brlcad |
possibly, but
that would have been pre-submission |
| 16:16.05 |
starseeker |
dloman: it's
rather disturbing they aren't being found |
| 16:16.16 |
starseeker |
nuts |
| 16:16.51 |
starseeker |
dloman: can
you post the results of make VERBOSE=1 that are related to the
failure? |
| 16:16.57 |
dloman |
starseeker:
if it helps, all the libs are in /usr/lib and
/usr/lib32 |
| 16:17.00 |
dloman |
kk, will
do |
| 16:17.39 |
brlcad |
starseeker:
it's kinda the same situation as writing a solver for nurbs surface
evaluation -- "surely there was a review of existing root solvers
before we went for writing our own" |
| 16:17.50 |
brlcad |
the answer is
"yes and no" |
| 16:18.14 |
brlcad |
the solver is
fairly tied to the data structures, same with
constraints |
| 16:19.48 |
starseeker |
ah |
| 16:20.02 |
brlcad |
fwiw, much of
libpc isn't the actual constraint solving but the data structures
for representing a constraint, the bridge for librt to
use |
| 16:20.14 |
brlcad |
so you could
conceivably hook in any constraint solver under the
hood |
| 16:20.25 |
starseeker |
nods - that might be interesting to look
at |
| 16:20.47 |
brlcad |
as would
determining where the current implementation is actually
at |
| 16:21.05 |
starseeker |
was doing some reading of SICP, and their description of what
a constraint system does/is good for kind of set off a light
bulb |
| 16:21.06 |
brlcad |
for all we
know, it could be done and working perfectly for our
needs |
| 16:21.48 |
starseeker |
not that I
have time to fool with it now of course, but it sounds quite
interesting |
| 16:22.15 |
brlcad |
when I
reviewed his work back during gsoc, it actually seemed to be
working very well |
| 16:22.48 |
brlcad |
the problems
he was working on were problems we were not yet faced with, solving
multiple constraints simultaneously |
| 16:23.06 |
brlcad |
there are
sample test driver programs in the tree that show it
working |
| 16:23.45 |
starseeker |
nods. I'm just wondering how hard it would be to shake out
bugs and demonstrate robustness there vs. using something like
gecode under the hood for the actual solving
part... |
| 16:23.57 |
starseeker |
but the only
way to know that is to dig into it |
| 16:24.34 |
brlcad |
you won't
know whether gecode is better or worse without writing a test
driver that evaluates the current state of affairs
regardless |
| 16:24.42 |
starseeker |
right |
| 16:25.20 |
brlcad |
given there
are already some simple test drivers, it would be an intersting
comparison |
| 16:25.30 |
brlcad |
useful too,
it's a current year task |
| 16:25.50 |
starseeker |
nods - maybe I can dive in after the geometry service gets
beaten into submission |
| 16:25.50 |
brlcad |
someone will
have to investigate and evaluate before the year's up |
| 16:26.03 |
brlcad |
has the same
deadline as the GS iirc :) |
| 16:26.12 |
starseeker |
O.o |
| 16:26.12 |
brlcad |
much smaller
task, though |
| 16:26.34 |
starseeker |
crawls under his desk and hides... |
| 16:26.46 |
starseeker |
and then
realizes that's a bad place to code from |
| 16:26.51 |
brlcad |
frack.. end
of month |
| 16:26.54 |
brlcad |
time to
release! |
| 16:27.01 |
brlcad |
damn short
month |
| 16:27.12 |
starseeker |
winces |
| 16:28.02 |
brlcad |
gsoc org
submissions opens up today too |
| 16:28.23 |
brlcad |
if we're
going to participate, someone is going to have to get started on
writing up a new task list on the wiki |
| 16:28.24 |
starseeker |
do you want
me to do the librt search port in CMake to avoid messing with
trunk? |
| 16:28.35 |
brlcad |
heck no
:) |
| 16:28.59 |
brlcad |
search
port? |
| 16:29.07 |
brlcad |
sounds rather
un-cmakeing |
| 16:29.20 |
starseeker |
sure, but
it's a nasty thing to do during a release cycle |
| 16:29.29 |
starseeker |
whoops,
bbl |
| 16:29.55 |
brlcad |
just have to
be more careful to not break build or functionality during commits,
just talking a day or two to test and tag |
| 16:37.13 |
CIA-77 |
BRL-CAD:
03brlcad * r43499 10/brlcad/trunk/TODO: |
| 16:37.13 |
CIA-77 |
BRL-CAD:
release tasks were not completed by the end of the month, so push
to the next |
| 16:37.13 |
CIA-77 |
BRL-CAD:
iteration. only remaining task that comes to mind is removing the
network dep |
| 16:37.13 |
CIA-77 |
BRL-CAD: from
bio.h (need a separate header since it's just for standard
i/o) |
| 17:04.38 |
CIA-77 |
BRL-CAD:
03brlcad * r43500 10/brlcad/trunk/src/libged/CMakeLists.txt: add
fb2pix.c and pix2fb.c |
| 17:18.41 |
CIA-77 |
BRL-CAD:
03jordisayol * r43501 10/brlcad/trunk/misc/debian/changelog: update
debian changelog |
| 18:11.41 |
CIA-77 |
BRL-CAD:
03brlcad * r43502 10/brlcad/trunk/include/ (Makefile.am
bin.h): |
| 18:11.41 |
CIA-77 |
BRL-CAD: add
an initial corrollary header file similar to bio.h but for
internet |
| 18:11.41 |
CIA-77 |
BRL-CAD:
networking instead of input/output. it's similarly a 'private'
self-contained |
| 18:11.41 |
CIA-77 |
BRL-CAD:
header (so no HAVE_* defines), but should help consolidate the
header |
| 18:11.41 |
CIA-77 |
BRL-CAD:
preprocessor logic into one place. this header is effectively
treated as a |
| 18:11.42 |
CIA-77 |
BRL-CAD:
system header coming before inclusions of brl-cad public/private
headers. |
| 18:14.23 |
CIA-77 |
BRL-CAD:
03brlcad * r43503 10/brlcad/trunk/src/librt/Makefile.am: missing
the tieprivate.h header |
| 18:16.50 |
CIA-77 |
BRL-CAD:
03brlcad * r43504 10/brlcad/trunk/src/librtserver/rtserver.c:
include headers for htonl |
| 18:20.17 |
CIA-77 |
BRL-CAD:
03brlcad * r43505 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c:
include bin.h instead of bio.h for htonl and friends |
| 18:22.32 |
CIA-77 |
BRL-CAD:
03brlcad * r43506 10/brlcad/trunk/include/bio.h: |
| 18:22.32 |
CIA-77 |
BRL-CAD:
remove inclusion of arpa/inet.h from bio.h since it's not desirable
to bundle |
| 18:22.32 |
CIA-77 |
BRL-CAD:
networking routines in with the input/output routines. this is in
part due to |
| 18:22.32 |
CIA-77 |
BRL-CAD: the
implied dependency on the windows socket library on the windows
platform, |
| 18:22.32 |
CIA-77 |
BRL-CAD:
which isn't necessarily true for inclusions only needing standard
i/o. the new |
| 18:22.33 |
CIA-77 |
BRL-CAD:
bin.h internet networking header now covers networking. |
| 18:28.16 |
CIA-77 |
BRL-CAD:
03brlcad * r43507 10/brlcad/trunk/src/librt/db5_io.c: need bin.h
instead of bio.h |
| 18:29.24 |
CIA-77 |
BRL-CAD:
03brlcad * r43508 10/brlcad/trunk/src/librt/db_scan.c: ditto, bio.h
-> bin.h for networking |
| 18:34.20 |
CIA-77 |
BRL-CAD:
03brlcad * r43509 10/brlcad/trunk/src/libged/bot_dump.c: need
networking and i/o functions here, so also include
bin.h |
| 18:34.30 |
CIA-77 |
BRL-CAD:
03brlcad * r43510 10/brlcad/trunk/src/librt/ (11 files in 11 dirs):
promulgation continues, switch from bio.h to bin.h where byteorder
functions are being used. |
| 18:34.34 |
``Erik |
the arpa inet
header in bio.h was for htonl/ntohl |
| 18:35.00 |
``Erik |
*readreadread* |
| 18:36.11 |
``Erik |
hm,
*update;compile* O.o |
| 18:36.42 |
CIA-77 |
BRL-CAD:
03brlcad * r43511 10/brlcad/trunk/src/conv/ (asc/asc2g.c
asc/g2asc.c poly-bot.c stl/g-stl.c): and maybe the last batch of
bin.h inclusions needed. |
| 18:36.51 |
brlcad |
I know - but
that made the header pull in more than just i/o |
| 18:37.06 |
brlcad |
the wrapper
header was needed, just made a new file |
| 18:37.19 |
brlcad |
one for just
networking |
| 18:37.41 |
brlcad |
so anything
that includes that file is implicitly requiring
ws2_32.lib |
| 18:38.56 |
brlcad |
sucks that
byteorder is in winsock on windows .. the bu xdr funcs provided a
nice encapsulation from that perspective, but still probably better
unwrapped |
| 18:40.18 |
CIA-77 |
BRL-CAD:
03starseeker * r43512 10/brlcad/branches/cmake/CMakeLists.txt: Try
InstallRequiredSystemLibraries on Windows MSVC |
| 18:41.14 |
CIA-77 |
BRL-CAD:
03brlcad * r43513 10/brlcad/trunk/src/conv/stl/stl-g.c: nope,
missed one |
| 18:46.58 |
*** join/#brlcad Ralith
(~ralith@d142-058-095-076.wireless.sfu.ca) |
| 19:00.17 |
CIA-77 |
BRL-CAD:
03starseeker * r43514 10/brlcad/branches/cmake/ (36 files in 24
dirs): MFC r43513, update CMakeLists.txt files to include winsock
in more places (untested) |
| 19:04.13 |
starseeker |
ah,
homovulgaris mentioned gecode back in 2008 |
| 19:16.03 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43515 10/brlcad/trunk/include/bin.h: need
sys/types.h for netinet/tcp.h |
| 19:21.41 |
``Erik |
probably
should be wrapping some #ifdef HAVE_SOME_H in there
*shrug* |
| 19:24.30 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43516 10/brlcad/trunk/include/bin.h: #define
<winsock2.h> doesn't quite work |
| 19:25.21 |
brlcad |
heh |
| 19:26.14 |
brlcad |
``Erik: bio.h
and bin.h intentionally do not have HAVE_* defines since they're
not supposed to be tied to configure -- more like system header
replacements |
| 19:27.10 |
brlcad |
they could be
converted / coupled with configure feature testing, but it would
change a few things |
| 19:41.18 |
CIA-77 |
BRL-CAD:
03davidloman * r43517 10/brlcad/branches/cmake/: Modify svn:ignore
to ignore .classpath and .project files (generated by
eclipse) |
| 19:59.10 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 19:59.10 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release prep for 7.18.2 under way
(20110202) |
| 20:29.05 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 20:53.07 |
CIA-77 |
BRL-CAD:
03brlcad * r43518 10/brlcad/trunk/src/mged/attach.c: include bin.h
instead of including winsock2.h directly |
| 20:55.25 |
CIA-77 |
BRL-CAD:
03brlcad * r43519 10/brlcad/trunk/configure.ac: |
| 20:55.25 |
CIA-77 |
BRL-CAD:
there's no reason to leave out the gnu extensions other than to try
and avoid |
| 20:55.25 |
CIA-77 |
BRL-CAD:
non-standard functions. in practice, however, c99 compliance means
we also |
| 20:55.25 |
CIA-77 |
BRL-CAD:
don't get the posix functions, which is somewhat problematic.
change the |
| 20:55.25 |
CIA-77 |
BRL-CAD:
compliance from std99 to gnu99. |
| 21:13.11 |
CIA-77 |
BRL-CAD:
03brlcad * r43520 10/brlcad/trunk/src/util/dunncomm.c: wrong
comment |
| 21:21.30 |
CIA-77 |
BRL-CAD:
03brlcad * r43521 10/brlcad/trunk/src/libfb/if_ogl.c: no longer
need the __BSD_VISIBLE/__USE_XOPEN/__USE_BSD hacking to get the
extension decls with configure using gnu99. |
| 21:35.36 |
CIA-77 |
BRL-CAD:
03brlcad * r43522 10/brlcad/trunk/src/tab/script.l: overcome flex
stupidities, define undefined to false in order to appease
preprocessor logic. |
| 21:48.56 |
CIA-77 |
BRL-CAD:
03brlcad * r43523 10/brlcad/trunk/src/ (16 files in 16
dirs): |
| 21:48.56 |
CIA-77 |
BRL-CAD:
enable the remainder of strict flags now that the build is verified
across mac |
| 21:48.56 |
CIA-77 |
BRL-CAD: and
linux. now all of brl-cad's source code builds strict-clean for
improved |
| 21:48.56 |
CIA-77 |
BRL-CAD:
security, maintainability, conformance compliance, stability,
reliability, and |
| 21:48.56 |
CIA-77 |
BRL-CAD:
more. |
| 21:54.40 |
CIA-77 |
BRL-CAD:
03brlcad * r43524 10/brlcad/trunk/src/remrt/ihost.c: replace the
net headers with bin.h |
| 22:31.23 |
*** join/#brlcad guest_tttt
(~rm@123.136.11.66) |
| 22:31.45 |
guest_tttt |
..... |
| 22:33.48 |
*** part/#brlcad guest_tttt
(~rm@123.136.11.66) |
| 22:37.11 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 23:02.16 |
*** join/#brlcad dtidrow_
(~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) |
| 23:02.17 |
CIA-77 |
BRL-CAD:
03brlcad * r43525 10/brlcad/trunk/src/conv/Makefile.am: missing the
shapefil.h header |
| 23:09.15 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 23:13.59 |
CIA-77 |
BRL-CAD:
03starseeker * r43526 10/brlcad/trunk/include/raytrace.h: search
will need regex.h once it is moved to librt |
| 23:16.52 |
CIA-77 |
BRL-CAD:
03starseeker * r43527 10/brlcad/trunk/src/librt/ (Makefile.am
search.c search.h): Add work done so far on search move to librt -
not being added to the compile until after the release. |
| 23:28.54 |
CIA-77 |
BRL-CAD:
03starseeker * r43528
10/geomcore/trunk/tests/svntest/CMakeLists.txt: fix install target
for svnTest |
| 23:38.27 |
CIA-77 |
BRL-CAD:
03starseeker * r43529 10/brlcad/branches/cmake/ (CMakeLists.txt
src/other/CMakeLists.txt): Move the TERMLIB option to src/other -
we need this set in advance of the third party logic. |
| 00:13.24 |
CIA-77 |
BRL-CAD:
03starseeker * r43530 10/brlcad/branches/cmake/CMakeLists.txt:
Remove the complex and only partially successful noprod logic -
with targets in toplevel bin dirs anyway the utility is minimal,
and not worth the complexity. |
| 00:36.45 |
CIA-77 |
BRL-CAD:
03starseeker * r43531 10/brlcad/branches/cmake/ (3 files in 3
dirs): Ignore other in src |
| 00:39.42 |
CIA-77 |
BRL-CAD:
03starseeker * r43532
10/brlcad/branches/cmake/src/librt/CMakeLists.txt: Ignore
search.h |
| 00:50.20 |
*** join/#brlcad Klebel
(~mk@w73.RIC.Berkeley.EDU) |
| 00:50.49 |
Klebel |
I can't find
'Set H' in the Edit menu |
| 00:57.36 |
Klebel |
press "Set H"
- says unknown operation. |
| 00:57.45 |
Klebel |
on the
command line |
| 00:58.31 |
starseeker |
Klebel: we
need more context |
| 00:59.29 |
Klebel |
page 60 in
the Introduction to MGED manual. |
| 00:59.29 |
Klebel |
pdf |
| 01:00.22 |
Klebel |
I created a
right circular cylinder, then it tells me to do, "Edit and then Set
H" |
| 01:00.33 |
Klebel |
and click the
middle mouse button several times |
| 01:01.02 |
starseeker |
to edit a
primitive, you need to use sed |
| 01:01.08 |
starseeker |
that puts you
in edit mode |
| 01:02.05 |
starseeker |
if you aren't
seeing Set H you probably aren't in edit mode |
| 01:02.08 |
Klebel |
ah, so sed
base1.s |
| 01:02.08 |
Klebel |
thanks, Set H
is now in the menu, and works |
| 01:02.29 |
starseeker |
that tutorial
was created with an older version of BRL-CAD, so there are
occasional differences |
| 01:02.43 |
Klebel |
yea I've
noticed that :/ |
| 01:07.15 |
Klebel |
is there a
command to get out of edit mode? |
| 01:07.26 |
starseeker |
accept or
reject |
| 01:07.40 |
Klebel |
ok
thanks |
| 01:09.02 |
CIA-77 |
BRL-CAD:
03starseeker * r43533 10/brlcad/branches/cmake/ (27 files in 22
dirs): MFC r43532 |
| 01:10.42 |
CIA-77 |
BRL-CAD:
03starseeker * r43534
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Uncomment -w
again for src/other |
| 01:17.39 |
CIA-77 |
BRL-CAD:
03starseeker * r43535
10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: We're
going for gnu99 now |
| 02:01.02 |
CIA-77 |
BRL-CAD:
03brlcad * r43536 10/brlcad/trunk/src/bwish/cadAppInit.c: include
bin.h instead of winsock2.h |
| 03:28.05 |
*** join/#brlcad guest_tttt
(~rm@123.136.11.66) |
| 03:34.43 |
*** part/#brlcad guest_tttt
(~rm@123.136.11.66) |
| 04:32.23 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 04:33.44 |
CIA-77 |
BRL-CAD:
03brlcad * r43537 10/brlcad/trunk/src/rttherm/pixtest.c: check
fwrite return value |
| 04:36.11 |
CIA-77 |
BRL-CAD:
03brlcad * r43538 10/brlcad/trunk/src/sig/ (24 files): check fwrite
return values for failure |
| 04:39.55 |
CIA-77 |
BRL-CAD:
03brlcad * r43539 10/brlcad/trunk/src/proc-db/brepintersect.cpp:
compiler is complaining about the first param to
SegmentPolylineIntersect possibly being NULL. as this is dev code,
just comment out for now in leu of removing the code. |
| 04:44.14 |
CIA-77 |
BRL-CAD:
03brlcad * r43540 10/brlcad/trunk/src/mged/points/points_parse.y:
bison is being stupid with some output code generating size_t
comparisons against >= 0. quell that warning along with a couple
other preprocessor symbols that are not defined but being used in
expressions. |
| 04:45.52 |
CIA-77 |
BRL-CAD:
03brlcad * r43541 10/brlcad/trunk/src/ (mged/points/points_scan.l
tab/script.l): quell flex lameness where fwrite() is being called
without checking the return value. this quiets the
compiler. |
| 04:51.08 |
CIA-77 |
BRL-CAD:
03brlcad * r43542 10/brlcad/trunk/src/ (23 files in 7
dirs): |
| 04:51.09 |
CIA-77 |
BRL-CAD:
categorically check return values for some of the stdio and stdlib
routines |
| 04:51.09 |
CIA-77 |
BRL-CAD:
(e.g. fwrite, scanf, system, dup, pipe, ...). not willing to put
forth |
| 04:51.09 |
CIA-77 |
BRL-CAD:
time/effort to do anything more than print the error since would
have to |
| 04:51.09 |
CIA-77 |
BRL-CAD:
evaluate each call on a case by case basis (and that's not
fun). |
| 05:10.50 |
*** join/#brlcad dli
(~dli@dsl-67-204-45-87.acanac.net) |
| 05:35.23 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.254.137) |
| 05:35.23 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:08.23 |
CIA-77 |
BRL-CAD:
03brlcad * r43543 10/brlcad/trunk/src/libfb/if_X24.c: fix
keybindings on Mac OS X so that cmd-click will produce button 3
events (so we can close framebuffers) without needing the user to
set X11.app to emulate a three button mouse. |
| 06:09.28 |
CIA-77 |
BRL-CAD:
03brlcad * r43544 10/brlcad/trunk/src/libfb/if_ogl.c: do the same
mouse-3 binding for ogl |
| 06:51.11 |
Klebel |
1 thing I
keep noticing in the Introduction manual, is that when I copy
primatives through the command line then run sed on the newly
copied primative it says: Error sph2.s not being
displayed |
| 06:51.37 |
Klebel |
the only way
I am able to copy is through the Primitive Editor |
| 07:01.04 |
CIA-77 |
BRL-CAD:
03brlcad * r43545
10/brlcad/trunk/src/tclscripts/mged/bindings.tcl: |
| 07:01.04 |
CIA-77 |
BRL-CAD: fix
mged zoom bindings on mac os x with default X11 (where 3-button
mouse |
| 07:01.04 |
CIA-77 |
BRL-CAD:
emulation is disabled) so that you can actually zoom out. make
cmd-click behave |
| 07:01.04 |
CIA-77 |
BRL-CAD: the
same as button-3. unfortunately, the same binding does not seem
possible |
| 07:01.04 |
CIA-77 |
BRL-CAD: with
option-click for mouse 2 (in fact, option seems to act like mod2
aka the |
| 07:01.04 |
CIA-77 |
BRL-CAD:
command-key. none of the other mod types seem to help. |
| 07:07.37 |
CIA-77 |
BRL-CAD:
03brlcad * r43546 10/brlcad/trunk/NEWS: |
| 07:07.38 |
CIA-77 |
BRL-CAD:
fixed a problem being able to zoom in with the default x11.app
configuration |
| 07:07.38 |
CIA-77 |
BRL-CAD:
where you could zoom out, but not back in without enabling 3-button
emulation. |
| 07:07.38 |
CIA-77 |
BRL-CAD: this
binds command+button1 the same as button3. couldn't get
option+button1 to |
| 07:07.38 |
CIA-77 |
BRL-CAD:
behave as button2 though. |
| 07:10.21 |
CIA-77 |
BRL-CAD:
03brlcad * r43547 10/brlcad/trunk/src/librt/primitives/table.c:
tested and rt_generic_xform() is NOT sufficient. wrong plot and
trace with loads of error. |
| 07:10.47 |
brlcad |
Klebel: when
you copy something, it's not automatically drawn |
| 07:10.57 |
brlcad |
cp old new ;
e new |
| 07:11.07 |
brlcad |
then sed and
friends will work |
| 07:11.12 |
brlcad |
(on
new) |
| 07:11.25 |
brlcad |
e ==
draw |
| 07:13.30 |
brlcad |
starseeker:
mged regression is failing with "Tcl_Import ERROR: unknown
namespace in import pattern "::itcl::*" |
| 07:14.09 |
brlcad |
wondering if
you're seeing that on your end |
| 07:14.50 |
brlcad |
only
namespace or itcl change that comes to mind is the mged/bwish setup
routine |
| 07:15.47 |
brlcad |
yeah,
namespace import fails because itcl_init is failing, can't
find/load the itcl .so file (testing on linux atm) |
| 07:52.39 |
Klebel |
thanks
brlcad |
| 10:18.24 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 10:38.35 |
*** join/#brlcad Elrohir
(~kvirc@p5B149820.dip.t-dialin.net) |
| 11:07.56 |
*** join/#brlcad Elrohir
(~kvirc@p5B149820.dip.t-dialin.net) |
| 11:13.53 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 11:30.56 |
dloman |
Mernin
all. |
| 11:46.40 |
CIA-77 |
BRL-CAD:
03d_rossberg * r43548 10/brlcad/trunk/include/bin.h: |
| 11:46.40 |
CIA-77 |
BRL-CAD:
undef some windows defines which are used in an other context
here |
| 11:46.40 |
CIA-77 |
BRL-CAD:
(same as in bio.h) |
| 11:49.56 |
CIA-77 |
BRL-CAD:
03d_rossberg * r43549 10/brlcad/trunk/ (3 files in 3 dirs):
raytrace.h got a regex.h include -- added the corresponding search
path |
| 12:14.00 |
starseeker |
brlcad: I'll
have to check - I'm doing most of my development work with CMake
these days, so I haven't tried the autotools regression in a
while |
| 12:14.12 |
starseeker |
I thought it
worked, but maybe it was a fluke... |
| 12:27.29 |
dloman |
Huh. Neato:
http://sewelldirect.com/Sewell-Minideck-USB-to-DVI-Display-Adapter.asp |
| 12:45.21 |
CIA-77 |
BRL-CAD:
03starseeker * r43550 10/brlcad/trunk/src/fbserv/fbserv.c:
Shadowing a global - fixed |
| 12:47.24 |
CIA-77 |
BRL-CAD:
03starseeker * r43551 10/brlcad/trunk/src/lgt/ (hmenu.c lgt.c):
Remove defined-but-unused functions causing lgt
failures. |
| 12:49.29 |
starseeker |
brlcad: still
getting a script.c failure: |
| 12:49.40 |
starseeker |
script.c: In
function ‘yy_get_next_buffer’: |
| 12:49.40 |
starseeker |
script.c:1414: error: comparison between
signed and unsigned integer expressions |
| 13:07.12 |
starseeker |
brlcad: OK, I
see a failure |
| 13:07.22 |
starseeker |
looks like a
different one though |
| 13:07.38 |
starseeker |
brlcad: are
you doing an in-dir or out of dir build? |
| 13:09.15 |
CIA-77 |
BRL-CAD:
03starseeker * r43552 10/brlcad/trunk/src/mged/chgview.c: Don't
shadow basename |
| 13:11.16 |
starseeker |
god I wish we
could switch to CMake |
| 13:12.26 |
starseeker |
out of dir
autotools build can't find the tclscripts to initialize the gui,
from the looks of it |
| 13:13.49 |
starseeker |
bizarrely
enough, if I start up with nu, package require Itcl DOES
succeed |
| 13:15.27 |
starseeker |
confound it,
autopath STILL has /usr/lib at the head of the auto_path search
path |
| 13:21.18 |
dloman |
so, brlcad
(autotools) doesn't like out of src builds atm? |
| 13:22.00 |
starseeker |
oh, I builds
OK but it doesn't seem to run |
| 13:23.27 |
starseeker |
auto_path is
getting all the paths set to the build dir versions of tclscript
paths, which doesn't work because they're still in the src
dir |
| 13:25.57 |
starseeker |
we can either
copy the tclscripts over into the build dir (which is a variation
on what CMake does currently) or tweak the path logic to point back
to the src dir |
| 13:26.32 |
starseeker |
but that
won't fix the issue of /usr/lib being up front in the search path,
which is an excellent way to pull in system installed things and
mix the tcl/tk environment up royally |
| 13:30.10 |
CIA-77 |
BRL-CAD:
03starseeker * r43553 10/brlcad/branches/cmake/ (66 files in 21
dirs): MFC r43552 |
| 13:33.10 |
starseeker |
nice little
subtle issues, particularly when we have to use a local tweaked
version of something and there's a vanilla system version getting
pulled in instead |
| 13:40.23 |
starseeker |
saddles up |
| 13:56.42 |
``Erik |
<PROTECTED> |
| 14:14.45 |
dloman |
I love
it. |
| 14:15.05 |
dloman |
the IT guys
are trying to tell me that its not possible to drive 4 monitors
from two video cards. |
| 14:17.24 |
dloman |
stares at brlcad's 5 monitor setup and laughs at
IT. |
| 14:17.55 |
dli |
dloman, two
video cards for 5 monitor? |
| 14:18.09 |
dloman |
brlcad
actually has 3 cards |
| 14:18.39 |
dloman |
but the point
remains the same. the IT guys I'm emailing obviously dunt know
what they are talking about. |
| 14:18.41 |
dli |
dloman, so
X-server can handle as many as you can provide? |
| 14:19.07 |
dloman |
should |
| 14:22.00 |
dli |
dloman, nice
to know |
| 14:22.51 |
dloman |
stumbled upon
a USB to DVI converter (see link above) that allows up to 6
external monitors :) |
| 14:22.57 |
dloman |
....i really
want to try that out. |
| 14:24.07 |
dli |
dloman, I got
a thinkpad with faulty video card, maybe, I can drive up a monitor
by USB, but I'm not sure |
| 14:24.40 |
dloman |
Might be
worth a look. |
| 14:24.51 |
dloman |
is the video
card integrated or dedicated? |
| 14:25.38 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43554 10/brlcad/trunk/src/libfb/if_ogl.c: event
is a struct, not a pointer |
| 14:29.08 |
dloman |
ahahaha, just
found a MB that has 7 x16 PCIe slots. Get 7 Eyefinity6's and
thats... 42 monitors plus 6 on USB. 48 screens.
Awesome. |
| 14:30.05 |
dloman |
Heh, i wonder
if that would actually work :) |
| 14:31.28 |
starseeker |
consideres the power demand and winces
slightly |
| 14:31.57 |
dloman |
If you can
afford all those cards and displays, the Powersupply becomes
trivial :) |
| 14:32.09 |
``Erik |
mr
fusion |
| 14:32.18 |
dli |
dloman, it's
deciated video, but still integrated on the mobo |
| 14:32.40 |
``Erik |
1.21
jiggawatts (whatever a jigga is) |
| 14:32.54 |
dloman |
dli: suckage.
You opened the case to ensure the gfx card isn't
removable? |
| 14:33.58 |
dloman |
``Erik:
you're borderline racist, so be careful :) |
| 14:34.11 |
``Erik |
O.o |
| 14:34.12 |
dli |
dloman, yes,
I opened it several times :) right now, the thinkpad works as a
file server, and a wireless router for my VoIP |
| 14:34.20 |
dloman |
ahaha,
nice. |
| 14:35.12 |
dli |
dloman, the
VoIP box supports only wired net, so the thinkpad hooks VoIP to
wifi. |
| 14:35.20 |
dloman |
well that
usb2dvi thingy costs about 100 bucks, and you might be able to get
an entire replacement laptop (depending on how old it is) for
that. |
| 14:35.42 |
dloman |
hates wifi. too slow. |
| 14:36.36 |
CIA-77 |
BRL-CAD:
03starseeker * r43555 10/brlcad/branches/cmake/src/libfb/if_ogl.c:
MFC r43554 |
| 14:37.27 |
dli |
dloman, then,
forget it, it's a 4-year-old core2duo level. |
| 14:37.53 |
dloman |
heh, i just
replaced my old core2 |
| 14:38.09 |
dli |
dloman, wifi
is orders faster than VoIP requires |
| 14:38.37 |
dloman |
understood |
| 14:39.19 |
dloman |
and wifi is
normally 'good enough' but the wife and I work with large photoshop
files and getting them on/off the fileserver via wifi is....
annoying at best. |
| 14:40.28 |
dli |
dloman, does
wifi-N help? |
| 14:40.37 |
dloman |
some. |
| 14:40.51 |
dloman |
we're in the
process of wiring the house for gig-e |
| 14:41.01 |
dloman |
so we can
plug in when we need speed. |
| 14:41.34 |
dli |
dloman,
that's wonderful :( when I get the budget to redo my home, I will
see how to make giga-e possible at home |
| 14:42.29 |
dloman |
we're doing
it slowly. |
| 14:42.31 |
dli |
dloman, do
you work with NURB objects? |
| 14:42.36 |
dloman |
negative. |
| 14:42.49 |
dloman |
I know next
to nothing about nurbs. |
| 14:42.57 |
dloman |
its on the
long 'tolearn' list. |
| 14:44.32 |
dli |
dloman,
brlcad suggests me to start with NURB intersection problem. I'm too
slow here to start :( |
| 14:47.56 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43556 10/brlcad/trunk/src/irprep/ir-X.c: size_t
casting fixes |
| 14:51.46 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43557 10/brlcad/trunk/src/mged/clone.c: size_t
casting |
| 14:52.13 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43558 10/brlcad/trunk/src/mged/dm-ogl.c: fill
out entire struct in table |
| 15:12.03 |
brlcad |
starseeker:
cool, what platform gave you the defined but unused
failures? |
| 15:14.00 |
brlcad |
dloman: you'd
saturate the bus before you could drive that many, but it would be
fun to see |
| 15:15.05 |
brlcad |
4 smaller
displays are possible on one dual-dual, or two big'uns |
| 15:15.28 |
brlcad |
dli: making
any progress? |
| 15:15.48 |
starseeker |
brlcad: was
on gentoo |
| 15:15.56 |
starseeker |
I'm not sure
if it was pulling in system itcl or not |
| 15:16.09 |
starseeker |
those friggin
auto_path settings make it problematic |
| 15:16.28 |
brlcad |
dli: atually
the suggestion was based purely on your interest and background --
otherwise, I would have suggested something much smaller to start
with :) |
| 15:16.38 |
brlcad |
starseeker:
did it work once installed? |
| 15:16.39 |
starseeker |
but the gui
issue at least was clear - paths were set to build dir, files were
in src dir - boom |
| 15:17.02 |
starseeker |
didn't try an
install - was working on regress - but I would expect that it
did |
| 15:17.25 |
brlcad |
k |
| 15:17.29 |
brlcad |
I'll run a
test here too |
| 15:17.47 |
brlcad |
if install
works, then I can at least still tag release |
| 15:18.17 |
starseeker |
I'm trying to
wait for the switch to cmake to really mess with the auto_path
settings - they should really simplify down now that we're
duplicating the install layout everywhere |
| 15:18.42 |
brlcad |
true, but it
also needs to be relocatable |
| 15:18.54 |
starseeker |
sure |
| 15:19.05 |
brlcad |
so an
"uninstalled" build tree should also work -- that's the main
concern |
| 15:19.06 |
starseeker |
the CMake
build, in my testing, is already relocatable |
| 15:19.42 |
brlcad |
hm |
| 15:20.05 |
starseeker |
I just meant
we'd have one set of dir paths that list all the tclscripts
subdirs, and then use either build root or install root to id them
for auto_path |
| 15:21.13 |
starseeker |
plus, I've
got to figure out how to strip those /usr/lib based paths out of
the front of the auto_path list |
| 15:22.18 |
brlcad |
it's not
build or install root, it'd be the runtime root for it to be
relocatable |
| 15:22.25 |
starseeker |
er,
right |
| 15:22.40 |
starseeker |
the
bu_brlcad_data/bu_brlcad_root logic |
| 15:22.43 |
brlcad |
k |
| 15:23.28 |
brlcad |
shouldn't
need to strip paths off auto_path -- someone is adding it, that's
the point of attack |
| 15:23.58 |
starseeker |
right - I'm
just concerned it might be tcl itself initializing auto_path to
those values |
| 15:24.04 |
starseeker |
at this point
I don't know |
| 15:24.11 |
brlcad |
sounds to me
like a system pkgIndex.tcl getting loaded |
| 15:24.52 |
starseeker |
uh... it
can't do that until it has paths to load pkgIndex.tcl files from -
that's why it needs that C init process |
| 15:25.23 |
brlcad |
sure, but
there are the built-ini *_Init() routines in the libraries that are
loaded |
| 15:25.37 |
starseeker |
nods |
| 15:25.39 |
brlcad |
if it pulls a
system .so, then it conceivably can modify the
auto_path |
| 15:26.36 |
starseeker |
it would help
if there was a debug setting to let us see where package require
was finding its .so files |
| 15:26.46 |
starseeker |
(for a given
package require operation) |
| 15:29.02 |
brlcad |
there are
ways to introspect tcl from the interpreter |
| 15:29.15 |
brlcad |
"info
loaded", "into library" |
| 15:29.31 |
brlcad |
man n
info |
| 15:30.15 |
starseeker |
ah,
excellent |
| 15:30.22 |
brlcad |
"package
names" |
| 15:32.05 |
starseeker |
I have a
hunch my gentoo box has a system itcl/itk that happened to work,
and it found that (since it didn't have the auto_path information
needed to bridge the divide between build and src dirs, based on
the gui behavior) |
| 15:32.39 |
starseeker |
would almost
be better if we could somehow reject libraries not in the "BRL-CAD
expected" location for Tcl packages |
| 15:32.58 |
starseeker |
would avoid
the accidentally, silently working issue |
| 15:54.58 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43559 10/brlcad/trunk/src/mged/ (edsol.c
mged.h): de-const due to possible deletion |
| 16:00.21 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43560 10/brlcad/trunk/src/mged/fbserv.c: Move
the forward declaration into the #if section that uses it, to avoid
the "declared 'static' but never defined" error. |
| 16:08.04 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43561 10/brlcad/trunk/src/proc-db/vegetation.c:
size_t cast fix |
| 16:17.37 |
dloman |
``Erik: I
think i found it. in GSThread::start(), the pthread was being
created in a detached state. In ~GSThread, pthread_join() was
called. According to the man page, calling _join on a detached
thread is a no no. |
| 16:19.09 |
CIA-77 |
BRL-CAD:
03davidloman * r43562 10/geomcore/trunk/src/utility/GSThread.cxx:
Commented out the pthread_join() call in GSThread::~GSThread. Man
page says that a pthread created in a detached state cannot be used
as a sync point via pthread_join() |
| 16:19.24 |
dloman |
see if that
messes anything up on bsd and/or mac |
| 16:29.39 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:39.39 |
CIA-77 |
BRL-CAD:
03davidloman * r43563 10/geomcore/trunk/src/utility/GSUuid.cxx: Fix
a bug where the buffer used to export the uuid was being free'd
prior to that buffer being used to generate a
std::string. |
| 17:18.06 |
dli |
brlcad, yes,
I'm still interested on the NURB intersection part. I will have
more time now to work on it. Had to go to hospital often in past
weeks |
| 17:19.38 |
dli |
brlcad, at
this stage, I'm still reading through the ON wiki: http://wiki.mcneel.com/developer/opennurbs/home |
| 17:20.11 |
dli |
brlcad,
still, I will report my success as well as my failure to you when
it's time |
| 17:21.18 |
brlcad |
naturally,
I'd hope we can choose the best development path so we achieve
success instead of failur ;) |
| 17:22.02 |
brlcad |
that might
mean not biting on one of the hardest problems first, there are
lots of places where some progress could be made that would help
get you familiarized with the source code |
| 17:23.16 |
dli |
brlcad, sure,
through evolution is good, but the code base overall is huge, it
might easier for me to start by writing something new |
| 17:24.04 |
brlcad |
new vs old
isn't as important as starting with something very
small |
| 17:24.25 |
brlcad |
nurbs
intersection is not small ... |
| 17:24.38 |
dli |
brlcad, if
you can point to some place, I would be glad to see whether I can
fix some small things in parallel with my intersection
problem |
| 17:24.48 |
brlcad |
so that was
probably over-ambitious without having touched any other
code |
| 17:26.33 |
CIA-77 |
BRL-CAD:
03brlcad * r43564 10/brlcad/trunk/doc/README.Linux: include
instructions to force 32-bit on platforms that default to 64-bit as
well. |
| 17:26.47 |
brlcad |
hm, something
came up just this week that is a nice small task |
| 17:27.23 |
brlcad |
and it's in a
similar section of library code as the brep/nurbs
primitive |
| 17:27.28 |
brlcad |
the revolve
primitive |
| 17:28.57 |
dli |
brlcad,
sounds good. is there a bug tracking thread for this
task? |
| 17:29.06 |
brlcad |
basically,
it's a very new primitive so it doesn't yet have support for matrix
transformations (scaling, translation, rotation) |
| 17:29.46 |
brlcad |
support for
matrix transforms is in one function, which revolve doesn't
presently implement |
| 17:30.12 |
brlcad |
https://sourceforge.net/projects/brlcad/forums/forum/362510/topic/4372998 |
| 17:30.49 |
brlcad |
that's merely
a day or two project, unlike nurbs which is several weeks
:) |
| 17:31.34 |
dli |
brlcad, so,
rt_generic_xform(), that's specific enough for me. I will report
what I can do later |
| 17:31.53 |
brlcad |
rt_generic_xform() isn't sufficient, which
was my last comment |
| 17:32.13 |
brlcad |
have to
implement rt_revolve_xform() similar to
rt_extrude_xform() |
| 17:32.46 |
brlcad |
src/librt/primitives/revolve/revolve.c and
src/librt/primitives/extrude/extrude.c respectively, with the
function listed in src/librt/primitives/table.c |
| 17:33.00 |
dli |
brlcad, I get
some rough idea about what's needed here, need to read the code
first |
| 17:33.40 |
CIA-77 |
BRL-CAD:
03brlcad * r43565
10/brlcad/trunk/src/other/tkhtml/Makefile.am: |
| 17:33.40 |
CIA-77 |
BRL-CAD: the
clean rule was overriding autoconf's default clean rule, which
calls |
| 17:33.40 |
CIA-77 |
BRL-CAD:
clean-am. this should fix the build where you follow a 32-bit build
with a |
| 17:33.40 |
CIA-77 |
BRL-CAD:
64-bit built and vice versa. stale .o build files were getting left
in the |
| 17:33.40 |
CIA-77 |
BRL-CAD:
.libs dir causing the build to halt. |
| 17:33.53 |
brlcad |
working on
that will introduce you to how primitives are implemented, some
basic structures, the callback interface, and some light
math |
| 17:34.03 |
brlcad |
all useful
and relevant for working on nurbs |
| 17:34.21 |
dli |
brlcad, let's
see. :) |
| 17:38.12 |
brlcad |
starseeker:
do you have a clean build? |
| 17:38.24 |
brlcad |
``Erik: when
was the last time you tried a windows build? |
| 17:38.33 |
brlcad |
needs a windows build test |
| 17:38.45 |
brlcad |
mac/linux are
clean here |
| 17:40.24 |
brlcad |
and ``Erik,
what can you tell me about the libtie integration? working on the
writeup |
| 17:48.54 |
``Erik |
tried one
yesterday, broke a lot using msvc8, will try another |
| 17:49.41 |
``Erik |
libtie's
functions are in librt, bots that are oriented or have normals
should pass to tie if you set the rt_min_tie (emulated
rt_min_piece) |
| 17:50.13 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.128.118) |
| 17:50.13 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:50.15 |
``Erik |
the
rt_min_tie is set to 4 billion and some change right now pending
more testing |
| 17:50.15 |
brlcad |
how does one
set rt_min_tie? |
| 17:50.23 |
``Erik |
uh, -c I
think? |
| 17:50.36 |
brlcad |
ah, so it'll
auto-kick over to tie for 4M+ models now |
| 17:51.21 |
``Erik |
4m+ bot
primitives |
| 17:51.28 |
brlcad |
right,
okay |
| 17:51.32 |
``Erik |
0xffffffff |
| 17:51.39 |
brlcad |
ah,
heh |
| 17:52.09 |
brlcad |
interesting,
so no way to turn it off then or is 0 special? :) |
| 17:52.19 |
``Erik |
from when
that was an int, not a size_t |
| 17:54.01 |
brlcad |
and rough
performance impact on a 4M model is what? 10%-500%? average
50%? |
| 17:55.06 |
``Erik |
didn't have a
4m primitive, at ~2000 it was 200% (100% gain), 200 was like 150%
(+50%), 12 was 70% (-30%) |
| 17:56.01 |
brlcad |
so on a real
model, should see the time about cut in half |
| 17:56.43 |
``Erik |
that was
tesselating a sphere, the 'real' models I tried were tesselations
of lots of arbs, not NURBS tesselations from an
importer |
| 17:57.03 |
``Erik |
the benchmark
numbers were from tesselated spheres |
| 17:57.37 |
``Erik |
jabs cia |
| 17:58.17 |
``Erik |
0 disables
tie as of 6 minutes ago |
| 17:59.01 |
brlcad |
hehe,
awesome |
| 17:59.39 |
brlcad |
so I'll run a
quick test on some bot model I have, see what things look
like |
| 18:00.07 |
``Erik |
there're a
couple rough edges that need cleaned up before I'm comfortable
impacting customers with it |
| 18:00.13 |
brlcad |
any other
caveats or useful info other than maybe not so hot for tiny
models? |
| 18:00.36 |
``Erik |
on occasion,
it misses :D |
| 18:00.47 |
brlcad |
rt_min_tie is
coming up empty, what's the real name? :) |
| 18:01.13 |
``Erik |
rt_bot_mintie |
| 18:01.23 |
brlcad |
thx |
| 18:01.24 |
``Erik |
(to mimic
rt_bot_minpieces) |
| 18:05.36 |
CIA-77 |
BRL-CAD:
03brlcad * r43566 10/brlcad/trunk/TODO: |
| 18:05.36 |
CIA-77 |
BRL-CAD: attr
command now sorts alphabetically, but then other users
reportedly |
| 18:05.36 |
CIA-77 |
BRL-CAD:
also/still want sorting based on creation order (because it makes
it easy to |
| 18:05.36 |
CIA-77 |
BRL-CAD: diff
and/or find new additions. need a sorting option. kicking off an
EDITOR |
| 18:05.36 |
CIA-77 |
BRL-CAD:
should now be better too now that the invocation has been
re-reviewed recently. |
| 18:10.12 |
``Erik |
script.c:1414: warning: comparison between
signed and unsigned |
| 18:10.19 |
``Erik |
src/remrt/remrt.c:752: warning: comparison
between signed and unsigned |
| 18:11.10 |
CIA-77 |
BRL-CAD:
03brlcad * r43567 10/brlcad/trunk/TODO: WE ARE FREE OF COMPILATION
WARNINGS! woot. |
| 18:14.51 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43568
10/brlcad/trunk/src/librt/primitives/bot/bot.c: rt_bot_mintie=0 now
means do not use tie |
| 18:16.43 |
brlcad |
my 752 is an
FD_MOVE line.. doesn't seem right |
| 18:17.11 |
``Erik |
I know, I've
been grepping around, fbsd might have a bad header |
| 18:17.41 |
brlcad |
maybe line
index from 0 and it's complaining about the tcp_listen_fd int
fd |
| 18:19.29 |
``Erik |
oohhhhh |
| 18:20.42 |
``Erik |
got
it |
| 18:21.15 |
``Erik |
(#ifndef
FD_MOVE ... we had our own for os's like fbsd which don't
provide) |
| 18:21.54 |
brlcad |
interesting |
| 18:24.38 |
brlcad |
looks like
rt_bot_mintie is only exposed via mged tcl var, not -c |
| 18:25.42 |
``Erik |
hm, I used
rt_bot_minpieces as a template, thought the librt tcl.c was called
on rt's startup |
| 18:26.04 |
brlcad |
i added
it |
| 18:26.34 |
brlcad |
it is a tcl
var inside the tcl interp that libtcl has running, but that's not
exposed to rt |
| 18:26.53 |
brlcad |
they are
manually wired to the global |
| 18:27.07 |
``Erik |
ah |
| 18:27.56 |
``Erik |
win32 just
built, had to remove regex.h from raytrace.h (or update the include
paths for most projects) and add ws2_32.lib to a handful of
converters |
| 18:29.55 |
brlcad |
yeah, regex.h
inside raytrace.h doesn't sound like a good idea |
| 18:30.14 |
brlcad |
should be an
implementation detail, not public api requirement |
| 18:31.30 |
brlcad |
poor
CIA-77 |
| 18:31.39 |
starseeker |
``Erik: guess
you're right, I'll have to do the void thing |
| 18:32.56 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43569 10/brlcad/trunk/include/raytrace.h:
conditionalize regex.h |
| 18:35.04 |
starseeker |
brlcad: I'm
still getting failures on Mac with script.c from
src/tab |
| 18:35.16 |
starseeker |
script.c:33:5: error: "__STDC_VERSION__"
is not defined |
| 18:35.26 |
starseeker |
script.c: In
function ‘yy_get_next_buffer’: |
| 18:35.27 |
starseeker |
script.c:1389: warning: comparison between
signed and unsigned |
| 18:40.38 |
``Erik |
the windows
comment in rt/do.c is due to "initializer not static". might need
to assign those in cm_set() as a runtime dealie |
| 18:41.05 |
brlcad |
aha, that
makes more sense |
| 18:41.16 |
brlcad |
those
variables are in librt, so it can't bind them |
| 18:41.22 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43570 10/brlcad/trunk/include/raytrace.h: remove
regex.h for now, windows would need most vcproj files
updated. |
| 18:41.24 |
brlcad |
dll import
suckage |
| 18:46.44 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43571 10/brlcad/trunk/src/remrt/remrt.c: fdset
uses unsigned, so fix if we need FD_MOVE defined |
| 18:52.33 |
CIA-77 |
BRL-CAD:
03brlcad * r43572 10/brlcad/trunk/src/rt/do.c: add support for -c
rt_bot_mintie |
| 18:53.22 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43573 10/brlcad/trunk/misc/win32-msvc8/ (5 files
in 5 dirs): link ws2_32.lib for ntohl/htonl |
| 19:00.18 |
CIA-77 |
BRL-CAD:
03brlcad * r43574 10/brlcad/trunk/src/nirt/ (command.c nirt.c
nirt.h): add support for setting rt_bot_mintie from within nirt,
similar to rt_bot_minpieces. add new -T option in addition to new
bot_mintie nirt command. |
| 19:08.24 |
CIA-77 |
BRL-CAD:
03brlcad * r43575 10/brlcad/trunk/NEWS: added -T and bot_mintie
options to nirt that correspond with controlling when erik's new
support for optimized BoT raytacing kicks on |
| 19:12.50 |
CIA-77 |
BRL-CAD:
03brlcad * r43576 10/brlcad/trunk/src/rt/do.c: expand the comment
now that the cause is known. need to set during runtime, not
compiletime. |
| 19:13.28 |
CIA-77 |
BRL-CAD:
03brlcad * r43577 10/brlcad/trunk/misc/win32-msvc/CMakeLists.txt:
back to not needing libregex search dir |
| 19:25.46 |
CIA-77 |
BRL-CAD:
03brlcad * r43578 10/brlcad/trunk/NEWS: (log message
trimmed) |
| 19:25.46 |
CIA-77 |
BRL-CAD:
reword tie integration from user-visible perspective. erik
integrated the |
| 19:25.46 |
CIA-77 |
BRL-CAD:
former 'libtie' high-performance triangle intersection engine (tie)
into librt |
| 19:25.46 |
CIA-77 |
BRL-CAD: as a
way to get optimized BoT raytracing. initial results showing a
halfing |
| 19:25.46 |
CIA-77 |
BRL-CAD:
reduction of raytrace time for models at 2k+ triangles. erik added
an |
| 19:25.47 |
CIA-77 |
BRL-CAD:
'rt_bot_mintie' option (exposed via mged and rt -c) for toggling
when the |
| 19:25.48 |
CIA-77 |
BRL-CAD:
optimization kicks in. currently set really high at 4M until
further testing |
| 19:41.00 |
CIA-77 |
BRL-CAD:
03starseeker * r43579 10/brlcad/branches/cmake/src/
(libged/search.c librt/search.c): |
| 19:41.01 |
CIA-77 |
BRL-CAD: Not
in final form yet (for one thing, the regex in db_plan_t will have
to become |
| 19:41.01 |
CIA-77 |
BRL-CAD: void
and be cast as needed) but this can run searches now. Can't be
committed |
| 19:41.01 |
CIA-77 |
BRL-CAD: to
trunk until after release in this form, but committing now in cmake
to have |
| 19:41.01 |
CIA-77 |
BRL-CAD: it
checked in somewhere |
| 19:45.23 |
CIA-77 |
BRL-CAD:
03starseeker * r43580 10/brlcad/branches/cmake/src/libged/search.c:
Whoops, need memory here too. |
| 19:52.04 |
dloman |
brlcad: do we
have any Display port to DVI or VGA adapters around the
office? |
| 19:52.10 |
dloman |
(if yo uknow
off hand) |
| 19:53.17 |
CIA-77 |
BRL-CAD:
03starseeker * r43581 10/brlcad/branches/cmake/ (include/raytrace.h
src/librt/search.h): Stick regex in the private search header for
now... |
| 20:23.41 |
starseeker |
``Erik: bob
says tcl is wonderful |
| 20:24.22 |
``Erik |
especially on
windows? |
| 20:25.54 |
starseeker |
heh |
| 20:51.56 |
CIA-77 |
BRL-CAD:
03starseeker * r43582 10/brlcad/branches/cmake/ (4 files in 3
dirs): This approach keeps the plan data structure out of
raytrace.h, and thus isolates regex. |
| 21:43.55 |
CIA-77 |
BRL-CAD:
03starseeker * r43583 10/brlcad/branches/cmake/ (23 files in 16
dirs): MFC r43582 |
| 21:48.02 |
*** join/#brlcad ``Erik_
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 21:58.38 |
CIA-77 |
BRL-CAD:
03starseeker * r43584 10/brlcad/trunk/ (7 files in 3 dirs): Put the
new search routines into trunk |
| 21:59.05 |
brlcad |
hope you
cross-compile tested that :) |
| 22:00.39 |
starseeker |
brlcad: just
mac so far - working on it |
| 22:00.55 |
starseeker |
had to
re-implement the search . ... stuff |
| 22:01.03 |
starseeker |
I think it
behaves the way you wanted it to now |
| 22:01.16 |
*** join/#brlcad Klebel
(~mk@169.229.55.243) |
| 22:02.11 |
brlcad |
I actually
just hope it works with it being injected right before the release,
and isn't like that nirt "fix" made right before
release |
| 22:02.32 |
starseeker |
brlcad:
sorry, I know it's a rotten time... |
| 22:02.56 |
starseeker |
I can back it
out in trunk and just work in cmake branch |
| 22:03.49 |
CIA-77 |
BRL-CAD:
03starseeker * r43585 10/brlcad/branches/cmake/src/ (4 files in 2
dirs): MFC r43584 |
| 22:03.53 |
brlcad |
committing is
fine, you should just be extra care and be testing more than
usual |
| 22:04.24 |
starseeker |
nods - it's hot off the press, I just now got it running, so
I'm starting the testing now |
| 22:05.03 |
starseeker |
if you've got
a working compile, you might check if the new behavior of (say)
search . -maxdepth=0 does what you expect |
| 22:05.34 |
starseeker |
I think we
can squash that TODO item, but since you spotted the issue
confirmation would be good :-) |
| 22:05.58 |
brlcad |
I can check
it (and you should too given the timing) |
| 22:06.04 |
starseeker |
oh, I
am |
| 22:06.41 |
starseeker |
I just ment I
wanted to make sure I had the behavior you wanted, given how hard
you had to work to explain it to me :-P |
| 22:07.44 |
brlcad |
at release
time, it becomes more like how trunk development used to be --
trunk HEAD should be treated like stable: changes tested on
multiple platforms before commit, runtime tested on
everything |
| 22:07.49 |
brlcad |
I
know |
| 22:08.12 |
brlcad |
I mean "you
too" should be making extra sure that all of search still works,
maybe run through the documented examples |
| 22:08.20 |
brlcad |
not just the
new feature |
| 22:08.21 |
starseeker |
ah |
| 22:08.26 |
starseeker |
gotcha |
| 22:09.50 |
starseeker |
how |
| 22:09.59 |
starseeker |
bot.c isn't
happy |
| 22:11.13 |
brlcad |
ah right,
warnings |
| 22:11.22 |
brlcad |
compile had
-w in effect |
| 22:11.53 |
brlcad |
perfect
example :) |
| 22:13.34 |
starseeker |
got those,
moving on... |
| 22:15.53 |
brlcad |
you mean you
already got those? |
| 22:17.35 |
starseeker |
think so -
just remove the unused and cast to size_t for
comparisons |
| 22:17.53 |
starseeker |
(don't want
to mess with bot->faces... types right now) |
| 22:18.26 |
brlcad |
have them
fixed here too |
| 22:19.21 |
starseeker |
ah - feel
free to stomp mine |
| 22:19.35 |
brlcad |
yours matched
mine |
| 22:19.40 |
starseeker |
cool |
| 22:19.48 |
brlcad |
but you
apparently weren't getting unused var warnings like I have
here |
| 22:20.00 |
starseeker |
really? you
got more? |
| 22:20.05 |
brlcad |
yep |
| 22:20.09 |
starseeker |
weird |
| 22:20.25 |
brlcad |
to be
expected |
| 22:21.32 |
brlcad |
one of the
lessons from all the cleanup is that even minor version number
differences in gcc result in different warnings, along with changes
to compilation options, 32-bit vs 64-bit, optimized vs
non-optimized |
| 22:22.24 |
brlcad |
and they're
not a combination that is exactly a superset, so there ends up
being something like 3! possible configurations |
| 22:22.35 |
brlcad |
3! or
4! |
| 22:25.04 |
starseeker |
nods |
| 22:30.06 |
_psilva |
:( |
| 22:30.21 |
starseeker |
_psilva:
? |
| 22:35.17 |
starseeker |
brlcad: my
mac compile is still failing in src/tab on script.c |
| 22:37.14 |
starseeker |
search
completes all the examples from the man page on
potential |
| 22:38.23 |
starseeker |
brlcad: what
version of flex and bison (or lex/yacc) are you working
with? |
| 22:55.22 |
starseeker |
oh,
right |
| 22:55.34 |
starseeker |
can't really
test well on the mac because of that messed up install |
| 22:59.44 |
starseeker |
with
autotools anyway... |
| 22:59.57 |
starseeker |
search looks
ok with the cmake build on the mac |
| 23:16.15 |
CIA-77 |
BRL-CAD:
03starseeker * r43586 10/brlcad/trunk/src/libged/search.c: Re-add
support for the '.' option (e.g. search . -name s*) but this time
do it at the ged level with post-processing of the full search.
Also doesn't print the leading '/' character for the '.'
searches. |
| 23:17.27 |
CIA-77 |
BRL-CAD:
03brlcad * r43587 10/brlcad/trunk/src/conv/patch/patch-g.c: curious
that thick_no only shows up as a potential longjmp clobber var when
compiling in 32-bit mode |
| 23:17.47 |
CIA-77 |
BRL-CAD:
03brlcad * r43588 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
damnits, found a bug during release testing. disable the
optimization so release can proceed. |
| 23:17.51 |
CIA-77 |
BRL-CAD:
03brlcad * r43589 10/brlcad/trunk/TODO: resolve the crash
post-release |
| 23:22.18 |
CIA-77 |
BRL-CAD:
03starseeker * r43590
10/brlcad/trunk/src/librt/primitives/bot/bot.c: Clear some warnings
on bot.c |
| 23:24.29 |
CIA-77 |
BRL-CAD:
03brlcad * r43591 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
quell unused var warnings for the non-optimized case. split vars
across impls. |
| 23:26.07 |
_psilva |
gdc crunch
sucks |
| 23:26.45 |
_psilva |
need more
comp days from this |
| 23:32.00 |
*** join/#brlcad Klebel
(~mk@w72.RIC.Berkeley.EDU) |
| 23:53.03 |
brlcad |
sushi:~
morrison$ flex --version |
| 23:53.03 |
brlcad |
flex
2.5.35 |
| 23:53.03 |
brlcad |
sushi:~
morrison$ bison --version |
| 23:53.03 |
brlcad |
bison (GNU
Bison) 2.3 |
| 00:20.51 |
starseeker |
will have to test with newer versions on mac to see if it
makes a difference |
| 00:23.45 |
CIA-77 |
BRL-CAD:
03starseeker * r43592 10/brlcad/branches/cmake/ (5 files in 4
dirs): MFC r43591 |
| 00:28.44 |
CIA-77 |
BRL-CAD:
03starseeker * r43593 10/brlcad/trunk/src/libged/search.c: gentoo
wants search_results initialized |
| 00:33.39 |
brlcad |
that's just
fantastic.. mged crash |
| 00:34.03 |
starseeker |
winces - what's the issue? |
| 00:34.14 |
brlcad |
don't know
yet, just crashed opening an nmg |
| 00:34.19 |
starseeker |
ah |
| 00:34.30 |
starseeker |
fwiw - search
seems to be working on gentoo |
| 00:55.57 |
brlcad |
excellent |
| 01:07.46 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 02:49.35 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 02:49.35 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release prep for 7.18.2 under way
(20110202) |
| 02:51.00 |
starseeker |
nods - I'll have to look at the current tests and see what he
got running |
| 02:51.17 |
starseeker |
he breaks
things out into analytical and numerical categories in the wiki
page |
| 02:51.57 |
starseeker |
I'm assuming
numerical would involve either floating point or some form of
quantizing |
| 02:55.44 |
starseeker |
huh - looks
numerical... |
| 03:04.01 |
starseeker |
wait...
gecode has a flatzinc support setup, which does have some sort of
Float support... |
| 03:51.28 |
CIA-77 |
BRL-CAD:
03brlcad * r43594 10/brlcad/trunk/NEWS: release write-up on the
integration of TIE with LIBRT and the new shp-g shapefile
importer. |
| 04:10.03 |
CIA-77 |
BRL-CAD:
03brlcad * r43595 10/brlcad/trunk/BUGS: encountered an infinite
loop bug trying to smooth a bot. might be the same traversal bug
encountered earlier, but needs testing / investigating. |
| 04:42.01 |
brlcad |
``Erik_:
harrumph.. I can't seem to get a render through to the tie
code |
| 04:42.35 |
brlcad |
created a
volume bot, smoothed it, rh orientation, mintie set to 1 .. still
kicks over to old way |
| 04:42.41 |
brlcad |
any
suggestions? |
| 04:42.51 |
*** join/#brlcad yukonbob
(~bch@S0106002129e399fc.ok.shawcable.net) |
| 04:42.53 |
yukonbob |
oh
hai |
| 04:42.56 |
brlcad |
howdy |
| 04:43.31 |
yukonbob |
my
friend. |
| 04:43.35 |
yukonbob |
how're
things? |
| 04:44.31 |
brlcad |
crazy busy,
trying to push a release out and hitting speed bumps left and
right |
| 04:44.33 |
brlcad |
bbl |
| 04:46.03 |
yukonbob |
working through a bump w/ .2 current release +
tk... |
| 04:49.20 |
``Erik_ |
does it prep
for tie? I may've borked some logic... |
| 04:49.50 |
yukonbob |
``Erik_: that
for me? |
| 04:50.14 |
``Erik_ |
no, unless
you're trying to do bot/tie raytracing |
| 04:50.16 |
brlcad |
``Erik_: prep
is where I've added some debug and it's not getting
there |
| 04:50.48 |
yukonbob |
stands back from the prep ties. |
| 04:51.05 |
``Erik_ |
hm, bot.c:208
is untested logic... I can look tomorrie |
| 04:51.44 |
CIA-77 |
BRL-CAD:
03brlcad * r43596 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
commit the debug code so it's clear what's going on with the tie
integration |
| 04:53.07 |
``Erik_ |
should be in
really early tomorrow, so I'll be able to crank up the tunes, chill
the office and be somewhat productive |
| 05:38.10 |
yukonbob |
brlcad: can I
squeak in a patch for configure? |
| 05:38.48 |
yukonbob |
will see if still has commit bit... |
| 05:54.24 |
CIA-77 |
BRL-CAD:
03bharder * r43597 10/brlcad/trunk/configure.ac: Direct use of
interp->result is deprecated; Use
Tcl_GetStringResult(). |
| 06:05.04 |
yukonbob |
I'll look for
more later... is not an immediate problem, but will be in
future. |
| 06:32.15 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 06:47.18 |
brlcad |
``Erik: nod,
i'll be in probably late morning after a package arrives, but will
poke at it some more with the debugger |
| 06:47.41 |
brlcad |
addressing a
couple other bugs at the moment too |
| 06:49.36 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.12.71) |
| 06:49.36 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:52.21 |
CIA-77 |
BRL-CAD:
03brlcad * r43598 10/brlcad/trunk/TODO: |
| 06:52.21 |
CIA-77 |
BRL-CAD:
bio.h header was de-netted, bin.h added. found a few other
show-stoppers, |
| 06:52.21 |
CIA-77 |
BRL-CAD:
though. nmg is busted due to a host/net bug. have to test tie
optimization for |
| 06:52.21 |
CIA-77 |
BRL-CAD:
release notes (as it's the major highlight). search implements '.'
so it needs |
| 06:52.21 |
CIA-77 |
BRL-CAD: a
quick test. and finally, verify red/ted work since tom is reporting
a failure |
| 06:52.22 |
CIA-77 |
BRL-CAD: in
.2 with red. |
| 07:15.15 |
brlcad |
it looks like
the tclvar hook into rt_bot_mintie isn't sticking if set from
mged |
| 07:16.59 |
brlcad |
heh, got it
to go in and it crashed |
| 07:17.32 |
brlcad |
(during
prep) |
| 07:20.10 |
brlcad |
aha, possibly
completely unrelated! |
| 07:33.36 |
brlcad |
ooor, maybe
it is related.. |
| 07:36.53 |
yukonbob |
getting build failure on ./src/libbu/bitv.c, w/ "array
subscript has type 'char'" at lines 251, 255... |
| 07:37.03 |
yukonbob |
also hitting hay.... ciao. |
| 07:44.16 |
CIA-77 |
BRL-CAD:
03brlcad * r43599 10/brlcad/trunk/src/librt/primitives/bot/btg.c:
not sure if this is right, but it takes care of rt bombing out with
a bad matrix during do_ae() due to zero-sized bounding
box |
| 07:53.02 |
CIA-77 |
BRL-CAD:
03brlcad * r43600 10/brlcad/trunk/src/rt/do.c: add a sanity check
in case code ends up computing an empty bounding box, so we don't
bomb out during bn_mat_inv(). make sure the viewsize is at least
not zero. |
| 07:53.59 |
brlcad |
that takes
care of the crash and bomb, but still no picture, reports invalid
segments |
| 08:14.35 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 10:24.35 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 11:28.17 |
CIA-77 |
BRL-CAD:
03starseeker * r43601 10/brlcad/branches/cmake/CMakeLists.txt: New
policy in 2.8.4 - we prefer the old behavior for now |
| 11:31.39 |
CIA-77 |
BRL-CAD:
03starseeker * r43602
10/brlcad/branches/cmake/src/other/libutahrle/ (4 files in 2 dirs):
Can't lean on the BRL-CAD checks for subdirs now - utah needs
M_LIBRARY |
| 11:33.40 |
CIA-77 |
BRL-CAD:
03starseeker * r43603 10/brlcad/branches/cmake/ (9 files in 4
dirs): MFC r43602 |
| 11:36.33 |
dloman |
Merning
all |
| 11:37.04 |
CIA-77 |
BRL-CAD:
03starseeker * r43604 10/brlcad/trunk/src/rt/do.c: Comment needs
terminating |
| 11:43.35 |
CIA-77 |
BRL-CAD:
03starseeker * r43605
10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: gentoo seems
to want cmax initialized - hopefully max is ok... |
| 11:45.59 |
CIA-77 |
BRL-CAD:
03starseeker * r43606
10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: initalize points in
dsp |
| 11:48.07 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
| 11:54.28 |
starseeker |
O.o |
| 11:54.34 |
starseeker |
src/librt/primitives/extrude/extrude.c: In
function ?classify_sketch_loops?: |
| 11:54.34 |
starseeker |
src/librt/primitives/extrude/extrude.c:394:
error: ?center2d? may be used uninitialized in this
function |
| 11:54.37 |
starseeker |
src/librt/primitives/extrude/extrude.c:1509:
note: ?center2d? was declared here |
| 11:54.39 |
starseeker |
src/librt/primitives/extrude/extrude.c:394:
error: ?rb? may be used uninitialized in this function |
| 11:54.42 |
starseeker |
src/librt/primitives/extrude/extrude.c:1507:
note: ?rb? was declared here |
| 11:54.43 |
dloman |
``Erik: Hey
man, is there still a tiny proxy running somewhere on seans
box? |
| 11:54.45 |
starseeker |
src/librt/primitives/extrude/extrude.c:394:
error: ?ra? may be used uninitialized in this function |
| 11:54.48 |
starseeker |
src/librt/primitives/extrude/extrude.c:1507:
note: ?ra? was declared here |
| 11:54.49 |
starseeker |
that's got me
puzzled |
| 11:55.04 |
dloman |
that is
pretty wierd? |
| 11:55.11 |
dloman |
oops
:/ |
| 11:56.01 |
starseeker |
unless I'm
missing something, line 394 doesn't have center2d in it |
| 12:02.32 |
dloman |
starseeker:
in fn isect_2D_loop_ray(..) on line 1545, isect_line_earc(..) is
called and center2d is passed in. |
| 12:03.25 |
dloman |
isect_line_earc(..) in turn calls
isect_line2(..), again passing in center2d |
| 12:03.39 |
starseeker |
but at that
point... why is it reporting uninitalized? |
| 12:03.45 |
dloman |
and line 394
is in isect_line2_ellipse() |
| 12:04.22 |
starseeker |
I tried a
V2SET on center2d right after it's declared, and it changes
nothing |
| 12:05.31 |
dloman |
....so that
means what? center2d is initialized? |
| 12:06.18 |
starseeker |
it means I
don't know what to do to convince the compiler it is
initialized |
| 12:07.57 |
starseeker |
even better,
it's only on the static build |
| 12:08.05 |
starseeker |
they dynamic
lib succeeds |
| 12:08.44 |
dloman |
nice. |
| 12:09.01 |
dloman |
well, outside
of tracing things visually, im of no use :) |
| 12:09.50 |
starseeker |
the only
difference I see in the extruce.o compile lines is the presence of
-Dlibrt_EXPORTS in the dynamic line |
| 12:11.01 |
starseeker |
no, that's
not it... |
| 12:11.03 |
starseeker |
what am I
missing |
| 12:14.24 |
``Erik |
<PROTECTED> |
| 12:14.29 |
starseeker |
oh
-fPIC |
| 12:16.41 |
starseeker |
I don't
believe it |
| 12:16.45 |
starseeker |
-fPIC is the
difference |
| 12:16.51 |
starseeker |
why would
that matter??? |
| 12:17.52 |
starseeker |
gcc version
4.4.5 |
| 12:23.14 |
``Erik |
-fPIC
instructs the linker to generate position independent
code |
| 12:23.27 |
``Erik |
relative
jmp's instead of absolute, etc |
| 12:23.50 |
``Erik |
gcc -E and
gcc -S might be handy if you wanna figure it |
| 12:25.28 |
CIA-77 |
BRL-CAD:
03starseeker * r43607
10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: More
initializations (why doesn't VSETALL get old_pl[3]??) |
| 12:26.45 |
CIA-77 |
BRL-CAD:
03starseeker * r43608
10/brlcad/trunk/src/librt/primitives/nmg/nmg_plot.c: another
initialization |
| 12:27.32 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43609
10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: force
cmin/cmax using VSETALL. This should be unnecessary, but some
compiler/OS combinations aren't smart enough to catch "int a;
if(something) a=0; else a=1;" and assume a is unset. |
| 12:28.15 |
CIA-77 |
BRL-CAD:
03starseeker * r43610
10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: whoops, plane
not point |
| 12:28.28 |
``Erik |
the amin vs
min in btg.c was important, they're different numbers :/ (actual
geometric min vs fpu friendly padding min, iirc) |
| 12:33.41 |
CIA-77 |
BRL-CAD:
03starseeker * r43611 10/brlcad/trunk/src/librt/search.c:
initialize new to NULL |
| 12:44.32 |
CIA-77 |
BRL-CAD:
03starseeker * r43612 10/brlcad/branches/cmake/CMakeLists.txt: Hmm
- how did this not trigger before? make sure HAVE_STRINGS_H
actually makes it into brlcad_config.h |
| 12:54.01 |
CIA-77 |
BRL-CAD:
03starseeker * r43613
10/brlcad/branches/cmake/src/librt/CMakeLists.txt: I can't believe
it, but without -fPIC in the static build possibly uninitialized
warnings appear with gcc 4.4.5 on gentoo. Only on
extrude.c |
| 12:58.02 |
CIA-77 |
BRL-CAD:
03starseeker * r43614 10/brlcad/trunk/src/liboptical/sh_toyota.c:
another initialization |
| 13:02.59 |
``Erik |
hm, musta
lost that in merge *sigh* |
| 13:05.18 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43615 10/brlcad/trunk/ (include/tie.h
src/librt/primitives/bot/tie_kdtree.c): remove obsolete kdtree
cache stuff |
| 13:09.38 |
CIA-77 |
BRL-CAD:
03starseeker * r43616
10/brlcad/branches/cmake/src/conv/intaval/CMakeLists.txt: Use
BRLCAD_ADD_EXEC for tgf-g |
| 13:10.26 |
brlcad |
I'l make sure
you have access to the new server sometime this week |
| 13:11.02 |
brlcad |
after release
is posted |
| 13:12.04 |
CIA-77 |
BRL-CAD:
03starseeker * r43617 10/brlcad/trunk/src/conv/nastran-g.c:
initializations |
| 13:13.43 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43618 10/brlcad/trunk/ (3 files in 2 dirs):
revive the actual min/max (amin/amax) |
| 13:14.12 |
brlcad |
starseeker:
zombie is back to life:
https://sourceforge.net/tracker/?func=detail&atid=640802&aid=3197208&group_id=105292 |
| 13:18.13 |
CIA-77 |
BRL-CAD:
03starseeker * r43619
10/brlcad/branches/cmake/src/conv/iges/CMakeLists.txt: Use
BRLCAD_ADDEXEC for iges |
| 13:21.06 |
CIA-77 |
BRL-CAD:
03starseeker * r43620 10/brlcad/trunk/src/conv/iges/
(conv_drawings.c trimsurf.c): initializations for iges |
| 13:21.18 |
starseeker |
brlcad: oh
god |
| 13:21.22 |
starseeker |
ok, I'll have
a look |
| 13:26.51 |
CIA-77 |
BRL-CAD:
03starseeker * r43621
10/brlcad/trunk/src/librtserver/rtserverTest.c: Quell a few
warnings - rts_clean doesn't seem to be defined
anywhere |
| 13:31.56 |
CIA-77 |
BRL-CAD:
03starseeker * r43622 10/brlcad/trunk/src/anim/anim_hardtrack.c:
initializations for anim |
| 13:32.09 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43623
10/brlcad/trunk/src/librt/primitives/bot/btg.c: woops, point_t, not
TIE_3 |
| 13:36.36 |
CIA-77 |
BRL-CAD:
03starseeker * r43624 10/brlcad/trunk/src/burst/grid.c:
initialization for burst |
| 13:37.56 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43625 10/brlcad/trunk/include/raytrace.h: set
RT_DEFAULT_MINTIE to 0 (disabled) |
| 13:41.46 |
CIA-77 |
BRL-CAD:
03starseeker * r43626 10/brlcad/trunk/src/fbed/fbed.c:
initializations for fbed |
| 13:42.25 |
brlcad |
wishes one of his compilation environments would have picked
up those warnings |
| 13:42.54 |
CIA-77 |
BRL-CAD:
03starseeker * r43627 10/brlcad/trunk/src/gtools/remapid.c:
initialization for remapid |
| 13:46.12 |
CIA-77 |
BRL-CAD:
03starseeker * r43628 10/brlcad/trunk/src/shapes/picket_fence.c:
initialize matrix |
| 13:48.45 |
CIA-77 |
BRL-CAD:
03starseeker * r43629 10/brlcad/trunk/src/util/pixborder.c:
initialize for pixborder |
| 13:49.14 |
starseeker |
finally.
there we go |
| 13:50.18 |
brlcad |
~starseeker++ |
| 13:50.23 |
brlcad |
thanks |
| 13:50.53 |
starseeker |
dingnabbit.
red problem confirmed |
| 13:55.11 |
CIA-77 |
BRL-CAD:
03starseeker * r43630 10/brlcad/branches/cmake/CMakeLists.txt:
Don't care about warnings on the time delta utilties |
| 13:57.15 |
starseeker |
brlcad:
interesting thing about those warnings - they popped up only when I
did a release build - optimizations flags, etc |
| 13:57.31 |
starseeker |
(well, some
of them) |
| 13:59.35 |
``Erik |
um, lots of
funky things go on depending on debug.. like 'HIDDEN' is "" on
debug and "static" in release, etc |
| 14:03.25 |
starseeker |
actually,
cancel that - red problem is NOT confirmed, with one possible
exception |
| 14:03.36 |
starseeker |
you can't
rename the region during a red command |
| 14:03.43 |
starseeker |
other than
that, I have success using it here |
| 14:05.43 |
starseeker |
IIRC, I
decided not to allow changing the object name during a red - it
complicated things a bit |
| 14:07.08 |
brlcad |
starseeker:
heh, I just saw yesterday's commit -- didn't realize that you just
deleted all of those variables :) |
| 14:07.53 |
``Erik |
scrum
~1300 |
| 14:07.59 |
``Erik |
er,
~1330 |
| 14:08.07 |
brlcad |
if it can't
be changed, it should probably not be in the file ... or it should
allow it ;) |
| 14:08.27 |
brlcad |
otherwise
people are going to try |
| 14:08.51 |
brlcad |
shouldn't be
too hard to allow, just keep a copy before and after |
| 14:08.59 |
starseeker |
ugh |
| 14:09.00 |
brlcad |
apply edits
to old, and if name changed, rename |
| 14:10.26 |
brlcad |
interesting
approach to search "." .. I think I like it |
| 14:18.54 |
starseeker |
brlcad:
adding renaming support will take a little time - is that something
you want prior to release? |
| 14:22.37 |
starseeker |
brlcad: if
you decide search looks good we can nuke the TODO item for that
particular tweak and update NEWS - I was waiting until I was sure
it was "done" |
| 14:25.07 |
starseeker |
saddles up |
| 14:40.55 |
brlcad |
starseeker:
if it works, then that's stable for release -- but would you follow
up with tom to see if that's what he was running into? |
| 14:41.45 |
brlcad |
the search
todo is my action to look at since I had that particular
request |
| 15:37.06 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
| 15:38.17 |
CIA-77 |
BRL-CAD:
03tbrowder2 * r43631 10/brlcad/trunk/src/tab/script.l: eliminate
unused function warning |
| 15:55.28 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:33.41 |
starseeker |
brlcad: I
thought I emailed him for more details, but I see it didn't pop
up... |
| 16:34.29 |
starseeker |
huh - sent
over 2 hours ago |
| 16:43.04 |
CIA-77 |
BRL-CAD:
03starseeker * r43632 10/brlcad/branches/cmake/ (21 files in 17
dirs): MFC -r43631 |
| 16:46.58 |
CIA-77 |
BRL-CAD:
03starseeker * r43633 10/brlcad/branches/cmake/CMakeLists.txt:
Lovely - check cmake version before we set CMP0017 |
| 16:55.18 |
starseeker |
heh:
http://spacewar.oversigma.com/ |
| 16:55.47 |
starseeker |
also http://spacewar.oversigma.com/html5/ |
| 16:56.30 |
starseeker |
``Erik:
whadya think, original BRL-CAD on a PDP1 emulator in html5?
:-P |
| 17:00.45 |
``Erik |
I don't think
it ever ran on a pdp1... mebbe an 11/70, though it might need a
vax11/780 by the time it did anything interesting |
| 17:01.09 |
``Erik |
um, jove
appeared in the repo in '83, then mid 85 is when really basic
raytracing started happening |
| 17:02.00 |
``Erik |
the date flag
to svn up makes for some amusing code spelunking if ya find
yourself with a bit of free time :D |
| 17:03.48 |
starseeker |
heh |
| 17:08.12 |
CIA-77 |
BRL-CAD:
03brlcad * r43634
10/brlcad/trunk/src/librt/primitives/nmg/nmg_plot.c: use VINIT_ZERO
macro symbol instead of {0.0, 0.0, 0.0} for point_t/vect_t. less
error-prone, less typing, and supports converion to fixed point
arithmetic down the road. |
| 17:08.39 |
starseeker |
brlcad: oops,
sorry - there'll be a few of those |
| 17:09.13 |
CIA-77 |
BRL-CAD:
03brlcad * r43635
10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: same with
HINIT_ZERO for 4D vector initialization. |
| 17:43.32 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43636
10/brlcad/trunk/src/librt/primitives/bot/btg.c: rewrite prep to be
correct and only make one tie_push call |
| 18:26.59 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43637
10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c:
reincorporate some of the lost changes |
| 21:23.41 |
CIA-77 |
BRL-CAD:
03starseeker * r43638
10/brlcad/branches/cmake/src/mged/points/CMakeLists.txt: Ugh. Go
vanilla with the cflags in points dir until it's clear what the
issue is |
| 21:57.55 |
starseeker |
hmm
http://www.research.ibm.com/haifa/projects/verification/fpgen/papers/plsrange.pdf |
| 22:02.19 |
starseeker |
http://portal.acm.org/citation.cfm?id=1048200 |
| 22:03.19 |
starseeker |
maybe we can
recruit this guy :-) http://johnsogg.blogspot.com/2011_01_01_archive.html |
| 22:16.12 |
starseeker |
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.112.3073 |
| 22:18.41 |
starseeker |
http://code.google.com/p/sketchsolve/ |
| 22:28.59 |
starseeker |
hah, cool -
not related directly to geometric constrants but possibly useful
for other things: http://adaptagrams.sourceforge.net/ |
| 22:38.04 |
starseeker |
reflects that the constraint system is going to require some
paper diving... |
| 22:42.20 |
starseeker |
hmm http://www.cs.purdue.edu/homes/cmh/electrobook/intro.html |
| 23:16.50 |
CIA-77 |
BRL-CAD:
03starseeker * r43639
10/brlcad/branches/cmake/src/conv/step/CMakeLists.txt: Use
BRLCAD_ADDEXEC for step-g |
| 23:17.47 |
CIA-77 |
BRL-CAD:
03starseeker * r43640
10/brlcad/branches/cmake/src/libpc/CMakeLists.txt: Yes boost, we
know, be quiet already |
| 23:21.03 |
CIA-77 |
BRL-CAD:
03starseeker * r43641 10/brlcad/branches/cmake/ (5 files in 3
dirs): |
| 23:21.03 |
CIA-77 |
BRL-CAD:
Rework handling of compile flags - no longer setting strict flags
at the |
| 23:21.03 |
CIA-77 |
BRL-CAD:
individual target levels, since BRL-CAD is going fully strict.
There are a few |
| 23:21.03 |
CIA-77 |
BRL-CAD:
local overrides for issues not yet resolved, but the default will
now be that |
| 23:21.03 |
CIA-77 |
BRL-CAD:
anything new automatically gets the struct flags with all warnings
unless |
| 23:21.03 |
CIA-77 |
BRL-CAD:
options are turned off. |
| 23:25.29 |
CIA-77 |
BRL-CAD:
03starseeker * r43642
10/brlcad/branches/cmake/misc/CMake/test_srcs/time.c.in: Add the
zero for day, not just month. |
| 23:59.25 |
*** join/#brlcad yukonbob_
(~bch@20-144.wireless.kamloops.net) |
| 00:16.22 |
CIA-77 |
BRL-CAD:
03starseeker * r43643 10/brlcad/trunk/src/libged/combmem.c: Do some
initializations for combmem.c, but it's not enough - getting some
more of the weird complaints that identify line numbers that don't
seem directly related to uninitialized aetvec and tvec |
| 00:21.50 |
CIA-77 |
BRL-CAD:
03starseeker * r43644 10/brlcad/trunk/src/libged/combmem.c: This
does it - init 'em all |
| 00:32.38 |
CIA-77 |
BRL-CAD:
03starseeker * r43645 10/brlcad/branches/cmake/src/ (5 files in 3
dirs): MFC r43644 |
| 01:28.27 |
CIA-77 |
BRL-CAD:
03starseeker * r43646 10/brlcad/trunk/ (include/raytrace.h
src/libged/search.c src/librt/search.c): Move the unique object
logic out of libged into a librt function. renaming and cleanup for
clarity, more comments in raytrace.h header. |
| 01:31.22 |
CIA-77 |
BRL-CAD:
03starseeker * r43647 10/brlcad/branches/cmake/ (include/raytrace.h
src/libged/search.c src/librt/search.c): MFC r43646 |
| 01:38.17 |
CIA-77 |
BRL-CAD:
03starseeker * r43648 10/geomcore/trunk/tests/svntest/main.c: Start
laying out the search plan for svn geometry testing. |
| 02:05.27 |
CIA-77 |
BRL-CAD:
03starseeker * r43649 10/brlcad/trunk/src/ (libged/search.c
librt/search.c): Shift responsibility for making the default
toplevel list of objects to librt from libged - this is sensible
default behavior and will save doing this every time search logic
is used to search the whole database. |
| 02:06.54 |
CIA-77 |
BRL-CAD:
03starseeker * r43650 10/brlcad/branches/cmake/src/
(libged/search.c librt/search.c): MFC r43649 |
| 02:08.06 |
CIA-77 |
BRL-CAD:
03starseeker * r43651 10/geomcore/trunk/tests/svntest/main.c: tweak
plan - search should iterate over everything by default
now. |
| 02:34.59 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 06:26.48 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.12.71) |
| 06:26.49 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:57.01 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 09:49.48 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 09:49.49 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release prep for 7.18.2 under way
(20110202) |
| 10:20.45 |
CIA-77 |
BRL-CAD:
03d_rossberg * r43652 10/brlcad/trunk/ (4 files in 4
dirs): |
| 10:20.45 |
CIA-77 |
BRL-CAD:
fixed release 43577 changes "back to not needing libregex search
dir" |
| 10:20.45 |
CIA-77 |
BRL-CAD: -
re-enabled the libregex build |
| 10:20.45 |
CIA-77 |
BRL-CAD: -
removed the unnecessary libregex search dirs |
| 11:51.31 |
CIA-77 |
BRL-CAD:
03starseeker * r43653 10/brlcad/branches/cmake/CMakeLists.txt:
VERSION_GREATER, not GREATER |
| 11:58.45 |
CIA-77 |
BRL-CAD:
03starseeker * r43654
10/brlcad/branches/cmake/misc/CMake/test_srcs/builddelta_end.c.in:
do something with fscanf return to quiet compiler. |
| 12:11.33 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 12:11.33 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release prep for 7.18.2 under way
(20110202) |
| 12:11.43 |
CIA-77 |
BRL-CAD:
03starseeker * r43656
10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: whoops, that
should have been in trunk - init min and max |
| 12:14.37 |
CIA-77 |
BRL-CAD:
03starseeker * r43657 10/brlcad/trunk/include/raytrace.h: comment
tweak |
| 12:40.55 |
CIA-77 |
BRL-CAD:
03starseeker * r43658 10/brlcad/branches/cmake/ (.
include/raytrace.h): fix comment in cmake too |
| 12:59.55 |
CIA-77 |
BRL-CAD:
03starseeker * r43659 10/brlcad/trunk/ (include/raytrace.h
src/libged/search.c src/librt/search.c): Ah, that's better - don't
wipe out the path name list passed to the search functions - that's
the responsibility of the function that created the list. provide
db_free_full_path_list to make that easier. |
| 13:00.40 |
CIA-77 |
BRL-CAD:
03starseeker * r43660 10/brlcad/branches/cmake/ (include/raytrace.h
src/libged/search.c src/librt/search.c): MFC r43659 |
| 14:09.45 |
brlcad |
MISSING from
src/librt/CMakeLists.txt: search.c |
| 14:09.45 |
brlcad |
NEED TO SYNC
CMAKELISTS.TXT |
| 14:10.09 |
starseeker |
once
sec... |
| 14:10.16 |
starseeker |
updates local autotools branch |
| 14:11.49 |
CIA-77 |
BRL-CAD:
03starseeker * r43661 10/brlcad/trunk/src/librt/CMakeLists.txt:
Sync autotools branch CMakeLists.txt file |
| 14:11.54 |
starseeker |
there we
go |
| 14:19.50 |
``Erik |
ponders removing strict from tab since script.c complains on
both osX.6 and fbsd :/ |
| 14:24.14 |
brlcad |
holy shit
that's a lot of "lost changes" erik .. heh |
| 14:24.38 |
brlcad |
some of it is
ws, but a lot not |
| 14:26.45 |
``Erik |
yeah, it was
a merge from trunk that stomped stuff, unfortunately :/ |
| 14:28.07 |
brlcad |
cool,
retesting |
| 14:28.16 |
starseeker |
needs to try compiling d_rossberg's CMake stuff to figure out
what it is/does, and see if it can be made to do that with cmake
branch files - if it can, the new CMake logic can be moved to trunk
(even if it doesn't get enabled as the default
system) |
| 14:28.30 |
brlcad |
starseeker:
r43630 .. heh, there are warnings that were that bad in time
testing code that YOU wrote?? |
| 14:30.00 |
brlcad |
same reason
they're maintenance burden for production code holds true for build
system code too |
| 14:31.40 |
brlcad |
r43607 also
isn't right, it's a hvect, not a vect, so VSETALL doesn't apply
([3] is the fourth H element) |
| 14:33.44 |
starseeker |
brlcad: keep
reading :-) |
| 14:35.17 |
starseeker |
43610 should
fix 43607 |
| 14:36.45 |
starseeker |
and I fixed
the compile warnings on those timing utilities - I took out all the
warning flag suppression for them in one of the later
commits |
| 14:38.07 |
CIA-77 |
BRL-CAD:
03brlcad * r43662
10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: pl is a
plane_t, fix a couple places where it's being treated like it's a
vect_t. |
| 14:43.33 |
brlcad |
I see, there
were still other problems in that file |
| 14:43.50 |
brlcad |
one that
wasn't immediately evident what [H] should be set to |
| 14:44.03 |
starseeker |
nods |
| 14:44.07 |
starseeker |
that is
odd |
| 14:44.48 |
starseeker |
does some of
that nmg code predate the establishment of the plane_t and vect_t
types? |
| 14:45.13 |
brlcad |
not
really |
| 14:45.26 |
starseeker |
sees if 7.18.2 builds... |
| 14:45.42 |
starseeker |
or r43153
anyhow |
| 14:45.49 |
brlcad |
the problem
is probably more code evolution, someone coming in years later and
thinking that a particular fastf_t * was one type vs
another |
| 14:46.57 |
brlcad |
for a long
while, some compilers did not like having vect_t or plane_t listed
as parameters, wanted the untypedef'd type (fastf_t*) |
| 14:47.08 |
brlcad |
even today, I
think some compilers still have a problem with it |
| 14:47.11 |
brlcad |
(gcc) |
| 14:47.24 |
starseeker |
huh |
| 14:47.46 |
brlcad |
ideally
should change those pl parameters to be plane_t, and see who
breaks |
| 14:48.04 |
starseeker |
probably
after release? ;-) |
| 14:48.31 |
brlcad |
43613 (-fPIC)
is concerning up there with r43630 (-w on build
infrastructure) |
| 14:49.03 |
brlcad |
probably,
more like the next time someone is in that file making logic
changes where it can be more carefully tested |
| 14:49.46 |
starseeker |
brlcad: 43613
is beyond my debug skills, at least without putting a lot of time
into it |
| 14:50.07 |
brlcad |
fPIC isn't
going to be valid for some compilers |
| 14:50.20 |
brlcad |
and doesn't
make sense for static code regardless |
| 14:50.56 |
brlcad |
paste the
(actual) compilation line and build failure |
| 14:51.09 |
starseeker |
I'll yank it
- I primarily needed to get by it to do other stuff at the
time |
| 14:51.28 |
starseeker |
build failure
was posted earlier... |
| 14:51.43 |
starseeker |
I don't have
the compilation line handy - it was only on my home gentoo box I
saw the issue |
| 14:52.28 |
brlcad |
kind of
one-liner tweak that gets ignored and is fine for a while, then
bites someone years down the road taking days to debug and
discover |
| 14:53.00 |
brlcad |
having some
issue that's PIC/non-PIC related can be disastrous debugging for
dynamic loading |
| 14:53.15 |
CIA-77 |
BRL-CAD:
03starseeker * r43663
10/brlcad/branches/cmake/src/librt/CMakeLists.txt: remove the fPIC
flag for extrude.c |
| 14:55.55 |
starseeker |
brlcad:
http://pastebin.mozilla.org/1122628 |
| 14:55.57 |
starseeker |
that's the
error |
| 14:56.34 |
brlcad |
can you paste
the whole log, from compile line to the end of the
error? |
| 14:56.47 |
starseeker |
not right now
- I can tonight |
| 14:57.01 |
brlcad |
k |
| 14:57.14 |
brlcad |
ahh, looks
like it's out of date to, line numbers aren't matching
up |
| 14:57.51 |
starseeker |
uh - that was
one of the fun parts of the error - line numbers reported didn't
seem to have anything to do with the variables that might be
unitialized |
| 14:59.51 |
brlcad |
I mean the
easy fix is to initialize all those vars it mentions |
| 14:59.58 |
starseeker |
ah |
| 14:59.59 |
brlcad |
if that's
indeed the issue |
| 15:00.20 |
brlcad |
that might at
least hone the warning to something else, leading towards the root
cause |
| 15:00.56 |
starseeker |
let me see if
a release build here can reproduce it... doubtful but you never
know |
| 15:05.26 |
CIA-77 |
BRL-CAD:
03brlcad * r43664 10/brlcad/trunk/include/vmath.h: add missing
V2INITALL and V2INIT_ZERO macros providing the 2D versions of
VINITALL and VINIT_ZERO |
| 15:06.15 |
CIA-77 |
BRL-CAD:
03brlcad * r43665
10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: initialize
a few 2d vars to zero, just because we like it that way |
| 15:08.26 |
starseeker |
yeah, thought
so - doesn't show up here |
| 15:08.40 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43666
10/brlcad/trunk/src/librt/primitives/bot/tie.c: reincorporate lost
changes |
| 15:10.20 |
CIA-77 |
BRL-CAD:
03brlcad * r43667
10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: slew of
functions not marked static that should be static. make the
compiler's job easier, those functions don't need to be
exported. |
| 15:10.38 |
brlcad |
that will
probably fix the failure between those changes |
| 15:10.48 |
starseeker |
brlcad: cool,
thanks! |
| 15:19.32 |
brlcad |
yeah, reading
through the code, it's looking like there might be some obscure way
that they'd get called without initialization or the compiler was
getting confused by sub-scope variables getting passed in as
arguments to other functions that had parameters with the same
name |
| 15:19.51 |
brlcad |
or it was
cleverly following the call tree use and found some path of
potential uninitialization |
| 15:20.30 |
brlcad |
either way,
the "why" doesn't matter so much in this instance since we can
simply initialize like it's saying we should without
harm |
| 15:20.50 |
starseeker |
nods |
| 15:22.05 |
CIA-77 |
BRL-CAD:
03brlcad * r43668
10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: init ra/rb
to zero too, pull them back up to the top scope since they're
double-declared in the same function. |
| 15:23.26 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43669
10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: get_indices
can't be static, it's also used in sketch |
| 15:23.48 |
cjdevlin |
any chance of
a losethos <http://www.losethos.com/>
port? |
| 15:26.24 |
starseeker |
cjdevlin: I'm
guessing probably not |
| 15:26.37 |
starseeker |
never heard
of it before - how did you come across it? |
| 15:27.25 |
cjdevlin |
i think i got
a new release announcement on a mailing list i am on. it's . . .
interesting |
| 15:27.48 |
starseeker |
it's intended
for recreational programming, not "production" use |
| 15:28.31 |
starseeker |
http://www.losethos.com/doc/Constitution.html
would seem to pretty much rule it out as a worthwhile platform to
port to |
| 15:28.33 |
cjdevlin |
he created a
custom version of c . . . i don't think anything will be ported to
this ever . . . |
| 15:30.23 |
starseeker |
Haiku is a
lot more interesting, but someone(tm) would have to get Tk ported
to their graphics system |
| 15:31.56 |
starseeker |
brlcad got
(iirc) all the non-graphical components of BRL-CAD compiled on
Haiku at one point, including tcl, but Tk is a whole 'nother
animal |
| 15:32.05 |
cjdevlin |
haiku is the
new beos right? |
| 15:34.12 |
starseeker |
pretty
much |
| 15:40.57 |
cjdevlin |
who maintains
the .debs on the brlcad site? |
| 15:40.59 |
starseeker |
winces thinking about a Haiku compile with the new
flags... |
| 15:41.23 |
starseeker |
we've had
some new work done on those recently... |
| 15:42.12 |
starseeker |
don't recall
if we actually got new debs uploaded to sf - the only Debian based
system I have is my laptop, and even there I compile... |
| 15:42.27 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.27.184) |
| 15:42.27 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 15:43.06 |
cjdevlin |
well, here's
the motivation for me asking . . . i am trying to learn how to
program. with some assistance from the people in this room i was
able to get source compiled a few times. i figured working on just
the packaging will be a way to get my feet wet. i am an ubuntu
user, but ubuntu is basically debian. |
| 15:43.18 |
cjdevlin |
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632 |
| 15:43.33 |
cjdevlin |
and it seems
like people have been trying to get it into debian for quite a
while |
| 15:43.51 |
starseeker |
take a look
in misc/debian |
| 15:45.14 |
cjdevlin |
i also don't
want to step on toes or reinvent the wheel if someone is actively
working on it |
| 15:45.15 |
starseeker |
ah, right -
Jordi Sayol |
| 15:45.30 |
starseeker |
back in
January |
| 15:45.54 |
starseeker |
most recent
commit was actually 2/28, so fair to say he's active
:-) |
| 15:46.22 |
cjdevlin |
does he spend
much time here? |
| 15:46.27 |
brlcad |
cjdevlin:
chances are greatly increased if you attempt the port
;) |
| 15:48.16 |
cjdevlin |
brlcad: well
then, based on my current working knowledge of programming and the
graphics libraries available on the target platform: expect commits
around 2020 (ish) :) |
| 15:49.05 |
cjdevlin |
brlcad the
program is only what? a million lines of code? |
| 15:49.25 |
CIA-77 |
BRL-CAD:
03d_rossberg * r43670
10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: export
rt_bot_mintie() for nirt |
| 15:49.53 |
starseeker |
brlcad: I
tried compiling 43153 on Redhat and can't reproduce it |
| 15:51.21 |
brlcad |
cjdevlin:
approximately, yep |
| 15:51.38 |
brlcad |
twice that if
you count all our dependenceis |
| 15:52.07 |
brlcad |
this losethos
guy is pretty awesome |
| 15:52.09 |
brlcad |
hilarious |
| 15:52.34 |
starseeker |
ah
HAH! |
| 15:52.39 |
starseeker |
system regex
doesn't work |
| 15:53.09 |
cjdevlin |
brlcad: isn't
2million the lines of code that run (ran) Jurassic Park :)
? |
| 15:53.46 |
cjdevlin |
he's been
working on it full time for more than 7 years . . . |
| 16:00.14 |
starseeker |
blinks |
| 16:00.20 |
starseeker |
system regex
works with trunk?? |
| 16:03.06 |
brlcad |
define
"works"? |
| 16:03.20 |
brlcad |
should
work.. |
| 16:04.10 |
starseeker |
yes, but that
looks like the change - 7.18.2 failed with system, trunk
succeeds |
| 16:05.21 |
brlcad |
so the good
news is 7.18.2 binaries might not be working if they're enable all,
but an enable all build should work for .2 and trunk |
| 16:05.38 |
brlcad |
er, if
they're NOT enable all |
| 16:06.11 |
starseeker |
right |
| 16:06.13 |
brlcad |
that begs the
question why system regex would fail -- perhaps a non-portable
regex expression being used |
| 16:06.25 |
brlcad |
red/ted use
regex? |
| 16:06.32 |
starseeker |
I am using
some features only supported by newer regex installs |
| 16:06.34 |
starseeker |
yes |
| 16:06.40 |
starseeker |
red does
anyway |
| 16:07.05 |
brlcad |
that should
be easy to fix then |
| 16:07.27 |
starseeker |
uh, define
fix... |
| 16:07.41 |
brlcad |
finds the expressions |
| 16:08.01 |
starseeker |
the part
that's throwing me is it succeeds in trunk |
| 16:08.05 |
brlcad |
there's no
"new" regex feature that isn't supported by older regex in another
form |
| 16:08.18 |
brlcad |
yeah, that's
interesting |
| 16:08.31 |
brlcad |
if trunk
succeeds with system regex, then maybe a red herring |
| 16:08.42 |
starseeker |
wait, let me
try trunk autotools |
| 16:08.43 |
brlcad |
coincidental,
but not the problem |
| 16:08.49 |
starseeker |
right |
| 16:08.59 |
_psilva |
ugh.. cant
login to 'new' account.. i left large corporations to avoid this
crap :( |
| 16:09.15 |
brlcad |
and then got
bought out by one |
| 16:09.26 |
_psilva |
cries |
| 16:09.45 |
brlcad |
president was
a pussy? sold out? |
| 16:10.02 |
_psilva |
he wanted his
millions? |
| 16:10.03 |
_psilva |
heh |
| 16:10.25 |
_psilva |
flash needs
to be replaced ;) |
| 16:11.05 |
brlcad |
join the
html5 committee? |
| 16:11.15 |
_psilva |
we'll
see |
| 16:11.58 |
_psilva |
bunch of
flash 'experts' are moving to html5 |
| 16:12.13 |
_psilva |
and are
implementing similar constructs via js/canvas |
| 16:12.19 |
brlcad |
this Terry
Davis losethos guy is pretty funny, wonder how he had so much time
to dedicate to something like that |
| 16:13.02 |
brlcad |
classic
hacking, for just the hell of it all on his own from
scratch |
| 16:13.42 |
brlcad |
random custom
constructs, caveats, and inconsisties all over the place, but fun
nontheless |
| 16:14.12 |
_psilva |
what's
this? |
| 16:14.15 |
cjdevlin |
it has a cool
flight sim though |
| 16:14.32 |
brlcad |
_psilva:
dude that wrote his own OS http://www.losethos.com/ |
| 16:14.47 |
brlcad |
not general
purpose, just for fun |
| 16:14.49 |
_psilva |
ah |
| 16:15.07 |
brlcad |
the "command
line" is actually a C-variant live interpreter |
| 16:15.26 |
_psilva |
we had quite
a time dealing with the creator of atheos, who's working at funcom
atm |
| 16:16.44 |
_psilva |
wow that's a
lot of effort |
| 16:17.15 |
cjdevlin |
it seems like
you guys are maintaining both autotools and cmake? mind if i ask
why? (purely a personal info question, not trying to start an
argument) |
| 16:17.18 |
brlcad |
all three
videos are pretty intersting |
| 16:17.36 |
brlcad |
cjdevlin:
we're migrating to cmake, but autotools is the oldstay until we
switch |
| 16:17.53 |
brlcad |
years went
into autotools, so it's pretty lock solid, but cmake is the new
coke |
| 16:18.23 |
cjdevlin |
helps the
cross platform effort also? |
| 16:18.30 |
brlcad |
that's the
main motivation |
| 16:18.51 |
_psilva |
did u ever
make a new gui for brlcad? |
| 16:19.00 |
brlcad |
getting a
unified build that'll span linux, mac, other unices, AND windows ..
which has been the lone child out |
| 16:19.14 |
brlcad |
_psilva: two
of them, but both still under development |
| 16:19.21 |
_psilva |
screens? |
| 16:19.35 |
brlcad |
archer is
about to go into alpha |
| 16:19.36 |
brlcad |
http://brlcad.org/tmp/archer.png |
| 16:20.11 |
starseeker |
if I got that
right, r43400 seems to work with system regex |
| 16:20.19 |
_psilva |
interesting..
tcl? |
| 16:20.29 |
brlcad |
http://brlcad.org/~starseeker/archer_latest.png |
| 16:20.37 |
brlcad |
http://brlcad.org/~starseeker/archer_ronja1.png |
| 16:21.40 |
brlcad |
_psilva:
yeah, archer is .. the "3rd gen" one isn't, but the screenshots are
more simple -- pre-pre alpha |
| 16:22.49 |
_psilva |
archer looks
nice |
| 16:22.56 |
_psilva |
better than
what i remember |
| 16:23.07 |
_psilva |
any info on
the 3rd gen ui? |
| 16:23.12 |
brlcad |
_psilva: most
of the time has been spent implementing support for NURBS and STEP,
library and source code refactoring, and the Geometry
Service |
| 16:23.55 |
brlcad |
most of the
GUI things you'd want require robust NURBS support, CSG evaluation
of NURBS, and reliable fast surface tessellation |
| 16:24.19 |
brlcad |
so the focus
has been on NURBS more than the GUI itself, so we can still have
verifiable CAD constructs |
| 16:24.29 |
_psilva |
ic |
| 16:24.55 |
brlcad |
some
screenies of 3rd gen at http://brlcad.org/wiki/User:Ralith |
| 16:25.50 |
brlcad |
the screenie
at the bottom actually has an embedded mged command interpreter,
input bindings mimicing mged, blender, and a game
controller |
| 16:26.04 |
_psilva |
cool |
| 16:26.10 |
brlcad |
otherwise,
mostly basic infrastructure |
| 16:29.13 |
cjdevlin |
was the
unix/linux version done in gtk? and now you are writing a new gui
in Qt? |
| 16:29.31 |
starseeker |
original gui
work was in Tk |
| 16:29.44 |
starseeker |
new effort
uses a combination of Qt and Ogre |
| 16:38.53 |
starseeker |
43200
exhibits the failure... |
| 16:55.11 |
starseeker |
43310
works... |
| 16:56.42 |
*** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ) |
| 16:56.50 |
*** join/#brlcad yukonbob1
(~bch@20-144.wireless.kamloops.net) |
| 17:01.04 |
*** join/#brlcad alex_jon1
(~alex_joni@81.196.65.201) |
| 17:05.44 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 17:23.49 |
starseeker |
ok, 43213
exhibits the failure |
| 17:35.46 |
starseeker |
hah, cool:
http://prod.nais.nasa.gov/eps/eps_data/137203-SOL-001-005.pdf |
| 17:39.24 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
| 17:40.49 |
*** join/#brlcad kanzure_
(~kanzure@131.252.130.248) |
| 17:41.08 |
starseeker |
even cooler:
http://simplesat.gsfc.nasa.gov/drawings.html |
| 17:47.24 |
starseeker |
wonder if
there are public cad drawings for that simplesat... |
| 17:51.36 |
alex_joni |
starseeker:
nice :) |
| 17:55.31 |
starseeker |
not a drawing
itself, but possibly interesting as a source of layout conventions:
http://mscweb.gsfc.nasa.gov/543web/files/GSFC-X-673-64-1F.pdf |
| 17:57.04 |
starseeker |
43214
fails... |
| 18:02.04 |
alex_joni |
heh, if I
would have followed that doc I probably would have never finished
with my design :) |
| 18:06.27 |
starseeker |
hmm...
http://hesperia.gsfc.nasa.gov/hessi/reference/drawings/hessi10_26_99%20Archive/ |
| 18:06.37 |
alex_joni |
starseeker:
http://juve.ro/blog-files/projects/01298803577/steadycam.pdf |
| 18:07.11 |
*** join/#brlcad epileg
(~epileg@188.119.210.222) |
| 18:07.11 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 18:16.53 |
starseeker |
alex_joni:
hah, cool! |
| 18:16.53 |
starseeker |
what license
is the model? |
| 18:16.56 |
starseeker |
looks like it
might be a solid model? http://juve.ro/blog/projects/01298803577 |
| 18:16.57 |
starseeker |
43216
fails... |
| 18:26.47 |
*** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ) |
| 18:29.25 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 18:32.08 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 18:39.39 |
starseeker |
43235
fails |
| 18:39.48 |
starseeker |
gets lunch |
| 18:58.22 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 19:00.51 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 19:13.27 |
alex_joni |
starseeker:
haven't decided on the license yet, but something open |
| 19:19.04 |
alex_joni |
not even sure
what licenses are aplicable to solid models and cad
drawings |
| 19:28.50 |
starseeker |
usually I see
creative commons |
| 19:29.01 |
starseeker |
(see openmoko
for an example) |
| 19:44.38 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
| 20:31.34 |
CIA-77 |
BRL-CAD:
03starseeker * r43671 10/brlcad/trunk/TODO: The reported red
failure was due to disabling compile of local regex, resulting in
interference from tcl regex. After commit 43259, this is no longer
occurring and proper behavior is restored. |
| 20:51.29 |
CIA-77 |
BRL-CAD:
03starseeker * r43672 10/brlcad/branches/cmake/ (5 files in 5
dirs): MFC r43671 |
| 20:59.40 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43673
10/brlcad/trunk/src/librt/primitives/bot/tie.c: indent |
| 21:11.19 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43674 10/brlcad/trunk/src/librt/primitives/bot/
(tie_kdtree.c tieprivate.h): de-magic the haschildren/leafnode bit
and comment some on bitpacking |
| 21:11.59 |
alex_joni |
starseeker:
sounds good |
| 21:25.34 |
CIA-77 |
BRL-CAD:
03starseeker * r43675
10/geomcore/trunk/src/other/subversion/other/apr-util/xml/expat/Makefile.in:
Looks like a Makefile.in got ignored. |
| 21:35.52 |
CIA-77 |
BRL-CAD:
03erikgreenwald * r43676
10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: check
alignment on kd nodes |
| 21:40.40 |
*** join/#brlcad vtts
(~vytautas@diz.ktu.lt) |
| 21:44.51 |
vtts |
hi, is such
problem known on mac os x? http://pastie.org/1630246 |
| 21:45.47 |
CIA-77 |
BRL-CAD:
03starseeker * r43677
10/geomcore/trunk/src/other/subversion/other/apr-util/ (87 files in
15 dirs): Sync apr-util directory with apr-util-1.3.10 |
| 21:56.11 |
CIA-77 |
BRL-CAD:
03starseeker * r43678 10/geomcore/trunk/src/other/subversion/
(CMake/ThirdParty.cmake CMakeLists.txt): third party build logic
ain't happy - get closer, but this won't be enough |
| 22:31.03 |
starseeker |
vtts: yow.
Is that with OpenGL enabled? |
| 22:33.26 |
vtts |
agl |
| 22:36.15 |
starseeker |
uh... we
don't use agl yet - we work with X11 opengl on the mac |
| 22:36.47 |
vtts |
ok then, I'll
try skipping OpenGL and see if it works |
| 22:36.59 |
alex_joni |
starseeker:
now with license info: http://juve.ro/blog/projects/01298803577 |
| 22:37.11 |
starseeker |
not sure if
that'll do anything, but worth a try... that's a pretty new version
of OSX |
| 22:37.54 |
starseeker |
alex_joni:
cool! what cad system are you modeling in? |
| 22:38.01 |
alex_joni |
I'll put the
solid up in a couple days (when I get a round-tuit) |
| 22:38.04 |
alex_joni |
starseeker:
alibre |
| 22:38.17 |
starseeker |
does it
export to step? (drool...) |
| 22:38.21 |
alex_joni |
yes |
| 22:38.34 |
starseeker |
awesome |
| 22:39.02 |
alex_joni |
I found it
very nice/cheap (about 2k for the expert version which does CAE,
CAM, unlimited everythings, etc) |
| 22:39.22 |
alex_joni |
limited CAM
though.. |
| 22:39.27 |
starseeker |
nods |
| 22:39.38 |
starseeker |
hey, if it
works it works |
| 22:39.40 |
alex_joni |
right |
| 22:39.48 |
alex_joni |
"only" 2.5D
and 3D |
| 22:40.09 |
alex_joni |
anyways, I
used SW a bit before this, and Inventor |
| 22:40.20 |
alex_joni |
but I like
alibre better, and it's less than half the price |
| 22:40.31 |
starseeker |
wonder what
engine they're using |
| 22:40.39 |
alex_joni |
oh, did I
mention you get 5 seats for that price? |
| 22:41.09 |
starseeker |
heh -
amazing. A far cry from the $30,000 per set licensing (back when
that was real money) |
| 22:41.23 |
alex_joni |
heh |
| 22:41.50 |
alex_joni |
they use step
as the internal datatype |
| 22:41.57 |
alex_joni |
some step
variant anyways |
| 22:42.03 |
starseeker |
sweet |
| 22:44.34 |
alex_joni |
they used to
have a limited free version |
| 22:44.45 |
alex_joni |
now it's
99$/seat for the personal version |
| 22:45.02 |
starseeker |
nods - lot like Mathematica in that
respect |
| 22:45.11 |
starseeker |
suck in the
students, then *wham* |
| 22:46.02 |
starseeker |
always preferred the open solutions, even if they weren't as
full-featured/glitzy, but sometimes you need the functionality
(especially for "real work") |
| 22:46.46 |
alex_joni |
yeah, I
know.. |
| 22:47.02 |
alex_joni |
well..
there's Octave out there ;) |
| 22:47.34 |
starseeker |
:-). That's
the Matlab-alike - for phyics (my undergrad) Maxima was the major
player |
| 22:47.50 |
starseeker |
Axiom later
made an appearance, and then Reduce as well |
| 22:48.05 |
alex_joni |
ah right, was
thinking of Matlab |
| 22:50.41 |
brlcad |
vtts: opengl
is fine, but you have to enable compilation of tcl/tk
(--enable-all) |
| 22:50.59 |
alex_joni |
starseeker:
step 203 / step 214 ? |
| 22:51.00 |
brlcad |
the system tk
on 10.6 is compatible, but will crash because we assume an X11
binding |
| 22:51.14 |
brlcad |
203 at the
moment |
| 22:51.20 |
starseeker |
alex_joni: I
believe 203, but if it's easy why not put up both? |
| 22:52.14 |
starseeker |
is a greedy sucker when it comes to test cases
:-P |
| 22:53.08 |
alex_joni |
coming up in
a sec |
| 22:54.13 |
alex_joni |
I can also
export ACIS and parasolid (x_t) |
| 22:54.23 |
alex_joni |
if those are
valid test cases let me know |
| 22:54.42 |
starseeker |
urm.
Interesting, but I don't know if those formats are
documented? |
| 22:55.08 |
brlcad |
sure, why not
-- x_t would be useful |
| 22:55.22 |
brlcad |
it's a
text-based format, somewhat easy to parse |
| 22:55.37 |
starseeker |
they'd all be
handy for "Rosetta stone" work if someone wanted to start figuring
out the formats, but for now we've got all we can do to support the
ones that are :-P |
| 22:55.46 |
starseeker |
having the
same model in multiple formats is quite handy |
| 22:57.33 |
starseeker |
's jaw hits the floor... |
| 22:59.10 |
vtts |
brlcad, make
install fails if i enable tcl/tk :( |
| 22:59.12 |
CIA-77 |
BRL-CAD:
03starseeker * r43679 10/geomcore/trunk/tests/svntest/main.c:
Commit svntest quick before it changes it's mind - got what appears
to be a working assembly search. Not doing much intelligent with it
yet, but that went surprisingly smooth. |
| 22:59.43 |
alex_joni |
ok, models
uploaded |
| 23:00.57 |
starseeker |
alex_joni:
awesome, thanks! |
| 23:02.12 |
brlcad |
vtts: what's
the failure? |
| 23:03.09 |
alex_joni |
starseeker:
let me know if you can open them |
| 23:08.26 |
starseeker |
oooh, wow -
step-g doesn't like the 203 file |
| 23:09.23 |
starseeker |
excellent -
good test case |
| 23:09.41 |
alex_joni |
heh |
| 23:10.52 |
starseeker |
actually is
quite a good test - lots of objects, but not huge |
| 23:10.55 |
alex_joni |
well, good
night all |
| 23:11.04 |
starseeker |
night, and
thanks again! |
| 23:11.06 |
alex_joni |
has to get up early |
| 23:11.11 |
starseeker |
yuck |
| 23:11.25 |
alex_joni |
not _that_
early.. around 7am (early for me) |
| 23:11.45 |
starseeker |
heh - for me
that's the dead zone - either 5am or 9am work |
| 23:12.03 |
alex_joni |
I'm more the
9am guy :) |
| 23:12.05 |
vtts |
brlcad, I
didn't save it :(, will pastebin it tomorrow |
| 23:12.11 |
alex_joni |
but it's
after 1am here.. so :/ |
| 23:12.19 |
starseeker |
alex_joni:
cool, night! |
| 23:14.41 |
starseeker |
must head out too... |
| 01:36.29 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 03:00.15 |
starseeker |
brlcad:
http://pastebin.mozilla.org/1124576 |
| 04:44.32 |
brlcad |
starseeker:
thanks |
| 04:44.37 |
brlcad |
try with that
fix |
| 04:44.44 |
CIA-77 |
BRL-CAD:
03brlcad * r43680
10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: |
| 04:44.44 |
CIA-77 |
BRL-CAD: pull
the declaration of center2d (and his friends) up to the top scope
to make |
| 04:44.44 |
CIA-77 |
BRL-CAD: sure
the warning reflects the current file state. preprocessor directive
in |
| 04:44.44 |
CIA-77 |
BRL-CAD: that
function was missing a semicolon, so perhaps that was confusing
gcc? see |
| 04:44.44 |
CIA-77 |
BRL-CAD: if
we still get an uninitialized use warning now that it's outside of
the loop. |
| 04:44.52 |
brlcad |
I think I
understand what it's detecting |
| 04:45.29 |
brlcad |
it is really
obscure and apparently not without bugs if those line numbers are
to be believed |
| 04:46.30 |
brlcad |
but the
center2d var was declared inside a loop, which I believe is only
initialized once, but not per iteration like one might expect so
it's possibly warning based on the future use. |
| 04:47.08 |
brlcad |
the only
thing unique about that function, however, was an inconsistent
macro call, so still a little bit of a mystery |
| 04:47.26 |
brlcad |
that'd be a
good one to see the post-preprocessor output being fed to
gcc |
| 05:45.01 |
*** join/#brlcad roberthl_
(~robert@v001.rhl.me.uk) |
| 05:52.40 |
brlcad |
outstanding
spelunking on the red failure, great to know exactly why it was
failing but working with HEAD |
| 05:53.12 |
brlcad |
starseeker:
so do you know which regex feature wasn't supported? |
| 05:54.02 |
brlcad |
curious how
our regex worked and theirs didn't, because theirs is actually a
never derivative |
| 05:54.16 |
brlcad |
unless if
it's something like the regex enums don't match, hmm |
| 05:54.52 |
brlcad |
aha, yep
that's it |
| 05:56.22 |
brlcad |
REG_NEWLINE
is 300 for Tcl and 10 for ours |
| 05:56.28 |
brlcad |
REG_EXTENDED
matches |
| 05:59.12 |
brlcad |
so that
mystery is solved |
| 06:00.15 |
brlcad |
one take-home
lesson to keep in mind for cmake is that it will have to make sure
include directories are NOT listed if a src/other dep is not going
to be compiled, otherwise that same type of problem can happen with
any of them (png, libz, ..) |
| 06:54.44 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 06:58.14 |
*** join/#brlcad Robert___
(~robert@v001.rhl.me.uk) |
| 07:06.46 |
vtts |
any way to
fix this? http://pastebin.com/rFeVqwHG |
| 07:07.51 |
vtts |
happens when
I click on Edit -> Combination Editor |
| 07:09.12 |
vtts |
same goes for
"Attribute Editor" and similar oneline error in command window for
geometree command |
| 07:09.36 |
vtts |
(mac os
x) |
| 07:12.33 |
vtts |
version from
svn r43679 |
| 08:04.12 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.12.71) |
| 08:04.12 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:14.20 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 12:52.07 |
starseeker |
brlcad: is
this what you need? http://bzflag.bz/~starseeker/extrude.preprocess |
| 12:52.24 |
starseeker |
(that's
without applying you're latest fix) |
| 12:53.16 |
starseeker |
brlcad: as a
rule, the include directory variables should do the right thing
when a src/other dep is turned on or off |
| 12:53.20 |
starseeker |
(for
cmake) |
| 12:53.46 |
starseeker |
that one is a
particular problem because we can have the situation where regex is
off and tcl is on |
| 12:54.20 |
starseeker |
(or was until
the rename anyway) |
| 12:58.58 |
starseeker |
bah
s/you're/your/ |
| 13:00.52 |
starseeker |
sweet - that
last tweak to extrude looks like it got it |
| 13:00.56 |
dloman |
@anyone: How
are tcl scripts 'automatically' loaded when mged launches? Aka, if
I have a tcl script or two I'd like to put in a few of my scripts
i've written and make them load whenever mged
launches.... |
| 13:01.07 |
starseeker |
thanks for
following that up brlcad - that was waaay out of my depth
:-P |
| 13:01.35 |
starseeker |
uh... I think
you can do that by putting source statements in
.mgedrc? |
| 13:01.46 |
dloman |
righto, got
that part |
| 13:02.03 |
dloman |
just with no
user configging, aka 'its part of mged' |
| 13:02.49 |
starseeker |
uh... you'd
have to stick them in one of the directories that libtclcad's
autopath logic (or the system tcl/tk) know about and alter the
pkgIndex.tcl file (I think?) |
| 13:03.07 |
starseeker |
take a look
at what src/tclscripts files do |
| 13:03.36 |
dloman |
awesome,
thanks. |
| 13:06.28 |
starseeker |
eyes the failure of toyjeep.g to convert with release flags
turned on... http://pastebin.mozilla.org/1126164 |
| 13:06.51 |
starseeker |
that seems to
happen ONLY when I turn on release build flags - with debug flags
it succeeds |
| 13:09.01 |
starseeker |
is that
another one specific to my system or has someone else seen
it? |
| 13:14.13 |
starseeker |
this is the
problem child: http://bzflag.bz/~starseeker/pipeproblem.asc |
| 13:20.45 |
d_rossberg |
starseeker:
what do you mean with "convert"? |
| 13:27.25 |
starseeker |
asc2g |
| 13:32.37 |
starseeker |
d_rossberg:
oh - have you had any chance to see if your particular cmake logic
can work with the new cmake build? |
| 13:33.49 |
d_rossberg |
no, haven't
tested yet |
| 13:34.17 |
starseeker |
hmm - maybe
I'm wrong, asc2g failed with both builpes... |
| 13:35.07 |
starseeker |
d_rossberg:
k. I'll try to take a look myself if I get a chance - that's the
main hurdle for being able to move the CMake logic to trunk (even
if we don't use it as the "default" build logic) |
| 13:35.54 |
starseeker |
s/builpes/both build configs/ |
| 13:37.31 |
starseeker |
here's a
little more detail on the pipe failure: http://pastebin.mozilla.org/1126269 |
| 13:39.32 |
starseeker |
looks like
VDOT is coming back with -1, which acos doesn't like... |
| 13:42.43 |
d_rossberg |
maybe it's
-1.0000000..0001 ? |
| 13:44.19 |
d_rossberg |
btw, i'll
update may brlcad cmake branch for a short code review
... |
| 13:48.43 |
dloman |
wow, 35 mins
to svn up. that's just painful :/ |
| 13:50.52 |
CIA-77 |
BRL-CAD:
03starseeker * r43681
10/brlcad/branches/cmake/misc/CMake/test_srcs/timedelta_end.c.in:
check fscanf here too to make compiler happy |
| 13:53.07 |
starseeker |
ah, good -
just needed a clean build - still avoids erroring out with debug
and does with release |
| 13:56.24 |
starseeker |
this is as
much as I know currently: http://pastebin.mozilla.org/1126326 |
| 14:02.26 |
starseeker |
why is
acos(-1) not happy... |
| 14:03.57 |
starseeker |
d_rossberg:
you may be right... let's see... |
| 14:11.21 |
starseeker |
yep |
| 14:11.27 |
starseeker |
d_rossberg:
thanks :-) |
| 14:11.33 |
starseeker |
now, what to
do... |
| 14:15.44 |
CIA-77 |
BRL-CAD:
03starseeker * r43682
10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: |
| 14:15.44 |
CIA-77 |
BRL-CAD: acos
isn't happy if we go outside the domain -1,1 and it looks like
floating |
| 14:15.44 |
CIA-77 |
BRL-CAD:
point fuzz is taking us inside in some cases and out in others -
peg it to -1 or |
| 14:15.44 |
CIA-77 |
BRL-CAD: 1 if
we're within VUNITIZE_TOL to avoid uncertainty principle effects
in |
| 14:15.44 |
CIA-77 |
BRL-CAD:
conversion behavior |
| 14:16.58 |
starseeker |
actually,
that may not be enough... |
| 14:18.36 |
d_rossberg |
starseeker:
how about "angle = bn_pi - acos(min(1., max(-1., VDOT(v1,
v2))));"? |
| 14:20.49 |
``Erik |
or vmath's
CLAMP() |
| 14:22.20 |
starseeker |
it's tricky,
because we DO want pipes to fail the check if they really do define
a pipe that's not within floating point fuzz of sane
limits |
| 14:22.46 |
starseeker |
I'm just
worried that borderline cases will still crop up... |
| 14:24.24 |
starseeker |
if the value
is less than -1.0 + fuzz it should fail... but whether a particular
value hits that threshold will vary from system to
system... |
| 14:24.36 |
starseeker |
-1.0 - fuzz
rather |
| 14:25.53 |
starseeker |
it's almost
like if it starts straying into bad (fuzzy) territory we need to
clamp not the VDOT result but the input geometry values themselves
to keep them out of the danger zone |
| 14:27.21 |
starseeker |
but how do we
do that? |
| 14:28.19 |
d_rossberg |
first you
have to put meaningful values to acos() and tan() |
| 14:29.10 |
d_rossberg |
only if this
was the case you may evaluate new_bend_dist |
| 14:30.03 |
d_rossberg |
and in my
opinion the VDOT() problem is a double precision
problem |
| 14:30.19 |
d_rossberg |
there you
have to "help" a little bit |
| 14:32.22 |
starseeker |
I'm betting
what happened was a modeler in mged pushed the pipe right to its
limits, which worked on that system but not on another. We need
another category of return value from the check which says "valid
but dangerous" to keep the modeler in MGED from setting to that
value but to allow existing geometry that already has the
borderline values to work |
| 14:34.29 |
brlcad |
starseeker:
yeah, that's what I would have needed wrt extrude.c |
| 14:39.48 |
starseeker |
uh... has
somebody been monkeying with MGED mouse bindings? |
| 14:40.30 |
starseeker |
both left and
right mouse buttons zoom in, and perspective is on whether I ask
for it or not... |
| 14:41.53 |
starseeker |
needs to head in here... |
| 14:43.49 |
brlcad |
starseeker:
yeah, I messed with mouse bindings recently because of that
problem, but maybe didn't get it right |
| 14:44.07 |
brlcad |
let me know
when you're stable to test a change |
| 14:45.39 |
CIA-77 |
BRL-CAD:
03brlcad * r43683 10/brlcad/trunk/TODO: report that comb editor
isn't working and jeep conversion failure |
| 14:46.33 |
starseeker |
brlcad: go
ahead - I'm done monkeying for the moment |
| 14:49.07 |
starseeker |
uh, pipe not
torus (or are you seeing torus failures?) |
| 14:49.19 |
brlcad |
ups,
right |
| 14:49.31 |
brlcad |
"torus bend"
failure |
| 14:49.45 |
starseeker |
that change I
made to pipe.c does work, but I don't know if it's
"right" |
| 14:52.43 |
starseeker |
we need an
"editing" check I think that is tighter than the import check, but
will allow movement of settings towards safer
directions |
| 14:54.55 |
starseeker |
in the case
of an import that has settings meeting import tolerance (i.e. "this
was valid on some system but is fuzzy/dodgy here") but not editing
tolerance "on this system we don't want this value, but since we
already have it don't fail" |
| 14:56.41 |
starseeker |
hits the road |
| 14:56.53 |
d_rossberg |
starseeker:
you may move the cmake logic to trunk, the brlcad.dll won't work
but it looks like it can be fixed with reasonable
effort |
| 14:57.40 |
d_rossberg |
and don't
bother the user with your numerical problems ;) |
| 14:58.16 |
d_rossberg |
prefer to
solve the numerics to writing a dialog |
| 14:58.33 |
starseeker |
one last note
- I dunno how reproducible it is, but perspective was on with the
jeep in release build and off in debug build |
| 14:59.23 |
d_rossberg |
on my system
(MSVC) acos() accepts invalid values, the result is a
nan |
| 15:00.28 |
d_rossberg |
anyway, this
kind of problem may arise always |
| 15:03.30 |
d_rossberg |
if you can
not be sure that the result of VDOT() is between -1 and 1 (as the
theory would say) _and_ acos() has a problem with it you have to
test it |
| 15:15.29 |
d_rossberg |
btw, your
test isn't optimal: e.g. local_vdot = -1.5 would still
crash |
| 15:18.09 |
brlcad |
oops, there
he goes :) |
| 15:22.19 |
CIA-77 |
BRL-CAD:
03bob1961 * r43684 10/brlcad/trunk/src/libtclcad/ged_obj.c: Fixed a
problem with rect_mode that was causing an offset rectangle to be
drawn. |
| 15:26.35 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
| 15:26.36 |
*** join/#brlcad starseek1r
(~starseeke@BZ.BZFLAG.BZ) |
| 15:28.02 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 15:39.27 |
CIA-77 |
BRL-CAD:
03brlcad * r43685
10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: |
| 15:39.27 |
CIA-77 |
BRL-CAD: why
there are custom blocks of code to unitize the vector instead of
calling |
| 15:39.27 |
CIA-77 |
BRL-CAD:
VUNITIZE() is curious and potentially related to the fuzzy
instability. |
| 15:39.27 |
CIA-77 |
BRL-CAD:
regardless, tweak the dot product result if it just barely
over/under-shoots due |
| 15:39.27 |
CIA-77 |
BRL-CAD: to
precision problems. using NEAR_ZERO/NEAR_EQUAL here isn't optimal
since |
| 15:39.28 |
CIA-77 |
BRL-CAD:
it'll clamp values already within the valid [1.0,-1.0] range to the
limit of |
| 15:39.29 |
CIA-77 |
BRL-CAD: that
range. |
| 15:40.26 |
brlcad |
d_rossberg:
good point about the range, but the dot should be between 1,-1
since they're both unit vectors .. code just wasn't obvious that
they were being unitized |
| 15:45.01 |
CIA-77 |
BRL-CAD:
03brlcad * r43686 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c:
still need the lengths of v1/v2 for subsequent input
validation |
| 15:55.43 |
d_rossberg |
brlcad: if
vdot > 1.0 => vdot = 1.0 and if vdot < -1.0 => vdot =
-1.0 otherwise acos() may crash the program! |
| 15:57.04 |
brlcad |
they're
already unit vectors so vdot shouldn't be more than fuzz, or you
saying check it anyways because it may crash (e.g., if there is
REALLY bad fuzz) |
| 15:57.21 |
brlcad |
works for
me |
| 15:57.46 |
d_rossberg |
check it the
simple way, you do not know for sure what "small" is |
| 16:00.13 |
d_rossberg |
otherwhise
the code is hard to understand (why he checks for 1.0+VUNITIZE_TOL?
what happens if vdot is >= 1.0+VUNITIZE_TOL?) |
| 16:01.20 |
CIA-77 |
BRL-CAD:
03brlcad * r43687 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c:
daniel has a good point, they're already unit so no harm saying
anything outside of range is clamped to the range limit |
| 16:06.37 |
CIA-77 |
BRL-CAD:
03brlcad * r43688 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c:
um, call CLAMP() dummy |
| 16:09.42 |
*** join/#brlcad yukonbob_
(~bch@20-144.wireless.kamloops.net) |
| 16:18.35 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
| 16:18.35 |
*** join/#brlcad ``Erik_
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 16:18.35 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 16:18.35 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 16:18.36 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
| 16:18.36 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 16:18.36 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 16:18.36 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 16:18.36 |
*** join/#brlcad vtts
(~vytautas@diz.ktu.lt) |
| 16:18.36 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
| 16:18.36 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 16:18.36 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 16:18.36 |
*** join/#brlcad kanzure_
(~kanzure@131.252.130.248) |
| 16:18.36 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
| 16:18.36 |
*** join/#brlcad dtidrow_
(~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) |
| 16:18.36 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 16:18.36 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
| 16:18.36 |
*** join/#brlcad _psilva
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
| 16:18.36 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 16:18.36 |
*** join/#brlcad kanzure__
(~kanzure@bioinformatics.org) |
| 16:18.36 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 16:18.36 |
*** mode/#brlcad [+o ChanServ] by
verne.freenode.net |
| 16:19.59 |
*** join/#brlcad WhiteCalf
(MK@2607:f0d0:3001:68::2) |
| 16:20.13 |
*** join/#brlcad CIA-14
(~CIA@208.69.182.149) |
| 16:22.13 |
*** join/#brlcad Ralith_
(~ralith@S010600221561996a.vc.shawcable.net) |
| 16:22.39 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 16:30.01 |
*** join/#brlcad starseek1r
(~starseeke@BZ.BZFLAG.BZ) |
| 16:30.01 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 16:30.01 |
*** join/#brlcad Ralith_
(~ralith@S010600221561996a.vc.shawcable.net) |
| 16:30.01 |
*** join/#brlcad CIA-14
(~CIA@208.69.182.149) |
| 16:30.01 |
*** join/#brlcad WhiteCalf
(MK@2607:f0d0:3001:68::2) |
| 16:30.01 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
| 16:30.01 |
*** join/#brlcad ``Erik_
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 16:30.01 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 16:30.01 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
| 16:30.01 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 16:30.01 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 16:30.01 |
*** join/#brlcad vtts
(~vytautas@diz.ktu.lt) |
| 16:30.01 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 16:30.01 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 16:30.01 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
| 16:30.01 |
*** join/#brlcad dtidrow_
(~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) |
| 16:30.01 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 16:30.01 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
| 16:30.02 |
*** join/#brlcad _psilva
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
| 16:30.02 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 16:30.02 |
*** join/#brlcad kanzure__
(~kanzure@bioinformatics.org) |
| 16:30.02 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 16:30.02 |
*** mode/#brlcad [+o ChanServ] by
verne.freenode.net |
| 16:42.00 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 16:45.19 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
| 16:55.14 |
*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) |
| 17:05.01 |
CIA-14 |
BRL-CAD:
03brlcad * r43689 10/brlcad/trunk/TODO: torus bend pipe failure
should be working now, needs one final test on the platform that
had the float fail. |
| 17:36.21 |
dloman |
question
about the tclIndex file: is that generated by something or do
we/can we manually edit that (to add tcl scripts) ? |
| 17:37.29 |
tofu |
it's
autogenerated |
| 17:38.43 |
*** join/#brlcad ezzieyguywuf
(~wolfie@cpe-071-070-255-232.nc.res.rr.com) |
| 17:39.25 |
ezzieyguywuf |
how do I
delete a shape after I have made it with in? I know I can remove it
from the framebuffer thing with erase, but I want to get rid of it
completely. |
| 17:39.50 |
brlcad |
dloman: if
you delete the file, it'll get regenerated |
| 17:40.24 |
brlcad |
same for
pkgIndex.tcl |
| 17:40.31 |
dloman |
kk, so how do
i add a new tcl script then... just put the .tcl file into the
src/tclscripts dir? |
| 17:40.52 |
brlcad |
depends on
what the script is |
| 17:41.07 |
brlcad |
somewhere in
the src/tclscripts hierarchy, but the routines are organized by
purpose |
| 17:41.27 |
dloman |
i fixed the
'grouper' script (by request) so it now works with 7.18 |
| 17:41.52 |
dloman |
figured id
finally put it in the repo |
| 17:42.13 |
brlcad |
that'd be the
mged subdir then, or a subdir under there |
| 17:43.00 |
dloman |
kk.
danke |
| 17:43.01 |
brlcad |
suggest
reading a few of the other tcl files in here |
| 17:43.05 |
brlcad |
*there |
| 17:43.14 |
brlcad |
to make sure
that it'll self-validate and load correctly |
| 17:45.05 |
brlcad |
src/tclscripts/mged/reid.tcl is a simple
example of mged-command validation |
| 17:45.15 |
ezzieyguywuf |
waits |
| 17:45.34 |
brlcad |
solclick.tcl
is another |
| 17:46.00 |
brlcad |
ezzieyguywuf:
kill |
| 17:46.12 |
ezzieyguywuf |
brlcad:
excellent thanks. |
| 17:46.16 |
brlcad |
the mged
quick reference sheet lists all of the basic commands |
| 17:46.23 |
brlcad |
avail on the
website under docs |
| 17:46.40 |
ezzieyguywuf |
bah, I should
look at that. I was going through the docs in order, and I'm still
on the tutorial thing. |
| 17:46.44 |
ezzieyguywuf |
Making a mug
as we speak :-P |
| 17:47.00 |
brlcad |
excellent |
| 17:48.47 |
ezzieyguywuf |
incidentally,
I have a sort of general question about brl-cad: is it a good
replacement for, say, SolidWorks or Pro/E. i.e. will I be able to
make solid model represenations of parts, put assemblies together,
and generate drawings in a relatively quick manner (once I'm
proficient of course)? |
| 17:50.10 |
brlcad |
ezzieyguywuf:
you will be able to make solid model representations of parts, put
assemblies together, and do so in a relatively quick manner once
you ar proficient, but it does take some time and practice to
become proficient |
| 17:50.25 |
brlcad |
wouldn't say
any worse than sw or proe, but definitely different |
| 17:50.37 |
brlcad |
now drawing,
though, are a different matter. |
| 17:50.58 |
brlcad |
you can
generate drawings, but not with dimensioning
information |
| 17:51.02 |
brlcad |
at least not
yet |
| 17:51.08 |
ezzieyguywuf |
brlcad: is
there perhaps a third-party program you would recommend for doing
drawings? with dimensioning and tolerances etc. |
| 17:51.44 |
brlcad |
open source
options are pretty limited, qcad comes to mind for 2D |
| 17:52.11 |
ezzieyguywuf |
hm, but in
that case I'd have build the part from scratch anew? |
| 17:52.19 |
brlcad |
we're the
next closest, but then annotations and dimensioning are still under
development (my task for the upcoming month actually) |
| 17:52.58 |
yukonbob_ |
annotations
++ |
| 17:53.11 |
ezzieyguywuf |
interesting.
Well, I plan on spending some time getting familiar and proficient
with brl-cad (or whichever open source CAD package I settle on)
before I try using it for any big projects. That will probably be a
year + out. |
| 17:53.18 |
brlcad |
ezzieyguywuf:
example of what you can get now: http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html |
| 17:53.32 |
brlcad |
run "rtedge"
in mged (or outside of mged) and you'll get a hidden-line
rendering |
| 17:54.23 |
ezzieyguywuf |
nice. But say
I wanted to get that rapid-prototyped: could I export it into an
appropriate file format for doing so? |
| 17:55.18 |
ezzieyguywuf |
obviously if
it was a part I wanted to have machined, I would need a drawing.
but if it was going to be machined on a C&C machine, I think
those just take solid-model files as well. |
| 17:58.28 |
brlcad |
ezzieyguywuf:
http://brlcad.org/tmp/converters_page23.jpg |
| 17:58.49 |
brlcad |
we've had
things rapid-prototyped from our files before with relative
ease |
| 17:58.58 |
brlcad |
it depends
how well modeled the object is |
| 17:59.22 |
brlcad |
most of the
rapid prototypers handle STL (or iges for some of the better
ones) |
| 18:00.16 |
starseek1r |
ezzieyguywuf:
if you can't run qcad (I don't think the free version ever got
updated to Qt4) you might try the fork librecad |
| 18:00.24 |
brlcad |
facetizing a
model is REALLY tricky business, only working without assistance
about 85-95% of the time |
| 18:00.41 |
brlcad |
(most
exporters require facetization) |
| 18:00.55 |
ezzieyguywuf |
hm, I
see. |
| 18:01.17 |
brlcad |
note even
packages like proe aren't 100%, they're around 90-95% |
| 18:01.23 |
ezzieyguywuf |
I use gnome
as my graphical environment, and gentoo just pulls in w/e qt libs
it needs when I install stuff, so I don't think qcad will be a
problem. |
| 18:01.30 |
ezzieyguywuf |
are you
familiar with free-cad? how does that stack up? |
| 18:02.32 |
brlcad |
decent
project, leverages opencascade for nearly everything is actually
useful .. but not something I'd consider useful for production
work |
| 18:03.09 |
ezzieyguywuf |
hm I
see. |
| 18:03.21 |
brlcad |
really
depends on your specific use case and data, though |
| 18:03.30 |
brlcad |
they might
have just enough to do what you need |
| 18:03.32 |
ezzieyguywuf |
well thank
you for your time. I'll keep working through the tutorials, and see
where that takes me as far as long-term brl-cad use. |
| 18:03.35 |
brlcad |
they're just
really in their infanccy |
| 18:03.48 |
brlcad |
no
problem |
| 18:04.01 |
brlcad |
feedback is
definitely welcome as you work your way through |
| 18:04.05 |
*** join/#brlcad ezzieyguywuf
(~wolfie@unaffiliated/ezzieyguywuf) |
| 18:04.24 |
brlcad |
if you run
into a problem, folks are usually here to help |
| 18:05.42 |
ezzieyguywuf |
yea, well
first bit of feedback would be that I've found some very minor
discrepencies between the tutorial and the prog, i.e. the first
time it tells you to do 'Edit >> Set H' it says "Hit Accept
when you're done" but doesn't tell you that Accept is in the Edit
menu :-P |
| 18:06.25 |
brlcad |
good
point |
| 18:06.36 |
brlcad |
the "accept"
command will also work |
| 18:09.00 |
ezzieyguywuf |
ah, good to
know. |
| 18:09.56 |
ezzieyguywuf |
I'm kinda
beating myself up for not taking notes on these discrepencies. Also
when it mentions colors in the Combination Editor, you have to
first click on Show Shader to get that option. |
| 18:11.24 |
CIA-14 |
BRL-CAD:
03brlcad * r43690 10/brlcad/trunk/doc/docbook/lessons/en/
(mged06_creating_a_goblet.xml mged09_globe_in_display_box.xml):
apply suggestion from ezzieyguywuf to make sure we refer to the
Edit *Menu* when telling then to select Accept. |
| 18:12.16 |
ezzieyguywuf |
brlcad: the
menu itself is actually mentioned, but on about the third accept,
two lessons later (I think. just for clarity) |
| 18:14.32 |
brlcad |
nods |
| 18:14.42 |
CIA-14 |
BRL-CAD:
03brlcad * r43691 10/brlcad/trunk/doc/docbook/lessons/en/ (2
files): update other references to Accept on the edit menu, change
click to select |
| 18:15.08 |
ezzieyguywuf |
:-D |
| 18:16.13 |
ezzieyguywuf |
so BRL-CAD
was originally written and used by the 'ballistics research
laborator' right? And one of the selling points (that I read on the
site) is that its more than just 'skin deep'. What does all this
mean though? I mean, does it mean I can design a mug and then drop
a rock on it and see what happens? |
| 18:18.44 |
brlcad |
the
"Ballistic Research Laboratory" (BRL), yes |
| 18:19.17 |
brlcad |
more than
just skin deep is a reference to our solid modeling
underpinnings |
| 18:19.37 |
brlcad |
as well as
complete modeling of object interiors |
| 18:20.23 |
brlcad |
so if I'm
modeling a vehicle, we're geared to represent every little bit of
detail, do so with incredible efficiency, and still be able to
analytically evaluate the model |
| 18:21.06 |
brlcad |
every nut,
bolt, wire, interior and exterior, and have it actually be
volumetrically accurate and mathematically well-defined |
| 18:23.40 |
*** join/#brlcad ezzieyguywuf
(~wolfie@unaffiliated/ezzieyguywuf) |
| 18:23.50 |
ezzieyguywuf |
wow, irssi
just froze for the first time in...years |
| 18:23.57 |
brlcad |
welcome back
;) |
| 18:24.05 |
ezzieyguywuf |
thanks
:-) |
| 18:27.18 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 18:27.25 |
brlcad |
so don't know
when you got cut off there, but hopefully answered your
question |
| 18:28.34 |
starseeker |
awesome - DOJ
is starting an antitrust investigation of MPEG-LA |
| 18:38.24 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 18:38.24 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 18:38.24 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
| 18:38.24 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 18:38.24 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 18:38.24 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 18:38.24 |
*** join/#brlcad Ralith_
(~ralith@S010600221561996a.vc.shawcable.net) |
| 18:38.24 |
*** join/#brlcad CIA-14
(~CIA@208.69.182.149) |
| 18:38.24 |
*** join/#brlcad WhiteCalf
(MK@2607:f0d0:3001:68::2) |
| 18:38.24 |
*** join/#brlcad ``Erik_
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 18:38.24 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
| 18:38.24 |
*** join/#brlcad vtts
(~vytautas@diz.ktu.lt) |
| 18:38.24 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 18:38.24 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
| 18:38.24 |
*** join/#brlcad dtidrow_
(~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) |
| 18:38.24 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 18:38.24 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
| 18:38.24 |
*** join/#brlcad _psilva
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
| 18:38.24 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 18:38.24 |
*** join/#brlcad kanzure__
(~kanzure@bioinformatics.org) |
| 18:38.24 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 18:38.25 |
*** mode/#brlcad [+o ChanServ] by
verne.freenode.net |
| 18:40.25 |
ezzieyguywuf |
I don't know
where we got cut off either, let me check my logs |
| 18:40.52 |
ezzieyguywuf |
<PROTECTED> |
| 18:44.32 |
ezzieyguywuf |
ah yea,
another quirk of the tutorial (and this is the second case of this,
lesson 11. can't recall the frist): tute says to run mater
mug.r<ENTER> but the mater command expects Usage: mater
region_name shader r g b inherit |
| 18:45.10 |
brlcad |
just two
lines missed then |
| 18:45.15 |
brlcad |
13:20 <
brlcad> so if I'm modeling a vehicle, we're geared to represent
every little bit of detail, do so with incredible efficiency, and
still be able to analytically evaluate the model |
| 18:45.19 |
brlcad |
13:21 <
brlcad> every nut, bolt, wire, interior and exterior, and have
it actually be volumetrically accurate and mathematically
well-defined |
| 18:45.49 |
ezzieyguywuf |
brlcad: but
the actual analytical evaluation is done outside of
brl-cad? |
| 18:45.51 |
brlcad |
ezzieyguywuf:
yeah, that's a relatively recent change to 'mater' that I'm not
happy with -- it's not supposed to require all usage
parameters |
| 18:45.54 |
brlcad |
basically a
bug |
| 18:46.20 |
ezzieyguywuf |
brlcad: ah. I
thought maybe I (read gentoo) compiled it wrong, and this it wasn't
interactive as it should have been. |
| 18:46.37 |
brlcad |
brl-cad
performs _geometric_ evaluation quite robustly, more complex
analytic evaluation is performed outside |
| 18:46.39 |
ezzieyguywuf |
I agree: why
take away the interactive option of the tool? leave it
in. |
| 18:46.54 |
brlcad |
it wasn't
intentional |
| 18:46.57 |
ezzieyguywuf |
ah
ok. |
| 18:47.05 |
brlcad |
just an
oversight during a code change a while back |
| 18:47.53 |
ezzieyguywuf |
these complex
analytic evaluations that are performed outside, they'd have to be
done reading the brl-cad database though, right? or does brl-cad
provide an api to easily access the data that the external program
would be? also, what are some examples of external programs for
performing these analyses? ansys? |
| 18:48.17 |
brlcad |
API |
| 18:48.22 |
CIA-14 |
BRL-CAD:
03brlcad * r43694 10/brlcad/trunk/TODO: mater command lost
interactive functionality, need to restore |
| 18:48.42 |
brlcad |
there are
literally dozens |
| 18:49.08 |
brlcad |
we provide a
ray query interface which allows you to sample geometry in any
matter you need for an analysis |
| 18:49.27 |
brlcad |
so lots of
codes use that interface for a whole range of advanced
purposes |
| 18:49.48 |
brlcad |
medical
dosage analysis, vulnerability/lethality analysis, signal analysis,
heat studies, structural |
| 18:50.14 |
ezzieyguywuf |
hrm,
interesting. very interesting. |
| 18:50.16 |
brlcad |
our closest
link is V/L, the code's name is MUVES -- a closed code developed by
the usgov |
| 18:51.14 |
brlcad |
the geometric
analyses we directly perform are presented and exposed area
calculations, volume, weight/mass, moments of inertia, centroids,
and aforementioned shotline queries |
| 18:51.43 |
brlcad |
ah, also
overlap/interference detection |
| 18:51.50 |
brlcad |
maybe a
couple others, but those immediately come to mind |
| 18:53.10 |
ezzieyguywuf |
so I can do a
lot with a solid-model mode in BRL-CAD. |
| 18:53.56 |
brlcad |
right |
| 18:54.19 |
brlcad |
our weakness
is converting to a surface model (polygonal) and direct
design |
| 18:54.49 |
brlcad |
http://brlcad.org/Industry_Diagram.png
might give you an idea |
| 18:55.50 |
brlcad |
still mostly
accurate though we have expanded to right a little bit with NURBS
and STEP support |
| 18:56.17 |
ezzieyguywuf |
hrm, I can't
make heads or tails of that diagram :-P |
| 18:56.30 |
brlcad |
lots of
layers of information to digest |
| 18:56.47 |
ezzieyguywuf |
ah, I see tha
BRL-CAD shaded region now. |
| 18:57.03 |
ezzieyguywuf |
so, I'm most
familiar with SolidWorks: where would that fall on that
diagram? |
| 18:57.33 |
ezzieyguywuf |
or, more
importantly, I'm starting work as a Mechanical Engineer soon: which
aspects of that diagram would you think would be most useful to me
professionaly? |
| 18:57.36 |
ezzieyguywuf |
for design
work. |
| 18:58.05 |
brlcad |
might help to
read it this way: CADD is basically AutoCAD industry, MCAD is
systems like GibbsCAM, the center 'CAD' domain is where you'd place
Solidworks, ProE, NX, CATIA |
| 18:59.05 |
brlcad |
CAID is
rather specialized systems, but that'd be systems like
Rhino3D |
| 18:59.54 |
ezzieyguywuf |
ah hah. the
diagram is now making more sense. |
| 18:59.58 |
brlcad |
the dotted
domains are different purposes that those domains tend to cater
to |
| 19:00.47 |
ezzieyguywuf |
what is NURBS
and STEP? |
| 19:01.08 |
ezzieyguywuf |
and can
BRL-CAD produce a mesh to use in, say, OpenFOAM? |
| 19:01.22 |
brlcad |
STEP is a
file exchange format |
| 19:02.13 |
brlcad |
similar to
IGES, successor |
| 19:02.16 |
brlcad |
NURBS is a
boundary representation format -- what a lot of commercial CAD
systems use to represent surfaces |
| 19:02.27 |
starseeker |
(Non-Uniform
Rational BSplines) |
| 19:02.33 |
ezzieyguywuf |
ah, I
see. |
| 19:02.41 |
brlcad |
ezzieyguywuf:
http://brlcad.org/d/node/82
<-- talks about converters in a bit more depth |
| 19:03.55 |
ezzieyguywuf |
ok, question
about the tutorial (sorry to keep shifting the convo back and
forth): I'm still working on the mug, and when I do tree mug.r it
shows that body.c is composed of u bodyout.s - bodyin.s, but a) the
inner rcc is not dotted and b) when I raytrace the inner rcc is not
cut out from the outer one. rather they seem to be merged into
one. |
| 19:04.06 |
ezzieyguywuf |
is it maybe
that I have more things drawn on the screen than I
want? |
| 19:04.14 |
ezzieyguywuf |
is there a
way to ls everything that is currently active? |
| 19:04.29 |
``Erik_ |
heh, pixdiff
of regular vs -c "set rt_bot_mintie=1" ... http://brlcad.org/~erik/bot20110304.png
(vs a while back with http://brlcad.org/~erik/bot20101229.png) |
| 19:04.44 |
brlcad |
ezzieyguywuf:
type "who" .. you might have multiple objects displayed |
| 19:05.35 |
brlcad |
``Erik: not
too shabby! |
| 19:05.42 |
ezzieyguywuf |
who lists
bodyout.s, bodyin.s, handle.s |
| 19:05.45 |
``Erik |
(only on 64b,
crashes on 32b still) |
| 19:05.48 |
brlcad |
``Erik:
mirrors fail to convert? |
| 19:06.05 |
``Erik |
same source
model, not sure why they're off |
| 19:06.27 |
brlcad |
looks like
you fixed all of the original failures |
| 19:06.52 |
``Erik |
yeah, backing
off a tiny bit did that... more concerned about the 32b issue, then
I need to get back to geomcore |
| 19:06.56 |
brlcad |
ezzieyguywuf:
so when you raytrace, you're raytracing those three primitives, not
mug.r |
| 19:07.34 |
ezzieyguywuf |
ah |
| 19:07.41 |
brlcad |
B mug.r will
erase those three you're viewing and draw mug.r, then it should go
to dotted for the subtracted objects and raytrace as you're
expecting |
| 19:07.48 |
ezzieyguywuf |
B mug.r...you
beat me to it :-P |
| 19:08.09 |
brlcad |
:) |
| 19:08.28 |
ezzieyguywuf |
ok. mug looks
proper, and yet the inner rcc is still not dotted. |
| 19:08.49 |
ezzieyguywuf |
I guess its a
'minor' thing but it bugs me because the dots would make things
easier to visualize pre-raytrace |
| 19:09.05 |
brlcad |
can you post
up your .g file somewhere? |
| 19:09.32 |
vtts |
howdy, r43679
gives http://pastebin.com/BmmDXE2u
when selectin Edit->Combination Editor (and few others), does
anybody know how to fix it? |
| 19:09.36 |
brlcad |
anon ftp to
brlcad.org if you don't |
| 19:09.39 |
ezzieyguywuf |
yea, one sec.
wait, I can't exactly pastebin it... |
| 19:09.53 |
brlcad |
vtts: saw
your report last night, it's on our list to verify |
| 19:10.12 |
vtts |
ok,
thanks |
| 19:10.24 |
brlcad |
thanks for
reporting it |
| 19:10.37 |
ezzieyguywuf |
http://ompldr.org/vN25zOQ <---
mug.g |
| 19:10.56 |
brlcad |
vtts: is this
your own compile? |
| 19:11.12 |
brlcad |
vtts: if it
is, retry with an --enable-all build |
| 19:11.28 |
vtts |
brlcad, it is
with --enable-all |
| 19:11.38 |
brlcad |
okay, good to
know |
| 19:12.18 |
vtts |
to be
precise: --enable-optimized --enable-threads --enable-all
--with-agl |
| 19:13.50 |
vtts |
is there a
way to define a custom phong based custom shader (like plastic but
with custom defaults)? |
| 19:14.24 |
ezzieyguywuf |
does brl-cad
have a facility by which I can say, for example, "insert an rcc
with its center at the same location as rcc1, a diameter that is
0.2 less, and a height that is 2 more (than that rcc1)" or do I
have to manually check the dims of the first in order to make the
second? |
| 19:14.27 |
``Erik |
'define' like
write your own C evaluator, or just set different
defaults? |
| 19:15.02 |
vtts |
i'd just like
to assign my_plastic to a region |
| 19:15.17 |
vtts |
multiple
regions that is |
| 19:15.53 |
vtts |
or any other
way to change properties for multiple objects |
| 19:16.22 |
vtts |
i'm thinking
about custom shader and change'ing it's default settings, but not
sure if it is possible |
| 19:16.50 |
brlcad |
vtts: yes
there is, you can customize any of the phong parameters |
| 19:16.57 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43695
10/brlcad/trunk/src/librt/primitives/bot/bot.c: we actually trigger
this correctly now, so remove the extra debugging info |
| 19:17.28 |
brlcad |
vtts: the
combination editor has a shader button, select it, enter your
object name, hit enter, and you should see all of the parameters
available |
| 19:17.42 |
vtts |
yeah i'm
using it now |
| 19:17.58 |
brlcad |
ezzieyguywuf:
does your wireframe look like this: http://brlcad.org/tmp/mug.png |
| 19:18.39 |
*** join/#brlcad roberthl
(~robert@v001.rhl.me.uk) |
| 19:18.42 |
brlcad |
(besides the
line thickness) the inner rcc looks dashed here |
| 19:18.50 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 19:18.54 |
vtts |
but have few
objects and was thinking if it would be possible to define custom
shader, assign it to regions, and modify its parameters (instead of
settings for every object) |
| 19:19.37 |
ezzieyguywuf |
brlcad: it
does not. let me take a screenshot. |
| 19:20.06 |
brlcad |
vtts: ah,
that'd be "shader objects" which we don't yet implement but is on
our wish list |
| 19:20.17 |
vtts |
ok
then |
| 19:20.23 |
brlcad |
vtts: you can
copy shaders from objects to objects without too much
difficulty |
| 19:20.54 |
ezzieyguywuf |
brlcad:
http://ompldr.org/vN25zYw |
| 19:20.54 |
vtts |
ok, i guess
i'll catch up with that with tutorials |
| 19:21.19 |
ezzieyguywuf |
vtts: which
tutorial are you on? I'm on the mug :-P |
| 19:21.27 |
brlcad |
ezzieyguywuf:
huh, that is bizzare |
| 19:21.29 |
vtts |
ezzieyguywuf,
i guess the same |
| 19:21.46 |
ezzieyguywuf |
brlcad: crazy
huh? Maybe I have an odd version? how can I check my
vers? |
| 19:21.47 |
brlcad |
ezzieyguywuf:
try "Z" |
| 19:22.01 |
brlcad |
then redraw
the mug |
| 19:23.00 |
brlcad |
your version
is on the window titlebar, 7.16.8 -- wireframe code hasn't really
changed |
| 19:23.16 |
ezzieyguywuf |
brlcad:
http://ompldr.org/vN25zZg |
| 19:23.20 |
brlcad |
you can try
opening one of the example geometry database files, havoc.g for
example, |
| 19:23.32 |
vtts |
what could
you recommend to generate something like first/third-angle
projections (with measurements if possible)? |
| 19:24.32 |
brlcad |
ezzieyguywuf:
yeah, at a glance I would say we didn't have the same .g so
apparently a bug of some sort |
| 19:24.54 |
brlcad |
ezzieyguywuf:
hate to say it, but try restarting mged, redraw |
| 19:25.18 |
ezzieyguywuf |
I'll try,
though this has persisted across multiple sessions of mged with
different databases |
| 19:25.20 |
brlcad |
note that the
raytrace rendering not changing underneath is correct, not a
bug |
| 19:25.54 |
brlcad |
vtts:
first/third-angle projections? |
| 19:25.55 |
ezzieyguywuf |
brlcad: yea I
know, I zoomed into the wireframe to make it easier to see, but
left the raytrace so you could see it really was hollowed
out. |
| 19:26.09 |
brlcad |
vtts, do you
mean a perspective view? |
| 19:26.20 |
brlcad |
ezzieyguywuf:
k, just making sure :) |
| 19:26.25 |
brlcad |
some are
confused by that |
| 19:26.30 |
brlcad |
it's
intentional |
| 19:26.33 |
vtts |
brlcad, yes,
but for printing with measurements and so on. |
| 19:27.22 |
brlcad |
vtts: Misc
-> Perspective will turn on perspective viewing |
| 19:27.32 |
ezzieyguywuf |
http://ompldr.org/vN25zZw brlcad:
also, I sometimes get a garbled mged screen, as seen in this
screenshot. if I shift-translate the object, though, it draws
appropriately. |
| 19:27.58 |
brlcad |
you can set
the exact angle on the command line with "set perspective [value]"
or "set perspective" to see the current value |
| 19:27.59 |
ezzieyguywuf |
brlcad: yea,
restarted, still not dashed. |
| 19:28.03 |
ezzieyguywuf |
I'm doing
'draw mug.r' |
| 19:28.49 |
brlcad |
ezzieyguywuf:
that's probably with the framebuffer enabled and you resize the
window, yes? |
| 19:28.50 |
vtts |
brlcad,
view'ing is not the problem, multiplane is quite good |
| 19:29.05 |
vtts |
but i'd like
to generate some specs. with measurements |
| 19:29.25 |
brlcad |
ezzieyguywuf:
you're seeing uninitialized framebuffer memory -- can either turn
the framebuffer off, or (as you found out) refresh |
| 19:29.42 |
brlcad |
not the best,
but has been low priority to address since data isn't
affected |
| 19:30.03 |
ezzieyguywuf |
brlcad: ah
ok. is framebuffer something that is brl-cad specific, or is it the
same framebuffer that is referred it in my linux kernel
etc? |
| 19:31.09 |
brlcad |
ezzieyguywuf:
it's the same concept as referred to in the kernel, but different
construct |
| 19:31.10 |
CIA-14 |
BRL-CAD:
03brlcad * r43696 10/brlcad/trunk/TODO: resizing embedded
framebuffer sucks, fix it |
| 19:31.11 |
ezzieyguywuf |
=== load
framebuffer; +++ refresh framebuffer; === <rest of code>
:-P |
| 19:32.08 |
brlcad |
vtts:
ezzieyguywuf just asked about that earlier today (as do many) ..
annotations and dimensions are currently being worked on but not
yet ready |
| 19:32.39 |
brlcad |
you can get
the model rendered as a hidden line rendering but annotations would
have to be added manually in another tool unfortunately until that
support is complete |
| 19:33.08 |
vtts |
ok,
thanks |
| 19:33.24 |
ezzieyguywuf |
what does
'mater' stand for? |
| 19:34.00 |
vtts |
physical
substance :) |
| 19:34.19 |
ezzieyguywuf |
:-P and how
are the mater and shade commands different? |
| 19:34.28 |
brlcad |
until then,
this is about as close as you'll get http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html
and http://brlcad.org/gallery/s/screenshots/extractor.png.html |
| 19:34.46 |
brlcad |
easily
scripted for a series of views, but still no
annotations |
| 19:35.02 |
vtts |
ok,
np |
| 19:35.11 |
CIA-14 |
BRL-CAD:
03starseeker * r43697 10/brlcad/trunk/TODO: Got a report of nirt
not working correctly on Windows - Bob has reproduced this and is
working on it |
| 19:35.46 |
brlcad |
'help mater'
.. mater is short for material |
| 19:35.52 |
ezzieyguywuf |
ah
ok. |
| 19:36.29 |
brlcad |
which is a
bit of a misnomer in that context, because it's technically just
the shader for visualization -- the actual material code is
set/used elsewhere |
| 19:36.57 |
ezzieyguywuf |
yea, I was
getting confused. "Where's the density? Material properties?
Etc?" |
| 19:37.41 |
starseeker |
brlcad:
should we add a rename of mater->shader to the deprecation.txt
file? |
| 19:37.56 |
brlcad |
oof |
| 19:38.13 |
brlcad |
probably, but
that's hard even for me to swallow .. because it's been 'mater'
forever :) |
| 19:38.37 |
ezzieyguywuf |
lol. its
cool, I'll just keep thinking of that character from the Cars (tm)
movie :-P |
| 19:39.05 |
brlcad |
mater is
still better way to set the other combination properties, object
color and inheritance |
| 19:39.12 |
brlcad |
shader only
sets the shader |
| 19:39.18 |
brlcad |
so would have
to resolve the other two |
| 19:40.42 |
brlcad |
starseeker:
probably best to just hit up the lower hanging fruit first, that
one requires figuring out new command(s) and options to cover
mater's existing commands |
| 19:40.50 |
brlcad |
s/commands/settings/ |
| 19:41.05 |
starseeker |
nods |
| 19:41.11 |
starseeker |
just a
thought while it came up |
| 19:44.47 |
brlcad |
yeah, I think
you're right |
| 19:44.51 |
brlcad |
just maybe
"not now" |
| 19:46.20 |
ezzieyguywuf |
so is there a
way to print out the geometry of a given object? i.e. if I create
an rcc and later want to see what its vertex, height and radius
are? |
| 19:48.07 |
brlcad |
'l' |
| 19:48.11 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
| 19:48.12 |
brlcad |
for
list |
| 19:49.16 |
brlcad |
ezzieyguywuf:
oh, and to answer your question from earlier, there are a few
custom commands for creating objects based on cylinder end
points |
| 19:49.31 |
brlcad |
rcc[tab][tab]
should show them, help should describe them |
| 19:50.18 |
starseeker |
brlcad:
sweeeeet. The head of the old simplesat project sent me about 180
autocad dwg files detailing the simplesat |
| 19:50.30 |
ezzieyguywuf |
I was asking
more for in general though. For example, in SolidWorks I usually
create an object, draw some costruction lines, and then place
things 'tangen' or in the 'middle' or 'coincident' etc. |
| 19:50.43 |
ezzieyguywuf |
s/tangen/tangent/ |
| 19:50.47 |
brlcad |
starseeker:
AWESOME! |
| 19:50.55 |
brlcad |
are they
solid or drawings only? |
| 19:51.01 |
ezzieyguywuf |
I wonder if I
can build things relative to other things in brl-cad as
well. |
| 19:51.12 |
starseeker |
drawings
only, but he says it was all him so they should be public
domain |
| 19:51.21 |
starseeker |
awesome
material for a modeling project :-) |
| 19:51.22 |
ezzieyguywuf |
brlcad: well,
I guess drawings. but then I can 'mate' solid things in an assembly
using similar relations. |
| 19:51.36 |
ezzieyguywuf |
oh, nwm you
were asking him. |
| 19:52.05 |
starseeker |
ezzieyguywuf:
heh, sorry - irc conversations are often kinda jumbled |
| 19:52.06 |
brlcad |
ezzieyguywuf:
there are ways, but they're fairly manual ways and they won't (yet)
stay constrained |
| 19:52.22 |
ezzieyguywuf |
hrm I
see. |
| 19:52.40 |
ezzieyguywuf |
I can see
that being an issue if I make a part and end up wanting to scale
it, for whatever reason. |
| 19:52.48 |
ezzieyguywuf |
how would you
approach that in brl-cad? |
| 19:53.00 |
ezzieyguywuf |
edit the
database directly? |
| 19:53.04 |
brlcad |
they'll scale
up just fine |
| 19:53.35 |
brlcad |
because
you'll have combined associated objects together into common
regions or groups, and the scale would apply to all
members |
| 19:53.44 |
ezzieyguywuf |
well, in the
mug example: if I wanted a mug twice as big, I'd have to double the
size of the inner rcc, the outer rcc, and resize the handle
appropriately. |
| 19:53.55 |
brlcad |
ah, no you
woudln't |
| 19:54.06 |
brlcad |
you'd just
apply a matrix edit to the mug, and scale it |
| 19:54.32 |
ezzieyguywuf |
hrm i see.
the subject of a later lesson in the tutorial maybe? |
| 19:55.08 |
brlcad |
if you select
Edit -> Matrix Edit, then select mug.r, then select any one of
your primitives in the next window, you'll be able to select Scale
on the Edit menu among a whole other range of edit
options |
| 19:55.12 |
brlcad |
yep |
| 19:55.31 |
ezzieyguywuf |
cool cool,
I'll keep trudging along then. |
| 19:55.32 |
brlcad |
it starts out
really basic just because there are so many foreign
concepts |
| 19:55.40 |
ezzieyguywuf |
yea I
gotcha. |
| 19:55.49 |
brlcad |
even for
people with CAD experience, we deviate in some respects |
| 19:55.53 |
brlcad |
s/some/many/
:) |
| 19:55.55 |
ezzieyguywuf |
its like
learning to walk again, except its learning te solid model again
:-P |
| 19:56.09 |
ezzieyguywuf |
lol. |
| 19:56.42 |
brlcad |
nods, I hear ya |
| 19:57.12 |
brlcad |
working on
improving our usability is a bigger-picture area we're working on,
but that's major long-term complicated work :) |
| 19:57.50 |
brlcad |
developing a
new easier-to-use gui while not alienating existing expert modelers
is pretty tricky.. |
| 19:58.10 |
ezzieyguywuf |
meh, I'm not
afraid to spend a week or two learning a new software. |
| 19:58.19 |
ezzieyguywuf |
kinda got
used to it working with linux :-P |
| 19:58.51 |
ezzieyguywuf |
brlcad: I
kind of like that I can do everything from a command-line if I
want |
| 19:59.05 |
brlcad |
with the
exception of two of them, all the models on http://brlcad.org/gallery/s/renderings/
were completely designed within BRL-CAD in anywhere from a couple
days to a couple months for the more complex models (which some of
the experts have down to just a couple weeks for even the most
complex) |
| 19:59.11 |
ezzieyguywuf |
one of the
reasons I stuck around: I was mucking about in SolidWorks last week
and had to do some repetitive stuff and thought to myself, "hey,
this would be so easy to script" |
| 19:59.39 |
brlcad |
now scripting
is actually one of our strengths! :) |
| 19:59.50 |
brlcad |
we do that
better, more flexibly, than most |
| 20:00.15 |
brlcad |
you just have
to know the command layer basics first :) |
| 20:00.16 |
ezzieyguywuf |
yea! that's
why I want to learn brl-cad. |
| 20:02.18 |
brlcad |
the goliath
is a pretty good example of what's possible in a short amount of
time -- that was modeled by a summer student from scratch (starting
with a ruler and pad of paper, and the mged tutorials) in about 6
weeks |
| 20:02.33 |
brlcad |
http://brlcad.org/gallery/s/renderings/goliath/ |
| 20:04.08 |
ezzieyguywuf |
so
theoretically, I could take that goliath model and run it through
an FEA program do a heat-transfer analysis on it
somehow? |
| 20:04.22 |
ezzieyguywuf |
i.e. the
project is useful for than just pretty pictures? |
| 20:05.07 |
CIA-14 |
BRL-CAD:
03starseeker * r43698 10/brlcad/branches/cmake/ (20 files in 6
dirs): MFC r43697 |
| 20:05.31 |
brlcad |
the actual
one they measured: http://armor.callihan.cc/gallery/goliath/06-Aberdeen_0165.JPG |
| 20:05.42 |
brlcad |
sure |
| 20:06.48 |
brlcad |
the bridge to
FEA is a pain because most require conversion from solid model to
polygonal, but we do have a stable export path through Sandia
National Lab's Cubit tool, which is one of the best at finite
element meshing |
| 20:06.49 |
ezzieyguywuf |
mulitpane
mode = awesome. |
| 20:11.11 |
vtts |
it would be
even better if there was a way to make secondary planes react to
view changes of the primary one :) |
| 20:11.54 |
ezzieyguywuf |
vtts: ah hah,
that would be sweet |
| 20:12.06 |
ezzieyguywuf |
I like how
its un-coupled though, that comes in handy too. |
| 20:12.14 |
ezzieyguywuf |
but I see how
coupling two or more views would be nice. |
| 20:12.37 |
brlcad |
vtts: how
would they react? |
| 20:13.58 |
vtts |
well they all
have a center point |
| 20:14.14 |
vtts |
it would be
nice to see changes relative to it |
| 20:14.46 |
vtts |
e.g. moving
view, or changing azimuth |
| 20:15.52 |
vtts |
I'm not used
to it, so shortly after starting using it got confused about
orientation of the object in secondary panes |
| 20:16.00 |
vtts |
but thats
just me |
| 20:16.17 |
ezzieyguywuf |
if I am in
edit mode, how do I shift the screet without resizing the object
I'm editing? |
| 20:16.26 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 20:16.26 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 20:16.28 |
ezzieyguywuf |
I can zoom
it/out with left/right click, but I want to pan too |
| 20:16.48 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 20:17.09 |
vtts |
ezzieyguywuf,
try using "x", "y", "z" keys |
| 20:17.14 |
vtts |
ezzieyguywuf,
or ae command |
| 20:17.36 |
brlcad |
ezzieyguywuf:
there are a slew of bindings (including pan) |
| 20:17.51 |
brlcad |
shift grips
document lists them |
| 20:18.34 |
starseeker |
thinks tonight would be a good time to see how the libredwg
project is coming... I can convert these to something else
on-by-one if I have to, but scripting it would be so much
nicer/easier... |
| 20:18.42 |
vtts |
by the way,
ctrl+alt+mouse-click doesn't work as it's supposed to on mac
:( |
| 20:27.16 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43699 10/brlcad/trunk/ (5 files in 2 dirs): more
tfloat->fastf_t/TIE_3->vect_t|point_t conversion |
| 20:27.46 |
ezzieyguywuf |
so the diff
between combinations and regions is that a combination is a
combination of primitave objects to make a particular, more complex
geometry, whereas a region is a combination of combinations and/or
primitative objects to create a complex object with material props
right? |
| 20:28.36 |
starseeker |
ezzieyguywuf:
a region is regarded as a solid object - if two regions overlap, it
is a modeling error |
| 20:28.52 |
starseeker |
combinations
under a region can overlap |
| 20:31.38 |
ezzieyguywuf |
but how come
I go to the combination editor to edit shading etc, and not the
'region editor' |
| 20:32.03 |
starseeker |
because the
same editor can edit both regions and combinations |
| 20:32.08 |
starseeker |
regions are
just combinations with a flag set |
| 20:32.09 |
ezzieyguywuf |
hrm, I
see. |
| 20:32.50 |
starseeker |
in hindsight
it would probably have been better to make the user interface
respect the whole "regions are special" mantra a bit more, but it
currently reflects the implementation reality (regions are combs
with a flag) |
| 20:33.24 |
ezzieyguywuf |
also: is
sloppy focus hard coded into mged? I have my window-manager set up
so that focus does NOT follow the mouse, only mouse clicks. but
between my framebuffer and mged command-line I see sloppy
focus. |
| 20:33.40 |
ezzieyguywuf |
starseeker:
good to know. |
| 20:33.50 |
starseeker |
not sure
about the focus |
| 20:35.22 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 20:36.17 |
ezzieyguywuf |
ok question:
how come when I change the color via the combination editor, I have
to blash the respective region/combination in order to see the new
color? |
| 20:36.53 |
starseeker |
you mean why
isn't the color update reflected in the wireframe? |
| 20:37.53 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43700 10/isst/trunk/configure.ac: libtie is no
more, just librt |
| 20:37.57 |
ezzieyguywuf |
starseeker:
yea. |
| 20:38.26 |
starseeker |
if we're
drawing a model with a LOT of lines (BoT models can have huge
numbers) a wireframe view update is non-trivial from a resource
perspective |
| 20:38.35 |
starseeker |
that'd be my
guess |
| 20:38.39 |
ezzieyguywuf |
hrm, I
see. |
| 20:38.44 |
ezzieyguywuf |
what is
BoT? |
| 20:38.50 |
starseeker |
bag of
triangles |
| 20:38.50 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43701 10/isst/trunk/gtk/ (gui.c isst.h
local_worker.c main.c net_worker.c): update to compile against
latest BRL-CAD |
| 20:39.22 |
brlcad |
ezzieyguywuf:
in brl-cad language groups are assemblies, regions are parts, and
combinations are the mechanism for structuring regions and
groups |
| 20:39.55 |
vtts |
starseeker,
is there a command to check if regions overlap? |
| 20:39.55 |
ezzieyguywuf |
so
combinations are like drawings. |
| 20:40.08 |
ezzieyguywuf |
in SolidWorks
that is (I caught the assemblies and parts reference) |
| 20:40.14 |
starseeker |
vtts:
rtcheck |
| 20:40.20 |
vtts |
superb |
| 20:40.45 |
brlcad |
man, lot of
irc network issues today |
| 20:40.56 |
ezzieyguywuf |
silly
irc. |
| 20:42.15 |
brlcad |
ezzieyguywuf:
sort of like "drawings", but since we're strictly 3D-only, we refer
to them more as "shapes" |
| 20:42.36 |
ezzieyguywuf |
gotcha
gotcha. |
| 20:42.38 |
brlcad |
a shape
becomes solid and occupies space when you put it in a
region |
| 20:43.11 |
ezzieyguywuf |
so it makes
sense to use a 'region editor' then, and not a 'combination editor'
yea? |
| 20:43.31 |
ezzieyguywuf |
since
strictly speaking combinations are just representations of what
will eventually be a solid object. |
| 20:43.56 |
brlcad |
it really
should just be an "object editor" and show you parameters
accordingly based on the object you're editing |
| 20:44.22 |
brlcad |
the next
generation interface eliminates that distinction |
| 20:44.32 |
brlcad |
just shows a
panel of parameters |
| 20:44.37 |
ezzieyguywuf |
ah hah. b/c I
can change the color of the wireframe which represents the
combination. |
| 20:44.43 |
ezzieyguywuf |
cool. |
| 20:44.49 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43702 10/isst/trunk/sdl/ (Makefile.am event.c
isst.h main.c myplugin.c): disable texture fonts, make compile with
current BRL-CAD |
| 20:46.58 |
brlcad |
notes our release TODO is getting LONGER faster than it's
getting shorter.. urg! |
| 20:47.31 |
ezzieyguywuf |
lol. |
| 20:54.39 |
CIA-14 |
BRL-CAD:
03starseeker * r43703 10/geomcore/trunk/tests/svntest/main.c: Got
lists of assemblies and regions, but a deep keep of the region is
not quite so simple. This seems like it might be another case where
librt functionality is in order, but might already be there... need
to check |
| 21:22.52 |
brlcad |
starseeker:
sorry to say it but search is nfg |
| 21:23.44 |
brlcad |
actually
seems royally busted, all three tests failed on a simple
model |
| 21:24.58 |
starseeker |
you're
kidding |
| 21:25.08 |
starseeker |
what
tests? |
| 21:26.40 |
brlcad |
tried:
search . -name mug.g (returned error about failing to make a plan)
search / -name mug.g (returned nothing) search . (crashed
mged) |
| 21:26.41 |
starseeker |
debates between screaming and crying... |
| 21:28.20 |
brlcad |
probably best
to just revert trunk to prior state for release, get it into the
next release .. assuming tie bot raytracing works; if it doesn't
then we have more time still |
| 21:28.48 |
brlcad |
s/mug.g/mug.r/ .. was using the .g ezzie
posted earlier |
| 21:29.00 |
brlcad |
http://ompldr.org/vN25zOQ |
| 21:30.48 |
brlcad |
looks like
"search /" has plan problems, returns unknown option passed to
find_create() |
| 21:31.05 |
brlcad |
then Error:
Failed to build find plan. |
| 21:31.22 |
starseeker |
I don't
believe it |
| 21:31.30 |
starseeker |
how did it go
south so fast? |
| 21:31.38 |
starseeker |
or maybe I
was dreaming... |
| 21:31.41 |
starseeker |
will revert |
| 21:32.25 |
brlcad |
the librt
code can probably stay, doesn't have to be full revert |
| 21:33.03 |
starseeker |
will need to
revert raytrace.h |
| 21:33.14 |
starseeker |
grinds teeth... |
| 21:34.09 |
CIA-14 |
BRL-CAD:
03starseeker * r43704 10/geomcore/trunk/tests/svntest/main.c:
something not right here... keep isn't creating much of anything in
the way of geometry... |
| 21:34.28 |
starseeker |
not good...
can't afford this right now |
| 21:35.07 |
brlcad |
you're in
good company, lots of hard show-stoppers |
| 21:35.23 |
brlcad |
see if bob
can fix the combination editor while's he's in there working on
nirt :) |
| 21:36.57 |
starseeker |
brlcad: real
quick - does search in its current form work on the command
line? |
| 21:37.07 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43705
10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: clean up #if
0 stuff |
| 21:37.10 |
starseeker |
e.g. mged
mug.g search . -name mug.r |
| 21:38.18 |
brlcad |
. works, /
doesn't |
| 21:38.25 |
brlcad |
interesting |
| 21:38.45 |
brlcad |
search . also
still crashes |
| 21:40.41 |
starseeker |
sees one error right off |
| 22:02.57 |
starseeker |
brlcad:
before I revert, can you give r43706 a go? |
| 22:03.09 |
CIA-14 |
BRL-CAD:
03starseeker * r43706 10/brlcad/trunk/src/ (libged/search.c
librt/search.c): Variety of fixes to both libged and librt search
logic. |
| 22:04.59 |
brlcad |
sure |
| 22:07.57 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43707 10/brlcad/trunk/ (5 files in 2 dirs):
revert to 43698, caused weird errors in output |
| 22:09.03 |
CIA-14 |
BRL-CAD:
03starseeker * r43708 10/brlcad/trunk/src/libged/search.c: Catch
another odd input case |
| 22:09.18 |
brlcad |
wow, isn't
that like all of your changes ``Erik |
| 22:10.55 |
``Erik |
heh, this was
a really weird one, bunches of misses showing up even on
cubes |
| 22:11.02 |
``Erik |
bastage
O.o |
| 22:16.51 |
starseeker |
waits in suspense... |
| 22:19.24 |
ezzieyguywuf |
how can I do
a primitive selection from the command-line? |
| 22:21.26 |
brlcad |
starseeker:
rebuilding now, testing in a few |
| 22:21.35 |
brlcad |
ezzieyguywuf:
sed |
| 22:21.35 |
CIA-14 |
BRL-CAD:
03brlcad * r43709 10/brlcad/trunk/TODO: combination editor bug
confirmed, mged init on mac DISPLAY issue wasn't specific to mged
so not a show-stopper (mged stall if started from Terminal,
restarting X11 fixed it) |
| 22:21.57 |
brlcad |
sed and oed
are the two ways to go into an edit mode from the command
line |
| 22:22.17 |
brlcad |
the latter
being pretty powerful, but a bit obtuse to use -- there is a
tutorial dedicated to it on the website |
| 22:22.40 |
brlcad |
it's how
you'd scale up, translate, rotate groups of geometry |
| 22:24.00 |
ezzieyguywuf |
brlcad: ah,
thanks. |
| 22:24.20 |
ezzieyguywuf |
heh, funny
how so many of mged commands are the same as unix
commands. |
| 22:24.21 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43710 10/brlcad/trunk/ (4 files in 2 dirs):
shift tie min/max to point_t |
| 22:39.28 |
brlcad |
starseeker:
that's looking MUCH better already |
| 22:39.56 |
brlcad |
'search .'
and 'search /' don't do the right thing, but quick test with -name
and -type seem to work as expected |
| 22:41.16 |
brlcad |
globbing
doesn't seem to be working right |
| 22:41.38 |
brlcad |
e.g.: search
. -name * |
| 22:42.31 |
starseeker |
try search .
-name \* maybe? |
| 22:42.36 |
brlcad |
hm. same test
that worked on the simple model is returning nothing for havoc for
both "search . -type c" and "search / -type c" .. |
| 22:42.39 |
starseeker |
or from the
command line search . -name \\* |
| 22:42.40 |
brlcad |
tried that,
nothing |
| 22:43.02 |
brlcad |
yeah, variety
of regression failures even for / |
| 22:43.06 |
starseeker |
odd, works
here... |
| 22:43.22 |
starseeker |
oh wait,
type... |
| 22:43.37 |
starseeker |
no, that
works too... |
| 22:43.54 |
brlcad |
worked on the
mug model, but not havoc |
| 22:44.35 |
starseeker |
tries havoc |
| 22:45.10 |
starseeker |
seems to
work... |
| 22:45.32 |
starseeker |
uh... |
| 22:45.36 |
starseeker |
what
platform? |
| 22:46.03 |
brlcad |
10.6 |
| 22:46.39 |
CIA-14 |
BRL-CAD:
03starseeker * r43711 10/geomcore/trunk/tests/svntest/main.c: Woot
- that was it, ignore nref in node write and we get
content |
| 22:46.56 |
brlcad |
hm, worked if
I restarted mged |
| 22:47.10 |
brlcad |
hope you're
not using static variables somewhere... |
| 22:47.42 |
starseeker |
not
intentionally... |
| 22:51.59 |
brlcad |
there we go,
got it to repeat |
| 22:51.59 |
brlcad |
not sure how
it's caused, but eventually, I can get it into a state where it
stops working |
| 22:52.04 |
starseeker |
great |
| 22:52.11 |
starseeker |
starts reverting... |
| 22:52.32 |
brlcad |
sounds like
it's really close, but just not very stable |
| 22:52.55 |
starseeker |
it just
returns nothing? |
| 22:53.01 |
brlcad |
yea |
| 22:53.11 |
brlcad |
opened havoc,
everything I tried worked |
| 22:53.13 |
starseeker |
and you just
did searches for a while? |
| 22:53.14 |
brlcad |
including
globbing |
| 22:53.40 |
brlcad |
then swapped
to mug.r, repeated random -type -name searches |
| 22:54.07 |
brlcad |
some
intentionally working but some not working (that should, like
"search ." and "search /") |
| 22:54.22 |
brlcad |
then switched
back to havoc (via opendb), and it was dead |
| 22:54.43 |
starseeker |
uh... what do
you expect for search . and search / - there's no plan
there |
| 22:54.54 |
brlcad |
plan is
optional |
| 22:55.17 |
brlcad |
according to
usage at least, which is how 'find' is too -- should return
everything |
| 22:55.24 |
brlcad |
no
plan |
| 22:57.15 |
starseeker |
I doubt that
has ever been true - if it was, it was accidental |
| 22:57.15 |
brlcad |
search .
becomes very similar to "ls *", search / becomes like "tree
[tops]" |
| 22:57.15 |
brlcad |
I remember
trying it earlier at one point and you had it working
:) |
| 22:57.19 |
starseeker |
not
intentionally |
| 22:57.24 |
brlcad |
subpath
searching seemed to have issues too, search /havoc -type
c |
| 22:57.36 |
brlcad |
search
/havoc/. -type c was fun |
| 22:57.51 |
brlcad |
fun as in
didn't do anything :) |
| 22:58.30 |
starseeker |
it's a pretty
good bet the option parsing for the strings isn't up to all those
options |
| 22:59.22 |
brlcad |
nods |
| 22:59.57 |
starseeker |
I had to be
getting lucky on how things fell through earlier, 'cause I sure
didn't have anything sophisticated in place |
| 23:00.08 |
brlcad |
that last one
would have been fine, heck could even limit usage to just "search
[.|] [plan]" but having it stop outright after a bit is
disconcerting :) |
| 23:00.09 |
starseeker |
the "do
nothing" thing worries me more |
| 23:00.24 |
brlcad |
yep |
| 23:00.35 |
starseeker |
you can't
hook a debugger up and track it somehow? |
| 23:00.45 |
starseeker |
will try to reproduce... |
| 23:01.04 |
brlcad |
not at the
moment, have build working on the other issue, but can poke on it
some more in a bit |
| 23:01.34 |
starseeker |
cool - I'll
lay off reverting for now then. From what ``Erik was saying, it
sounds like he's got a bit more to go there |
| 23:02.05 |
brlcad |
``Erik: think
it'll be this weekend or you'll need more time? |
| 23:03.01 |
starseeker |
think he's on
his way home |
| 23:10.23 |
brlcad |
k, sending an
update to the list then |
| 23:18.35 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
| 23:20.19 |
ezzieyguywuf |
you know, I
start mged from a terminal. unless I explicitly type exit into
mged, though, the process stays alive. i.e. I can X out the
framebuffer window (which destroys the mged prompt window as well)
and kill the term that I launched mged from and the process
persists. I feel like this is a serious issue. |
| 23:20.38 |
starseeker |
brlcad: the
iteration over dbip->dbi_Head is failing - all the directory
pointers are coming back null |
| 23:20.49 |
starseeker |
how could
that happen? |
| 23:33.20 |
brlcad |
starseeker:
maybe something is freeing memory |
| 23:34.10 |
starseeker |
it's not
that... I checked ls, it's working |
| 23:34.19 |
starseeker |
most are
null, but clearly not all |
| 23:34.22 |
``Erik |
it works for
64b, 32 gets off... I think there may be a rogue ptr +=
sizeof(bah*) that's not quite right or something... feel free to
take a look if ya want, there's not that much code... the optimized
split routine is a major portion, and it's not used with the
default path |
| 23:34.26 |
starseeker |
forgot it's a hash table |
| 23:34.41 |
``Erik |
(mebbe I'm
too deep in it, fresh eyes might spot something
obvious) |
| 23:35.43 |
``Erik |
(my only 32b
box is fbsd, which might align things different than other
platforms, too...) |
| 23:36.34 |
starseeker |
is down in the pattern matching in the back trace now, which
is scary scary turf... |
| 23:36.49 |
brlcad |
ezzieyguywuf:
if you can characterize exact steps to reproduce the problem and
what you're expecting it to do (even if it's exactly the steps you
just mentioned), please report it as a bug to the bug tracker:
https://sourceforge.net/tracker/?func=add&group_id=105292&atid=640802 |
| 23:37.09 |
ezzieyguywuf |
brlcad:
sure. |
| 23:37.12 |
brlcad |
closing the
graphics window is supposed to shut down mged (whereas closing the
command window is not) |
| 23:37.30 |
brlcad |
I known issue
on Mac OS X makes it not close there, but should work for
linux |
| 23:37.47 |
brlcad |
and windows,
don't know that it's been tested there in a while |
| 23:37.50 |
ezzieyguywuf |
maybe its cuz
I'm running it in gnome and not a qt-based DE |
| 23:38.07 |
brlcad |
shouldn't
matter, but can describe your setup in the report |
| 23:38.37 |
ezzieyguywuf |
you sure that
link you gave me is right? |
| 23:44.11 |
CIA-14 |
BRL-CAD:
03brlcad * r43712 10/brlcad/trunk/TODO: yet another, gqa gets in
line |
| 23:46.53 |
brlcad |
iirc, it's
actually the job of the terminal program to decide whether to kill
or detact processes that are still running if a terminal session is
closed |
| 23:46.54 |
brlcad |
so that might
be a gnome-terminal issue |
| 23:46.54 |
brlcad |
but closing
the graphics window should have exited mged |
| 23:46.54 |
brlcad |
it's right if
you already have an sf account, otherwise, can go here: https://sourceforge.net/tracker/?group_id=105292&atid=640802 |
| 23:46.54 |
brlcad |
bug reports
require an sf account so we can interact with the
submitter |
| 23:53.39 |
starseeker |
aaand I wiped
out the process that reproduced it |
| 23:53.40 |
starseeker |
lovely |
| 23:55.31 |
starseeker |
ah
ha |
| 23:55.58 |
brlcad |
needs a good shader example |
| 23:59.30 |
CIA-14 |
BRL-CAD:
03starseeker * r43713
10/brlcad/trunk/src/librt/search.c: |
| 23:59.31 |
CIA-14 |
BRL-CAD:
Looks like that doggone global was stuck in 'on', and because it
started that |
| 23:59.31 |
CIA-14 |
BRL-CAD: way
the plans never formed properly - they assumed no output command
was needed |
| 23:59.31 |
CIA-14 |
BRL-CAD: when
it was. The global was inherited from the design of find, and I
never |
| 23:59.31 |
CIA-14 |
BRL-CAD:
cared for it, but it'll be a bit of work to do it any other way so
for now just |
| 23:59.31 |
CIA-14 |
BRL-CAD: make
sure it's zero before we start forming plans. |
| 00:02.30 |
starseeker |
brlcad: I
can't get it to enter the bad state again, but I just managed to
see that that variable was on before I lost the other debug
session |
| 00:02.44 |
starseeker |
pretty sure
that's it - it would make sense |
| 00:07.57 |
brlcad |
what
variable? |
| 00:08.03 |
starseeker |
db_search_isoutput |
| 00:08.14 |
brlcad |
static? |
| 00:08.27 |
starseeker |
checks... |
| 00:08.49 |
brlcad |
shouldn't
really be anything static in the code pushed up into librt, or even
the code in libged really |
| 00:08.49 |
starseeker |
no |
| 00:09.01 |
brlcad |
as that
implies statefulness |
| 00:09.12 |
starseeker |
search.c in
librt, line 103 |
| 00:09.44 |
starseeker |
it does
control state during the building of the plan, iirc |
| 00:10.12 |
brlcad |
ahh,
worse! |
| 00:10.13 |
brlcad |
global |
| 00:10.18 |
brlcad |
that's
statefulness |
| 00:10.21 |
starseeker |
nods |
| 00:10.29 |
starseeker |
that's been
thre |
| 00:10.33 |
starseeker |
s/thre/there |
| 00:10.36 |
starseeker |
from the
get-go |
| 00:11.05 |
starseeker |
so probably
we never stressed the other search implementation enough to spot
it, or we got lucky and avoided any badness
accidentally |
| 00:11.24 |
brlcad |
you have full
controll of the calling params, should be easy to
eliminate |
| 00:11.39 |
starseeker |
you mean pass
it around? |
| 00:11.48 |
brlcad |
better than a
global |
| 00:12.00 |
brlcad |
especially in
a lib |
| 00:12.01 |
starseeker |
can do that, but it means changing a lot of function arg
lists to match a new template |
| 00:12.08 |
starseeker |
nods |
| 00:12.44 |
starseeker |
I can do it,
but not tonight - I'm a half hour late now :-/ |
| 00:12.57 |
brlcad |
at a minimum,
the global could be changed to be a static scope global, so it's
only accessible via those functions |
| 00:13.01 |
brlcad |
nods |
| 00:13.11 |
brlcad |
no worries,
we have at least a couple days of debugging |
| 00:13.23 |
starseeker |
gqa blew up
too... augh |
| 00:13.55 |
starseeker |
making sure
the formation of the plan starts with it at zero should do for now,
and next week I'll eliminate the global |
| 00:14.03 |
brlcad |
suspect gqa
will be easy |
| 00:14.35 |
starseeker |
at least the
pipe fix was kinda nifty - nice work on that (you and
d_rossberg) |
| 00:14.59 |
starseeker |
(and ``Erik
for suggesting clamp) |
| 00:16.48 |
starseeker |
while I'm at
it, I'll try to get search . and search / to work - could cheat and
just supply -name * by default if no plan is available |
| 00:17.21 |
starseeker |
or probably
just -print |
| 00:18.01 |
starseeker |
actually,
come to think of it that should be the result of calling
db_search_formplan with an empty argv list - will have to confirm
that |
| 00:18.15 |
starseeker |
heads out |
| 00:18.39 |
brlcad |
yeah, I
suspect it'll just happen if you specify no plan |
| 00:29.04 |
CIA-14 |
BRL-CAD:
03brlcad * r43714 10/brlcad/trunk/src/librt/db5_types.c: put
bu_vls_true() to use so that we can more robustly detect true/false
string values for standard attributes. note that the bu_str_true()
will match 'R' as true too since only clearly negative values
constitute false. |
| 00:30.48 |
CIA-14 |
BRL-CAD:
03bob1961 * r43715 10/brlcad/trunk/src/libged/nirt.c: Fixed a bug
in libged/nirt.c that was tripping in the /* skip commands */
section of the windows specific code when an object being passed to
nirt contained -e in its name. |
| 00:36.29 |
brlcad |
pretty
awesome:
http://www.engineeringtv.com/video/Opposed-Piston-Opposed-Cylinder |
| 00:44.06 |
CIA-14 |
BRL-CAD:
03brlcad * r43716 10/brlcad/trunk/src/librt/db5_types.c: ws
cleanup |
| 00:50.28 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 01:57.29 |
*** join/#brlcad dloman_
(~claymore@BZ.BZFLAG.BZ) |
| 01:58.33 |
*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) |
| 02:30.09 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 03:44.09 |
starseeker |
tofu: looks
like the pipe fix is confirmed |
| 03:47.43 |
CIA-14 |
BRL-CAD:
03starseeker * r43717 10/brlcad/branches/cmake/ (10 files in 5
dirs): MFC r43716 |
| 04:23.47 |
starseeker |
aaaand
libredwg doesn't get to first base |
| 04:30.28 |
starseeker |
growl...
http://www.opendesign.com/teigha_viewer
can view 'em but not export 'em |
| 04:31.29 |
brlcad |
starseeker:
those are prime for import into autocad or proe then export as
iges, step, and dxf |
| 04:32.42 |
starseeker |
nods - proe can read them and export them as a number of
things (including pdf, which is probably most immediately useful
since they aren't solid) but it'll be a long slog to do 180 one by
one (especially into multiple formats) |
| 04:33.08 |
starseeker |
installed rpm on gentoo just to get that viewer, too...
grumble |
| 04:33.18 |
brlcad |
iirc, proe on
the linux side can be scripted |
| 04:52.14 |
CIA-14 |
BRL-CAD:
03brlcad * r43718
10/brlcad/trunk/src/libbu/booleanize.c: |
| 04:52.14 |
CIA-14 |
BRL-CAD:
expand on bu_str_true() so that we can distinguish more strongly
between values |
| 04:52.14 |
CIA-14 |
BRL-CAD: that
seem to be false or true and 'everything else'. Unrecognized
responses |
| 04:52.14 |
CIA-14 |
BRL-CAD:
still return as true, but should return as >1 so callers can
distinguish yes/no |
| 04:52.14 |
CIA-14 |
BRL-CAD: from
possible input exceptions. return the first character as the
exception |
| 04:52.15 |
CIA-14 |
BRL-CAD:
value for posterity. |
| 04:52.49 |
CIA-14 |
BRL-CAD:
03brlcad * r43719 10/brlcad/trunk/include/bu.h: document that
callers can distinguish potential exceptions with return values
>1 |
| 05:24.33 |
CIA-14 |
BRL-CAD:
03brlcad * r43720 10/brlcad/trunk/src/mged/cmd.c: even with the
plain wrapper, if the ged func returns GED_MORE, respect its
authoritah |
| 06:09.56 |
CIA-14 |
BRL-CAD:
03brlcad * r43721 10/brlcad/trunk/src/mged/cmd.c: (log message
trimmed) |
| 06:09.56 |
CIA-14 |
BRL-CAD:
implement some nifty redraw code that looks at what objects are
displayed and |
| 06:09.56 |
CIA-14 |
BRL-CAD: what
command-line arguments were specified. if displayed objects are
being |
| 06:09.56 |
CIA-14 |
BRL-CAD:
listed on the command line, then they are potentially being edited
so go ahead |
| 06:09.57 |
CIA-14 |
BRL-CAD: and
redraw them. while this might cause redraw lag for huge models on
commands |
| 06:09.57 |
CIA-14 |
BRL-CAD: that
are merely read-only, the more common problem is the display not
being |
| 06:09.58 |
CIA-14 |
BRL-CAD:
refreshed when it should for commands that DO edit the geometry,
leading to user |
| 06:14.10 |
CIA-14 |
BRL-CAD:
03brlcad * r43722 10/brlcad/trunk/NEWS: |
| 06:14.10 |
CIA-14 |
BRL-CAD: with
the automatic redraw code now in the base wrapper, about 120 mged
commands |
| 06:14.10 |
CIA-14 |
BRL-CAD: will
potentially refresh the display that would have otherwise including
dozens |
| 06:14.10 |
CIA-14 |
BRL-CAD: that
modify geometry. display updates on changes should improve
usability, |
| 06:14.11 |
CIA-14 |
BRL-CAD:
reduce confusion, and help mged be more consistent |
| 06:18.25 |
CIA-14 |
BRL-CAD:
03brlcad * r43723 10/brlcad/trunk/src/libged/mater.c: (log message
trimmed) |
| 06:18.25 |
CIA-14 |
BRL-CAD:
restore incremental prompting functionality to the mater command.
even better |
| 06:18.25 |
CIA-14 |
BRL-CAD: than
before. leverage GED_MORE for additional prompting for any
unspecified |
| 06:18.25 |
CIA-14 |
BRL-CAD:
arguments. also takes advantage of bu_str_true()'s ability to
detect input |
| 06:18.25 |
CIA-14 |
BRL-CAD:
exceptions. this feature was prompted by discussions with
ezzieyguywuf via IRC |
| 06:18.25 |
CIA-14 |
BRL-CAD: and
having run into the problem myself several times, where
mater |
| 06:18.26 |
CIA-14 |
BRL-CAD:
unintentionally stopped prompting for missing arguments when it was
migrated to |
| 06:23.41 |
CIA-14 |
BRL-CAD:
03brlcad * r43724 10/brlcad/trunk/NEWS: |
| 06:23.41 |
CIA-14 |
BRL-CAD:
restored interactive prompting for mged's 'mater' command, which
was |
| 06:23.41 |
CIA-14 |
BRL-CAD:
functionality lost during the migration to libged.this feature was
prompted |
| 06:23.41 |
CIA-14 |
BRL-CAD:
after discussions with ezzieyguywuf via IRC and after having run
into the |
| 06:23.41 |
CIA-14 |
BRL-CAD:
problem myself several times while modeling. tutorial documentation
was |
| 06:23.41 |
CIA-14 |
BRL-CAD:
inconsistent as it relied on the interactive prompting for
instruction. |
| 06:24.55 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.249.60) |
| 06:24.55 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:52.55 |
CIA-14 |
BRL-CAD:
03brlcad * r43725 10/brlcad/trunk/src/libged/mater.c: restore the
previous mater command behavior to report the current values being
set when prompting the user for new values. approximate the old
text not worry too much about getting a perfect match. |
| 06:59.31 |
CIA-14 |
BRL-CAD:
03brlcad * r43726 10/brlcad/trunk/src/libged/mater.c: go ahead and
expand the green and blue component values. also make it clear that
the values being shown are the current values. |
| 07:04.01 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.168.51) |
| 07:04.01 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:59.27 |
CIA-14 |
BRL-CAD:
03brlcad * r43727 10/brlcad/trunk/src/libged/mater.c: |
| 07:59.28 |
CIA-14 |
BRL-CAD:
further efforts to mime the old behavior or better. make the g and
b color |
| 07:59.28 |
CIA-14 |
BRL-CAD:
components optional once again if the color is being deleted. add
back support |
| 07:59.28 |
CIA-14 |
BRL-CAD: for
deleting the shader string and color setting. use '.' to skip
parameters |
| 07:59.28 |
CIA-14 |
BRL-CAD:
(here we deviate from original since we can't yet set default more
parameters. |
| 08:00.25 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 08:02.00 |
CIA-14 |
BRL-CAD:
03brlcad * r43728 10/brlcad/trunk/src/libged/mater.c: fix the
prompt if we're skipping/deleting the color, account for an offset
of two. |
| 08:02.10 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:10.22 |
*** part/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 08:17.43 |
CIA-14 |
BRL-CAD:
03brlcad * r43729 10/brlcad/trunk/src/libged/mater.c: offset
pushing towards the wrong direction, be positive. also catch the
error case where color has been deleted but then later is
'skipped'. |
| 08:25.46 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 08:29.56 |
CIA-14 |
BRL-CAD:
03brlcad * r43730 10/brlcad/trunk/src/libged/mater.c: tweak the
usage, let user know which channel is teh suck |
| 08:30.36 |
CIA-14 |
BRL-CAD:
03brlcad * r43731
10/brlcad/trunk/doc/docbook/lessons/en/mged11_refining_mug.xml:
update tutorial example interactive output for the mater command to
reflect new form |
| 08:32.15 |
CIA-14 |
BRL-CAD:
03brlcad * r43732 10/brlcad/trunk/TODO: mater now properly prompts
for missing parameters interactively |
| 08:35.51 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.15.235) |
| 08:35.51 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:37.26 |
CIA-14 |
BRL-CAD:
03brlcad * r43733 10/brlcad/trunk/ (NEWS TODO): |
| 08:37.26 |
CIA-14 |
BRL-CAD: bob
reportedly fixed the bug causing nirt to not work on windows. user
reported |
| 08:37.26 |
CIA-14 |
BRL-CAD: that
nirt on windows was failing if run in a command window. bob found
a |
| 08:37.26 |
CIA-14 |
BRL-CAD:
problem where it was getting tripped up on objects with '-e' in
their name. |
| 09:22.29 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 09:57.52 |
*** join/#brlcad Ralith_
(~ralith@S010600221561996a.vc.shawcable.net) |
| 11:13.16 |
CIA-14 |
BRL-CAD:
03jordisayol * r43734 10/brlcad/trunk/sh/ (make_deb.sh
make_rpm.sh): update copyright to 2011 |
| 13:11.14 |
starseeker |
makes a note to check into Pro/Batch |
| 13:30.42 |
starseeker |
yeah... the
Tegiha file convertor worked under wine, and librecad can open the
dxf files (so can we with dxf-g) but there aren't any good ways I
can find to get decent pdf output - gonna have to use Pro/Batch or
something like it |
| 13:46.46 |
starseeker |
O.o freecad
is in main portage now? (wrong category, media-gfx, but
still...) |
| 13:47.16 |
starseeker |
tries it... haven't had great luck with the sci overlay
builds to date... |
| 14:34.06 |
CIA-14 |
BRL-CAD:
03starseeker * r43735 10/brlcad/branches/cmake/src/librt/ (search.c
search.h): |
| 14:34.06 |
CIA-14 |
BRL-CAD:
Globals are evil - need to pass db_search_isoutput around as a
parameter during |
| 14:34.06 |
CIA-14 |
BRL-CAD: the
process of forming the plan. As a side benefit, it shouldn't be
necessary |
| 14:34.06 |
CIA-14 |
BRL-CAD: for
f_print to reset the value anymore, since the scope of the variable
is now |
| 14:34.06 |
CIA-14 |
BRL-CAD:
limited to the plan forming process |
| 14:34.30 |
starseeker |
brlcad: I
think that's got it |
| 14:34.44 |
starseeker |
still need to
fix behavior for search . and friends |
| 14:50.27 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 15:01.40 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 15:03.31 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 15:03.46 |
*** part/#brlcad piksi (piksi@pi-xi.net) |
| 15:40.28 |
ezzieyguywuf |
wow, brlcad
you've been busy. |
| 15:40.36 |
ezzieyguywuf |
I still need
to submit that bug report... |
| 16:04.03 |
ezzieyguywuf |
ah, another
discrepency I noticed in the tutorials is when it tells you to cp
certain shapes, it never tells you that you have to draw them first
before you can do anything to them. |
| 16:31.30 |
starseeker |
those hessi
dwg files may be even more extensive than simplesat... |
| 16:31.35 |
starseeker |
sweet |
| 16:48.18 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 17:35.17 |
ezzieyguywuf |
heh, I'm
running mged vers 7.16.8 which is > vers 6.0 so according to the
tute the order of inside should be botto-top-rear-front-right-left
but instead I got front-rear-right-left-bottom-top |
| 17:36.50 |
vtts |
are all menu
actions executable from command line? e.g. is it possible to enter
multi pane mode, set active pane, show model axes on it and so
on? |
| 17:41.44 |
ezzieyguywuf |
vtts: pretty
sure you can. checkout the quick reference card. |
| 17:42.11 |
vtts |
didn't find
it there |
| 17:42.14 |
ezzieyguywuf |
hrm. |
| 17:42.42 |
vtts |
i can change
view options of an active pane, but don't know how tu change mode
or switch to other pane |
| 17:43.30 |
vtts |
found a few
functions in the source, but don't know where to get id from (e.g.
setmv id) |
| 17:44.43 |
vtts |
eh... silly
me... id is on the title bar |
| 17:44.59 |
vtts |
does a face-palm action |
| 17:45.24 |
ezzieyguywuf |
:-D |
| 18:04.20 |
ezzieyguywuf |
hrm, still no
dotted lines for me.... |
| 18:33.23 |
ezzieyguywuf |
so man, its
taking a while for the raytracer to raytrace this toy truck.
sometimes it even fails. Could it be I'm doing something
wrong? |
| 18:33.38 |
ezzieyguywuf |
I would
expect perfermance for something of this simple geometry to be
pretty good. |
| 18:36.08 |
ezzieyguywuf |
http://ompldr.org/vN29hYw
screenshot of raytrace after ~1min |
| 19:40.56 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.133.151) |
| 19:40.56 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:15.05 |
ezzieyguywuf |
so....what
are my chances of modelling an airfoil using brl-cad? |
| 22:22.24 |
CIA-14 |
BRL-CAD:
03jordisayol * r43736 10/brlcad/trunk/ (10 files in 3 dirs): add
new GNU/Linux mime-type icons for geometry db file v.4 and
v.5 |
| 23:13.39 |
Ralith |
Would there
be any interest in an effort to add GPU accelereation to the
raytracer? |
| 23:58.35 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 01:14.33 |
starseeker |
vtts:
rtedge |
| 03:43.26 |
brlcad |
starseeker:
so good news is I figured out the cause for why the combination
editor no longer works, bad news is it was the pacakge require
replacements you put in leu of ITcl_Init() in mged's
setup.c |
| 03:56.28 |
CIA-14 |
BRL-CAD:
03brlcad * r43737 10/brlcad/trunk/ (NEWS TODO
src/mged/setup.c): |
| 03:56.29 |
CIA-14 |
BRL-CAD:
fixed the combination editor. didn't achieve understanding into the
underlying |
| 03:56.29 |
CIA-14 |
BRL-CAD:
cause (left as an exercise to the reader), but changing Itcl_Init()
to a |
| 03:56.29 |
CIA-14 |
BRL-CAD:
'package require Itcl' was not equivalent. iwidgets ends up
attempting to |
| 03:56.29 |
CIA-14 |
BRL-CAD:
create a class twice (LabeledFrame) causing a runtime error.
changed back so |
| 03:56.29 |
CIA-14 |
BRL-CAD:
release can progres. |
| 04:03.00 |
CIA-14 |
BRL-CAD:
03brlcad * r43738 10/brlcad/trunk/src/util/: rtwizard moved to
tclscripts |
| 04:08.36 |
CIA-14 |
BRL-CAD:
03brlcad * r43739
10/brlcad/trunk/src/tclscripts/rtwizard/rtwizard.tcl: use the same
initialization approach archer uses so rtwizard will run prior to
installation |
| 04:19.24 |
CIA-14 |
BRL-CAD:
03brlcad * r43740 10/brlcad/trunk/src/bwish/ (cadAppInit.c
main.c): |
| 04:19.24 |
CIA-14 |
BRL-CAD: same
patch applied to mged for unbreaking the Combination Editor applies
here. |
| 04:19.24 |
CIA-14 |
BRL-CAD:
confirmed that archer and rtwizard were non-functional, would not
start, due to |
| 04:19.24 |
CIA-14 |
BRL-CAD:
multiple class errors. this reverts the package require back to an
Itcl_Init(), |
| 04:19.24 |
CIA-14 |
BRL-CAD: itk
too. archer/rtwizard now start up again. |
| 04:23.05 |
brlcad |
vtts: the bug
you reported here is now fixed, thanks |
| 04:26.52 |
CIA-14 |
BRL-CAD:
03brlcad * r43741 10/brlcad/trunk/NEWS: (log message
trimmed) |
| 04:26.53 |
CIA-14 |
BRL-CAD: may
or may not be specific to Mac OS X, but the bug report and
confirmation were |
| 04:26.53 |
CIA-14 |
BRL-CAD: both
on Mac OS X. the bug prevented both archer and rtwizard (both
bwish-based) |
| 04:26.53 |
CIA-14 |
BRL-CAD: from
running. they'd abort out during initialization with a multiple
class |
| 04:26.53 |
CIA-14 |
BRL-CAD:
error. problem was isolated as a change to the way bwish
initialized. thanks |
| 04:26.53 |
CIA-14 |
BRL-CAD: to
vtts for reporting the related combination editor bug via IRC.
Runtime |
| 04:26.54 |
CIA-14 |
BRL-CAD:
release testing for the previous release presumably happened on
Linux, so this |
| 04:30.52 |
starseeker |
is getting rather tired of Itcl/Itk |
| 04:31.04 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 04:31.10 |
brlcad |
oops |
| 04:31.15 |
starseeker |
is getting rather tired of Itcl/Itk |
| 04:32.19 |
brlcad |
I presume
those package require changes were tested on Linux? |
| 04:32.39 |
starseeker |
I've been
using them to do everything for a while now |
| 04:32.58 |
starseeker |
Windows, Mac
and Linux |
| 04:33.14 |
brlcad |
on Mac?
rtwizard loads? |
| 04:33.33 |
starseeker |
dunno about
rtwizard - will have to check tomorrow if I can make it
in |
| 04:33.42 |
starseeker |
has a leak somewhere |
| 04:33.47 |
brlcad |
mged would
start just fine, it wasn't until it hit a panel that used
iwidgets |
| 04:33.49 |
starseeker |
basement
carpet is wet |
| 04:33.55 |
brlcad |
fun! |
| 04:33.57 |
brlcad |
not |
| 04:34.07 |
starseeker |
and we found
out one of our cats has gone blind |
| 04:34.13 |
starseeker |
this has been
a real kicker of a weekend |
| 04:34.14 |
brlcad |
aw |
| 04:43.46 |
CIA-14 |
BRL-CAD:
03brlcad * r43742 10/brlcad/trunk/TODO: search seems to be working
much better now, but noticed several non-critical test failures
that current usage docs (and reasonable expectations) indicate they
should work. most are pretty simple. |
| 07:10.55 |
*** join/#brlcad ibot
(~ibot@198.60.114.207) |
| 07:10.55 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release prep for 7.18.2 under way
(20110202) |
| 09:06.27 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 09:15.17 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.250.99) |
| 09:15.17 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:23.05 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.203.101) |
| 10:23.05 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 11:06.05 |
dloman |
yawns |
| 11:08.33 |
dloman |
So.... if a
cmake find script isn't finding libraries... where should i put the
paths to the libs? in PATH or LD_LIBRARY_PATH ? |
| 11:21.26 |
Ralith |
might as well
try and see |
| 11:27.04 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.225.133) |
| 11:27.04 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 11:56.19 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.238.155) |
| 11:56.19 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:13.44 |
starseeker |
dloman:
depends on the script |
| 12:13.49 |
starseeker |
which script
is failing? |
| 12:19.21 |
dloman |
findqt |
| 12:19.38 |
starseeker |
try putting
the bin directory that has the qt binaries in PATH |
| 12:19.39 |
dloman |
at i verified
qt is in /usr/lib32 |
| 12:19.44 |
dloman |
right
on |
| 12:19.49 |
dloman |
just sat back
down |
| 12:19.54 |
dloman |
gonna try
that very thing :) |
| 12:20.01 |
starseeker |
heh |
| 12:22.08 |
dloman |
so yeah....
lots of rain + sudden temp drop + stupid winds == nastly little
mess up here. |
| 12:22.41 |
dloman |
one entire
side of my jeep is coated in 1/2" of snow/ice stuff that's hard as
a rock. |
| 12:22.48 |
starseeker |
ow |
| 12:22.50 |
dloman |
broke both my
ice chippers on it. |
| 12:23.15 |
starseeker |
is trying to figure out where the water that soaked his
closet carpet is coming from... |
| 12:23.35 |
dloman |
check the
walls. |
| 12:23.42 |
dloman |
we just had a
leak fixed. |
| 12:23.42 |
starseeker |
guessing
either the roof finally gave up the ghost or a hole in the siding
over the front door... |
| 12:23.54 |
starseeker |
walls are
pretty dry |
| 12:24.00 |
dloman |
ours were too
:) |
| 12:24.12 |
dloman |
leaking in
the second story (of 3 stories) |
| 12:24.24 |
dloman |
was running
down a beam or two in the main load bearing wall. |
| 12:24.28 |
dloman |
crazy |
| 12:24.38 |
starseeker |
dloman: who
did you call to get it taken care of? |
| 12:24.57 |
dloman |
oh man. Its
the contractor that originally put our roof on. |
| 12:25.08 |
starseeker |
ah |
| 12:25.11 |
dloman |
name is down
stairs, but its a MD contractor |
| 12:25.28 |
dloman |
$200 min
visit fee, but that covers 90% of leak fixes and shingle
replacements. |
| 12:25.55 |
starseeker |
sounds
interesting |
| 12:30.07 |
dloman |
ill dig up
the name the next time I head downstairs. |
| 12:32.35 |
starseeker |
dloman:
awesome, thanks |
| 12:36.34 |
dloman |
So who knew:
Batman Begins score == great coding music :) |
| 12:37.01 |
starseeker |
hehe |
| 12:37.20 |
starseeker |
probably won't be in today, or if he is it'll be
later |
| 12:37.41 |
starseeker |
need to
schedule leak fix due and get dehumidifier rented |
| 12:47.21 |
dloman |
Cranford
Contractors: 410 792 7663 |
| 12:47.40 |
dloman |
they got here
pretty quick (2 day turnaround) considering all the wind we've been
having lately |
| 12:48.02 |
dloman |
this is my
first experience with them, but they seemed to have fixed up the
roof pretty well. |
| 12:50.52 |
starseeker |
hmm... I
probably need somebody to deal with siding as well as
roof |
| 12:53.40 |
dloman |
ah bloody
hell. |
| 12:53.52 |
dloman |
:/ gotta get
QT. |
| 12:53.59 |
starseeker |
hehe |
| 12:54.17 |
dloman |
thought it
was installed, but noooooo. nothing can be that easy |
| 12:55.28 |
dloman |
I so need an
8 core laptop..... |
| 13:12.38 |
brlcad |
PATH is
binaries, LD_LIBRARY_PATH is libraries (for linux/bsd, not other
platforms) |
| 13:13.17 |
dloman |
brlcad: kk
awesome |
| 13:23.34 |
dloman |
hahaha, just
a a film trailer for "Inner city vs Outer space" |
| 13:23.47 |
dloman |
street thugs
vs space aliens |
| 13:23.54 |
dloman |
aaaahahahaha,
i love it. |
| 13:24.06 |
dloman |
"Attack the
Block" i think its called. |
| 14:38.20 |
*** join/#brlcad ezzieyguywuf
(~wolfie@unaffiliated/ezzieyguywuf) |
| 14:42.36 |
epileg |
brlcad:
actual trunk successfully compile in ubuntu and fedora, but i get
errors in opensuse, and i'm a bit lost. Can You help me
please? |
| 14:42.36 |
epileg |
http://paste.debian.net/109872/ |
| 15:08.37 |
ezzieyguywuf |
[10:08:27]
IRCnet: irc.freenode.net:6667 (IRCnet) |
| 15:08.39 |
ezzieyguywuf |
whoops |
| 15:14.57 |
CIA-14 |
BRL-CAD:
03davidloman * r43743 10/geomcore/trunk/src/utility/ (Config.cxx
GSUuid.cxx): Add some includes to make compiling on Ubuntu 10.10
work. |
| 15:21.33 |
CIA-14 |
BRL-CAD:
03davidloman * r43744 10/geomcore/trunk/ (2 files in 2 dirs): More
includes to make compiling on Ubuntu 10.10 work. |
| 15:25.38 |
CIA-14 |
BRL-CAD:
03davidloman * r43745 10/geomcore/trunk/src/GS/GSClient.cxx: cast
uint64_t to long long to make printf happy |
| 15:30.43 |
CIA-14 |
BRL-CAD:
03davidloman * r43746 10/geomcore/trunk/ (3 files in 2 dirs): Final
round of adding includes to make compiling on Ubuntu 10.10
work. |
| 15:49.30 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43747
10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: add
search.c |
| 16:12.37 |
brlcad |
epileg: sure,
the key there is "warnings being treated as errors" |
| 16:13.21 |
brlcad |
so either
"make STRICT_FLAGS=" or run configure with
--disable-strict |
| 16:14.41 |
epileg |
ok, i'll try
with "--disable-strict" |
| 16:31.24 |
CIA-14 |
BRL-CAD:
03brlcad * r43748 10/brlcad/trunk/src/libfb/tcl.c: expand the
function declarations from K&R form to complete 'real'
prototypes. these probably belong in a lifb_private.h header or
(better) wrapped into a callback btable. |
| 16:31.46 |
brlcad |
that should
quell the warning too |
| 16:41.08 |
epileg |
brlcad:
solved! successfully compile and install on openSUSE |
| 16:42.34 |
epileg |
BTW I do not
find the way to make an application as default for some mime-type
in KDE. no problem in GNOME. Someone nows how to do it? |
| 16:42.46 |
epileg |
*knows |
| 16:50.36 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.144.236) |
| 16:50.36 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:03.13 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.145.13) |
| 17:11.23 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:30.51 |
dloman |
Is there a
built in try/catch framework inside the TCL we use? |
| 17:40.24 |
vtts |
brlcad,
thanks for the fix, just checked it, works like a charm |
| 17:43.54 |
vtts |
if you are in
the mood, there is another one, with "archer -h": http://pastebin.com/unDAYkfJ |
| 17:44.17 |
vtts |
mac os x,
r43748 build with --enable-all |
| 17:45.00 |
vtts |
although
launching it with other options doesn't cause this |
| 17:45.47 |
vtts |
unfortunately
i don't have ogl support, so cannot see anyting past the startup
screen |
| 18:03.01 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.142.105) |
| 18:12.10 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.137.168) |
| 18:12.10 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:25.43 |
``Erik |
well, poop,
tcl ignores --disable-64bit-build |
| 18:35.13 |
dloman |
So it turns
out that the Children of Dune OST is pretty darn good. |
| 18:41.15 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.138.0) |
| 18:51.14 |
CIA-14 |
BRL-CAD:
03davidloman * r43749 10/geomcore/trunk/src/libJob/JobManager.cxx:
QT ripout cleanup: JobManager *should* start workers when
JobManager::start() is called. |
| 18:57.43 |
CIA-14 |
BRL-CAD:
03brlcad * r43750 10/brlcad/trunk/BUGS: archer's kill command seems
to be working better now |
| 18:59.04 |
CIA-14 |
BRL-CAD:
03brlcad * r43751 10/brlcad/trunk/TODO: write up a bunch of archer
to-do tasks that are necessary before archer can go into beta (some
are even alpha blockers). mostly focusing on usability and
migration. |
| 19:01.33 |
CIA-14 |
BRL-CAD:
03davidloman * r43752 10/geomcore/trunk/ (include/AbstractJob.h
src/libJob/AbstractJob.cxx): Wire UUIDs back into
abstractjob. |
| 19:13.19 |
CIA-14 |
BRL-CAD:
03davidloman * r43753 10/geomcore/trunk/tests/libJob/
(BasicJMTest.cxx PrintToStdOutJob.cxx): Get BasicJMTest working
again. |
| 19:15.04 |
CIA-14 |
BRL-CAD:
03davidloman * r43754
10/geomcore/trunk/tests/libJob/BasicJMTest.cxx: Bad Developer:
Redundant delete calls for JM. Forgot to delete PrintToStdOutJob
objects on exit. |
| 19:25.38 |
CIA-14 |
BRL-CAD:
03davidloman * r43755
10/geomcore/trunk/docs/CMakeLists-Template.txt: Drop template. Very
outdated. |
| 19:29.11 |
CIA-14 |
BRL-CAD:
03davidloman * r43756 10/geomcore/trunk/tests/coreInterface/: Drop
coreInterface test ....dunno how I missed removing this
earlier. |
| 19:30.35 |
CIA-14 |
BRL-CAD:
03davidloman * r43757 10/geomcore/trunk/tests/
(libEvent/BasicEventTest.cxx libNet/PrintingMsgHandler.h): Remove a
few lingering QT ghosts |
| 19:34.46 |
CIA-14 |
BRL-CAD:
03davidloman * r43758 10/geomcore/trunk/src/ (CMakeLists.txt
adminpanel/): Drop Adminpanel. Old research project that is no
longer useful. |
| 19:36.53 |
CIA-14 |
BRL-CAD:
03davidloman * r43759 10/geomcore/trunk/include/ (AppLauncher.h
BaseApp.h): Drop unused application launch framework. |
| 19:37.36 |
CIA-14 |
BRL-CAD:
03davidloman * r43760 10/geomcore/trunk/src/libJob/ (JobWorker.cxx
JobWorker.h): Remove a few more lingering QT ghosts |
| 19:43.14 |
CIA-14 |
BRL-CAD:
03davidloman * r43761 10/geomcore/trunk/CMakeLists.txt: Remove
CMake's search for QT. ....and with that, Geomcore is 100% qt
free. |
| 19:43.45 |
brlcad |
woot |
| 19:44.03 |
brlcad |
horay for
simplified dependency management ;) |
| 19:46.47 |
CIA-14 |
BRL-CAD:
03brlcad * r43762 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c:
unnecessary cast |
| 19:48.05 |
``Erik |
adminpanel
doesn't require qt? or is it not part? |
| 19:48.32 |
dloman |
it was a
research thingy |
| 19:48.39 |
dloman |
already been
superseded |
| 19:48.48 |
dloman |
so i just
deleted it. |
| 19:49.43 |
``Erik |
aight, cool..
saw some gui pieces, so I wasn't touching it |
| 19:54.54 |
dloman |
``Erik:
starseeker thanks for all the help! |
| 19:57.33 |
starseeker |
that reminds
me - the assembly and region trial on Friday succeed in something
like 30 seconds as opposed to 5 minutes for havoc |
| 19:59.08 |
starseeker |
dloman:
you're welcome :-) |
| 20:01.14 |
starseeker |
brlcad: are
you volunteering to make new icons? :-P |
| 20:01.15 |
CIA-14 |
BRL-CAD:
03jordisayol * r43763 10/brlcad/trunk/misc/debian/brlcad.sh: add
brlcad man path to manpath env. variable in GNU/Linux |
| 20:25.12 |
*** join/#brlcad ezzieyguywuf
(~wolfie@cpe-071-070-255-232.nc.res.rr.com) |
| 20:43.37 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.129.10) |
| 20:43.37 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:48.41 |
brlcad |
starseeker:
if it's holding up beta, sure |
| 20:48.57 |
brlcad |
that one
isn't an alpha hold-up, but should be fixed by beta |
| 20:49.51 |
starseeker |
<PROTECTED> |
| 20:50.10 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43764
10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: clean up
#if0 blocks, commented out printfs, etc |
| 20:50.11 |
starseeker |
those were
mostly just "better than grey pixels" |
| 20:54.37 |
brlcad |
I noticed
that there were a bunch of icons missing, I only listed the few
that had some bigger issue |
| 20:55.29 |
brlcad |
isolates the nmg bug down to ~100 lines |
| 21:01.52 |
yukonbob1 |
brlcad:
what's the script and what are it's requirements (ie: needs certain
database, certain brl-cad version, certain env?) |
| 21:11.40 |
brlcad |
yukonbob1:
it's our tcl test suite |
| 21:11.55 |
brlcad |
runs hundreds
of commands through mged |
| 21:12.20 |
brlcad |
one of the
hundreds is crashing, and it wasn't immediately obvious which one
exactly |
| 21:25.06 |
*** join/#brlcad Ralith
(~ralith@d142-58-35-248.burnaby.sfu.ca) |
| 21:33.37 |
*** part/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 21:36.43 |
yukonbob1 |
brlcad: ah --
is this only w/ most recent versions of brl-cad, or would I be able
to witness w/ 7.18.0 |
| 21:36.47 |
yukonbob1 |
? |
| 21:41.45 |
brlcad |
it's been in
there for over a year, it's part of our regression
testing |
| 21:41.50 |
starseeker |
brlcad:
missing? you mean primitives without icons? |
| 21:43.00 |
brlcad |
yeah |
| 21:43.31 |
brlcad |
e.g., not a
big deal that rpp doesn't have an icon |
| 21:43.37 |
starseeker |
ah |
| 21:44.01 |
brlcad |
expecially
since it'd then have to be rectified against arb8's icon since
they'd look identical |
| 21:44.05 |
starseeker |
tried to at least get something for most of the significant
ones, although adimttedly some of them suck... |
| 21:44.46 |
brlcad |
I was just
listing the things that might affect release, not a critique or
comment on the progress made to great |
| 21:44.56 |
brlcad |
to *date ..
great stuff |
| 21:45.16 |
starseeker |
nods - we really need a proper graphic artist for "release
quality" graphics |
| 21:45.27 |
starseeker |
that's a
skill all its own |
| 21:45.51 |
brlcad |
since we were
talking about release issues the other day, I thought I'd offload
several things that I've noticed |
| 21:47.29 |
starseeker |
cool -
thanks! |
| 21:47.30 |
brlcad |
making proper
graphics isn't hard - you just have to be hyper observant,
obsessive attention to detail, or decent amount of
experience |
| 21:47.38 |
starseeker |
now if only
we could get time to work on them... |
| 21:48.25 |
brlcad |
yep |
| 21:48.43 |
brlcad |
it takes a
long time to make good graphics |
| 21:49.37 |
brlcad |
coders
undervalue graphics designers (oh that's easy, just takes a couple
hours..) as often as managers undervalue coders (oh that's easy,
just takes a couple days) |
| 21:50.12 |
CIA-14 |
BRL-CAD:
03starseeker * r43765 10/brlcad/branches/cmake/ (27 files in 15
dirs): MFC r43764 |
| 21:52.52 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
| 21:55.16 |
starseeker |
brlcad: I
don't suppose we can bsd license common.h by any
chance? |
| 22:00.08 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 22:00.08 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release prep for 7.18.2 under way
(20110202) |
| 22:22.21 |
CIA-14 |
BRL-CAD:
03brlcad * r43766 10/brlcad/trunk/src/librt/ (Makefile.am
primitives/nmg/nmg.c): partial revert of the ntohl/htonl
conversions made to NMG since they cause a crash. turn off strict
since we're temporarily reverting back to bu xdr
routines. |
| 22:23.08 |
starseeker |
brlcad: after
release, do you mind if I try to straighten out whatever the issue
was with package require Itcl and go back to that
approach? |
| 22:23.38 |
starseeker |
is taking a stab at updating the CMake logic for current code
and now remembers why he went the other route... |
| 22:27.09 |
brlcad |
starseeker:
there's not really copyright-worthy in common.h, at least nothing
I'd worry about reusing on a whim :) |
| 22:27.21 |
starseeker |
ah, cool
:-) |
| 22:27.39 |
starseeker |
will need the UNUSED macro or something like it to make
openNURBS happy with strict flags... |
| 22:28.02 |
brlcad |
starseeker:
you can sort it out before or after the release (preferably on a
platform where you can reproduce), the issue was really just
getting back to a stable point |
| 22:28.21 |
starseeker |
nods - I'll wait for now |
| 22:28.32 |
brlcad |
i have my
suspicion as to the cause |
| 22:28.43 |
starseeker |
what's
that? |
| 22:28.46 |
brlcad |
it's double
declaration of classes |
| 22:28.53 |
brlcad |
so basically
inconsistency |
| 22:28.57 |
starseeker |
ah |
| 22:29.03 |
brlcad |
I think you
just didn't take it far enough |
| 22:29.14 |
brlcad |
you make itcl
and itk package require but not iwidgets |
| 22:29.29 |
brlcad |
so iwidgets
was static loaded, but the other two not |
| 22:29.31 |
starseeker |
O.o
|
| 22:29.45 |
brlcad |
so something
went awry in tcl's book-keeping of what is loaded |
| 22:29.47 |
starseeker |
I didn't
realize there was a library to be statically loaded with
iwidgets |
| 22:29.59 |
starseeker |
thought it
was just a bunch of tcl scripts |
| 22:30.19 |
brlcad |
it
is |
| 22:30.37 |
brlcad |
but it does a
Tcl_Import of iwidgets |
| 22:30.50 |
starseeker |
ahhh |
| 22:31.14 |
brlcad |
I don't know
-- I could be way off, but that's something that came to
mind |
| 22:31.33 |
starseeker |
wonders how the heck it works for him... |
| 22:31.44 |
brlcad |
should
frankly be able to remove itcl/itk/iwidgets from
bwish/mged |
| 22:31.54 |
brlcad |
make the
scripts package require correctly |
| 22:32.16 |
starseeker |
oh, you mean
do it "normally" in the src/tclscripts files? |
| 22:32.25 |
brlcad |
right |
| 22:32.52 |
brlcad |
there's no
benefit for the cad commands to be auto-loaded on instantiation of
an interpreter |
| 22:33.00 |
brlcad |
I mean, no
major one at least |
| 22:36.11 |
starseeker |
should be
fair to package require BRL-CAD or some such... |
| 22:38.29 |
CIA-14 |
BRL-CAD:
03brlcad * r43767 10/brlcad/trunk/src/fbed/Makefile.am: per-target
cppflags wasn't added until 1.7+ so use AM_CPPFLAGS
instead |
| 22:42.35 |
starseeker |
rtwizard runs
here - I wonder if that's due to the screwy install setup I
have... |
| 22:48.36 |
starseeker |
brlcad:
remind me why we're importing itcl/itk/iwidgets into the global
namespace? |
| 22:49.33 |
brlcad |
better
question is what will break if we don't import it, and that I do
not know |
| 22:49.49 |
starseeker |
hmm |
| 22:50.28 |
brlcad |
plenty broke
from what should have been an equivalent change ;) |
| 22:52.53 |
starseeker |
Oh, I wasn't
planning on doing it now :-P |
| 22:53.03 |
starseeker |
we have
enough release problems without borrowing more |
| 22:53.29 |
starseeker |
I'd just
really like to get to where our Tcl/Tk stuff isn't so cranky and
fragile anymore |
| 22:54.57 |
starseeker |
O.o I can't
reproduce the failure here - what platform did you see it
on? |
| 22:57.04 |
brlcad |
mac,
10.6 |
| 22:57.25 |
brlcad |
vtts was also
on mac iirc, dunno which version |
| 22:57.48 |
brlcad |
mine is
usually an enable-all build for testing |
| 23:18.28 |
brlcad |
starseeker:
when you wrote the tcl mged tests .. what state did you leave them
in? |
| 23:18.43 |
brlcad |
i.e., were
they working? |
| 23:23.18 |
starseeker |
at the time
they were, I believe |
| 23:23.25 |
starseeker |
that was a
long time ago |
| 23:23.50 |
starseeker |
Pro/Batch
sucks |
| 23:24.40 |
brlcad |
interesting |
| 23:25.06 |
brlcad |
because I got
a magic bomb translating halfspaces, null parameter, that I can't
see having ever worked |
| 23:26.16 |
starseeker |
huh |
| 23:26.34 |
starseeker |
shrugs - I may have messed it up somehow |
| 23:27.26 |
brlcad |
no
no |
| 23:27.33 |
brlcad |
the problem
was in librt |
| 23:28.01 |
starseeker |
oh, you mean
an actual problem with the halfspace, not the test
scripts? |
| 23:28.12 |
brlcad |
I added the
support, I just don't see how translating a half ever worked with
the out pointer was null |
| 23:28.18 |
brlcad |
right |
| 23:39.21 |
brlcad |
hm, well
that's positive.. seems to be crashing on linux too |
| 23:39.37 |
brlcad |
starseeker:
if you have a build, can you test what make test in regress/mged
does? |
| 23:43.31 |
CIA-14 |
BRL-CAD:
03brlcad * r43768 10/brlcad/trunk/src/librt/primitives/half/half.c:
how did this ever work? if the out pointer is null, we need to
initialize and create one. nearly identical to what extrude does
now. |
| 23:43.43 |
starseeker |
um... need to
make an autotools build, one sec |
| 23:45.32 |
brlcad |
try without
that change first |
| 23:45.35 |
CIA-14 |
BRL-CAD:
03starseeker * r43769 10/brlcad/branches/cmake/src/
(bwish/cadAppInit.c bwish/main.c mged/cmd.c mged/setup.c): CMake
branch isn't set up to build with itcl/itk C api - need to resolve
the package require issues. |
| 23:45.43 |
starseeker |
k |
| 23:48.16 |
starseeker |
brlcad: when
rtwizard is crashing, is it from an installed location or the build
dir? |
| 23:49.17 |
starseeker |
heh - just
noticed, shapelib is actually an lgpl dependency |
| 23:49.25 |
starseeker |
looks like
our first |
| 23:54.13 |
starseeker |
interesting -
comb.tcl already has a package require Iwidgets |
| 23:54.21 |
brlcad |
starseeker:
actually it's dual-licensed |
| 23:54.22 |
brlcad |
MIT |
| 23:54.29 |
starseeker |
ah,
cool |
| 23:54.44 |
brlcad |
an odd
dual-license, but I wasn't going to complain |
| 23:54.46 |
starseeker |
wonders what the point of a dual LGPL/MIT license
is... |
| 23:55.16 |
starseeker |
autotools
build clunking along |
| 23:55.31 |
starseeker |
will have to remember how to run those tests again -
completely forgotten |
| 23:56.55 |
brlcad |
cd
regress/mged && make test :) |
| 23:56.56 |
starseeker |
iirc, I had
notions of replacing the sh regression logic with tcl regression
logic for cross-platform compatibility... |
| 23:57.04 |
starseeker |
oh, I got it
that far? cool |
| 23:57.19 |
brlcad |
looks like my
linux failure has been fixed with recent changes |
| 23:57.55 |
starseeker |
rtwizard
appears to have package require calls too |
| 23:58.48 |
starseeker |
somewhat
bemusingly, I don't see such a call in archer |
| 23:59.46 |
brlcad |
iirc, my
rtwizard invoke was pre-install |
| 00:01.05 |
brlcad |
I rarely test
from install unless I'm nearing release testing, several extra
minutes saved per compile, which adds up fast |
| 00:04.42 |
starseeker |
nods - I'm the same way |
| 00:05.06 |
starseeker |
it's a
possible difference to check - the cmake build and the autotools
build runs are quite different |
| 00:05.56 |
brlcad |
nods |
| 00:06.45 |
brlcad |
yeah, I just
verified that your halfspace test failed for half on linux
too |
| 00:06.56 |
brlcad |
it's the
oed.mged set of tests |
| 00:07.04 |
starseeker |
hmm - wonder
if I just commented it out and moved on... |
| 00:07.19 |
brlcad |
I was running
them manually since they're easier to isolate |
| 00:07.23 |
starseeker |
some of those
were a little tricky to set up, so I may have just assumed I had
done it wrong |
| 00:07.30 |
starseeker |
nods |
| 00:07.37 |
brlcad |
so it maybe
always has failed |
| 00:08.10 |
brlcad |
thing is, it
stops the whole testing progression and stops pretty early on with
it trying to move a half |
| 00:08.24 |
starseeker |
possibly -
that has to be over a year since I've touched those, and probably
longer, so I don't recall much |
| 00:08.24 |
brlcad |
with the fix,
it gets all the way to the end |
| 00:08.29 |
starseeker |
sweet! |
| 00:08.39 |
brlcad |
successfully
even |
| 00:08.45 |
brlcad |
now the log
is another matter... |
| 00:09.00 |
brlcad |
heh, it lists
slews of errors and failures, but it's not clear which are
intentional and which are not |
| 00:09.12 |
brlcad |
e.g., saw a
"killall*" in there |
| 00:09.35 |
brlcad |
but then that
might have been a prefix or something too |
| 00:09.38 |
starseeker |
urm... don't
recall if I got to the intentional failure checking or
not... |
| 00:10.00 |
starseeker |
mainly recalls a lot of time spent on primitives and quick
reference card commands |
| 00:10.52 |
starseeker |
brlcad: you
still build primarily in the source tree? |
| 00:11.01 |
brlcad |
well then, it
looks like I maybe just implemented non-pushed matrix edit support
for halfspaces |
| 00:12.27 |
brlcad |
depends on
the platform, maybe half the time but I wouldn't say it's primarily
in or out |
| 00:13.11 |
brlcad |
some
platforms are almost exclusively out of dir (linux), some are mix
in/out depending on what I'm doing (mac), and others still are
almost always in dir (release) |
| 00:13.19 |
starseeker |
k - don't
know why that would still matter but also something to keep in
mind |
| 00:14.03 |
brlcad |
possible, but
it was a pretty isolated failure with the double-class
error |
| 00:14.35 |
brlcad |
i'll give it
another test post-release |
| 00:16.02 |
starseeker |
brlcad: I
think we found your new commuter car:
http://blogs.wsj.com/tech-europe/2011/03/07/the-car-faster-than-a-speeding-bullet/ |
| 00:21.57 |
starseeker |
brlcad: yep:
ERROR: NULL rt_half_internal pointer, file primitives/half/half.c,
line 505 |
| 00:22.13 |
starseeker |
updates to confirm fix |
| 00:22.18 |
brlcad |
cool |
| 00:22.28 |
brlcad |
pretty much
confirms, awesome |
| 00:22.49 |
brlcad |
hm, I don't
see how/where oed actually applies the matrix |
| 00:31.10 |
starseeker |
brlcad: for
which test? |
| 00:31.44 |
starseeker |
oh, confirmed
that regression is fixed with the latest update |
| 00:32.58 |
brlcad |
that's
bizzare though too |
| 00:33.10 |
brlcad |
the test does
oed / oed_half.c/oed_half.s |
| 00:33.35 |
brlcad |
then merely
presses accept |
| 00:33.47 |
brlcad |
that results
in the halfspace import fail |
| 00:33.53 |
brlcad |
fishy |
| 00:33.57 |
starseeker |
O.o |
| 00:35.13 |
brlcad |
*sigh* ..
back to gdb for understanding |
| 00:37.10 |
starseeker |
technically
we don't have to pass those for release, they were never added to
the "offical" regression testing... |
| 00:37.58 |
brlcad |
it's not a
matter of passing the test, it's a failure related to code that
changed |
| 00:38.23 |
brlcad |
the tests are
simple enough, they're worth checking into to make sure something
else wasn't horked |
| 00:38.57 |
starseeker |
nods - just noting that some of the "failures" may be nothing
new... |
| 00:39.31 |
brlcad |
sure |
| 00:39.42 |
brlcad |
but they're
the closest thing to a test at this point for all the librt code
that was changed |
| 00:39.49 |
starseeker |
ah,
point |
| 01:10.52 |
starseeker |
hmm... cmake
build succeeds in running rtwizard and archer on 10.6, although I
do see those kCGError messages |
| 01:11.03 |
starseeker |
will have to try autotools tomorrow |
| 01:15.27 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 02:48.01 |
CIA-14 |
BRL-CAD:
03brlcad * r43770 10/brlcad/trunk/NEWS: |
| 02:48.01 |
CIA-14 |
BRL-CAD:
inadvertently reviewing and fixing bugs for release, fixed a
never-implemented |
| 02:48.01 |
CIA-14 |
BRL-CAD:
feature of halfspaces. if you put them into a combination and apply
a matrix to |
| 02:48.01 |
CIA-14 |
BRL-CAD: the
combination, librt would bomb with an invalid magic error. the
half |
| 02:48.01 |
CIA-14 |
BRL-CAD:
primitive was updated to handle that case which is used by mged to
apply |
| 02:48.02 |
CIA-14 |
BRL-CAD:
matrices to wireframes without writing to a disk
record. |
| 02:49.00 |
CIA-14 |
BRL-CAD:
03brlcad * r43771 10/brlcad/trunk/TODO: technically unbusted though
only because it's half-reverted. still investigating the cause, but
todo is todone. |
| 03:16.09 |
brlcad |
gives bottie a final round of testing |
| 03:16.32 |
starseeker |
brlcad: the
last report on bottie was "consistently crashing" |
| 03:17.47 |
CIA-14 |
BRL-CAD:
03brlcad * r43772 10/brlcad/trunk/src/librt/primitives/half/half.c:
oops, wrong cast |
| 03:19.10 |
brlcad |
heh,
k |
| 03:29.04 |
brlcad |
just worked
with a simple sphere test case |
| 03:30.04 |
brlcad |
50%
speedup |
| 03:30.46 |
brlcad |
(of tie vs
bot .. sph was around 200% faster) |
| 03:33.58 |
starseeker |
cool |
| 03:34.14 |
starseeker |
huh, this is
interesting: http://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/ |
| 03:34.16 |
brlcad |
nice 300%
improvement on a model with just 9k tris |
| 03:34.25 |
brlcad |
600k rtfm vs
200k rtfm |
| 03:35.15 |
brlcad |
I think I've
seen that site |
| 03:37.16 |
starseeker |
needs to read through that |
| 03:37.18 |
brlcad |
and it scales
nicely on a big image, 21 sec vs 7 sec |
| 03:37.23 |
starseeker |
awesome
:-) |
| 03:37.26 |
brlcad |
the whole
team should read through that |
| 03:37.41 |
brlcad |
about once a
year ;) |
| 03:37.52 |
starseeker |
hehe |
| 03:38.24 |
starseeker |
will probably rediscover it around this time next
year |
| 03:57.13 |
brlcad |
wow, actual
10x increase on a 0.5M poly bot (simple sphere) |
| 04:00.28 |
brlcad |
and on a 1.2M
poly... |
| 04:02.41 |
brlcad |
3 sec vs 62
sec |
| 04:02.58 |
brlcad |
hawt |
| 04:04.33 |
brlcad |
so that's
about as good as it will probably get comparison-wise since it's a
simple shape that's best for kdtree being compared with a bot not
using pieces optimization (default) and is but a single simple
shape |
| 04:09.00 |
brlcad |
nice, 5x
increase on t62 |
| 04:09.13 |
brlcad |
(after
removing the silly "I want normals" limitation) |
| 04:10.05 |
brlcad |
hm, maybe not
on that one ... |
| 04:23.32 |
brlcad |
yeah, that
wasn't right, looking to be about 40% faster (about 13s vs 21s) on
a fully hierarchical bot t62 |
| 04:44.20 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 04:44.20 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release prep for 7.18.2 under way
(20110202) |
| 05:55.51 |
CIA-14 |
BRL-CAD:
03brlcad * r43773 10/brlcad/trunk/NEWS: looks like today is the
day. reword the BoT-TIE metrics having directly observed (valid)
performance from 40% to 20x faster. include details that the
acceleration is presently disabled by default. |
| 05:58.37 |
CIA-14 |
BRL-CAD:
03brlcad * r43774 10/brlcad/trunk/TODO: peformance tested, results
very promising |
| 06:00.02 |
``Erik |
bottie breaks
on 32b |
| 06:00.40 |
``Erik |
took some
work to get a 32b linux build (needs fixing), but it breaks there,
too, not just fbsd |
| 06:01.55 |
CIA-14 |
BRL-CAD:
03brlcad * r43775 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
since it's disabled by default, is there really any point in
requiring normals and orientation? tested on several unoriented and
normal-free bots with success too. |
| 06:02.04 |
``Erik |
(--disable-64bit-build causes failed build
on a 64b linux build, -m32 is not being added correctly to
src/other) |
| 06:02.22 |
brlcad |
yep, see
README.Linux about that |
| 06:02.58 |
brlcad |
you basically
have to force it kicking and screaming |
| 06:03.54 |
``Erik |
heh, had to
./configure CFLAGS=-m32 CXXFLAGS=m32 and then force compile tk and
another with /usr/lib/libfonconfig.so.1 instead of
-lfontconfig |
| 06:04.25 |
brlcad |
probably
because you need LDFLAGS-m32 too |
| 06:04.45 |
``Erik |
no, there is
no /usr/lib/libfontconfig.so ... mebbe an arl screwup |
| 06:05.02 |
brlcad |
probably, I
manually fixed a couple bad X11 libs |
| 06:05.11 |
brlcad |
bad ==
missing symlink |
| 06:05.47 |
brlcad |
either way,
results looking pretty good now |
| 06:05.53 |
``Erik |
aaanyways,
32b tie crashes where I tried it, I've a lot of mods at work
digging into it, but if you wanna dig in, knock yourself out...
imma go unconcious |
| 06:06.25 |
brlcad |
i'm satisfied
with it, I'm pressing for release tagging -- one last thing to
check on |
| 06:06.51 |
brlcad |
it was
working well enough to put numbers on the gains |
| 06:07.14 |
brlcad |
t62 is pretty
darn close to real-world, it was around 40% |
| 06:07.15 |
``Erik |
it takes a
bit of work to trigger, so whatever... I'm not keen on release
notes when it doesn't work 32b, but *shrug* I have more important
stuff to worry about |
| 06:07.33 |
brlcad |
the notes say
it's disabled by default and preliminary |
| 06:07.44 |
brlcad |
so there can
be a future not when it's not off by default |
| 06:09.43 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43776 10/brlcad/trunk/TODO: note 32b issue for
bottie |
| 06:10.21 |
``Erik |
tomorrow;
geomcore. |
| 06:12.16 |
CIA-14 |
BRL-CAD:
03brlcad * r43777 10/brlcad/trunk/TODO: huzzah! .. looks like the
nmg failures were related to one of the other failures (probably
nmg) because now everything is working again. |
| 07:00.49 |
brlcad |
tomorrow;
tag. |
| 07:00.53 |
brlcad |
er,
today |
| 07:46.36 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:28.59 |
*** join/#brlcad epileg
(~epileg@188.119.210.222) |
| 08:29.02 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 09:13.01 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 12:39.23 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 12:51.07 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.248.2) |
| 12:51.07 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:58.10 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.250.138) |
| 12:58.10 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:59.37 |
starseeker |
reflects that a function to find all local maximums and
minimums in a dsp dataset would probably be a good start at more
intelligent spline surface generation... |
| 13:16.35 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.250.138) |
| 13:16.35 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:22.07 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.250.138) |
| 13:22.07 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:22.30 |
*** join/#brlcad dli
(~dli@dsl-173-248-211-229.acanac.net) |
| 13:31.37 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.250.138) |
| 13:31.37 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:42.51 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.248.2) |
| 13:42.51 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:49.34 |
CIA-14 |
BRL-CAD:
03starseeker * r43778 10/brlcad/branches/cmake/CMakeLists.txt: Add
some documentation on what the distcheck routine does |
| 13:50.20 |
CIA-14 |
BRL-CAD:
03jordisayol * r43779 10/brlcad/trunk/ (misc/debian/rules
sh/make_rpm.sh): change the number of simultaneous jobs on "make",
during deb/rpm building process |
| 13:53.19 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:52.22 |
``Erik |
hm, dns
issues with brlcad.org ? |
| 15:04.18 |
CIA-14 |
BRL-CAD:
03brlcad * r43780 10/brlcad/trunk/misc/Makefile.am:
debian/application-x-brlcad.png was replaced with two v4/v5 png
files |
| 15:05.30 |
brlcad |
shouldn't
be |
| 15:06.35 |
``Erik |
I can't
resolve from several different machines |
| 15:06.39 |
``Erik |
including
bz |
| 15:08.40 |
brlcad |
working for
me |
| 15:08.55 |
``Erik |
on bz? tried
other machines to avoid cache artifacts? |
| 15:09.06 |
epileg |
``Erik: not
working here in Spain |
| 15:09.33 |
brlcad |
just reset
named, try again |
| 15:12.08 |
``Erik |
"no servers
could be reached" |
| 15:12.52 |
``Erik |
(from several
different machines using different dns servers, other domains
resolve) |
| 15:13.08 |
brlcad |
what query
you using? |
| 15:13.19 |
brlcad |
does
"nslookup google.com - bzflag.bz" work for you? |
| 15:13.25 |
``Erik |
"nslookup
brlcad.org" and "dig brlcad.org" |
| 15:13.41 |
``Erik |
yes, that
works |
| 15:14.43 |
brlcad |
oh
my |
| 15:14.58 |
epileg |
here in
spain, exactly same as ``Erik |
| 15:15.07 |
``Erik |
on one
machine, I got, um |
| 15:15.17 |
``Erik |
;; reply from
unexpected source: 76.96.5.201#53, expected
68.87.71.230#53 |
| 15:15.20 |
``Erik |
stuff like
that |
| 15:15.46 |
brlcad |
could be
related to zoneedit migration |
| 15:17.00 |
``Erik |
*shrug* we'll
see if it clears up, ah surpose |
| 15:19.16 |
brlcad |
yeah,
NS1.ZONEEDIT.COM is not responding |
| 15:20.05 |
brlcad |
all three
appear to be snookered |
| 15:20.08 |
*** join/#brlcad ezzieyguywuf
(~wolfie@cpe-071-070-255-232.nc.res.rr.com) |
| 15:20.12 |
``Erik |
they don't
have site redundant secondaries? O.o |
| 15:21.29 |
``Erik |
ah, pay per
secondary, lame :) |
| 15:22.15 |
``Erik |
jabs some code for a while |
| 15:23.17 |
brlcad |
is paying for a secondary |
| 15:23.28 |
brlcad |
that's why
there's three, one's even in the uk |
| 15:23.37 |
brlcad |
all three are
unreachable |
| 15:23.56 |
``Erik |
heh, 99.998,
guess this is that .002 |
| 15:27.29 |
``Erik |
irssi for
noobs lessons *sigh* :D |
| 15:32.51 |
brlcad |
of 7 dns
servers, looks like 5 of them are down |
| 15:35.08 |
brlcad |
er, 13 of
19 |
| 15:39.46 |
starseeker |
``Erik: oh,
don't worry - in another 10 years or so I may not be a noob
anymore |
| 15:46.01 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 15:47.03 |
``Erik |
so'z I gotta
enjoy it while I can, right? :> |
| 15:47.21 |
starseeker |
heh |
| 15:49.10 |
brlcad |
note that
brlcad.org is still reachable as bzflag.bz (at least for
now) |
| 15:50.04 |
brlcad |
http://63.246.136.17/d/ will get you
to the website |
| 15:50.19 |
``Erik |
ayup, that's
what I did earlier for my comic page, before calling out the dns
issue (was poking around to see if the httpd was having issues,
if'n ya look at the sudo log) |
| 15:51.13 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43781 10/geomcore/trunk/TODO: UUID is wired in
and QT is gone |
| 15:58.19 |
``Erik |
http://www.youtube.com/watch?v=xQqQ-Kcjowg
"rental car olympics" |
| 16:12.21 |
brlcad |
heh |
| 16:21.27 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 16:23.08 |
*** join/#brlcad Nohla
(~Nohla@64.76.19.227) |
| 16:33.58 |
dli |
brlcad, my
first try for rt_revolve_xform(), http://pastebin.com/Tf3Qsg7J |
| 16:34.53 |
dli |
brlcad, still
reading include/rtgeom.h |
| 16:57.27 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.21.22) |
| 16:57.27 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:19.38 |
starseeker |
O.o |
| 17:25.11 |
starseeker |
What the...
I'm seeing warning messages on OSX that are suppressed by adding
-Werror |
| 17:34.32 |
starseeker |
no, that's
not it... |
| 17:37.08 |
starseeker |
Ah - it's the
presence or absence of STRICT_FLAGS in brlcad_config.h |
| 17:37.48 |
starseeker |
Ohhhhh. I
see. |
| 17:38.22 |
starseeker |
bu.h linen
160 |
| 18:05.24 |
CIA-14 |
BRL-CAD:
03starseeker * r43782 10/brlcad/branches/cmake/ (6 files in 5
dirs): (log message trimmed) |
| 18:05.24 |
CIA-14 |
BRL-CAD:
Rework how CFLAGS are assigned in CMake. Major changes are using
build type |
| 18:05.24 |
CIA-14 |
BRL-CAD:
specific flags to hold things instead of the catch-all, and
changing the |
| 18:05.24 |
CIA-14 |
BRL-CAD:
STRICT_FLAGS brlcad_config.h include to WARNING_FLAGS. The way
CMake sets |
| 18:05.24 |
CIA-14 |
BRL-CAD:
things up, turning on the warnings but not strict just means you're
expecting to |
| 18:05.24 |
CIA-14 |
BRL-CAD: see
all the same output without failing. Conditionalizing the
bu.h |
| 18:05.24 |
CIA-14 |
BRL-CAD:
undef/redefine logic on strict and not warning violated that
principle, because |
| 18:18.32 |
CIA-14 |
BRL-CAD:
03starseeker * r43783 10/brlcad/branches/cmake/CMakeLists.txt:
Setting linker flags now, not compiler flags |
| 18:20.45 |
CIA-14 |
BRL-CAD:
03starseeker * r43784 10/geomcore/trunk/tests/svntest/main.c: don't
do a region subdirectory |
| 18:21.23 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43785
10/geomcore/trunk/src/utility/GSThread.cxx: destroy the mutex in
the GSMutex destructor |
| 18:51.15 |
starseeker |
brlcad: I
still can't reproduce the rtwizard/archer/bwish issue |
| 19:25.47 |
*** join/#brlcad Nohla
(~Nohla@64.76.19.227) |
| 19:45.24 |
*** join/#brlcad Nohla
(~Nohla@64.76.19.227) |
| 19:50.52 |
CIA-14 |
BRL-CAD:
03starseeker * r43786 10/brlcad/branches/cmake/ (10 files in 9
dirs): MFC r43785 |
| 20:01.18 |
CIA-14 |
BRL-CAD:
03starseeker * r43787 10/brlcad/branches/cmake/src/other/ (13 files
in 6 dirs): Ah, right - src/other builds actually have to do their
thing properly now. Get tkpng, tktable and tkhtml set up with some
find_package calls. |
| 20:12.37 |
CIA-14 |
BRL-CAD:
03starseeker * r43788 10/geomcore/trunk/ (CMake/ CMakeLists.txt
cmake/): Do like most other projects and put our CMake modules in a
CMake directory |
| 20:21.28 |
*** part/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 20:37.01 |
CIA-14 |
BRL-CAD:
03starseeker * r43789 10/geomcore/trunk/ (3 files in 2 dirs): Make
realpath happy on OSX |
| 20:49.58 |
CIA-14 |
BRL-CAD:
03jordisayol * r43790 10/brlcad/trunk/ (3 files in 2 dirs): add an
"update gtk icon cache" and some minor improvements on "install"
and "remove" scripts of deb/rpm packages |
| 20:59.53 |
*** join/#brlcad dli_
(~dli@dsl-69-171-148-245.acanac.net) |
| 21:01.21 |
CIA-14 |
BRL-CAD:
03bob1961 * r43791 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl:
Added a TkTable::see method. |
| 21:06.09 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43792
10/geomcore/trunk/src/libNet/NetMsgRouter.cxx: update
getListOfHandlers to work correctly with STL maps |
| 21:20.05 |
CIA-14 |
BRL-CAD:
03brlcad * r43793 10/brlcad/trunk/src/libged/gqa.c: |
| 21:20.06 |
CIA-14 |
BRL-CAD: add
some error recovery to gqa so that we don't bomb out
during |
| 21:20.06 |
CIA-14 |
BRL-CAD:
bu_malloc/bu_calloc when passed a zero size allocation. probably
means |
| 21:20.06 |
CIA-14 |
BRL-CAD:
something earlier went awry but check here regardless so we can be
more graceful |
| 21:20.06 |
CIA-14 |
BRL-CAD:
about halting. |
| 21:20.29 |
starseeker |
``Erik:
that's got it, thanks! |
| 22:34.36 |
CIA-14 |
BRL-CAD:
03starseeker * r43794 10/geomcore/trunk/tests/svntest/main.c: Put
each geometry object into its own directory. |
| 22:39.03 |
starseeker |
brlcad: about
50 seconds when I put each object in its own directory (regions and
assemblies) |
| 23:10.30 |
CIA-14 |
BRL-CAD:
03starseeker * r43795 10/brlcad/branches/cmake/include/bu.h: Go
ahead and keep the old comment |
| 23:13.47 |
CIA-14 |
BRL-CAD:
03starseeker * r43796 10/brlcad/trunk/ (configure.ac include/bu.h):
STRICT_FLAGS -> WARNING_FLAGS - just a rename as far as
autotools is concerned, no behavior change |
| 23:45.26 |
CIA-14 |
BRL-CAD:
03starseeker * r43797 10/geomcore/trunk/src/GS/ (9 files): First
step of renaming geoclient and geoserv to geomclient and
geomserv |
| 23:47.36 |
CIA-14 |
BRL-CAD:
03starseeker * r43798 10/geomcore/trunk/src/GS/ (geomclient.cxx
geomserv.cxx): geoclient and geoserv renamed to use geom prefix -
sounds less like geospatial related software |
| 00:00.55 |
CIA-14 |
BRL-CAD:
03brlcad * r43799 10/brlcad/trunk/TODO: add a couple tasks I've had
squirreled away for a couple years, visualization requests from
external application devs |
| 00:01.17 |
``Erik |
wait, what?
we're not making map software? |
| 00:01.39 |
starseeker |
``Erik: yeah,
yeah... it was bothering me |
| 00:02.29 |
starseeker |
although come
to think of it, whadya bet there's something somewhere out there
called geoserv? |
| 00:03.16 |
``Erik |
quite a bit,
it'd seem |
| 00:04.26 |
starseeker |
you're
kidding - no one grabbed it? |
| 00:04.41 |
``Erik |
there's a
company, a .org, a lot of GIS stuff, ... |
| 00:16.47 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 00:16.47 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release prep for 7.18.2 under way
(20110202) |
| 00:21.51 |
CIA-14 |
BRL-CAD:
03starseeker * r43804 10/geomcore/trunk/TODO: Add some notes and
thoughts about immediate next steps to the TODO for
geomcore |
| 00:24.42 |
brlcad |
looks like
DNS is restored |
| 00:26.42 |
starseeker |
yep -
sweet |
| 00:26.49 |
``Erik |
should
probably have unified test output and a shell script to fire them
all off and make a dashboard |
| 00:27.09 |
``Erik |
let's do it
in xml... wrapped in couchdb... :D |
| 00:27.15 |
starseeker |
heh |
| 00:27.31 |
starseeker |
really should look at CDash |
| 00:28.09 |
starseeker |
especially
for geometry service, it's output would be a nice "ooo, shiny"
progress report |
| 00:32.44 |
CIA-14 |
BRL-CAD:
03starseeker * r43805 10/geomcore/trunk/ (doc/ docs/):
docs->doc |
| 00:48.07 |
CIA-14 |
BRL-CAD:
03starseeker * r43806 10/geomcore/trunk/ (. doc/Doxyfile
doc/Doxyfile.in doc/docbook/): |
| 00:48.07 |
CIA-14 |
BRL-CAD:
Nifty tweak for doc directory - although it's early to be thinking
along the |
| 00:48.07 |
CIA-14 |
BRL-CAD:
lines of docbook, set up an svn:externals property to pull the xsl
sheets and |
| 00:48.07 |
CIA-14 |
BRL-CAD: any
other resources from BRL-CAD's doc/docbook directory, instead of
duplicating |
| 00:48.08 |
CIA-14 |
BRL-CAD: them
in geomcore. Also rename Doxyfile - that will need to have some
hardcoded |
| 00:48.08 |
CIA-14 |
BRL-CAD:
paths replaced with CMake variables. |
| 00:48.58 |
brlcad |
zoneedit was
hit was a DDoS earlier, hence the downtime |
| 00:49.47 |
brlcad |
script is
chugging along .. :) |
| 00:54.23 |
``Erik |
how goeth
account migration? |
| 00:54.56 |
``Erik |
slaps on his booties and heads into town
O.o |
| 00:55.07 |
brlcad |
release
bugs |
| 00:55.46 |
brlcad |
have taken
six days longer than expected now, so a bit backed up |
| 00:56.17 |
CIA-14 |
BRL-CAD:
03starseeker * r43807 10/geomcore/trunk/doc/doxygen/: add doxygen
dir |
| 00:59.31 |
CIA-14 |
BRL-CAD:
03starseeker * r43808 10/geomcore/trunk/doc/ (Doxyfile.in
doxygen/CMakeLists.txt doxygen/Doxyfile.in): Add a CMakeLists.txt
file for doxygen building |
| 01:07.38 |
CIA-14 |
BRL-CAD:
03starseeker * r43809 10/geomcore/trunk/ (CMakeLists.txt
doc/CMakeLists.txt doc/doxygen/Doxyfile.in): Add some logic for
doxygen building - dunno if it works yet |
| 01:12.31 |
brlcad |
initial stats
coming in on the raw filesystem overhead |
| 01:14.57 |
brlcad |
creating 526
dirs takes approximately 1.25 seconds |
| 01:15.16 |
CIA-14 |
BRL-CAD:
03starseeker * r43810
10/geomcore/trunk/tests/svntest/CMakeLists.txt: May need
TCL_INCLUDE_DIRS for svnTest |
| 01:15.42 |
brlcad |
keeping all
objects in havoc above and at region is approximately 62
seconds |
| 01:16.44 |
brlcad |
file size
expands from 576k to 2420k |
| 01:20.50 |
brlcad |
of those 62s
keeping geometry, 60s comprised overhead time reinvoking mged and
re-reading the .g file -- so the actual keep operation (create
file, traverse tree, write to file) is only about 2s of
time |
| 01:21.32 |
CIA-14 |
BRL-CAD:
03starseeker * r43811 10/geomcore/trunk/doc/doxygen/
(CMakeLists.txt Doxyfile.in): Exclude src/other. Doxygen generation
works now for geomcore, but turned off by default. |
| 01:22.06 |
starseeker |
huh - so
maybe I am doing something wrong with the svn stuff |
| 01:22.18 |
brlcad |
or svn
overhead is just that much |
| 01:24.05 |
brlcad |
ov the 60s
spend reinvoking mged and re-reading the .g, approximately 56s is
spent reinvoking mged .. so about 4s to read the .g 526
times |
| 01:24.37 |
brlcad |
undoubtedly
cache'd fs data making that fast |
| 01:25.10 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 01:25.51 |
brlcad |
takes approx
0.05s to open, read all 526 .g files, and cat them
together |
| 01:29.00 |
brlcad |
interestingly, havoc.g: 586k, uncompressed
into dirs: 2420k, reconstituted into single .g: 870k |
| 01:29.41 |
CIA-14 |
BRL-CAD:
03starseeker * r43812 10/geomcore/trunk/doc/doxygen/CMakeLists.txt:
Whoops, add the headers to the party |
| 01:30.43 |
brlcad |
that model
apparently has a decent amount of sub-region reuse going on to
cause a 42% expansion |
| 01:30.58 |
brlcad |
so it'll be a
good test case later too |
| 01:34.26 |
brlcad |
and I think
that's about all we need to know for now.. the best case overhead
is going to be about 3s-4s to do a round-trip dir breakout,
traverse tree, write out objects, read them back in, and recreate
.g -- the rest is overhead elsewhere |
| 01:35.05 |
starseeker |
nods - cool |
| 01:35.12 |
brlcad |
considering
the vast majority of that 4s is only during import with <1s
during export, that sounds entirely reasonable |
| 01:37.46 |
brlcad |
for anyone
else looking to play with a .g break-out, this script will do the
trick: |
| 01:37.51 |
brlcad |
file=whatever.g ; for i in `mged -c $file
search / 2>&1 ` ; do obj="`basename $i`" ; reg="`mged -c
$file search $i -type r 2>&1`" ; if test "x$reg" = "x$i" ;
then echo "mkdir $obj" ; echo "mged -c $file keep $obj/${obj}.g
$obj" ; elif test "x$reg" = "x" ; then echo "# skipping $obj" ;
else echo "mkdir $obj" ; echo "mged -c $file keep -R $obj/${obj}.g
$obj" ; fi ; done | tee doit.sh |
| 01:38.48 |
brlcad |
from there
you can sh the script or cat the mkdirs to a new script or count
regions, non-regions, skipped sub-objects, etc |
| 01:39.00 |
brlcad |
hugs search |
| 01:40.06 |
brlcad |
and if I'd
had a newer install on hand, I could have skipped the silly
"basename $i" with 'search .' instead of 'search /' |
| 01:46.07 |
starseeker |
except those
no-arg search requests are still busted... |
| 01:46.30 |
starseeker |
there's some
subtlty there I haven't figured out yet |
| 02:02.08 |
brlcad |
actually,
"search /" that I'm using there works just fine with
7.16.10 |
| 02:02.30 |
starseeker |
nods - I know, the new setup broke it |
| 02:02.33 |
brlcad |
so I'd wager
it's some new checks for args you've added |
| 02:02.57 |
brlcad |
maybe a
simple check that just needs to be removed, or an off-by-one
argc |
| 02:03.00 |
starseeker |
there's
something more to it than that |
| 02:03.20 |
starseeker |
I passed in a
null argv, and got some kind of crash |
| 02:03.35 |
starseeker |
in the paren
squish logic, if memory serves |
| 02:03.45 |
starseeker |
haven't had
time to hunt it down |
| 02:03.48 |
brlcad |
ok |
| 02:04.01 |
brlcad |
runs away |
| 05:49.55 |
brlcad |
starseeker:
curious changes to the WARNING_FLAGS/STRICT_FLAGS for the attr
params -- is strict vs warning compilation options in cmake
dependent or independent on each other? |
| 05:51.18 |
brlcad |
in autotools,
the two options are dependent so you can have warn but not strict,
warn and strict, not warn and not strict, or not warn and
strict |
| 05:52.55 |
brlcad |
that change
on the cmake branch looked like it made 'warn and strict' not
possible (because our own bu_log cannot compile with the attr
warnings, but we want attr warnings for stdio functions (the warn
and not strict case) so they can be fixed |
| 05:54.11 |
brlcad |
of the four
cases, warn+strict is the most important to make default since it
keeps things the most clean, but that's where the printf-attr
warning becomes problematic |
| 06:02.37 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.242.239) |
| 06:02.37 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:05.50 |
*** join/#brlcad Stattrav_
(~Stattrav@122.167.250.138) |
| 10:53.00 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.4.189) |
| 10:53.01 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:13.17 |
starseeker |
brlcad: um...
warn + strict should be the default |
| 12:14.00 |
starseeker |
brlcad: you
can have all four combinations with cmake too |
| 12:14.29 |
brlcad |
except by
tying attr_format123 to warnings, that should stop the
build |
| 12:14.41 |
starseeker |
uh...
how? |
| 12:14.46 |
starseeker |
OH |
| 12:14.59 |
starseeker |
my definiton
of warning and strict are probably slightly different |
| 12:15.11 |
starseeker |
in cmake,
struct is JUST -Werror |
| 12:15.49 |
brlcad |
and your
warnings probably doesn't include -Wformat |
| 12:15.55 |
starseeker |
checks |
| 12:16.02 |
starseeker |
I believe it
does |
| 12:16.43 |
starseeker |
It's part of
Wall |
| 12:16.47 |
starseeker |
checks gcc docs |
| 12:16.50 |
brlcad |
then it
should halt the build :) |
| 12:17.06 |
starseeker |
without
Werror, it's just a warning |
| 12:18.05 |
brlcad |
our own
print-style functions (e.g., bu_log()) declare themselves to be
printf-style functions, so some versions of gcc recognize that and
validate the arguments against the format specifier |
| 12:18.27 |
starseeker |
right - that
was happening on the mac as a warning with -Wall (not an
error) |
| 12:18.45 |
brlcad |
which is fine
and dandy for all the stdio functions, even fine for most of our
functions, except where we've extended the format specifier and
added %V, which will kick off a warning |
| 12:19.18 |
brlcad |
so our own
bu_log() statements will issue a warning where we don't want one,
halting the build if strict is enabled |
| 12:19.28 |
starseeker |
are you
expecting -Wformat, on its own without -Werror, to error out in the
case of bu_log? Because that's not the behavior I saw |
| 12:19.37 |
starseeker |
right |
| 12:21.14 |
brlcad |
that's a bad
thing :) |
| 12:21.37 |
starseeker |
Uh... why?
-Werror makes it hault |
| 12:21.48 |
starseeker |
without
-Werror, it's just informative |
| 12:21.55 |
starseeker |
I thought it
made sense |
| 12:22.07 |
brlcad |
I don't think
you're seeing the issue yet |
| 12:22.42 |
brlcad |
we want
strict+warning to be the default, yes? |
| 12:22.51 |
starseeker |
yes - it
is |
| 12:23.15 |
*** join/#brlcad Stattrav_
(~Stattrav@122.172.4.189) |
| 12:23.39 |
brlcad |
if warning
implies Wformat warnings, which it should, then Wformat will issue
warnings on our exisiting bu_log() calls |
| 12:24.02 |
starseeker |
but we don't
want that and never will |
| 12:24.02 |
brlcad |
as currently
written, warnings that cannot be quelled because we have no way to
tell gcc about %V |
| 12:24.36 |
brlcad |
we don't want
that, but gcc is going to give us that because we turn on
Wformat |
| 12:24.40 |
starseeker |
right - the
STRICT_FLAGS trick quelled them for strict builds |
| 12:26.15 |
brlcad |
and now
they're toggled based on whether warnings are on/off,
yes? |
| 12:26.27 |
brlcad |
(in cmake
branch) |
| 12:27.15 |
starseeker |
the
workaround in bu.h for -Wformat is toggled ONLY when the warnings
themselves are on, independend of whether STRICT is also specified
(i.e. whether -Werror is added to the mix, which is all STRICT does
in CMake) |
| 12:27.22 |
brlcad |
they being
the attr_format attributes in particular |
| 12:27.49 |
starseeker |
in CMake,
STRICT doesn't duplicate the WARNING flags the way configure.ac
does |
| 12:27.55 |
brlcad |
I get that
Werror is all strict is, that's fine and entirely
expected |
| 12:28.17 |
brlcad |
the issue is
whether the warnings settings turns those attributes
on/off |
| 12:28.49 |
starseeker |
don't we
always want them turned off anytime -Wformat is there, regardless
of whether we're strict or not? |
| 12:28.50 |
brlcad |
if attribute
is on when warnings is on, then warnings+strict won't be possible
(because gcc will issue warnings where we use %V) |
| 12:29.23 |
starseeker |
right |
| 12:29.25 |
brlcad |
if attribut
is off when warningsa is on, then nowarn+strict won't be possible
(same issue) |
| 12:30.33 |
starseeker |
now you've
lost me - if attribute is off, then why does nowarn+strict
fail? |
| 12:30.43 |
starseeker |
nowarn+strict
doesn't include -Wall |
| 12:31.08 |
starseeker |
it does in
autotools, but not in cmake |
| 12:32.32 |
brlcad |
maybe that's
the distinction, because there's two types of "no warn" in the
autotools build |
| 12:32.44 |
starseeker |
oh, there
are? |
| 12:33.19 |
brlcad |
--enable-warnings turns on "extra"
warnings |
| 12:34.13 |
brlcad |
so let me
understand this, the ATTR_FORMAT* defines -- you have them getting
turned on/off when? |
| 12:35.07 |
starseeker |
OK - there
are two compiler related options in CMake that impact
this |
| 12:35.28 |
starseeker |
BRLCAD-ENABLE_COMPILER_WARNINGS and
BRLCAD-ENABLE_STRICT, defined in
misc/CMake/CompilerFlags.cmake |
| 12:36.01 |
starseeker |
COMPILER_WARNINGS turns on Wall, Winline,
etc. but does not include Werror |
| 12:36.19 |
starseeker |
so the
compile will blather like crazy but not error out |
| 12:36.51 |
starseeker |
If you set
BRLCAD-ENABLE_STRICT, it will make sure
BRLCAD-ENABLE_COMPILER_WARNINGS is set to ON and then add -Werror
to the party |
| 12:38.36 |
brlcad |
sure, all
sounds how I thought -- it's boils down to those attribute flags,
when are they turned on/off? |
| 12:39.07 |
brlcad |
are they
coupled to ENABLE_COMPILER_WARNINGS or ENABLE_STRICT ? |
| 12:39.13 |
brlcad |
presumably
the prior? |
| 12:39.37 |
brlcad |
and are they
toggled on when ENABLE_COMPILER_WARNINGS is 'on' or
'off'? |
| 12:41.16 |
starseeker |
the attribute
flags are toggled on when ENABLE_COMPILER_WARNINGS is off (i.e.
-Wall is not present) |
| 12:41.22 |
starseeker |
(sorry,
network hickup |
| 12:42.15 |
starseeker |
if
ENABLE_COMPILER_WARNINGS is on, we've got -Wall and we're going to
get complaints about %V |
| 12:42.23 |
starseeker |
so we want
the attribute flags off |
| 12:43.06 |
starseeker |
when
ENABLE_STRICT is on, ENABLE_COMPILER_WARNINGS is also on, so
they're off then too |
| 12:45.51 |
starseeker |
in bu.h,
we're keying off the warning flags because they contain -Wall, but
it has the same effect as keying off of STRICT because STRICT
always turns on Warnings |
| 12:46.27 |
starseeker |
the benfit to
doing it this way is that when Warnings are on but STRICT is off,
we still don't want the %V reports |
| 12:46.45 |
starseeker |
and this gets
rid of them |
| 12:47.57 |
starseeker |
brlcad: I
didn't really change the behavior from autotools that
much |
| 12:48.31 |
starseeker |
I'm just
suppressing the %V error reporting in one additional
case |
| 12:52.06 |
starseeker |
I suppose
ideally the thing to do would be to check for -Wall or -Wformat in
the compiler flags after configure and key off of that as to
whether or not to enable/disable the ATTR_FORMAT* stuff |
| 12:52.29 |
brlcad |
basically it
sounds like it's suppressing ATTR_FORMAT* entirely then,
yes? |
| 12:52.40 |
starseeker |
yes, except
when warnings are off |
| 12:53.24 |
starseeker |
I was getting
an unexpected behavior on the Mac of getting warnings without
STRICT on that disappeared when I turned on STRICT |
| 12:53.27 |
brlcad |
they're on
when warnings are off, they off when warnings are on, so they have
no effect |
| 12:53.59 |
starseeker |
they're on
when the additonal warnings we supply are on |
| 12:54.12 |
starseeker |
any warnings
gcc or CMake's default flags put in there are still
present |
| 12:54.34 |
starseeker |
sorry -
they're OFF when our additional warnings are ON |
| 12:55.20 |
starseeker |
if by off we
mean the %V warnings are suppressed |
| 12:56.11 |
brlcad |
I think
"STRICT always turns on Warnings" might be a key distinction, is
that true or is strict only -Werror? :) |
| 12:56.43 |
starseeker |
Right now,
STRICT will kick on the extra warnings |
| 12:56.52 |
starseeker |
it does not
have to be that way |
| 12:57.00 |
brlcad |
will turning
off warnings turn off strict? |
| 12:57.26 |
starseeker |
Hmm... I
don't believe so |
| 12:58.04 |
starseeker |
but turning
off warnings with strict on won't work, because strict will catch
it and turn them back on |
| 12:58.32 |
brlcad |
to be
continued then.. the overarching issue is this: |
| 12:58.50 |
starseeker |
the logic
flow is in misc/CMake/CompilerFlags.cmake |
| 13:00.31 |
brlcad |
we want the
ATTR_FORMAT warnings to be reported for a bu_log calls, but we also
want verbose warnings and strict all of the time (and by default)
... so there's a whole category of warnings that we can't enable
when strict is on because our own code will trip them |
| 13:00.58 |
starseeker |
right |
| 13:01.33 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 13:01.34 |
brlcad |
if there's a
way for the format warnings (on bu_log) to be issued whenever
strict is off (ideally when warnings are on), then we should be
fine |
| 13:02.12 |
starseeker |
Oh... you DO
want to see the %V warnings if strict is off? |
| 13:02.20 |
starseeker |
found that a serious distraction |
| 13:02.48 |
brlcad |
only because
I fixed the 100's of other valid warnings that provided by adding
it |
| 13:03.20 |
starseeker |
then what
about adding -Wno-format to STRICT? |
| 13:03.30 |
brlcad |
because we
want Wformat for stdio calls |
| 13:03.37 |
starseeker |
hmm |
| 13:04.17 |
starseeker |
valid
warnings in bu_log functions? |
| 13:04.26 |
brlcad |
yep, tons of
them |
| 13:04.42 |
brlcad |
there was
just that one niche that couldn't be quelled |
| 13:05.01 |
brlcad |
so it's good
to have reported otherwise they won't get fixed |
| 13:05.09 |
brlcad |
it just can't
be a build stopper |
| 13:05.23 |
brlcad |
that's why it
only toggled off with strict |
| 13:06.06 |
starseeker |
what about
adding -Wno-error=format |
| 13:06.15 |
starseeker |
to just the
strict build |
| 13:06.34 |
starseeker |
then strict
and warning outputs will be consistent |
| 13:06.41 |
brlcad |
that still
turns off stdio format warnings being errors, and they're more
problematic than our bu calls |
| 13:06.52 |
brlcad |
might be
fine |
| 13:07.12 |
starseeker |
what threw me
was the warnings being more verbose on just warning than on
strict |
| 13:07.21 |
starseeker |
i'd rather
the warnings still be present in strict |
| 13:07.52 |
brlcad |
but therein
they fundamentally can't unless ATTR_ is always
disabled |
| 13:08.01 |
brlcad |
it's either
reporting for our bu funcs or it's not |
| 13:08.24 |
starseeker |
so the risk
of Wno-error=format is that it won't hault on non-bu_log specific
errors? |
| 13:08.34 |
starseeker |
and hence we
ignore them |
| 13:08.40 |
brlcad |
right |
| 13:09.24 |
starseeker |
we're paying
a high price for %V - is it really that useful? |
| 13:09.37 |
brlcad |
I *really*
just want some way to tell the compiler about %V :) |
| 13:10.50 |
brlcad |
I think it is
-- that's a lot of bu_vls_addr() calls that make reading bu_log
statements long and messy |
| 13:11.09 |
starseeker |
what about
some kind of macro? |
| 13:11.20 |
brlcad |
o.O |
| 13:11.45 |
brlcad |
crap, late ..
to be continued :) |
| 13:11.55 |
starseeker |
k, gotta get
moving myself |
| 13:12.02 |
starseeker |
I'll put it
back |
| 13:13.45 |
CIA-14 |
BRL-CAD:
03starseeker * r43813 10/brlcad/trunk/ (4 files in 3 dirs): Sigh.
%V is a pain, but we do want the warnings if -Werror isn't
around. |
| 13:16.05 |
CIA-14 |
BRL-CAD:
03starseeker * r43814 10/brlcad/trunk/src/librt/ (search.c
search.h): yipe, stray librt/search code got sucked in by
mistake |
| 13:17.44 |
starseeker |
gah! |
| 13:17.55 |
starseeker |
what'd I do
to search |
| 13:20.53 |
CIA-14 |
BRL-CAD:
03starseeker * r43815 10/brlcad/trunk/src/librt/ (search.c
search.h): Whoops, looks like I only committed the global variable
removal to cmake branch. Silly me. |
| 13:30.18 |
CIA-14 |
BRL-CAD:
03starseeker * r43816 10/brlcad/branches/cmake/ (8 files in 5
dirs): (log message trimmed) |
| 13:30.19 |
CIA-14 |
BRL-CAD: MFC
r43815, put STRICT_FLAGS back where it was - apparently the
presence of %V |
| 13:30.19 |
CIA-14 |
BRL-CAD:
warnings only in non-strict builds is expected - we want to see
other bu_log |
| 13:30.19 |
CIA-14 |
BRL-CAD:
related warnings that are valid, and cannot separate the wheat from
the chaff |
| 13:30.19 |
CIA-14 |
BRL-CAD: when
it comes to the error reporting, so we have to make that tradeoff
in order |
| 13:30.19 |
CIA-14 |
BRL-CAD: to
add -Werror. This is very unfortunate since it means a strict build
isn't |
| 13:30.20 |
CIA-14 |
BRL-CAD:
sufficent to catch all valid warnings and a NON-strict build is
also required |
| 13:34.36 |
*** join/#brlcad dli
(~dli@dsl-69-171-148-245.acanac.net) |
| 13:52.31 |
starseeker |
brlcad: ok,
so a macro probably isn't workable/useful |
| 13:53.20 |
starseeker |
what about
having bu_log accept %s for a VLS and a normal string, and then
checking which it is on the backend and doing the right
thing? |
| 13:57.58 |
starseeker |
couldn't it
check the vls_magic to identify whether the input was a vls or
not? |
| 14:06.39 |
CIA-14 |
BRL-CAD:
03starseeker * r43817 10/brlcad/branches/STABLE/ (565 files in 146
dirs): Sync STABLE to trunk r43816 |
| 14:06.52 |
starseeker |
ah, fairly
painless - phew |
| 14:07.02 |
starseeker |
heads in |
| 14:21.23 |
brlcad |
awesome,
thanks! |
| 14:21.27 |
brlcad |
tests |
| 14:36.52 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.137.140) |
| 14:36.53 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:36.54 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.137.140) |
| 15:25.10 |
dloman |
anyone else
having issues with the cmake brlcad branch? |
| 15:36.29 |
*** join/#brlcad Nohla
(~Nohla@64.76.19.227) |
| 16:00.34 |
CIA-14 |
BRL-CAD:
03davidloman * r43818 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx:
Cmd line parsing is adding an extra element to the end of the
std:list. Pop it off prior to passing list to cmd
processor. |
| 16:01.53 |
CIA-14 |
BRL-CAD:
03davidloman * r43819 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx:
Remove the debug printer |
| 16:09.02 |
brlcad |
starseeker:
43814 reverted the removal of the librt global too |
| 16:09.17 |
brlcad |
ahh, you
caught, never mind :) |
| 16:10.28 |
CIA-14 |
BRL-CAD:
03davidloman * r43820 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx:
Since the cmd was copied from the front of the stack, pop off the
first element prior to passing to the cmd processor. |
| 16:12.47 |
dloman |
looks like
thats the last of the qt ripout bugs.... |
| 16:22.15 |
starseeker |
dloman:
what's the issue with the cmake branch? |
| 16:23.01 |
dloman |
during
config, it was failing when 'trycompile'-ing the base types like
int and short and long |
| 16:23.12 |
starseeker |
O.o |
| 16:23.17 |
starseeker |
what
platform? |
| 16:23.26 |
dloman |
i verified
(via the brlcad trunk) that i actually had that support
:) |
| 16:23.30 |
dloman |
ubuntu
10.10 |
| 16:23.36 |
starseeker |
is this a new
failure? |
| 16:23.41 |
dloman |
lemme get the
specific failure. |
| 16:23.44 |
dloman |
yeah |
| 16:23.55 |
dloman |
worked fine
last time I compiled (...firday i think) |
| 16:23.59 |
dloman |
err
friday |
| 16:24.03 |
starseeker |
probably has
something to do with the cflags rework, but that's a bit
surprising |
| 16:26.21 |
dloman |
starseeker:
http://pastebin.com/FsMdxkuP |
| 16:26.31 |
dloman |
yeah, it was
rather odd, imho |
| 16:26.46 |
dloman |
"Wait, I
don't have an int anymore? WTF.." |
| 16:27.25 |
starseeker |
dloman: I
can't see that - can you try pastebin.mozilla.org? |
| 16:27.59 |
dloman |
sure
thing. |
| 16:28.12 |
dloman |
is there a
'paste bin of choice for BRLCAD-ers' ? |
| 16:28.40 |
starseeker |
not really -
I think the bzflag one was taken down a while ago, so usually the
lisp or the mozilla one get used |
| 16:29.56 |
dloman |
http://pastebin.mozilla.org/1140041 |
| 16:31.09 |
starseeker |
dloman: is
that a clean build dir? |
| 16:31.17 |
starseeker |
i.e. a clean
cmake run? |
| 16:31.29 |
dloman |
yuppers! |
| 16:31.41 |
dloman |
lemme svn up,
nuke and redo one more time.... justincase |
| 16:31.44 |
starseeker |
what's you're
cmake line? |
| 16:31.54 |
starseeker |
cmake
../brlcad-cmake or some such? |
| 16:32.10 |
starseeker |
s/you're/your |
| 16:32.40 |
dloman |
interesting.... |
| 16:32.48 |
dloman |
on the SVN
UP |
| 16:33.03 |
dloman |
it told me it
'restored' src/other/zlib/zconf.h |
| 16:33.08 |
dloman |
that
normal? |
| 16:33.09 |
starseeker |
that's
expected |
| 16:33.13 |
dloman |
kk |
| 16:33.28 |
starseeker |
zconf.h needs
to not be present for CMake but must be present for
autotools |
| 16:33.29 |
dloman |
...so
something is altering the src tree? isn't that
naughty? |
| 16:33.54 |
starseeker |
until we're
not building autotools anymore, it has to stay in the repository -
so CMake gets rid of it for a cmake build |
| 16:34.05 |
dloman |
kk |
| 16:34.20 |
dloman |
fyi the cmake
line is: cmake ../brlcad-cmake/ |
| 16:34.29 |
starseeker |
yes, it's
naughty - I don't like it, but as long as we need both autotools
and cmake support there's not much I can do |
| 16:34.35 |
starseeker |
k |
| 16:34.37 |
dloman |
just did a
clean checkout, clean build. same error. |
| 16:35.02 |
starseeker |
hmm |
| 16:35.14 |
starseeker |
it wants
TERMLIB... |
| 16:35.22 |
dloman |
in classic
Chris Farley: "What'd you DO?!?!" |
| 16:35.27 |
dloman |
=P |
| 16:36.51 |
starseeker |
dloman: can
you post... one sec... |
| 16:37.24 |
starseeker |
well, for
starters, can you post the full build log from cmake../brlcad-cmake
to failure? |
| 16:41.16 |
dloman |
console
capture or is there a specific log file you want? |
| 16:41.44 |
starseeker |
console
capture for starters |
| 16:41.49 |
starseeker |
may need
something more specific |
| 16:42.03 |
dloman |
http://pastebin.mozilla.org/1140086 |
| 16:42.40 |
dloman |
nice. malloc
failure. turns out i really dont have 1.76TB of ram...
hrm... |
| 16:42.46 |
dloman |
debugs |
| 16:43.57 |
starseeker |
dloman: do
you have a CMakeError.log file in CMakeFiles? |
| 16:46.32 |
dloman |
lemme
look |
| 16:47.10 |
dloman |
yup. u
want? |
| 16:47.17 |
starseeker |
please |
| 16:47.19 |
CIA-14 |
BRL-CAD:
03starseeker * r43821 10/geomcore/trunk/include/ (5 files): Don't
think they're in the right places yet, but start putting some of
the docs into doxygen comments. |
| 16:47.33 |
starseeker |
TERMLIB needs
to be defined, and it isn't |
| 16:48.24 |
dloman |
http://pastebin.mozilla.org/1140101 |
| 16:52.27 |
starseeker |
ummm. |
| 16:52.30 |
starseeker |
weird |
| 17:23.25 |
CIA-14 |
BRL-CAD:
03starseeker * r43822 10/brlcad/branches/cmake/src/other/ (4 files
in 4 dirs): Ah, that was where the extra m64s were coming from -
don't use FORCE when setting CFLAGS. Tcl/Tk build logic needs a
revisit |
| 17:29.52 |
starseeker |
dloman: by
the way, geomcore should generate doxygen docs for you now with
"make doxygen" |
| 17:47.52 |
CIA-14 |
BRL-CAD:
03starseeker * r43823 10/geomcore/trunk/doc/URL_URI_URN: Add
examples for url type requests |
| 17:55.36 |
*** join/#brlcad _psilva_
(~psilva@12.160.193.229) |
| 18:01.09 |
starseeker |
Program
received signal EXC_BAD_ACCESS, Could not access
memory. |
| 18:01.09 |
starseeker |
Reason:
KERN_INVALID_ADDRESS at address: 0x746e6575 |
| 18:01.20 |
starseeker |
0x0018572a in
ControlledThread::start (this=0x6024e0) at
geomcore/src/utility/ControlledThread.cxx:40 |
| 18:01.27 |
starseeker |
40
bool preRetVal = this->preStartupHook(); |
| 18:07.42 |
*** join/#brlcad _psilva
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
| 18:34.51 |
*** join/#brlcad ezzieyguywuf
(~wolfie@unaffiliated/ezzieyguywuf) |
| 18:53.44 |
``Erik |
heh
http://games.slashdot.org/story/11/03/09/1546225/Cloud-Gaming-With-Ray-Tracing |
| 19:52.15 |
*** join/#brlcad Ralith
(~ralith@d142-058-095-082.wireless.sfu.ca) |
| 19:59.40 |
*** join/#brlcad dtidrow_
(~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) |
| 22:20.46 |
*** join/#brlcad dli (~dli@132.205.216.62) |
| 22:27.19 |
*** join/#brlcad yukonbob
(~bch@20-144.wireless.kamloops.net) |
| 23:01.56 |
CIA-14 |
BRL-CAD:
03starseeker * r43824 10/brlcad/trunk/src/libged/red.c: Bah.
Windows complicates our matching - need to allow for carriage
returns as well as newlines. This exposes other problems, as
apparently red was never able to successfully parse a Windows text
file. |
| 23:02.54 |
starseeker |
the regular
expression matching is failing on Windows on the last item before
the end of the file - it's almost as if it doesn't recognize that
it needs to stop |
| 23:03.20 |
starseeker |
dunno if
that's regex, the bu_mapped_file, or what |
| 23:38.01 |
starseeker |
it's
suggestive that the debugger in windows didn't know how to print
the last line cleanly but the one on Mac does print cleanly (i.e.
no trailing garbage after the last comb tree entry) |
| 23:45.04 |
*** join/#brlcad Ralith
(~ralith@d142-058-095-082.wireless.sfu.ca) |
| 00:21.21 |
starseeker |
probably shouldn't need this but wants to read it anyway:
http://www.amazon.com/Art-Debugging-GDB-DDD-Eclipse/dp/1593271743 |
| 00:47.36 |
brlcad |
starseeker:
did the file have a trailing newline? |
| 00:47.45 |
brlcad |
er,
newline+cr |
| 00:48.37 |
brlcad |
Ahh.. ddd ...
the first debugger I ever used. |
| 00:48.51 |
brlcad |
that was a
neat debugger, pretty memory graphs |
| 00:48.59 |
Ralith |
oo, it has
graphs? |
| 00:49.01 |
Ralith |
install |
| 00:49.24 |
brlcad |
yeah, if you
had a linked list, you'd see your memory nodes and how they link
together |
| 00:49.59 |
brlcad |
very simple
ones, but enough to get the idea of what the data is
doing |
| 00:50.36 |
starseeker |
brlcad: it
did, but that shouldn't matter |
| 00:50.40 |
brlcad |
http://v3.sk/~lkundrak/grub2-gdb/ddd-ls.png |
| 00:51.03 |
brlcad |
starseeker:
so red is still busted on windows? |
| 00:51.14 |
starseeker |
yes - in fact
it never worked |
| 00:51.47 |
starseeker |
wonders how many white hairs he has racked up due to
red... |
| 00:52.18 |
brlcad |
'never' is a
very long time with brl-cad, you sure? :) |
| 00:52.59 |
starseeker |
well, the new
regex based version never worked |
| 00:53.08 |
brlcad |
that I'd
believe :) |
| 00:53.21 |
CIA-14 |
BRL-CAD:
03starseeker * r43825 10/brlcad/branches/cmake/src/libged/red.c:
MFC r43824 |
| 00:53.28 |
starseeker |
the regex
didn't account for the brain-dead windows approach to line endings,
and once we got past that the EOF situation causes a
crash |
| 00:54.23 |
brlcad |
that's right,
you are using some regex extension to match lines
right? |
| 00:54.36 |
CIA-14 |
BRL-CAD:
0386.163.157.31 07http://brlcad.org
* r2482 10/wiki/Main_Page: /* Getting started */ |
| 00:54.37 |
starseeker |
match across
multiple lines, yes |
| 00:55.26 |
starseeker |
it LOOKS like
regexec is running right off the end of the bu_mapped_file
buffer |
| 00:55.32 |
Ralith |
pretty |
| 00:55.43 |
Ralith |
and by pretty
I mean useful |
| 00:55.55 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2483
10/wiki/Main_Page: Reverted edits by
[[Special:Contributions/86.163.157.31|86.163.157.31]] ([[User
talk:86.163.157.31|Talk]]); changed back to last version by
[[User:Paulcs|Paulcs]] |
| 00:56.01 |
brlcad |
Ralith:
:) |
| 00:56.16 |
starseeker |
wonders if he can convince work to pick up a copy of that
book... |
| 00:56.29 |
brlcad |
ddd got its
groove on back in the early 90's |
| 00:56.36 |
brlcad |
hasn't really
ever changed unfortunately, lot of potential there |
| 00:57.08 |
brlcad |
starseeker:
it very well may be running off the end if it's looking for an
EOF |
| 00:57.19 |
CIA-14 |
BRL-CAD:
0386.163.157.31 07http://brlcad.org
* r2484 10/wiki/Error_Messages: Initial stub |
| 00:57.27 |
Ralith |
suddenly
SLIME doesn't hold all the cards anymore |
| 00:59.28 |
starseeker |
terminating
with \0 may work too... that's what OSX shows me after the mapped
file, anyway... |
| 01:00.03 |
starseeker |
had hoped the bu_mapped_file routines would have some kind of
guarantee about sanity at the end of the buf, but maybe
not |
| 01:04.26 |
brlcad |
it's just a
buffer of data |
| 01:06.13 |
starseeker |
then I'm
gonna have to do something else with it |
| 01:06.24 |
starseeker |
because on
every platform but Windows, regexec knows to stop |
| 01:06.33 |
brlcad |
now what
could be happening is that on windows, it doesn't have mmap() so
bu_mapped_file() is falling back to simple write()
calls |
| 01:06.54 |
brlcad |
and if it was
off-by-one, it could leave off the trailing '\0' |
| 01:08.10 |
brlcad |
you'd
probably not even notice that on code that processed one line at a
time |
| 01:11.21 |
starseeker |
looks like it
used read() to pull it in |
| 01:13.23 |
CIA-14 |
BRL-CAD:
03brlcad * r43826 10/brlcad/trunk/src/libbu/mappedfile.c: make sure
the buffers zero-terminate in case the files being mapped do
not |
| 01:14.09 |
brlcad |
don't know if
that'll fix it, but easy enough to test |
| 01:14.16 |
starseeker |
is on it |
| 01:16.19 |
CIA-14 |
BRL-CAD:
03starseeker * r43827
10/brlcad/branches/cmake/src/libbu/mappedfile.c: MFC
r43826 |
| 01:18.28 |
starseeker |
yep, that's
got it |
| 01:18.33 |
starseeker |
brlcad:
thanks!! |
| 01:18.59 |
starseeker |
will have to check for other cases were n isn't enough in
regex expressions |
| 01:20.42 |
starseeker |
looks like
red may be the only case... |
| 01:21.31 |
brlcad |
your regex
doesn't look right |
| 01:21.48 |
brlcad |
[[:blank:]\r?\n] |
| 01:22.08 |
brlcad |
presumably
implying \r is optional, but that's not what ? means
there |
| 01:22.21 |
brlcad |
it's a char
class |
| 01:22.30 |
brlcad |
[[:blank:]\r\n]* |
| 01:22.40 |
brlcad |
or
[[:blank:]\r\n]+ |
| 01:22.56 |
starseeker |
hmm... wonder
why it worked |
| 01:23.08 |
brlcad |
because
you're matching a literal '? |
| 01:23.16 |
brlcad |
exactly
once |
| 01:23.32 |
brlcad |
? or space or
\r or \n |
| 01:24.14 |
brlcad |
several
places that pattern repeats |
| 01:25.32 |
starseeker |
ah |
| 01:25.41 |
starseeker |
so I probably
don't need the ? then |
| 01:27.35 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: |
| 01:27.35 |
CIA-14 |
BRL-CAD:
deleted "[[Error Messages]]": there needs to be more purpose than
just itemizing |
| 01:27.35 |
CIA-14 |
BRL-CAD:
possible error messages coming from brl-cad tools. the one you
listed isn't |
| 01:27.35 |
CIA-14 |
BRL-CAD: even
exactly an 'error' as it is an explanation why it skips
_GLOBAL |
| 01:30.54 |
CIA-14 |
BRL-CAD:
03starseeker * r43828 10/brlcad/trunk/src/libged/red.c: Tweak the
regex expressions for carriage return correctness - hopefully
that's closer |
| 01:34.08 |
starseeker |
has to head out, will try new regex stuff
tomorrow |
| 01:34.27 |
CIA-14 |
BRL-CAD:
03starseeker * r43829 10/brlcad/branches/cmake/src/libged/red.c:
MFC r43828 |
| 01:34.49 |
CIA-14 |
BRL-CAD:
03brlcad * r43830 10/brlcad/trunk/src/libged/red.c: |
| 01:34.50 |
CIA-14 |
BRL-CAD:
simplify with the [:space:] character class which already includes
newline and |
| 01:34.50 |
CIA-14 |
BRL-CAD:
carriage return. [:blank:] is a gnu extension and won't necessarily
be |
| 01:34.50 |
CIA-14 |
BRL-CAD:
supported for a given vendor regex library. also fix a missed
character class |
| 01:34.50 |
CIA-14 |
BRL-CAD: '?'
inclusion with the [:space:] swappage. |
| 01:38.45 |
starseeker |
sighs - someday I'll understand regex... |
| 01:38.57 |
CIA-14 |
BRL-CAD:
03starseeker * r43831 10/brlcad/branches/cmake/src/libged/red.c:
MFC r43830 |
| 01:42.29 |
starseeker |
huh -
apparently Kitware has a free CDash service: http://my.cdash.org/ |
| 01:43.39 |
starseeker |
wow http://my.cdash.org/index.php?project=OpenStudio |
| 01:43.41 |
brlcad |
yep |
| 01:43.49 |
CIA-14 |
BRL-CAD:
03brlcad * r43832 10/brlcad/trunk/src/libged/red.c: semper fi, er,
simplify. let things fall through so there is only one copy of the
cleanup code and a consolidated simplified return
location. |
| 01:44.24 |
starseeker |
brlcad: would
that serve for a BRL-CAD reporting setup or would we want our own
CDash server? |
| 01:44.26 |
brlcad |
man that
looks like ass |
| 01:44.43 |
brlcad |
I *want* to
love cdash .. but that ui is a bit of an eyesore :) |
| 01:44.51 |
starseeker |
hehe |
| 01:45.06 |
brlcad |
I'd think
we'd still want our own, but still up to whomever does the work in
my book |
| 01:45.28 |
starseeker |
well, we
could always rip off the CruiseControl generated html and teach
CDash to output that instead... |
| 01:45.28 |
brlcad |
that way we
could hook scripting into the loop for custom actions |
| 01:46.00 |
brlcad |
it is just
the reporting front-end, so you still have to have compilation
nodes set up and sending in results |
| 01:46.12 |
starseeker |
right |
| 01:46.18 |
brlcad |
cruisecontrol
is the other one I couldn't remember |
| 01:46.23 |
brlcad |
buildbot the
third |
| 01:46.36 |
starseeker |
cruisecontrol
had the GUI you liked? |
| 01:47.06 |
brlcad |
http://cruisecontrol.sourceforge.net/ |
| 01:47.18 |
brlcad |
it's really
easy to use |
| 01:47.55 |
brlcad |
features
neatly grouped together with simplified reporting, then options to
dive into more detail or even raw build logs only when you ask for
it |
| 01:47.57 |
CIA-14 |
BRL-CAD:
03starseeker * r43833 10/brlcad/branches/cmake/src/libged/red.c:
MFC r43832 |
| 01:48.19 |
starseeker |
hmm... guess
we could use their exec builder to fire off cmake |
| 01:48.49 |
CIA-14 |
BRL-CAD:
03brlcad * r43834 10/brlcad/trunk/src/libged/red.c: ws
cleanup |
| 01:49.38 |
brlcad |
yep |
| 01:49.49 |
brlcad |
though again,
strong emphasis on "no strong preference" |
| 01:50.20 |
brlcad |
if you or
anyone else wanted to even just play with a small random
pet-project CI system, I'd take no issue |
| 01:50.40 |
starseeker |
is wary of a tool brlcad doesn't like the looks of (*memories
of font discussions and graphical layout
issues*) |
| 01:50.53 |
brlcad |
it's much
more important that we have continuous integration than we have
"the best" |
| 01:51.21 |
brlcad |
I'd get used
to any dashboard so long as it wasn't a maintenance burden or
timesink |
| 01:51.50 |
starseeker |
wonder where
we can run enough virtual machines to hit all the configs and not
create a pool of molten metal... |
| 01:51.59 |
brlcad |
their whole
purpose is to report failures simply and *quickly* so they get
caught as early as possible, so they can get isolated and fixed as
early/easily as possible |
| 01:52.06 |
starseeker |
pity
sourceforge took down that server farm |
| 01:52.45 |
brlcad |
any desktop
machine with a few corew would be sufficient enough to crank out a
half-dozen builds an hour |
| 01:53.24 |
starseeker |
dynamic lib
only and no docs, maybe... |
| 01:54.07 |
starseeker |
unless maybe
virtual machine overhead is lower these days than I
remember |
| 01:55.04 |
brlcad |
anything that
can presently compile the package in less than 10 minutes should be
sufficient |
| 01:55.37 |
starseeker |
wonder if we
could prepare stripped down virtual box/qemu images set up to build
BRL-CAD and report, then set them up as downloadable goodies for
people who want to pile in and and automatically test... setiathome
for BRL-CAD :-P |
| 01:56.29 |
brlcad |
at worse, you
get another box or two or have different types of test builds --
quick fast simple reduced builds across everything on one box, then
a more extensive slower build box that runs the full regression,
docs, bench, etc at a slower rate |
| 01:57.00 |
brlcad |
heh, I'm not
sure that'd be useful :) |
| 01:57.16 |
brlcad |
if it was a
vm image, we'd get tons of reports testing the exact same
thing |
| 01:57.35 |
starseeker |
well, we
wouldn't need hundereds of testers - but we could have a list of
"images we need testing and need volunteers for" |
| 01:58.06 |
brlcad |
better would
be a build target or even a shell script that took a given checkout
or source tarball through all the paces, and reported
back |
| 01:58.35 |
brlcad |
so we could
basically get a report anytime someone tried to build |
| 01:58.48 |
starseeker |
that'd be
configuration explosion though |
| 01:59.02 |
brlcad |
sure, so?
:) |
| 01:59.07 |
brlcad |
entries in a
db is all |
| 01:59.17 |
brlcad |
we hit up the
most common failure reports |
| 01:59.28 |
brlcad |
till there
are none |
| 01:59.32 |
starseeker |
that sounds a
bit different than cruisecontrol/cdash... |
| 01:59.44 |
brlcad |
they'd report
to cc/cd |
| 02:00.04 |
starseeker |
I got the
impression cc/cd didn't know the details about the
machine/os/etc... |
| 02:00.12 |
starseeker |
maybe I
didn't look close enough |
| 02:00.48 |
brlcad |
doesn't
really have to know, it just has to send in results -- we could
easily put machine details into a log that is sent back |
| 02:00.56 |
brlcad |
benchmark
suite does exactly that now |
| 02:01.05 |
starseeker |
nods |
| 02:01.18 |
brlcad |
speaking of
such |
| 02:01.40 |
brlcad |
we're going
to have to really kick in gear things into gear thursday if gsoc
app is going to happen |
| 02:01.58 |
starseeker |
ah, we're
coming up on the deadline? OK |
| 02:02.10 |
starseeker |
hunts for the wiki page with project ideas |
| 02:02.16 |
brlcad |
deadline is
friday mid-day |
| 02:02.35 |
brlcad |
it'll take me
a couple hours to write up the application submission |
| 02:02.50 |
starseeker |
k - what do
you need me to do firstist and mostist? |
| 02:02.57 |
brlcad |
few hours for
someone to work up a (VERY) detailed project ideas page |
| 02:03.43 |
brlcad |
they gave
feedback in '09 that our ideas page needed a lot more ideas and
detail (but that they were going to accept us anyways) |
| 02:03.48 |
starseeker |
update
http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas
or start over? |
| 02:04.07 |
starseeker |
s/update/expand upon |
| 02:04.18 |
brlcad |
I'd start
with http://brlcad.org/wiki/Google_Summer_of_Code/,
update any references to dates/times/requirements |
| 02:04.31 |
brlcad |
add new
section for 2011 where there are dated sections |
| 02:04.46 |
starseeker |
right |
| 02:05.22 |
brlcad |
the project
ideas page for 2008 was moved to http://brlcad.org/wiki/Google_Summer_of_Code/2008/Project_Ideas |
| 02:05.43 |
brlcad |
so can do the
same for 2009 and either start a new http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas
or expand on it |
| 02:06.30 |
brlcad |
I think we
should strongly de-emphasize projects that let devs code alone like
we've had in the past |
| 02:06.30 |
starseeker |
they wanted
MORE ideas?? we've got quite a few here |
| 02:06.38 |
brlcad |
yeah, ironic,
eh? |
| 02:07.17 |
starseeker |
so, no going
off in the corner and working on iges or step? |
| 02:07.33 |
brlcad |
we get
compared against other big-boys, they expect more |
| 02:07.36 |
brlcad |
e.g.,
http://www.freebsd.org/projects/summerofcode.html#ideas |
| 02:07.54 |
brlcad |
freebsd's
whole set of gsoc pages is arranged decently |
| 02:08.06 |
brlcad |
notice how
those idea links expand to something even more
impressive |
| 02:09.16 |
brlcad |
yeah, ideally
not things like iges/step unless they have some exceptional
familiarity in that area |
| 02:09.21 |
starseeker |
brlcad: they
can code almost anything alone if they put their minds to
it... |
| 02:09.38 |
brlcad |
something
that will make them explore the code better, reuse, refactor,
integrate |
| 02:10.06 |
brlcad |
the only
project that might be an exception would be continuation of new
gui |
| 02:11.06 |
starseeker |
nods... I'll do my best... |
| 02:11.31 |
starseeker |
would
continuation of the constraints work fall under the integrate
category or the isolated category? |
| 02:12.54 |
starseeker |
crud - I've
gotta get outta here |
| 02:13.30 |
brlcad |
starseeker:
better example of an "integrated" projects that would benefit us
you can add/expand: ogre display manager, qt display manager, qt
framebuffer, cross-platform adrt, libged transactions, .. maybe a
quick scan down TODO for the bigger tasks |
| 02:13.45 |
brlcad |
constraint
continuation would be integrated |
| 02:14.14 |
brlcad |
goal would
have to be something precise like prep or parameters hooked into
mged menus, etc |
| 02:15.44 |
brlcad |
also need
mentors to step up: dloman indianlarry ``Erik louipc yukonbob
poolio or anyone else |
| 02:15.59 |
brlcad |
since I'll
need your google id again |
| 03:22.13 |
starseeker |
brlcad: oh -
any opinion on using %s for both strings and vls in
bu_log? |
| 03:28.30 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/move: [[Google Summer of Code/Project
Ideas]] moved to [[Google Summer of Code/2009 Project Ideas]]:
Moving old Project Ideas page to a date specific location - time
for a new one. |
| 03:38.01 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2487 10/wiki/Google_Summer_of_Code/Project_Ideas: Start layout
setup for the new Project Ideas iteration |
| 03:49.01 |
brlcad |
erp, missing
slash |
| 03:51.00 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: |
| 03:51.00 |
CIA-14 |
BRL-CAD:
deleted "[[Google Summer of Code/Project Ideas]]": content was:
'The list of |
| 03:51.00 |
CIA-14 |
BRL-CAD:
possible projects below should serve as a good starting point for
new developers |
| 03:51.00 |
CIA-14 |
BRL-CAD: that
would like to get involved in working on BRL-CAD. Th...' (and the
only |
| 03:51.00 |
CIA-14 |
BRL-CAD:
contributor was
'[[Special:Contributions/Starseeker|Starseeker]]') |
| 03:51.09 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Google Summer of
Code/2009/Project Ideas]]": Deleted to make way for
move |
| 03:51.11 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Google Summer of Code/2009 Project
Ideas]] moved to [[Google Summer of Code/2009/Project Ideas]]:
consistency with 2008 |
| 03:51.42 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2490
10/wiki/Google_Summer_of_Code/2009: refere to old ideas
page |
| 03:52.40 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: restored "[[Google Summer of
Code/Project Ideas]]": 2 revision(s) restored: hrm, looks like mw
or I was confused with a bogus url |
| 03:53.30 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2491
10/wiki/Google_Summer_of_Code/2009: historic ref |
| 03:54.04 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2492
10/wiki/Google_Summer_of_Code/2009/Project_Ideas: historic
ref |
| 03:56.34 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2493
10/wiki/Google_Summer_of_Code/2009: past tense |
| 04:00.25 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2494
10/wiki/Google_Summer_of_Code: reword for past tense |
| 04:04.26 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2495
10/wiki/Google_Summer_of_Code: reword for more awesome |
| 04:05.57 |
brlcad |
starseeker:
my inclination is that would be bad (overloaded behavior,
inconsistent, probably more confusing than warnings) and probably
wouldn't even work since the compiler is supposed to validate that
typeof() is a char* for %s, which it wouldn't be |
| 04:10.17 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2496
10/wiki/Google_Summer_of_Code/2011: stub in for 2011 |
| 04:13.37 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2497
10/wiki/Google_Summer_of_Code/Checklist: numbered list |
| 04:14.17 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2498
10/wiki/Google_Summer_of_Code/Checklist: retitle |
| 04:15.28 |
starseeker |
growl... so
we're permenantly stuck with the %V warnings then |
| 04:16.23 |
starseeker |
unless we get
the gcc devs to add a new feature, and even then it'll only be in
the newest gcc versions |
| 04:16.53 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2499
10/wiki/Google_Summer_of_Code/Checklist: regroup for
clarity |
| 04:17.44 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2500
10/wiki/Google_Summer_of_Code/Checklist: subtasks don't need to be
numbered |
| 04:21.57 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2502
10/wiki/Google_Summer_of_Code: KISS |
| 04:23.14 |
brlcad |
wonders if dloman would be willing to work up this year's
gsoc flyer |
| 04:24.04 |
brlcad |
( prior
examples at
http://brlcad.org/wiki/Google_Summer_of_Code#BRL-CAD_participation_in_GSoC
) |
| 04:31.58 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2503
10/wiki/Google_Summer_of_Code/Checklist: add deadline
dates |
| 04:33.11 |
brlcad |
that's about
all I can push through for tonight |
| 04:33.18 |
brlcad |
need to get
back to release |
| 04:33.20 |
starseeker |
nods |
| 04:35.10 |
brlcad |
thinks we need at least 30 fleshed out ideas, perhaps
categorized similar to http://brlcad.org/wiki/Contributor_Quickies |
| 04:35.29 |
brlcad |
(EASY,
MEDIUM, HARD) |
| 04:36.06 |
brlcad |
or Web, C,
C++, Tcl |
| 04:36.15 |
brlcad |
both |
| 04:36.36 |
starseeker |
brlcad: OK...
I'm just tossing stuff up right now, I'll sort it once it's more
fleshed out |
| 04:36.42 |
brlcad |
nods |
| 04:37.11 |
brlcad |
you can
probably utilize the entire 2009 list and just keep adding more,
remove the one or two that are no longer relevant |
| 04:38.03 |
starseeker |
oh - I was
starting with the whole "more interactive" thing and was gonna
review the 2009 list to see what qualified... |
| 04:39.26 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2504 10/wiki/Google_Summer_of_Code/Project_Ideas: More ideas -
this isn't anything like final form, probably - just
scratchpad |
| 04:40.30 |
brlcad |
typo in the
top title section |
| 04:40.45 |
brlcad |
sure, however
you wanna do it :) |
| 04:40.58 |
starseeker |
the "AN IDEA"
one? |
| 04:40.59 |
brlcad |
aim for 50,
hopefully we'll get to 40 :) |
| 04:41.05 |
brlcad |
"=." |
| 04:41.17 |
starseeker |
oh, good
eye |
| 04:41.41 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2505 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 04:41.47 |
starseeker |
kinda liked
FreeBSD's grouping by larger scale topic |
| 04:42.09 |
starseeker |
I'll take a
whack, then you can tell me why it's wrong :-P |
| 04:42.26 |
starseeker |
brlcad: did
you want to get those red changes into this release? |
| 04:45.59 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 04:56.00 |
*** join/#brlcad dli
(~dli@dsl-69-171-148-245.acanac.net) |
| 04:57.26 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2506 10/wiki/Google_Summer_of_Code/Project_Ideas: list a few more
things... |
| 04:58.00 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2507 10/wiki/Google_Summer_of_Code/Project_Ideas: Constraint
solver needs its own page |
| 04:58.33 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2508 10/wiki/Geometric_Constraint_Solver: Put description on
individual page |
| 05:09.28 |
starseeker |
brlcad: do
you happen to know whether or not its possible to recognize an
arbitrary NURBS surface as being a component of (say) a sphere or a
torus? |
| 05:10.30 |
Ralith |
starseeker:
is BRL-CAD doing SoC this year? |
| 05:10.35 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2509 10/wiki/Google_Summer_of_Code/Project_Ideas: More tasks to
flesh out... |
| 05:10.43 |
starseeker |
we'll see
:-) |
| 05:11.24 |
Ralith |
if so, will
almost certainly submit a GPU accel proposal. |
| 05:18.59 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2510 10/wiki/Google_Summer_of_Code/Project_Ideas: Couple more
NURBS ideas... |
| 05:26.26 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2511 10/wiki/Ayam_Editor_Feature_Integration: Toss a few notes
into the Ayam/NURBS entry |
| 05:53.25 |
brlcad |
starseeker:
did someone report red? |
| 05:53.31 |
starseeker |
Victor |
| 06:06.27 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2512 10/wiki/Google_Summer_of_Code/Project_Ideas: That's around 30
ideas... some work to do tomorrow |
| 06:50.18 |
brlcad |
Ralith: one
never knows until orgs are announced |
| 06:51.02 |
Ralith |
yeah, meant
to ask "applying" |
| 06:51.07 |
Ralith |
and wiki
confirms |
| 06:51.44 |
brlcad |
starseeker:
not definitively unless the surfaces are tagged with originating
geometry |
| 06:53.02 |
brlcad |
Ralith: yeah,
it looks like we're probably applying if I can get a couple more
mentors to sign on |
| 06:53.10 |
Ralith |
awesome |
| 06:53.32 |
Ralith |
would be a
great way to spend the summer |
| 06:54.36 |
brlcad |
Ralith: I'd
be cautious about a gpu accel project for the same aforementioned
"prefer integrated code, minimal 'new code'" concerns -- it'd have
to be very specific about how it'd be integrated and
beneficial |
| 06:55.35 |
brlcad |
and from a
former gsoc'er, you'll have to work twice as hard to
convince |
| 06:56.19 |
Ralith |
hm, that's a
shame |
| 06:57.12 |
brlcad |
not really,
it's only fair to the 3k other students :) |
| 06:57.21 |
Ralith |
hah |
| 06:57.23 |
Ralith |
yeah |
| 06:58.23 |
brlcad |
if someone
had been more actively commiting over the past year and a half,
it'd be a totally different story ;) |
| 06:58.24 |
Ralith |
may play with
it anyway, depending on what else I end up doing |
| 06:58.27 |
brlcad |
hell, even
passively :) |
| 06:59.29 |
Ralith |
looks slightly regretful |
| 07:00.08 |
brlcad |
the point of
gsoc is to get students engaged in open source, even if it's not
brl-cad ... http://www.ohloh.net/p/brlcad/contributors/17162689320215
tells a sad story |
| 07:00.45 |
Ralith |
yes, it's
quite true |
| 07:00.51 |
Ralith |
though I've
been plenty active elsewhere |
| 07:00.56 |
Ralith |
not sure why
ohloh hasn't picked up on that |
| 07:01.10 |
brlcad |
not intending
to pick on you personally, just saying that puts you back into the
boat with everyone else on level standing |
| 07:01.18 |
Ralith |
I
know |
| 07:01.30 |
brlcad |
you can
combine accounts |
| 07:02.07 |
Ralith |
I think most
of the projects simply aren't on ohloh |
| 07:02.11 |
Ralith |
which can be
remedied, certainly |
| 07:02.37 |
Ralith |
but anyway,
not too relevant |
| 07:03.24 |
brlcad |
yeah, the
project itself is more the issue, it'd have to be carefully spelled
out |
| 07:03.50 |
Ralith |
nod |
| 07:04.19 |
brlcad |
for example,
most of the gpgpu research is on accellerating triangle raytracing
-- that's just not very interesting any more, especially now that
we have our new TIE library integrated with LIBRT |
| 07:04.23 |
Ralith |
mainly it
strikes me as a good opportunity to learn more about raytracing and
rt's internals in particular, as well as GPU frobbery |
| 07:04.52 |
Ralith |
hm. |
| 07:05.03 |
Ralith |
I wasn't
aware it was a research area per se |
| 07:05.04 |
brlcad |
so it'd have
to be some other means to accellerate librt, which would be either
in the spatial partitioning, the boolean weaving, the primitive
evaluations, etc |
| 07:05.14 |
brlcad |
oh hell yeah,
a huge one |
| 07:05.40 |
Ralith |
isn't
raytracing embarassingly parallel across each ray? |
| 07:05.55 |
brlcad |
nvidia and
intel fighting it out, both trying to push gpgpu raytracing into
gaming, it's been five years+ in the making |
| 07:06.02 |
brlcad |
yes? |
| 07:07.06 |
Ralith |
perhaps I
drastically misunderstand the problem, but wouldn't simply mapping
rays across GPU compute units—with fairly straight port of the
relevant rt code—be a huge gain? |
| 07:07.39 |
brlcad |
mapping rays
to the gpu is trivial, days work |
| 07:07.52 |
brlcad |
you have to
evaluate and march those rays |
| 07:07.57 |
brlcad |
against
geometry |
| 07:08.06 |
Ralith |
right, I
meant mapping the entire process |
| 07:08.48 |
brlcad |
so how does
one evaluate whether a ray intersects with a torus on the
gpu? |
| 07:09.00 |
brlcad |
heck, even a
simple sphere |
| 07:09.27 |
brlcad |
it's doable,
but it's not a 1-1 mapping or a mere matter of "porting"
anything |
| 07:09.49 |
brlcad |
you generally
have to completely rethink how data is packed and
evaluated |
| 07:10.46 |
Ralith |
I guess it
should have been obvious that the hardware is ill-optimized for the
subtleties of geometry more complex than triangles. |
| 07:10.49 |
brlcad |
that's why
most of the research is just with triangles -- only have to deal
with one entity type that is very trivial to evaluate, has a fixed
constant data size, etc |
| 07:11.10 |
Ralith |
that sounds a
bit beyond what I can accomplish based on what I know, at least in
a single summer. |
| 07:11.22 |
brlcad |
the hardware
isn't even really geared for triangles, but the calculations are so
few |
| 07:11.31 |
Ralith |
well |
| 07:11.37 |
Ralith |
sketchy
understanding here |
| 07:12.02 |
brlcad |
you actually
*can* do spheres even easier if you apply the same techniques you
apply for triangles, but then a beast like a torus becomes super
problematic because it requires a root solver |
| 07:12.03 |
Ralith |
but aren't
GPUs pretty much all about vector ops, and triangles trivial to
work with within those? |
| 07:12.21 |
brlcad |
yep, that's
where fixed data size becomes a win |
| 07:12.30 |
brlcad |
*small* fixed
data size |
| 07:12.43 |
Ralith |
and the math,
surely? |
| 07:12.58 |
Ralith |
well, I
suppose you just said that |
| 07:13.12 |
Ralith |
alright,
thanks for the explanation; sounds like this was
ill-conceived. |
| 07:14.03 |
Ralith |
an
interesting problem to be sure, but I don't have the background to
do original work in that sort of thing. |
| 07:14.45 |
brlcad |
it's a great
feature, a great research project, but very non-trivial to say the
least -- you'd probably be able to publish in an journal or even
siggraph if you got it working for general implicit
geometry |
| 07:15.21 |
brlcad |
easier attack
vector would be accelerating our boolean weaving step |
| 07:15.30 |
Ralith |
haven't a
clue what that is O.o |
| 07:15.36 |
brlcad |
exactly
:) |
| 07:16.19 |
Ralith |
ah
well. |
| 07:16.23 |
brlcad |
that's where
the "you'd have to work twice as hard to convince" came
from |
| 07:16.48 |
brlcad |
because it
could take a month just to get schooled up on the background
knowledge needed |
| 07:17.08 |
Ralith |
knowing the
scope of the problem, even that seems generous |
| 07:17.18 |
Ralith |
for weak
values of knowing even now |
| 07:18.06 |
brlcad |
that's where
if you were already familiar with even the basic mechanics of librt
working on portions of the code consistently, that'd make for an
easier case to dive into such a hard problem |
| 07:19.30 |
brlcad |
you'd know
the application structure's purpose, how hit callbacks work, when
boolean evaluation is performed, what that means, how the implicits
evaluate, types of CSG dag nodes, etc |
| 07:20.22 |
Ralith |
perhaps
continuing jonored's work on a toolpather would be more
realistic? |
| 07:20.38 |
brlcad |
fairly
complex code, highly optimized, and critical code at that which
would require 100% validation |
| 07:20.49 |
Ralith |
though I'm
not certain of my ability to find a footing with the (as far as I
can tell, currently buggy) math there either |
| 07:21.11 |
brlcad |
what
toolpather? |
| 07:21.20 |
Ralith |
I suppose he
never posted it here |
| 07:21.31 |
Ralith |
you recall a
while back that he was working on a gcode generator? |
| 07:21.34 |
Ralith |
couple years
ago or so? |
| 07:21.45 |
brlcad |
not
specifically |
| 07:21.50 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
| 07:21.58 |
Ralith |
he was, and
it got abandoned in favor of his studies |
| 07:22.09 |
Ralith |
but I got
ahold of him a few months back and got him to send me a tarball of
the git repo |
| 07:22.28 |
brlcad |
I do recall
that discussion |
| 07:22.44 |
Ralith |
he claims
outline tracing is mostly working, though in my limited experiments
I've not gotten correct output |
| 07:22.51 |
brlcad |
that wasn't
based on brl-cad iirc, though, no? |
| 07:23.09 |
Ralith |
er, it uses
librt to interrogate BRL-CAD databases |
| 07:23.21 |
brlcad |
hrm |
| 07:23.22 |
Ralith |
not sure how
much more 'based on' it gets |
| 07:23.36 |
Ralith |
want a look
at the tarball? |
| 07:23.55 |
brlcad |
not at the
moment, but it is interesting |
| 07:23.59 |
Ralith |
kk |
| 07:24.12 |
Ralith |
I'll see if I
can take a better look at it in the coming month and work out what
state it's really in |
| 07:26.20 |
brlcad |
yeah, that
was back in january we were talking about it |
| 07:26.28 |
brlcad |
you were
asking about curvature |
| 07:28.31 |
Ralith |
yeah, jonored
mentioned that torus curvature was the standing bug; I had planned
to dive in and fix that if I could get it to behave for simpler
primitives |
| 07:28.52 |
Ralith |
haven't
managed that yet, though haven't put much time in it |
| 07:37.13 |
brlcad |
if it really
is non-gui based (which an old post of his indicated), that would
be a good one to get working and fully integrate |
| 07:37.25 |
brlcad |
basically a
"g-gcode" converter |
| 07:45.21 |
Ralith |
it is indeed
commandline. |
| 07:46.00 |
Ralith |
in fact it
even follows the naming scheme |
| 07:46.01 |
Ralith |
g2gcode |
| 07:46.08 |
Ralith |
bear in mind,
though, that additive and subtractive toolpaths are differnet
beasts |
| 07:46.16 |
Ralith |
different* |
| 07:57.27 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 07:58.53 |
Ralith |
gah. |
| 07:59.14 |
Ralith |
journal
website lists this article as 'full text available,' but when I log
in through my univ it's preview only :| |
| 07:59.42 |
Ralith |
gunna have to
get a physical copy I guess. |
| 08:08.57 |
Ralith |
(trying to
get ahold of Martin Held's "On the computational geometry of pocket
machining") |
| 08:21.55 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.172.122) |
| 08:21.56 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:38.38 |
*** join/#brlcad dli
(~dli@dsl-69-171-148-245.acanac.net) |
| 11:16.19 |
d_rossberg |
i get fringes
on ray-tracing cones |
| 11:17.26 |
d_rossberg |
e.g. the
havoc's tail (ae 300 0) |
| 13:47.57 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2513 10/wiki/Google_Summer_of_Code/Project_Ideas: add subversion
idea |
| 13:55.10 |
starseeker |
brlcad: would
search exec be a viable GSoC project? |
| 14:45.37 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2514
10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core
Library Enhancement */ |
| 14:57.37 |
``Erik |
cdash is
heavily css driven. if it's the look and not the structure, it
should be easy to make it less ugly |
| 15:20.32 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43835
10/geomcore/trunk/tests/utility/threadTest.cxx: programmatically
test for functional threading instead of spewing junk to the screen
for human analysis |
| 15:21.46 |
starseeker |
``Erik: you
good to mentor? |
| 15:23.06 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2515 10/wiki/Google_Summer_of_Code/Project_Ideas: Couple more line
items - that's 38... |
| 15:23.19 |
``Erik |
yup, msg'd
brlcad my id |
| 15:24.34 |
starseeker |
``Erik: can
you scan that list and see if I left out any juicy items? brlcad
was talking about wanting 50... |
| 15:24.55 |
``Erik |
yeah, I
looked over it t his morning, um |
| 15:25.16 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 15:25.17 |
``Erik |
I'll splat
some stuff on and if someone doesn't like it, they can remove it
O.o |
| 15:25.25 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.159.181) |
| 15:25.25 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 15:31.44 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2516
10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core
Library Enhancement */ |
| 15:32.33 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2517
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tools
*/ |
| 15:36.03 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2518
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tools
*/ |
| 15:36.47 |
``Erik |
is [[NURBS
Intersections]] an evaluation of a CSG of NURBS into a single
one? |
| 15:37.10 |
starseeker |
no, that's
just the surface/surface problem and related
subproblems |
| 15:37.40 |
starseeker |
I doubt a
summer of code student could get all the way to the final evaluated
model |
| 15:37.57 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2519
10/wiki/Google_Summer_of_Code/Project_Ideas: 'csg' makes more sense
than 'boolean' here |
| 15:38.58 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2520
10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core
Library Enhancement */ |
| 15:39.25 |
``Erik |
hm, can
always harvest TODO and http://brlcad.org/~sean/ideas.html
for some more |
| 15:39.40 |
starseeker |
nods - I grabbed a few out of there |
| 15:39.49 |
starseeker |
was trying to
look for things that would be 'integrated' |
| 15:39.53 |
``Erik |
orange page,
too? |
| 15:39.59 |
starseeker |
nods |
| 15:40.20 |
starseeker |
for example,
I'd worry that a Blender plugin would kinda be off in its own
little world... |
| 15:41.01 |
starseeker |
now if they
want to snarf the Blender file import that game kit implemented and
turn it into a BRL-CAD importer... :-) |
| 15:41.24 |
``Erik |
a little bit,
but it would need a fair amount of communication to figure out how
to translate and what functionality |
| 15:42.06 |
starseeker |
nods - well, we've probably got close to enough lined up
there - now we need to start filling 'em in |
| 15:42.11 |
``Erik |
ooh, they
have one now? last I looked, their format was basically a swizzle
of memory dumped to disk |
| 15:42.37 |
starseeker |
yeah, pretty
much - apparently someone figured out how to do something
intelligent with it... |
| 15:42.41 |
starseeker |
one
sec... |
| 15:42.55 |
``Erik |
starts writing a test for ControlledThread
O.o |
| 15:43.06 |
starseeker |
http://code.google.com/p/gamekit/ |
| 15:45.15 |
``Erik |
yeah, saw
that before, hm |
| 15:48.18 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2521 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 16:21.27 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2522 10/wiki/OGRE_Display_Manager: Flesh out OGRE task (I think
this is low difficulty?) |
| 16:21.40 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 16:45.24 |
brlcad |
starseeker:
sure, search exec would be viable |
| 16:47.28 |
brlcad |
most of the
index card tasks are decent gsoc tasks |
| 16:47.33 |
brlcad |
should do a
quick scan |
| 16:48.12 |
brlcad |
since they're
< month for us, that easily scales up to 3 months for someone
else including communication, reporting, testing, and
documentation |
| 17:11.35 |
dli |
brlcad,
http://paste.pocoo.org/show/351409/ |
| 18:36.43 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43836
10/geomcore/trunk/tests/utility/threadTest.cxx: start stubbing in
ControlledThread test |
| 18:41.51 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2523 10/wiki/Qt_Display_Manager: Qt display manager |
| 18:42.31 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2524 10/wiki/Qt_Display_Manager: Qt, not ogre |
| 18:53.59 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2525 10/wiki/Qt_Framebuffer: Qt framebuffer |
| 18:56.07 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2526 10/wiki/Qt_Framebuffer: Grr - framebuffer, not display
manager |
| 19:08.51 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2527 10/wiki/Other_Cross_Platform_Framebuffer: Cross Platform
framebuffer |
| 19:21.20 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2528 10/wiki/High_Dynamic_Range_Support: HDR output
support |
| 19:21.27 |
starseeker |
``Erik: mind
reviewing the HDR one if you have a sec? |
| 19:21.57 |
``Erik |
sure, um, and
I just changed the css to mark the 'new' class as red, so'z you can
tell which ones you've done |
| 19:22.11 |
starseeker |
thanks
:-) |
| 19:22.30 |
``Erik |
(we can
revert it once this exercise is over if brlcad wants, it's in
RCS) |
| 19:23.12 |
``Erik |
"There is not
fundamental reason" ... wow, right out of the gate
:> |
| 19:23.29 |
starseeker |
heh, sorry -
distracted |
| 19:23.35 |
starseeker |
(house is
leaking again) |
| 19:23.50 |
``Erik |
other than
the picasso grammar, looks decent... |
| 19:28.10 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2529 10/wiki/High_Dynamic_Range_Support: |
| 19:40.18 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2530 10/wiki/MGED_to_Archer_Command_Migration: Command
migration |
| 20:09.10 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43837
10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx:
indent |
| 20:23.33 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43838
10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: purdee
kulurz |
| 21:01.24 |
CIA-14 |
BRL-CAD:
03Markhobley 07http://brlcad.org *
r2531 10/wiki/Talk:Error_Messages: wikibook |
| 21:27.22 |
brlcad |
dli: oh
snap |
| 21:27.28 |
brlcad |
aua he
left |
| 21:31.19 |
brlcad |
debates trying an application form this
year |
| 21:31.34 |
starseeker |
for GSoc you
mean? |
| 21:31.38 |
brlcad |
yeah |
| 21:31.49 |
starseeker |
does seem
kinda rushed |
| 21:32.14 |
brlcad |
many of them
just have no idea on how to pitch an idea, so there ends up being a
lot of information we have to keep asking for |
| 21:33.35 |
brlcad |
it has helped
in the past to separate out those who HAVE thought through their
idea and have a lot to say, but many of those devs tend to have
trouble integrating their thoughts with our codebase |
| 21:33.50 |
brlcad |
or worse, the
ones that can write great, but can't actually code |
| 21:34.45 |
starseeker |
had thought about some basic "submit this code with your
application" kinda things, but that takes time to
define |
| 21:35.22 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43839
10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: more
indentation, staticizing, etc |
| 21:35.26 |
starseeker |
``Erik:
what's your take? |
| 21:35.55 |
``Erik |
*shrug* |
| 21:36.33 |
``Erik |
we tried
"submit a patch" a couple years back, seems it was a bit of a
pain |
| 21:37.15 |
starseeker |
``Erik:
should we rush to get it "ready" or punt until next
year? |
| 21:37.47 |
brlcad |
submit a
patch worked pretty well I thought -- the strong patches ended up
being the strong coders |
| 21:38.09 |
brlcad |
kept the
application count down, but I think it worked |
| 21:38.23 |
``Erik |
the weak
patches were a depressing time sink, though :) |
| 21:38.41 |
brlcad |
so we be more
agressive in reviewing them |
| 21:39.03 |
``Erik |
starseeker:
doesn't hurt to try, they're usually fairly easy going if minor
tweaking is needed |
| 21:39.04 |
brlcad |
we can point
them to the quickies this year |
| 21:39.22 |
starseeker |
brlcad: good
idea |
| 21:39.26 |
brlcad |
no quickie
should take more than a day or few |
| 21:39.35 |
starseeker |
whoops,
contractor is here |
| 21:39.37 |
brlcad |
we can
certainly expand that list |
| 21:57.01 |
CIA-14 |
BRL-CAD:
03erikgreenwald * r43840 10/geomcore/trunk/ (59 files in 3 dirs):
footer.sh |
| 22:00.37 |
``Erik |
damnit,
thought I broke that soon enough |
| 22:33.17 |
starseeker |
brlcad:
expand the projects list? I've still got to get all those fleshed
out |
| 22:47.33 |
*** join/#brlcad dli
(~dli@dyn-216-212.wireless.concordia.ca) |
| 23:56.42 |
brlcad |
starseeker: I
meant the quickies list, no worries -- that'd be before they start
applying, not before tomorrow |
| 00:05.57 |
dli |
brlcad, my
second try for rt_revolve_xfrom(): http://paste.pocoo.org/show/351409/ |
| 00:10.30 |
starseeker |
Gah, what
happened to Project Ideas |
| 00:11.10 |
starseeker |
oh, that's
the Code_In |
| 00:11.13 |
starseeker |
nevermind,
carry on |
| 00:21.30 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2532 10/wiki/MGED_Sketch_Editor_Migration_and_Enhancement: Sketch
editor |
| 00:34.47 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2533 10/wiki/Ayam_Editor_Feature_Integration: Ayam editor
integration |
| 00:45.37 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2534 10/wiki/Analytical_Raytracing_Visualization: analytical
raytracing GUI |
| 00:59.07 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2535 10/wiki/Level_of_Detail_Wireframes: LOD
wireframes |
| 01:10.07 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2536 10/wiki/BoT_Editing: BoT editing |
| 01:21.16 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 02:27.28 |
*** join/#brlcad dli
(~dli@dsl-69-171-148-245.acanac.net) |
| 02:33.12 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2537 10/wiki/NMG_Editing: NMG editing |
| 02:48.30 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2538 10/wiki/Graph_layout_based_geometry_hierarchy_view: graph
based viewing |
| 02:49.33 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2539 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 02:50.10 |
starseeker |
Well, at this
rate I'll be done in a few more days :-/ |
| 02:50.40 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 02:55.02 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2540 10/wiki/Geometric_Constraint_Solver: |
| 02:57.00 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2541 10/wiki/Google_Summer_of_Code/Project_Ideas: move HDR
entry |
| 02:57.46 |
KimK |
On the
brlcad.org homepage,what does it mean "...licensed at over 2,000
sites..."? Licensed how? |
| 02:58.11 |
starseeker |
KimK: I think
that refers to the pre-open-source days |
| 03:00.07 |
KimK |
OK, thanks. I
could only find BSD, GNU, and similar in the FAQs, Wiki, etc. , and
I was confused. |
| 03:00.37 |
starseeker |
KimK: BRL-CAD
being open source is a relatively recent thing (compared to its
overall history) |
| 03:01.25 |
starseeker |
http://developers.slashdot.org/article.pl?sid=05/01/08/1823248 |
| 03:01.56 |
KimK |
OK, very good
what year did it open? I missed that part. So that text should
perhaps read "...in use at over 2,000 sites..."? Oops, I'm typing
too slow again, I'll bet you're ahead of me. |
| 03:10.20 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2542 10/wiki/Analysis_Library: analysis library |
| 03:21.04 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2543 10/wiki/Geometry_Conversion_Library: geometry
conversion |
| 03:24.16 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2544 10/wiki/Geometry_Conversion_Library: |
| 03:24.51 |
brlcad |
dli: I saw
that, commented right after you left -- that's totally
awesome |
| 03:26.08 |
brlcad |
dli: can you
post that patch file to our patches tracker? |
| 03:26.38 |
brlcad |
https://sourceforge.net/tracker/?func=add&group_id=105292&atid=640804 |
| 03:40.07 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2545 10/wiki/GED_Transactions: GED transactions |
| 04:04.59 |
KimK |
I tried
installing the BRL-CAD .deb (Ubuntu 10.04), Gdebi says I need
libncurses5 (>= 5.7+20100313), I have what must be the latest,
it is 5.7, but it's 20090803-2ub. Any advice? |
| 04:10.50 |
KimK |
Go plead my
case to the Ubuntu libncurses5 maintainers, I guess? Please post
any advice and I'll check back later. Thanks in
advance. |
| 04:11.41 |
louipc |
you sure the
deb is appropriate for your distro? |
| 04:13.05 |
louipc |
as far as I
understand debian and ubuntu are not quite interchangable
anymore |
| 04:13.53 |
dli |
brlcad,
thanks, still testing it, need to get it work before posting to
tracker |
| 04:13.57 |
louipc |
so you may
need to alter some things if you want a debian package to work with
ubuntu |
| 04:14.14 |
brlcad |
dli: ah,
thought you already had it finished :) |
| 04:15.20 |
dli |
brlcad, not
yet. still have to test how it work. also, I'm still not sure I can
simply keep the 2d vectors |
| 04:15.21 |
brlcad |
louipc: are
you interested in being a gsoc mentor? |
| 04:16.41 |
brlcad |
~seen
jordisayol |
| 04:16.42 |
ibot |
brlcad: i
haven't seen 'jordisayol' |
| 04:16.47 |
louipc |
brlcad: I
would, but I don't have much free time unfortunately :( |
| 04:18.02 |
KimK |
louipc: OK,
thanks, I had not considered that I might not be able to use a .deb
on Ubuntu anymore, I'll look into that. |
| 04:18.17 |
louipc |
brlcad: Not
really sure how I could mentor either since I'm not horribly active
in the project :/ |
| 04:18.39 |
louipc |
KimK: you can
use .deb packages, but they should be packaged specifically for
Ubuntu |
| 04:19.38 |
brlcad |
louipc:
anyone who has contributed enough to be trusted enough with commit
access is eligible, participation is voluntary for
everyone |
| 04:20.16 |
KimK |
louipc: Do
you know if there a BRL-CAD developer who packages for ubuntu?
Maybe from his own web page or PPA? |
| 04:20.28 |
louipc |
I could
mentor as in "It works" "it doesn't work, fix it" :D |
| 04:20.41 |
louipc |
KimK: not
sure |
| 04:21.03 |
KimK |
louipc: OK,
thanks. |
| 04:21.19 |
brlcad |
KimK: jordi
put together the recent .deb files |
| 04:21.36 |
brlcad |
~seen
epileg |
| 04:21.37 |
ibot |
epileg
<~epileg@unaffiliated/epileg> was last seen on IRC in channel
#brlcad, 2d 13h 6m 39s ago, saying: 'here in spain, exactly same as
``Erik'. |
| 04:21.45 |
brlcad |
that's
him |
| 04:23.34 |
brlcad |
louipc: good
to know -- we have a decent number of "auditing" mentors this year,
so just putting out feelers for folks in our community interested
in taking on a student |
| 04:23.43 |
brlcad |
which is
generally 10-20 hours a week |
| 04:24.13 |
louipc |
oh man that
would be too much |
| 04:26.08 |
brlcad |
add's up fast
-- just an hour or two a day of discussion on IRC will add up to
around that much |
| 04:26.33 |
brlcad |
but no
problem, figured worth asking -- let me know if you change your
mind |
| 04:26.58 |
louipc |
is that like
a 3mo gig? |
| 04:27.20 |
brlcad |
roughly |
| 04:27.59 |
brlcad |
http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline |
| 04:49.30 |
starseeker |
brlcad: If I
can't get to 40, we may just have to live with it... |
| 04:49.39 |
starseeker |
I've got to
sleep soon, been a long day here |
| 04:49.45 |
brlcad |
heh, that's
great |
| 04:50.07 |
brlcad |
it's plenty,
better to have 30 that are solid than 40 that are all
half-arsed |
| 04:50.36 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 04:51.22 |
starseeker |
I'm at 16
now, and given I need to review them all once more... I'll work it
tomorrow morning too, of course |
| 04:51.49 |
brlcad |
me too,
started on the application a while ago |
| 04:52.40 |
starseeker |
moron former
homeowners claimed they didn't need the sump pump, and we didn't
have to worry about it |
| 04:52.56 |
starseeker |
Wrong |
| 04:53.20 |
``Erik |
lame |
| 04:53.29 |
``Erik |
you're not in
a designated flood area, I imagine? |
| 04:53.47 |
starseeker |
no, but the
front half of our home is partially underground |
| 04:53.53 |
``Erik |
so'z no flood
insurance or anything... |
| 04:54.01 |
starseeker |
nah, we'll
have to eat it |
| 04:54.06 |
``Erik |
4 days of
solid rain is weird for md |
| 04:54.11 |
brlcad |
you also
believed them :) |
| 04:54.29 |
starseeker |
brlcad: Oh, I
know - I'm not claiming any medals |
| 04:54.47 |
``Erik |
I'm glad mine
is a slab, back yard turns to swamp, but no flooding :) |
| 04:54.48 |
brlcad |
any hole in
the ground is subject to water pressure |
| 04:55.25 |
starseeker |
figured if they had gotten away with it so long, must mean
the local lay of the land was such that there wasn't significant
water presence |
| 04:55.37 |
starseeker |
turns out
they were just really friggin lucky |
| 04:55.52 |
brlcad |
or they never
went down there ;) |
| 04:56.08 |
starseeker |
<snort>
yeah, that may be too |
| 04:56.35 |
starseeker |
also, they
only added the carpet in 2008 (we found out today) so perhaps they
wouldn't have noticed earlier incidents |
| 04:56.44 |
brlcad |
I'm wanting
to dig and install a french drain down mine, plenty of hydrostatic
pressure here |
| 04:57.04 |
brlcad |
really just wants an excuse to buy a
jackhammer |
| 04:57.05 |
``Erik |
I'm sure
you're well above the aquafer and have permeable soil, these last
few days have been massive with the consistent rainfall, the soil
is all saturating and there's nowhere for it to go... |
| 04:57.10 |
starseeker |
hehe |
| 04:57.33 |
starseeker |
``Erik: yeah,
noticed that - grounds as wet as squishy as I can ever remember
seeing it here |
| 04:58.11 |
starseeker |
we may be
"lucking out" and getting that right set of circumstances the
former owners never happened to get |
| 04:58.14 |
``Erik |
um, I kinda
got a bit stuck at work... in the grass/mud... with 4wd :D tore up
a bit of grass this evening |
| 04:58.25 |
starseeker |
but still, I
should have known better - they didn't add the sump system for
nothing |
| 04:58.39 |
starseeker |
it cost money
to add, and lord knows nothing in this place cost more than it had
to... |
| 04:58.42 |
``Erik |
standing
water all along the grass strip there |
| 04:59.13 |
starseeker |
nods - when I had to park in grass this morning, I didn't
even consider going in front first |
| 04:59.48 |
``Erik |
was able to
get out fine for lunch, it was after another few hours of rain that
it just turned to mud |
| 05:00.41 |
starseeker |
brlcad:
you're getting as bad as Bob, considering the relative sizes of
your properties - for you a jackhammer would take almost as much
relative storage space as Bob's backhoe |
| 05:00.56 |
``Erik |
gonna have to
wetvac one of the carpet bits, van drug in all sorts of mud
O.o |
| 05:01.09 |
starseeker |
ick |
| 05:01.21 |
brlcad |
naw, they
don't take that much space |
| 05:01.32 |
``Erik |
heh,
jackhammer would fit down brlcad's suicide hole |
| 05:01.47 |
brlcad |
that's
exactly where I intend to start |
| 05:02.16 |
brlcad |
if i'm going
to install a sauna down there, I want the hydrostatic pressure
released |
| 05:03.47 |
``Erik |
gym has a
sauna, make it a combo wine cellar/humidor :D |
| 05:04.56 |
brlcad |
it'll have a
wine rack, shower, sauna, sink, and toilet; still debating on the
hot tub |
| 05:05.03 |
``Erik |
or put a rack
down there to hang your car |
| 05:05.28 |
brlcad |
oh I totally
thought about installing an elevator to lower my car into "the
pit" |
| 05:05.34 |
``Erik |
has been wondering about putting in a slab under his deck to
put a hot tub on |
| 05:06.16 |
brlcad |
kind of like
these:
http://dornob.com/secret-agent-style-stealth-lift-patio-car-elevator/ |
| 05:06.46 |
brlcad |
ah, right --
this one almost exactly:
http://dornob.com/hydraulic-living-room-car-lift-rides-right-into-your-home/ |
| 05:07.29 |
``Erik |
just bolt a
couple handles on the side and pick it up :D |
| 05:12.23 |
``Erik |
brlcad: do
you have the gsoc corrospondance concerning 'more detail' available
for starseeker? is it volume, or information density? |
| 05:13.02 |
brlcad |
what? |
| 05:13.05 |
``Erik |
(or did
everyone get the same 'guidance' to push the mentors?) |
| 05:14.01 |
brlcad |
oh that was a
private conversation directly to me while they were reviewing our
application in '09 |
| 05:14.48 |
``Erik |
hm, so
nothing to help steer starseeker with that olympian
task |
| 05:15.22 |
brlcad |
it's not
quite as bad as it sounds, it's not really volume or density, just
sufficient variety to attract a wide range of students |
| 05:16.03 |
brlcad |
what was
there for '09 is what we ended up with *after* I expanded the list
in response to them saying we need more |
| 05:16.13 |
``Erik |
ah,
'k |
| 05:16.14 |
brlcad |
so that's
about par |
| 05:16.17 |
starseeker |
ah, that's
different |
| 05:16.41 |
``Erik |
clarification, w00t |
| 05:17.24 |
brlcad |
it should
basically have at least that much detail, but more importantly be
clear that there is a wide range of skills and it is easy for
-randome_student- to figure out which topics might be of interest
at a glance |
| 05:18.43 |
``Erik |
also;
starseeker has been breaking things down into a heirarchy with
links to the meat, are the goog reviewers going to be cool with
that, or do they want a single page view? it'd be fairly simple sql
to generate a single "big honkin' page", I'd think |
| 05:19.16 |
brlcad |
they're
unlikely to dive deep |
| 05:19.39 |
brlcad |
they have
hundreds of these to go through, they're going to sweep through the
site in all of 30 seconds |
| 05:19.52 |
starseeker |
we can
flatten it at the end, if we must - this is a better way for me to
keep track of what is and isn't done yet |
| 05:20.32 |
brlcad |
hence the
focus on clarity and organization, dumb simple clear that there's a
lot of topics and possibilities |
| 05:20.50 |
brlcad |
maybe a
shallow hierarchy would be a good balance |
| 05:21.15 |
brlcad |
like grouping
each of the major categories all onto one page together |
| 05:21.41 |
``Erik |
they already
are, under === == = headers, but the task description is a
link |
| 05:21.41 |
brlcad |
then just
have to consider what type of variety those top-level categories
convey |
| 05:22.35 |
brlcad |
right but
instead of kicking you off to a page with just one topic (which is
kinda useful), it'd kick you over to a page for that category with
the other dozen ideas in that topic area |
| 05:23.02 |
brlcad |
so even if
they only click one level deep, they get to see that there are lots
of project ideas |
| 05:23.47 |
brlcad |
I'd stick
with the one per page and massive top index for now until they're
mostly all fleshed out and named in non-brl-cad-technical
terms |
| 05:23.54 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2546 10/wiki/Geometry_Selection_Functionality: geometry
selection |
| 05:37.57 |
brlcad |
an iges task
would be good |
| 05:38.42 |
starseeker |
I'll see what
I can do - convert iges to spit out openNURBS nurbs? |
| 05:41.27 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2547 10/wiki/Libsvn_within_Geometry_Database_Format: libsvn in
.g |
| 05:42.32 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2548 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tools
*/ |
| 05:50.03 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2549 10/wiki/IGES_import_improvements: IGES updates |
| 05:50.31 |
starseeker |
ok, I gotta
sleep now |
| 05:51.21 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2550
10/wiki/Talk:Error_Messages: |
| 06:15.39 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:12.18 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 09:43.21 |
CIA-14 |
BRL-CAD:
03davidloman * r43841 10/geomcore/trunk/src/libNet/Portal.cxx:
Cleaned up a bit of messageLen checking logic. twas
wrong. |
| 09:46.28 |
CIA-14 |
BRL-CAD:
03davidloman * r43842
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/
(4 files in 2 dirs): Performing some java<->c/c++ bug
troubleshooting. Added the ability to down sample 16bit character
strings to 8bit character strings. |
| 10:48.38 |
dli |
how do I
disable -Werror? |
| 10:54.57 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 11:07.18 |
dli |
src/conv/patch/patch-g.c in 7.18.2 fails
with -Werror |
| 13:28.20 |
dloman |
my prayers to
all of you in or have family near the Pacific..... |
| 13:35.08 |
dli |
dloman, no
wonder 'tsunami' is a japanese word. no news of tsunami losses out
of japan yet |
| 13:42.06 |
starseeker |
dli: disable
strict |
| 13:44.12 |
dli |
starseeker,
yes, I found out that, but someone may still have to fix
patch-g.c |
| 13:44.44 |
dli |
or it's my
compiler, patch-g.c looks alright to me |
| 13:47.08 |
starseeker |
7.18.4 should
have a lot of strictness fixes |
| 13:49.22 |
dli |
starseeker,
the warning is about uninitilized variables, but it should not
happen to me. I will try whether some reorganizing helps the
compiler |
| 13:50.22 |
starseeker |
dli: I'd
suggest checking out the lastest subversion trunk and trying
that |
| 13:50.46 |
dli |
starseeker, I
will try that |
| 13:57.18 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2551 10/wiki/Space_Partitioning_for_Tessellation: tessellation
space paritioning |
| 14:02.01 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:09.21 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2552 10/wiki/STEP_Libraries: STEP improvements |
| 14:10.44 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2553 10/wiki/STEP_Libraries: |
| 14:21.59 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2554 10/wiki/NURBS_Intersections: surface/surface |
| 14:27.33 |
dloman |
dli: death
toll (worst guess i've read thus far) is at 60 and
climbing. |
| 14:27.50 |
dloman |
based only on
the video footage i've seen, that number's going to go waaay
up. |
| 14:28.27 |
starseeker |
it's bad, but
fortunately Japan is accustomed to dealing with
earthquakes |
| 14:28.53 |
dloman |
heh, the
quake was nothing, its the tsunami that's destroying
everything |
| 14:29.03 |
starseeker |
nods |
| 14:29.27 |
starseeker |
if large
waves hit less prepared areas of the world, the results could get a
lot worse |
| 14:30.02 |
dloman |
reuter's is
reporting that country's oil refineries are on fire, most of their
nuclear power plants have experienced an emergency shutdown,
etc. |
| 14:30.33 |
dloman |
righto,
that's what most people are saying. the warning system has been
greatly enhanced since the indonesia disaster in 2004 |
| 14:30.40 |
starseeker |
nods - 8.9 is a bad earthquake no matter how prepared you
are |
| 14:31.25 |
dloman |
waiting on
news from my cuson Josh. he's station at the naval medical
hospital in Okinawa |
| 14:31.47 |
dloman |
heh
s/cuson/cousin/ |
| 14:32.02 |
starseeker |
I imagine
he's probably OK |
| 14:32.28 |
starseeker |
probably
rather busy though |
| 14:32.29 |
dloman |
he is, i'm
just wanting to hear it from him, not his Command :) |
| 14:32.35 |
starseeker |
ah |
| 14:32.50 |
dloman |
oh yeah, that
slacker is going to finally earn his pay :) |
| 14:38.00 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2555 10/wiki/NURBS_Tessellation: nurbs tessellatoin |
| 14:40.12 |
dloman |
wow.... a
whirlpool...
http://www.cnn.com/video/#/video/world/2011/03/11/vo.whirlpool.earthquake.nhk?hpt=C2 |
| 14:41.59 |
starseeker |
grr
s/tessellatoin/tessellation |
| 14:54.04 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2556
10/wiki/Generalized_abstracted_spacial_partitioning_capability:
abstracted space partitioning |
| 14:56.03 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2557 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 15:03.39 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2558 10/wiki/Rework_of_libbu/libbn_to_not_require_Tcl: tcl
scrubbing |
| 15:13.05 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2559
10/wiki/Complete_bu_image/libicv_and_redo_all_pix_tools_to_use_it:
libicv |
| 15:14.23 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2560 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 15:31.30 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2561 10/wiki/Add_exec_option_to_search: search exec |
| 15:34.13 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2562 10/wiki/Add_exec_option_to_search: |
| 15:34.54 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2563 10/wiki/Add_exec_option_to_search: |
| 15:59.36 |
brlcad |
dloman: so
what would a tsunami feel like from inside a sub near the surface
but not on the surface? a can of beans? |
| 16:00.27 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2564 10/wiki/SVG_renderer: vector line rendering |
| 16:00.29 |
dloman |
probably be a
lot of rocking and rolling (angles n dangles) but no real
biggy. |
| 16:00.45 |
dloman |
we were at
100ft under a cat 4 hurricane once |
| 16:00.55 |
dloman |
was lots of
pitching, but thats it. |
| 16:00.59 |
brlcad |
don't think
you could get a barrel roll? |
| 16:01.03 |
dloman |
heh |
| 16:01.24 |
dloman |
nuclear sub
does a barrel roll and you'd have a pretty sizeable nuclear
accident :) |
| 16:02.04 |
``Erik |
http://seemslegit.com/_images/61b896b4384935498227a03c54b85370/93%20-%20barrel-roll%20ship.jpg |
| 16:03.32 |
dloman |
not loading
for me :/ |
| 16:03.38 |
dloman |
but I think i
have seen that one before. |
| 16:03.51 |
``Erik |
cargo ship
heeling at 80 or so? |
| 16:03.59 |
dloman |
ya |
| 16:05.32 |
dloman |
but on the
note of nuclear accidents, seems Japan is going to have one of
those too :/ |
| 16:05.54 |
dloman |
once of their
plants scrammed out and they can't get emergency cooling
established to the core :( |
| 16:06.18 |
brlcad |
"shut it off!
SHUT IT OFF!" |
| 16:06.25 |
dloman |
=D |
| 16:06.27 |
brlcad |
fuck,
RUN! |
| 16:06.48 |
starseeker |
that's Not
Good |
| 16:07.02 |
dloman |
Yeah, they
learned something from the chernobyl plants :) |
| 16:07.13 |
starseeker |
I thought
modern plants were supposed to fail safe |
| 16:07.19 |
brlcad |
dli: curious,
now have two impls that are nearly identical but with interesting
differences |
| 16:07.27 |
dloman |
"Whats that
big red light and that alarm for?" "Nothing, just keep on with the
test" |
| 16:07.46 |
dloman |
it is 'safe'
from a meltdown standpoint. |
| 16:08.03 |
dloman |
pressurized
water reactors shut themselves down on high temp |
| 16:08.30 |
starseeker |
so what's the
accident part? ruin all the core machinery? |
| 16:08.42 |
dloman |
but the
byproducts of the fission process are always activated and have to
shed their energy |
| 16:08.54 |
dloman |
so even a
shutdown core will generate heat for weeks. |
| 16:09.16 |
brlcad |
weenie roast
party! |
| 16:09.23 |
dloman |
run a core at
100% for a few months then scram it and you will see about 7% heat
generation for a few hours. |
| 16:10.07 |
dloman |
that 7%
decays to 0% (aka heat gen is < than the losses to ambient) in
usually about 15-21 days. |
| 16:10.18 |
dloman |
the entire
time, however, you must provide heat removal |
| 16:10.32 |
dloman |
which is the
problem the Japanese plan is having. |
| 16:10.50 |
dloman |
the tsunami
flooded a lot of their facilities and messed up a bunch of
equipment |
| 16:11.05 |
dloman |
so they are
having trouble removing the decay heat. |
| 16:11.54 |
dloman |
which, if let
go unchecked, could reach a high enough temperature to start
melting some of the cladding around the fuel rods, thus releasing
activated fission products into the coolant. |
| 16:12.00 |
``Erik |
read that
most of japan's nukes went emergency shutdown and oil refineries
are on fire |
| 16:12.07 |
dloman |
still
contained, but a naaaaaaaaaasty cleanup. |
| 16:12.49 |
dloman |
however, if
the tsunami has damaged any of the coolant piping, that nasty stuff
could get out.... |
| 16:13.42 |
dloman |
But, unles
they build 'em stupid over there in Japan (not likely) there is
usually a backup to the backup to the backup |
| 16:14.11 |
dloman |
and if their
emergency cooling system has failed, then they will prbably
fallback on the emergency emergency cooling system :) |
| 16:15.50 |
dloman |
</AccidentialNukeTheoryClass>
...sorry |
| 16:16.36 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2565 10/wiki/NMG_Raytracing_Performance_Improvement: nmg raytrace
performance |
| 16:17.39 |
starseeker |
hopes they get it handled, and not just for their sake - last
thing the world needs is another reason to be skittish about
nuclear power |
| 16:18.40 |
starseeker |
crap - sounds
like that death toll from Japan is going to get a lot
higher |
| 16:18.50 |
dloman |
seen the
videos on cnn ? |
| 16:19.04 |
CIA-14 |
BRL-CAD:
03brlcad * r43843
10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: apply an
initial (reportedly non-working) version of rt_revolve_xform() from
dli |
| 16:19.11 |
dloman |
i watched
over 20 cars get swallowed by water.... its going to be really
bad |
| 16:21.08 |
starseeker |
good god -
what IS that whirlpool from? |
| 16:21.24 |
dloman |
dunno, but it
stops toward the end. really wierd. |
| 16:21.48 |
``Erik |
small fissure
opening up? tsunami water draining strangely? |
| 16:21.55 |
dloman |
http://www.myvisitingcard.com/2011/onagawa-fire-broke-out-declared-nuclear-power-emergency-situation.html |
| 16:22.18 |
starseeker |
wondered if it was some subterranian crack in the sea
floor... |
| 16:22.37 |
dloman |
Dr evil's
secret lair flooded? |
| 16:22.42 |
CIA-14 |
BRL-CAD:
03brlcad * r43844
10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: move up in
order to compare patch |
| 16:24.00 |
starseeker |
dloman:
what's a "nuclear emergency situation"? |
| 16:24.10 |
dloman |
intentionally
vauge |
| 16:24.15 |
dloman |
=D |
| 16:24.19 |
starseeker |
humph |
| 16:24.30 |
dloman |
the article
states that they 'cooling the reactor is not going as
planned' |
| 16:24.49 |
dloman |
which means
they got th reactors safelt shutdown, but are having issues
mantaining cooling to the core. |
| 16:25.00 |
dloman |
to remove the
above mentioned 'decay' heat |
| 16:26.05 |
dloman |
push comes to
shove, the did just have a tsunami, so they have plenty of water to
use for cooling. :/ |
| 16:35.07 |
CIA-14 |
BRL-CAD:
03brlcad * r43845
10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: |
| 16:35.07 |
CIA-14 |
BRL-CAD: and
then merge in his version that reportedly works with a couple
changes. we |
| 16:35.07 |
CIA-14 |
BRL-CAD: do
need a copy of the bu_vls, so init and cat accordingly. skt was
apparently a |
| 16:35.07 |
CIA-14 |
BRL-CAD: typo
and MAT4X3VEC instead of MAT4X3PNT is probably what got it
working. |
| 16:35.38 |
dloman |
ah, looks
like the waves have finally reached cali |
| 16:38.22 |
CIA-14 |
BRL-CAD:
03brlcad * r43846
10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: doxygen +
ws |
| 16:39.54 |
CIA-14 |
BRL-CAD:
03brlcad * r43847
10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: eip/eop was
specific to extrude. use rip/rop for revolve. |
| 16:40.49 |
CIA-14 |
BRL-CAD:
03brlcad * r43848 10/brlcad/trunk/src/librt/primitives/table.c: dli
implemented rt_revolve_xform and it compiles, so turn it on for
testing |
| 16:42.48 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2566 10/wiki/Plate_Mode_NURBS_raytracing: plate mode
NURBS |
| 16:44.00 |
starseeker |
Just under 20
to go |
| 16:45.23 |
CIA-14 |
BRL-CAD:
03brlcad * r43849 10/brlcad/trunk/ (AUTHORS NEWS): Dongxu Li
implemented support for applying matrix transformations (scale,
translate, rotate) to the revolve primitive. promote him up from
the special thanks section to being recognized as a code
contributor. |
| 16:45.47 |
brlcad |
kicks off a final release build while he works on the gsoc
application |
| 16:48.11 |
brlcad |
really
curious to know whether the the libbu mmap bug affects other tools
on windows |
| 16:51.48 |
CIA-14 |
BRL-CAD:
03brlcad * r43850 10/brlcad/trunk/NEWS: (log message
trimmed) |
| 16:51.48 |
CIA-14 |
BRL-CAD:
cliff and I apparently (hopefully) squished the 'red' command bug
where it |
| 16:51.48 |
CIA-14 |
BRL-CAD:
wasn't working on windows. the problem was two-fold. the regex code
wasn't |
| 16:51.48 |
CIA-14 |
BRL-CAD:
breaking on newlines and (apparently) libbu's mapped_file fallback
support had |
| 16:51.49 |
CIA-14 |
BRL-CAD: an
off-by-one error where it wasn't terminating the mapped file with a
zero |
| 16:51.49 |
CIA-14 |
BRL-CAD:
byte. that was causing regex to scan beyond the buffer extent. that
issue very |
| 16:51.49 |
CIA-14 |
BRL-CAD:
likely affects other tools and interfaces that use our mapped file
support on |
| 16:51.55 |
brlcad |
amazing, went
from being a tiny patch release to looking more and more like a
full minor update |
| 16:55.46 |
brlcad |
``Erik: you
have any gimp skill? need a small image to represent the TIE BoT
enhancement (max 256x256) |
| 16:57.34 |
brlcad |
was thinking
maybe a two 128x128 images in opposite corners of the 256x256
space, one partially rendered 20%, the other at 100%, with text
above/below each respectively saying old mesh rendering and new
approach |
| 16:58.11 |
brlcad |
or maybe a
new validation image of the truck showing the pixdiff differences,
scaled down |
| 16:58.20 |
brlcad |
(or rendered
at that size even better) |
| 17:10.15 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2567 10/wiki/CSG_to_NURBS_conversion: finish up
CSG->Brep |
| 18:01.24 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2568 10/wiki/Google_Summer_of_Code/Project_Ideas: Remove a few
entries - getting down to the wire |
| 18:26.06 |
``Erik |
nope, no gimp
skill at all, I can click on 'script-fu' and click 'scale', that's
about it |
| 18:26.18 |
``Erik |
starseeker:
vic reports red is not working on mac |
| 18:26.35 |
``Erik |
a very recent
change broke it |
| 18:54.27 |
brlcad |
probably the
regexes |
| 18:55.21 |
brlcad |
will look after the application is done |
| 19:27.03 |
``Erik |
hm, too late
for new ideas for gsoc? |
| 19:28.18 |
``Erik |
"voxelize",
like facetize, to spew out a big honkin' union of arb8's, mebbe
using the marching cubes grid stuff... to feed cfd's and
stuff |
| 19:31.09 |
starseeker |
``Erik: not
too late if you want to add it |
| 19:31.43 |
starseeker |
had to take down some stuff in his house - I'll try to get a
couple more done.. |
| 19:32.15 |
starseeker |
still got
work going on - drywall out everywhere... |
| 19:33.20 |
dloman |
ever find
that leak? |
| 19:33.39 |
starseeker |
dloman: it
was the friggin sump pump (or rather, lack thereof) |
| 19:33.48 |
dloman |
broke or
missing? |
| 19:33.54 |
starseeker |
previous
homeowners assured us they'd never needed it (they took it
out) |
| 19:34.02 |
starseeker |
we though
"well, OK..." |
| 19:34.06 |
starseeker |
oops |
| 19:34.11 |
dloman |
oh
man..... |
| 19:34.20 |
starseeker |
one of my
more expensive mistakes |
| 19:34.24 |
dloman |
i thought it
was regulation to have one? |
| 19:34.31 |
starseeker |
? |
| 19:34.33 |
starseeker |
dunno |
| 19:34.52 |
dloman |
looking to
build my next house, so i have a reg book at home. I'll check
:) |
| 19:34.57 |
dloman |
SUE
THEM!!!! |
| 19:34.59 |
dloman |
j/k |
| 19:35.19 |
dloman |
is the
piping/wiring to a sump pump still in place? |
| 19:35.38 |
starseeker |
<snort>
I doubt it's "on the books" - we asked about it durning the home
buying process, and one of the pros would have said something if it
was actually required... |
| 19:36.06 |
starseeker |
dloman: sure
- there's a sump, an outside pipe and an outlet. They just took
out the indoor pipe and pump and turned it into a
closet |
| 19:36.45 |
starseeker |
now that I've
got the mirror wall off the staircase, there's a much bigger mold
spot |
| 19:37.01 |
starseeker |
too high for
recent activity, so looks like the pipe to the faucet outside may
be having issues |
| 19:37.11 |
dloman |
oh hell....
mold... im so sorry man :( |
| 19:40.26 |
starseeker |
they cut out
like four feet of drywall and sprayed some stuff, so the mold is
gone, but we look like a home rennovation show down
there |
| 19:42.21 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2569
10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core
Library Enhancement */ |
| 19:45.47 |
``Erik |
what was the
name of that thing mike did? uh, qubit or something? |
| 19:45.58 |
starseeker |
cubit |
| 19:46.22 |
starseeker |
http://cubit.sandia.gov/ |
| 19:46.41 |
starseeker |
was never much interested in it, as it's not open
source |
| 19:47.00 |
starseeker |
(at least,
the interesting parts related to mesh generation don't seem to
be) |
| 19:47.30 |
brlcad |
``Erik: I
need your link_id not your google id this year |
| 19:48.06 |
brlcad |
dloman: did
you see my message about a poster? :) |
| 19:48.20 |
dloman |
message? |
| 19:48.22 |
dloman |
negative |
| 19:49.18 |
brlcad |
we're going
to need another gsoc poster this year, it's a chance to take some
creative artistic liberty and make a neat page enticing students to
apply |
| 19:49.37 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2570 10/wiki/Material_and_Shader_Objects: material and shader
objects |
| 19:49.38 |
brlcad |
you'd be
perfect for that, as shown by other graphics you've worked on of
late ;) |
| 19:49.41 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2571
10/wiki/Voxelize: New page: Voxel data sets are commonly used in
computational fluid dynamic simulations. The current technique for
creating voxels from BRL-CAD geometry is to use the proprietary
cubit framework. Th... |
| 19:49.42 |
dloman |
where was the
message? Or was that it? |
| 19:49.47 |
starseeker |
and you don't
want me doing it :-P (see archer icons) |
| 19:50.09 |
dloman |
yeah,
starseeker MS paint isnt that great of an editor :P |
| 19:50.25 |
brlcad |
you can see
the previous two years posters by me and cliff at
http://brlcad.org/wiki/Google_Summer_of_Code#BRL-CAD_participation_in_GSoC |
| 19:50.49 |
starseeker |
<snort>
Gimp + inkscape + http://www.openclipart.org/
baby |
| 19:51.17 |
brlcad |
cool, the
initial submission is DONE |
| 19:51.22 |
brlcad |
now to
tweak |
| 19:51.24 |
starseeker |
awesome |
| 19:52.41 |
starseeker |
``Erik: any
of the existing ones you want to fill in? (shader enhancements
might be a good one, you have more knowledge about 'em than I
do) |
| 19:52.47 |
``Erik |
huzzah, a
menu items appear, it is effective! |
| 19:53.47 |
``Erik |
nah,
starseeker, I'm good :D (not sure what the shader thing is
about) |
| 19:58.12 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2572
10/wiki/GUI_Animation_editor/creator: New page: Creating animations
using BRL-CAD is currently a very manual and tricky process. A GUI
editor to create Bezier splines for moving objects, lights and the
camera and generating rt scripts a... |
| 19:58.39 |
starseeker |
``Erik: I was
thinking investigate Open Shader Language and how we can benefit
from it |
| 19:58.46 |
starseeker |
maybe too
vague for a gsoc project though |
| 19:58.51 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2573
10/wiki/GUI_Animation_editor/creator: |
| 19:59.08 |
``Erik |
I dunno the
open shader language... similiar to renderman? |
| 19:59.16 |
starseeker |
yeah... |
| 19:59.18 |
starseeker |
<PROTECTED> |
| 19:59.33 |
starseeker |
http://opensource.imageworks.com/?p=osl |
| 19:59.40 |
starseeker |
was a big
thing at siggraph |
| 19:59.57 |
brlcad |
mm, shader
objects |
| 20:00.21 |
starseeker |
brlcad: did I
miff that one? |
| 20:00.27 |
starseeker |
may be typing too fast here... |
| 20:00.41 |
brlcad |
I haven't
read any of them yet, delegation my dear watson |
| 20:00.45 |
brlcad |
taking a lot
of time just to prep the app |
| 20:00.49 |
starseeker |
nods |
| 20:01.00 |
brlcad |
it's in, but
I still have at least an hour of editing and re-reviewing to
go |
| 20:01.04 |
starseeker |
got
it |
| 20:01.18 |
brlcad |
leaving it
all on you guys :) |
| 20:01.23 |
starseeker |
well, if it
gets buy gsoc review we can polish it later |
| 20:01.27 |
CIA-14 |
BRL-CAD:
03jordisayol * r43851 10/brlcad/trunk/sh/ (make_deb.sh
make_rpm.sh): modify deb/rpm building packages
dependencies |
| 20:06.03 |
dloman |
brlcad: when
u need the poster by? |
| 20:06.46 |
brlcad |
whenever it's
ready really |
| 20:06.53 |
``Erik |
yesterday
morning |
| 20:06.59 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2574
10/wiki/Shader_Enhancements: New page: Shaders for the ray-tracer
are currently coded in C and explicitly added to the active shader
list. A shader to bridge the RT shader system to the BSD licensed
implementation of OSL ( [htt... |
| 20:07.18 |
brlcad |
if you want
to make sure you don't waste time, then as soon as org applications
are approved |
| 20:07.29 |
starseeker |
``Erik: heh,
beat me too it - thanks! |
| 20:07.39 |
brlcad |
since ours
has a high chance of acceptance, then anytime really |
| 20:07.40 |
``Erik |
probably
needs cleanup/editing anyways |
| 20:07.58 |
``Erik |
I'm just
spewing out rough draft quality stuff here... :D |
| 20:08.22 |
starseeker |
checks... |
| 20:08.28 |
starseeker |
``Erik: you
think I'm not? |
| 20:08.35 |
starseeker |
I tend to
ramble in the best of times |
| 20:08.40 |
starseeker |
writing fast
makes it worse |
| 20:10.14 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2575
10/wiki/General_Tree_Walker: New page: There are currently several
slightly different functions to recursively walk the CSG tree. This
task would be to implement a new tree walking function capable of
replacing them all and alt... |
| 20:12.22 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2576 10/wiki/Shader_Enhancements: Tweak shader enhancements
entry |
| 20:13.19 |
starseeker |
hits blender-g |
| 20:16.09 |
brlcad |
should
probably be blend-g ;) |
| 20:16.17 |
starseeker |
er,
right |
| 20:16.35 |
starseeker |
heh -
blender-g, toaster-g, eggbeater-g... |
| 20:16.35 |
brlcad |
remember to
try and avoid brl-cad specific conventions at least in the project
titles and initial sentance descriptions |
| 20:16.54 |
CIA-14 |
BRL-CAD:
03Erik 07http://brlcad.org * r2577
10/wiki/Converter_completion_so_all_current_formats_have_both_import_and_export:
New page: BRL-CAD implements numerous importers and exporters for a
wide variety for formats, but not every format has both an importer
and an exporter. An old list is available in the repository
[h... |
| 20:17.05 |
brlcad |
it should be
worded as if BRL-CAD did not exist (e.g., "Blender geometry
importer") |
| 20:17.15 |
starseeker |
brlcad: I'll
try to make a pass and eliminate as much of that as I
can... |
| 20:17.22 |
brlcad |
then can go
into detail on the specific page |
| 20:17.27 |
``Erik |
next time I
make a disposable geometry format, I am so calling it
spatula. |
| 20:17.57 |
brlcad |
really liked avoCADo :) |
| 20:18.17 |
brlcad |
(dead for 3
years now) |
| 20:18.36 |
starseeker |
is it on
sourceforge? we could try a takeover :-P |
| 20:18.37 |
brlcad |
there's some
nurbs code you could look into snarfing starseeker |
| 20:18.44 |
starseeker |
what
license? |
| 20:18.55 |
brlcad |
sourceforge
project name sucks -- "avocado-cad" |
| 20:19.21 |
brlcad |
ah right,
gpl |
| 20:19.26 |
brlcad |
bleh |
| 20:19.46 |
starseeker |
there are
least two other nurbs libs I'm aware of that are will remaing
GPL |
| 20:19.49 |
starseeker |
very
frustrating |
| 20:19.56 |
starseeker |
(especially
SISL...) |
| 20:21.10 |
brlcad |
dloman: the
only stipulation is that the poster should be predominantly made
with brl-cad imagery ;) |
| 20:21.17 |
brlcad |
which
shouldn't be hard for you of all people |
| 20:25.04 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2578 10/wiki/Blender-g_importer: blend-g |
| 20:28.11 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/move: [[SVG renderer]] moved to [[Vector
output from raytracing]]: retitle |
| 20:29.28 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/move: [[Blender-g importer]] moved to
[[Blender file format converter]]: retitle |
| 20:29.38 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2583 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 20:30.24 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2584 10/wiki/General_Tree_Walker: |
| 20:37.42 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.148.157) |
| 20:37.43 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:49.05 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2585 10/wiki/Overlap_tool: overlap tool |
| 20:52.23 |
CIA-14 |
BRL-CAD:
03jordisayol * r43852 10/brlcad/trunk/ (misc/debian/rules
sh/make_deb.sh sh/make_rpm.sh): update "make" simultaneous jobs,
during deb/rpm building process |
| 20:52.29 |
``Erik |
pics
http://www.theatlantic.com/infocus/2011/03/earthquake-in-japan/100022/ |
| 20:53.10 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2586 10/wiki/Automated_exploded_view_tool: exploded
view |
| 20:53.46 |
brlcad |
i guess it
did happen |
| 20:58.49 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2587 10/wiki/Automated_cutaway_view_tool: cutaway view |
| 20:59.52 |
starseeker |
pants - thanks ``Erik for the assist |
| 20:59.56 |
CIA-14 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2588 10/wiki/Google_Summer_of_Code/Project_Ideas: remove stray
links |
| 21:01.36 |
starseeker |
just before
4pm EST |
| 21:02.13 |
starseeker |
now has to head in - ``Erik if you want to flatten the page
in some way shape or form you're welcome |
| 21:02.45 |
brlcad |
thanks
starseeker, tis great rogress |
| 21:05.23 |
starseeker |
brlcad: your
welcome, my pleasure - we'll hope it's enough |
| 21:11.20 |
``Erik |
http://www.youtube.com/watch?v=vs2l38DoqsQ |
| 22:41.30 |
brlcad |
dloman: do
you have a link_id? |
| 22:45.34 |
CIA-14 |
BRL-CAD:
03128.63.32.5 07http://brlcad.org *
r2589 10/wiki/Google_Summer_of_Code/Project_Ideas: stray
text |
| 22:57.18 |
starseeker |
hmm:
http://www.nasa.gov/open/source/ |
| 23:00.08 |
brlcad |
adds the final finishing touches |
| 23:03.31 |
CIA-14 |
BRL-CAD:
03starseeker * r43853 10/brlcad/branches/cmake/ (8 files in 6
dirs): MFC r43852 |
| 23:03.44 |
starseeker |
wonders if he can attend a two day virtual
conference... |
| 23:06.56 |
brlcad |
that's
probably the best-worded GSoC application to date |
| 23:07.20 |
brlcad |
invariably
reorganize every time, clean up the organization and writeup
structure |
| 23:07.29 |
starseeker |
cool
:-) |
| 23:09.18 |
starseeker |
yeow, what
the heck... |
| 23:09.29 |
brlcad |
430 orgs
applied |
| 23:09.34 |
starseeker |
rebuilds clean - hopefully this is just a messed up
build... |
| 23:09.44 |
starseeker |
brlcad: is
that more than last year? |
| 23:09.54 |
brlcad |
yeah |
| 23:10.04 |
brlcad |
but then org
acceptance has increased every year too |
| 23:10.19 |
starseeker |
how long
typically before we find out? |
| 23:12.01 |
brlcad |
http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline |
| 23:12.19 |
starseeker |
ah,
right |
| 23:12.33 |
brlcad |
~gsoc |
| 23:12.33 |
ibot |
gsoc is
probably the Google Summer of Code, a program run annually by
Google to provide (paid for) jobs to students to code on open
source projects over summer. See http://code.google.com/soc/ for
details. |
| 23:12.46 |
brlcad |
~timeline |
| 23:13.15 |
brlcad |
~timeline is
the GSoC 2011 timeline is at
http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/timeline |
| 23:13.15 |
ibot |
okay,
brlcad |
| 23:20.43 |
starseeker |
interesting... red works on my
Mac |
| 23:20.53 |
starseeker |
let's try
with system regex |
| 23:21.26 |
brlcad |
that is
interesting |
| 23:21.39 |
brlcad |
he wouldn't
have likely compiled with system regex on mac |
| 23:21.44 |
brlcad |
because of
system tcl/tk |
| 23:21.54 |
brlcad |
unless he
specifically turned on system regex |
| 23:22.25 |
starseeker |
that's cmake
build... suppose I should try autotools |
| 23:22.58 |
brlcad |
at least,
auto doesn't work on 10.6 because system tcl IS a compatible .6,
but mged/libdm crashes trying to make X11 calls |
| 23:24.35 |
starseeker |
ah... in
principle, the CMake FindTCL should spot that system Tcl/Tk isn't
X11 - will have to try that out |
| 23:28.03 |
starseeker |
may have to
ask him more specifically what failed |
| 23:28.24 |
brlcad |
technically,
configure is checking correctly |
| 23:28.27 |
brlcad |
our code is
wrong |
| 23:30.08 |
brlcad |
hopes for an ogre/qt dm project |
| 23:30.35 |
starseeker |
That'd be
awesome |
| 23:31.43 |
starseeker |
no, system
regex worked too |
| 23:32.02 |
starseeker |
wonder if his
build got into a weird state - I had to flush my cmake build and
redo |
| 23:32.28 |
starseeker |
will check with him on Monday, assuming he doesn't have to be
home for more contractor fun |
| 23:52.51 |
dli |
starseeker,
how big is the whole svn repository? it has been downloading for
two hours |
| 23:52.58 |
starseeker |
uh
oh |
| 23:53.09 |
starseeker |
dli: you
don't want the whole thing |
| 23:53.31 |
starseeker |
try svn co
https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk
brlcad-svn |
| 23:55.21 |
dli |
starseeker,
oh, I only put https://brlcad.svn.sf.net/svnroot/brlcad/
there :( my bad |
| 23:55.33 |
starseeker |
ouch |
| 23:55.48 |
starseeker |
yeah, that'll
pull all tags, all branches, all of everything |
| 23:56.46 |
starseeker |
I'll
generally use the svn browse functionality to check the structure
of a repository prior to downloading |
| 23:59.59 |
dli |
starseeker,
I'm putting this together for a gentoo ebuild:( |
| 01:40.16 |
KimK |
Hi, I can't
install the 7.18.2 .deb in Ubuntu 10.04 due to dependency issues
(my libncurses5 is too old, it's current). Would it be a reasonable
project to compile BLR-CAD from source on my machine, or would I
hit the same libncuses5 wall anyway? |
| 01:40.52 |
KimK |
s/libncuses5/libncurses5/ |
| 01:41.38 |
KimK |
s/BLR-CAD/BRL-CAD/ |
| 01:42.26 |
KimK |
is sure glad he caught those mispellings before that went
out, whew! |
| 02:19.33 |
starseeker |
might be able to get his hands on a neo1973
phone... |
| 04:02.21 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 04:23.18 |
dli_ |
KimK, still
couldn't get 7.18.2? |
| 05:35.40 |
KimK |
dli_: Hi, I
have the .deb of course, but gDebi says my libncurses5 is too old,
I have 5.7+2009xxxx and it wants 5.7+2010xxxx or something. So I
thought I might be able to persuade a dev to freshen the Ubuntu
10.04 libncurses5, but I haven't managed that yet either. I think
even the Debian libncurses5 is too old. So then I thought, maybe
compile from source on my machine? Anyway, no, BRL-CAD still not
installed here. |
| 05:39.57 |
KimK |
dli_: And I
have the source tarball, but I'm trying to learn git and brlcad is
on Sourceforge with SVN. So I've been fiddling with git-svn to load
the development source, I have done that several times, lol. Maybe
Sourceforge's SVN doesn't play nice with git-svn? I haven't got
that sorted out yet. |
| 05:43.16 |
KimK |
dli_: Thanks
for checking on me. Any and all comments and advice appreciated.
Again, I would like to install BRL-CAD on Ubuntu 10.04 LTS by any
method. No hurry, I just wanted to try it and see what all the fuss
is about, lol! |
| 05:49.59 |
KimK |
dli_:
Pursuing this problem from another angle, I wonder if you could
help me find out what OS the BRL-CAD developers are using, where
they got this new libncurses5? I have virtualbox, and I'm getting
the new Debian 6.0 DVD (slowly). If I installed Debian 6.0 in VBox,
would I be able to install BRL-CAD there? Just thinking about other
ways to skin the cat. |
| 05:54.15 |
Ralith |
there's
fuss? |
| 06:16.08 |
KimK |
Haha, sure!
Powerful and free/open, if perhaps not easy to learn and use? Such
are the reports I hear, anyway. |
| 06:21.54 |
KimK |
If it's in
the same class as SolidWorks, and is free/open and Linux-friendly,
I'd certainly like to have a look at it. |
| 06:50.15 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.156.61) |
| 06:50.15 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 09:20.39 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.156.61) |
| 09:20.39 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 09:33.51 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 11:01.59 |
dli_ |
KimK, you may
try to rebuild it. First make sure you have deb-src lines in your
sources.list, then: apt-get build-dep brlcad; apt-get -b source
brlcad |
| 11:25.11 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2599
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Non-Uniform
Rational B-Splines */ |
| 11:29.02 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2600
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Display Managers /
Framebuffers */ |
| 11:35.11 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2601
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Graphical Interface
Enhancements */ |
| 11:40.50 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2602
10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 11:49.36 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2604
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Project Ideas
*/ |
| 11:50.38 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2605
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Graphical User
Interface Infrastructure Projects */ |
| 11:50.52 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2606
10/wiki/Google_Summer_of_Code/Project_Ideas: /* User Interface
Enhancement Projects */ |
| 11:54.19 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2607
10/wiki/Google_Summer_of_Code/Project_Ideas: separate into two
categories |
| 11:56.57 |
CIA-14 |
BRL-CAD:
03Sean 07http://brlcad.org * r2608
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tool Projects
*/ |
| 12:32.14 |
``Erik |
it should
build fine from source on any reasonably recent *nix... the
developers use mac, freebsd, rhel and gentoo for the most
part |
| 12:53.49 |
cjdevlin |
KimK: i have
installed on 10.04 several times from source. i had no
issues. |
| 13:17.13 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.156.61) |
| 13:17.13 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:19.11 |
cjdevlin |
i just did a
wget on this link:
http://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/7.18.2/brlcad-7.18.2.tar.gz/download
|
| 13:19.11 |
cjdevlin |
and the
tarball i got was 7.18.0? |
| 13:31.54 |
KimK |
dli_ ,
cjdevlin: OK, I will try building from source. I did try installing
Debian 6.0 in Vbox and then installing BRL-CAD there, that seemed
to work, but I'd prefer to have BRL-CAD on my main screen. So this
MGED is the main app screen? Are there tutorials on the Wiki? I
looked at the wiki and downloaded a bunch of manuals, but I'm
starting from zero here, and this doesn't look like any other CAD
program I've ever run across. Anything on YouTub |
| 13:31.54 |
KimK |
e? Where do
you recommend newbies begin? |
| 13:31.57 |
KimK |
Opps |
| 13:32.01 |
KimK |
Oops |
| 13:32.37 |
cjdevlin |
there is a
tutorial on the wiki. before you try to build run: sh
autogen.sh |
| 13:33.25 |
cjdevlin |
the tutorial
is still *pretty* close, but there are some
inconsistencies. |
| 13:33.36 |
cjdevlin |
did you ask
about this in the ubuntu forums a week or so ago? |
| 13:33.41 |
cjdevlin |
ubuntu
irc* |
| 13:36.29 |
KimK |
OK, thanks, I
will. That's not in the wiki? I may have asked about updating
libncurses5, were you there? I didn't really get anywhere with that
though. Where does everybody put the tarball if they might want to
have SVN later too? I presume SVN (devel) is broken once in
awhile? |
| 13:37.50 |
KimK |
Or do I have
to pick one or the other and use only ~/brlcad/ ? |
| 13:38.26 |
cjdevlin |
the tutorial
is available . . . let me see if i can find it. i kind of remember
something like that when i first tried to build. autogen took care
of it. you can use checkinstall to install programs as a
'package' |
| 13:40.43 |
cjdevlin |
http://brlcad.org/wiki/Documentation |
| 13:41.13 |
cjdevlin |
the
introduction to mged is a complete tutorial. you can be up and
running in a few hours if you can sit that long :-) |
| 13:41.59 |
cjdevlin |
and the code
is hosted on sourceforge: http://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/ |
| 13:42.13 |
cjdevlin |
sourceforge
went down a few weeks ago, but that is very uncommon |
| 13:42.22 |
KimK |
OK, thanks
for looking. I was just thinking that it would be nice to have both
the tarball source for the latest release version and the SVN
source for the devel version, even if broken sometimes, but I don't
want to do anything that's non-standard. Who knows, maybe I can
even help later on. |
| 13:43.41 |
cjdevlin |
i am not a
developer. i am relatively new myself. the guys that really know
what they are doing read the logs, so if you stay logged on long
enough you will definitely get the help you need/want |
| 13:44.24 |
cjdevlin |
are you
building now? |
| 13:44.25 |
KimK |
Yes, I was
wondering about sourceforge. I'm a git fan and I tried to download
with git-svn, which I've done before other places. But it didn't
seem to work, it started, then stalled out. If I use SVN, it works
fine. |
| 13:44.56 |
cjdevlin |
for
sourceforge i usually just do a wget |
| 13:45.23 |
KimK |
That doesn't
work for SVN, does it? |
| 13:45.27 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:47.25 |
cjdevlin |
not sure. i
have never tried it. i have just stuck with the stable releases so
far. |
| 13:48.49 |
KimK |
Ha, thanks
for the tip about staying logged on. I'll add this channel to my
auto sign-on. A friend of mine has access to 1 seat of SolidWorks,
but that may turn out to be temporary, who knows? So it would be
good if I could learn BRL-CAD as an alternate. But I'm more in
favor of it becasue of the free/open thing. SW may be nice, but I
don't own it. I can own BRL-CAD. |
| 13:50.20 |
cjdevlin |
i know a
windows version is in the works and they are converting from
autotools to cmake for cross platform-ability
</madeupword> |
| 13:50.49 |
cjdevlin |
are you
trying to build now? |
| 13:53.08 |
KimK |
No, I haven't
tried yet. I was still wondering about whether the
tarball/scripts/automake/etc will be happy if I put them someplace
besides ~/brlcad/ ? Can I put it anywhere? |
| 13:54.46 |
cjdevlin |
yes. |
| 13:54.58 |
KimK |
How about
~/brlcad7182/ ? Would that be OK? |
| 13:55.18 |
cjdevlin |
i download
all of the files i build into
~/source/<nameofprog> |
| 13:56.05 |
cjdevlin |
when you
extract it, it will create a directory in a format of:
brlcad-7.18.2 |
| 13:56.21 |
KimK |
OK, I'll try
that. I usually use git, so I haven't done a tarball for anything
yet. But that sounds OK. |
| 13:56.53 |
cjdevlin |
it's just a
compressed version. |
| 14:00.29 |
KimK |
The wiki
mentions ./autogen.sh is that what you meant when you wrote sh
autogen.sh ? |
| 14:01.37 |
cjdevlin |
yes, that
does the same thing |
| 14:02.06 |
KimK |
OK. I hadn't
seen that sh before, just the ./ |
| 14:03.06 |
cjdevlin |
./ runs
executables, sh invokes the shell directly. *.sh is the shell file
type, so ./ will call the shell anyways |
| 14:03.19 |
dloman |
Mernin
all. |
| 14:03.32 |
KimK |
Wait, before
I do that, wasn't there some brlcad-build-essentials or something?
Let me scroll back... |
| 14:03.59 |
cjdevlin |
regular
build-essentials |
| 14:04.41 |
KimK |
brlcad-dev
maybe? I thought there was something. No? |
| 14:05.09 |
KimK |
I should
already have build-essentials |
| 14:05.32 |
KimK |
OK, I'll try
it and see if it warns me |
| 14:05.36 |
dloman |
I know i'm
jumping in the middle of this and havent read the backlog yet, but
are you trying to get brlcad built from source? |
| 14:05.46 |
KimK |
Yes, I
am. |
| 14:05.54 |
KimK |
HI, thanks
for asking |
| 14:06.02 |
cjdevlin |
there are no
ubuntu brl-cad dev packages. |
| 14:06.14 |
KimK |
OK,
thanks. |
| 14:06.29 |
dloman |
KimK: having
problems then? |
| 14:09.10 |
KimK |
Well, had
some other problems before, but just starting to build from source
right now. OK, it says it's prepared and to run ./configure and
then make. I'll start it. |
| 14:09.49 |
dloman |
you have
multicore machine? |
| 14:12.07 |
dloman |
My oh my,
things are looking grim at the Dai-Ichi plant in
Japan.... |
| 14:13.27 |
KimK |
No, one core.
And I run 32-bit Ubuntu even though it's an AMD64 (small, cheap one
though) because I stick with the EMC2 folks and 64-bit real-time
isn't quite soup yet. |
| 14:14.05 |
dloman |
okay then,
you're in for a bit of a wait. brl-cad takes a while to
build. |
| 14:15.39 |
KimK |
I saw one
medium-sized warning about
>>>>>>>>>>>>>Floating Point
May not be
Compatible>>>>>>>>>>>> or
something. And a couple of small warnings. But it didn't stop, it
completed. It said type make, so I did. |
| 14:15.50 |
dloman |
right
on. |
| 14:16.11 |
dloman |
if configure
succeeded, then you are probably good to go. |
| 14:16.20 |
dloman |
the make will
take some time, though. |
| 14:16.58 |
cjdevlin |
KimK: i had
the same issue w/ the libncurses i think. running autogen.sh took
care of it for me. i had the same floating point warning, but
haven't run into an issue yet. |
| 14:17.42 |
cjdevlin |
just built on
a sempron: Elapsed compilation time: 1 hour, 5 minutes, 24
seconds |
| 14:17.42 |
cjdevlin |
Elapsed time
since configuration: 1 hour, 7 minutes, 30 seconds |
| 14:17.46 |
cjdevlin |
not too crazy
:) |
| 14:20.28 |
KimK |
OK, no
problem. cjdevlin , dloman , thanks very much for your help. Ha, I
was just going to ask if it would be about an hour or more. I have
a recent but unremarkable motherboard, 4G of ram (well, 3.7after
the on-board-graphics robbery), and a cheap proc. |
| 14:21.22 |
dloman |
as long as
you can afford the time, then 1+ hrs is no biggie :) |
| 14:22.04 |
cjdevlin |
KimK: the
machine i built on is a fossil of sorts. it shouldn't take you
quite that long. |
| 14:22.28 |
cjdevlin |
but if you
are planning on upgrading/working on release code often, i would
recommend using checkinstall |
| 14:22.33 |
KimK |
Don't feel
like you guys have to stick around. If you've got someplace to go,
go. Thanks for your help. I might let it run and come back later
myself. Should I follow the wiki "build from SVN" (skipping the SVN
part) to finish the install? I saw some stuff about adding symbolic
links and so forth. |
| 14:23.23 |
dloman |
oh I work
here, so I'll be here all day =D |
| 14:23.34 |
KimK |
Ha, OK,
thanks. |
| 14:26.20 |
*** join/#brlcad PrezKennedy
(MK@2607:f0d0:3001:68::2) |
| 14:28.57 |
dloman |
simply put,
after the 'make' is finished, you can 'make install' to install the
compiled binaries to your machine. |
| 14:29.11 |
dloman |
then just run
any of them from the command line. |
| 14:29.24 |
dloman |
its likely
you are looking for the graphical editor: mged |
| 14:31.00 |
KimK |
Ha, you're
ahead of me, but I had already started typing: OK, so (reading from
wiki) when make is done, make test, make benchmark, make install,
bunch of symbolic links, fis the path, benchmark, mged. Does that
sound about right? |
| 14:31.21 |
KimK |
s/fis/fix/ |
| 14:31.27 |
dloman |
could even be
easier than that. |
| 14:31.29 |
dli_ |
KimK, I still
suggest you run the debian/rules script to build, better than
checkinstall |
| 14:32.11 |
dloman |
if you are
installing to a dir that is already on your PATH, (and you have
perms to do so) then it should be as simple as 'make install' then,
once finished, 'mged' |
| 14:33.27 |
KimK |
dli_: OK, how
do I do that? What do you suggest? dloman: Shall I fix the path
first, when make is done? |
| 14:33.49 |
dloman |
what os are
you running anyways? |
| 14:34.01 |
dli_ |
KimK, apt-get
build-dep brlcad |
| 14:34.14 |
dli_ |
KimK, apt-get
-b source brlcad |
| 14:34.26 |
KimK |
Ubuntu 10.04
LTS 32-bit with EMC2 special-patched RTAI real-time kernel.
|
| 14:35.30 |
dloman |
KimK: at the
end of the ./configure run, did you happen to see where it said it
was set to install to? |
| 14:35.39 |
KimK |
dli_: OK, can
I do that while make is running? |
| 14:36.29 |
dli_ |
KimK, oh, I
didn't realize brlcad is not in ubuntu :( |
| 14:36.35 |
KimK |
dloman: No I
didn't think to check, and I'm pretty sure it's scrolled off now.
But I had deleted my ~/brlcad/ dir, so if it's back, it created
it. |
| 14:36.47 |
dloman |
dli_: if KimK
is already configured and compiling, why try getting packages via
apt? |
| 14:37.01 |
dloman |
nm |
| 14:37.30 |
dloman |
KimK: do you
have sudo perms on this machine? |
| 14:38.11 |
dli_ |
dloman, make
install is basically bypassing apt, checkinstall should be avoided,
whenever possible |
| 14:39.00 |
cjdevlin |
dli_:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632 |
| 14:39.21 |
dloman |
what are the
detremental effects of compiling and installing manually? Its
never cause me a problem..... |
| 14:40.08 |
KimK |
dloman: Yes,
my machine. I'm the owner. Hey, I really appreciate the help you
guys. You probably all have a lot of experience with BRL-CAD now,
but think back to when you first started with it. How long did it
take before you could make simple cubes and cones and sort of have
a clue what's going on with it? |
| 14:40.21 |
cjdevlin |
dli_: why do
you recommend avoiding checkinstall (just curious - as i have said,
i'm pretty new)? |
| 14:40.55 |
cjdevlin |
KimK: if you
work through that tutorial you can make a simple radio in the first
1/2 hour |
| 14:41.57 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 14:41.58 |
dli_ |
cjdevlin, if
you have the debian/ script folder in source |
| 14:42.02 |
KimK |
cjdevlin: OK,
I'll find it. I downloaded about any PDF I ran across. |
| 14:43.40 |
cjdevlin |
dli_: i would
think just running checkinstall would be easier for someone new
that is just trying it out over dpkg-buildpackage or
debuild? |
| 14:44.55 |
dli_ |
cjdevlin, we
need a debian/ubuntu repository, so user can do: apt-get build-dep,
and apt-get -b source |
| 14:46.55 |
cjdevlin |
dli_: i don't
disagree with that, but at this point, afaik, that isn't an
option? |
| 14:47.09 |
KimK |
dli_: I did
apt-get --dry-run on those packages. It was as you guys suspected,
they were both "E: Unable to find a source package for
brlcad" |
| 14:47.34 |
dli_ |
cjdevlin, I
have no idea, I thought there must be a repository for brlcad
already:( |
| 14:47.53 |
dli_ |
couldn't
believe it, gentoo seems to be the only one has brlcad in main
tree |
| 14:48.05 |
KimK |
(And I've got
something like 109 repos cranked in!) |
| 14:48.19 |
cjdevlin |
there is not,
the previous link i posted is the 'request for packaging' in debian
(which will then make it into ubuntu) |
| 14:48.57 |
cjdevlin |
if the group
would be so kind as to help me out, i wouldn't mind
building/maintaining a ppa for brl-cad on launchpad |
| 14:49.50 |
CIA-14 |
BRL-CAD:
03davidloman * r43863 10/geomcore/trunk/tests/utility/uuidTest.cxx:
Minor print verbage change. Removed WS. |
| 14:50.29 |
KimK |
Oh, BTW, make
is done. Probably for a few minutes now. (Put your money into more
RAM, every time, lol!) |
| 14:51.28 |
KimK |
cjdevlin:
That would be great, ppa's are always a great
convenience. |
| 15:00.30 |
CIA-14 |
BRL-CAD:
03davidloman * r43864 10/geomcore/trunk/src/utility/Config.cxx: WS
and Formatting. |
| 15:00.40 |
dli_ |
cjdevlin,
KimK just want to double check before 'checkinstall', what is your
prefix during ./configure |
| 15:01.30 |
*** join/#brlcad PrezKennedy
(MK@2607:f0d0:3001:68::2) |
| 15:01.51 |
cjdevlin |
after make,
just do: sudo checkinstall |
| 15:02.06 |
cjdevlin |
for
checkinstall you shouldn't have to do anything
different |
| 15:03.36 |
cjdevlin |
(outside of
making sure checkinstall is there: sudo apt-get install
checkinstall) |
| 15:12.31 |
KimK |
Oh, sorry
guys, I was following the wiki. So far I've done make test and make
benchmark. And I skipped ahead to fix the paths because I haven't
quite figured out what to do with that bunch of symbolic links yet.
Different versions installed at the same time? dli_ OK, how can I
check the prefix? The directory I was building in was
~/source/brlcad-7.18.2 I have no knowledge of checkinstall, but
I'll check up on it. OK, I have checkinstall now. I |
| 15:12.31 |
KimK |
<PROTECTED> |
| 15:15.24 |
dli_ |
KimK, better
to check config.log |
| 15:17.02 |
dli_ |
KimK, if your
prefix is /usr it mean mess up the whole system, better in
/opt/brlcad, or /usr/brlcad |
| 15:18.28 |
KimK |
There's a
bunch of stuff in config.log, I'm not sure what you're asking
for. |
| 15:19.12 |
dloman |
can easily
just run ./config again, and note the install paths at the
end |
| 15:19.44 |
KimK |
Would you
like me to pastebin the config.log file? |
| 15:21.09 |
KimK |
Especially,
how can I tell if this "mess up the whole system" thing has
occurred? |
| 15:21.31 |
dloman |
KimK: did you
do a 'make install' ? |
| 15:25.07 |
CIA-14 |
BRL-CAD:
03davidloman * r43865 10/geomcore/trunk/ (include/Config.h
src/utility/Config.cxx): Added int and short getter to Config.
Simplify via code consolidation |
| 15:25.43 |
dli_ |
KimK, you can
pastebin config.log |
| 15:26.10 |
KimK |
dloman: No, I
haven't. I did the autogen thing, configure, make, make test, make
benchmark, passed on make install, took a pass on the symbolic
links, skipped ahead to fix the paths and wait for more advice,
haven't got to benchmark and mged yet. |
| 15:27.19 |
dloman |
The sym links
are an optional setup for having multiple versions of the brlcad
libraries installed. (its just standard ops for any libraries
installed that require olderversions to remain on the
system) |
| 15:27.36 |
dloman |
so from this
point on, if all you are trying to do is get mged up and
running: |
| 15:28.17 |
dloman |
1) Verify
your installation path by: either runing ./config again or check
the config.log to see where the PREFIX path is set to. |
| 15:28.28 |
dloman |
2)
'mged' |
| 15:28.33 |
dloman |
and you
should be good to go. |
| 15:28.57 |
dli_ |
dloman,
what's the default prefix? /usr/loca/? |
| 15:29.20 |
KimK |
Apparently
that file is too big for pastebin. Do you guys have a place you
like to post that file? |
| 15:29.27 |
dloman |
I believe
so. |
| 15:30.09 |
dloman |
im on RHEL,
but I'll check the default prefix here. |
| 15:30.21 |
KimK |
OK, running
./config again |
| 15:30.36 |
dli_ |
KimK, only
beginning part, like: head -100 config.log|wgetpaste |
| 15:31.05 |
dloman |
looks like
/usr/brlcad/ is default for RHEL.. and likely ubuntu
also. |
| 15:31.53 |
cjdevlin |
it
is |
| 15:32.16 |
dli_ |
ac_default_prefix=/usr/local |
| 15:32.23 |
KimK |
prefix:
/usr/brlcad Does that sound right? |
| 15:32.32 |
dloman |
so as long as
you have perms to install to /usr/brlcad, you should be
gtg. |
| 15:32.37 |
dloman |
sure
does. |
| 15:32.40 |
dli_ |
AC_PREFIX_DEFAULT([/usr/brlcad]) |
| 15:32.50 |
KimK |
There are
some subs below that too |
| 15:33.06 |
dloman |
right.
standard stuff: lib, include, share..... |
| 15:33.38 |
KimK |
Still need
the short pastebin? |
| 15:33.55 |
cjdevlin |
in the
directory where you ran the config and make scripts, if brl-cad is
something you sure you want, you can just do: sudo make
install |
| 15:34.13 |
cjdevlin |
if you aren't
sure (it's something you might want to remove) then you can look
into using checkinstall |
| 15:34.57 |
dli_ |
cjdevlin,
always use checkinstall instead of 'make install', whenever
possible |
| 15:35.12 |
dloman |
even if
someone does a 'make install' and want to uninstall it later....
its as simple as rm -fr /usr/brlcad |
| 15:35.18 |
dloman |
or even 'make
uninstall' |
| 15:35.25 |
KimK |
I want it,
but I might at some point want to upgrade to the next newer
tarball. How would that affect things? |
| 15:36.06 |
dli_ |
KimK, do
checkinstall and let apt to handle it :( |
| 15:36.20 |
cjdevlin |
agrees with dli_ |
| 15:36.43 |
KimK |
Oh, OK. So
just delete the dir ~/source/brlcad-7.18.2 and install new in
~/source/brlcad-7.18.4 (or whatever?) |
| 15:37.18 |
KimK |
OK, so use
the checkinstall? |
| 15:37.34 |
KimK |
Sorry, I'm a
slow typer. Or I type to long. |
| 15:37.44 |
cjdevlin |
KimK: yes,
use checkinstall |
| 15:37.49 |
KimK |
s/to long/too
long/ |
| 15:37.55 |
cjdevlin |
sudo apt-get
install checkinstall |
| 15:38.36 |
cjdevlin |
then in the
directory where you did the config and make do: sudo checkinstall
(and then just go w/ the defaults and a simple package desc. i.e.
'brl-cad') |
| 15:38.38 |
KimK |
I have
checkinstall now. And abandon the make install that I never
did? |
| 15:39.04 |
KimK |
And abandon
the symbolic link business? |
| 15:39.16 |
dloman |
not to argue,
because checkinstall certainly is a good tool, but brlcad has its
own uninstall rule plus it installs to its own directory, so its
non-intrusive. *shrug* |
| 15:39.38 |
dloman |
i use make
install and make uninstall on my ubuntu 10.10 machine all the time.
never had an issue. |
| 15:39.39 |
cjdevlin |
KimK:
checkinstall will essentially do the make install for you, but it
will treat the install as if you had installed it via
synaptic/apt |
| 15:39.58 |
KimK |
I don't mind
running out of a directory. The EMC folks call that
running-in-place. |
| 15:40.03 |
dloman |
KimK: Yes,
the sym link stuff is optional. |
| 15:40.28 |
cjdevlin |
dloman: i
agree with you also, but it's nice to have it come up when you do
dpkg -l (esp when newer people need other help that this may
affect) |
| 15:41.00 |
KimK |
The EMC folks
use run-in-place to have assorted versions of their programs all
installed at once. |
| 15:41.34 |
KimK |
Maybe some
call it compiled-in-place? |
| 15:44.01 |
KimK |
Let me ask
you this. Assuming in the future there might be a release of
brlcad-7.18.4 (as above), then I could have both .2 and .4
installed at once if I leave apt-get out of it? But if I use
checkinstall twice, then apt-get will want to remove the older
version, even though it's in a separate directory, is that
right? |
| 15:45.01 |
cjdevlin |
KimK: both
options allow for multiple installs. at this point it is up to you
to determine which method is easiest for you. |
| 15:45.13 |
KimK |
Sorry, I'm
not really familiar with checkinstall, I'm just trying to get a
handle on all this. |
| 15:45.36 |
cjdevlin |
but either
way it is very possible to have multiple versions of brl-cad
installed concurrently |
| 15:45.57 |
cjdevlin |
and neither
choice is really the *wrong* one. |
| 15:48.54 |
KimK |
Well, I don't
mind whether I type 20 characters or 30 characters on the command
line, but what I do know is that I'm pretty new at BRL-CAD, and I
expect to install it again on other PCs, and there's a written
procedure on the wiki that I can refer to again, however imperfect
it might be. So I think I'd like to refer to the wiki just because
it's written on the wall there, if you guys don't mind. |
| 15:50.01 |
cjdevlin |
it is your
computing machine :-) and people will be here to help either
way. |
| 15:50.56 |
KimK |
And this
should not be taken as any type of criticism of you guys, I
appreciate your help very much and am just trying to stumble my way
through the jungle here. |
| 15:51.03 |
dloman |
download->autogen.sh->configure->make->make
install |
| 15:51.22 |
dloman |
if everything
goes well, it should be that easy |
| 15:51.52 |
dloman |
if some of
the libs that brlcad needs are not present on the machine, then
'./config --enable-all' |
| 15:52.04 |
dloman |
and brlcad
will build everything it needs to run |
| 15:53.37 |
KimK |
OK, easy is
good, lol! And until there's a PPA or a repo or something better,
installing by tarballs in ~/source/brlcad_revision_number/ seems
like an OK thing to do? |
| 15:53.53 |
dloman |
yuppers. |
| 15:54.10 |
dloman |
if you have
any Winderz machines, the binaries are precompiled. == even
easier |
| 15:54.54 |
dli_ |
looks like
Nishchay is working on brlcad in debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632 |
| 15:55.41 |
KimK |
OK. So now to
tidy up the loose ends here, I should just have to say make
install? Then benchmark and mged? |
| 15:56.04 |
dli_ |
KimK,
checkinstall |
| 15:56.18 |
cjdevlin |
KimK: sudo
make install |
| 15:56.24 |
cjdevlin |
that will
install it |
| 15:56.43 |
KimK |
checkinstall?
sudo make install? |
| 15:57.06 |
cjdevlin |
if you are
trying to stick to the wiki, just do: sudo make install |
| 16:03.24 |
KimK |
I finally got
around to the short pastebin, I just grabbed the first several
hundred lines and pasted them. http://pastebin.com/WpBLDK6T |
| 16:10.11 |
KimK |
I looked at
the bugs.debian link above, there was a git repo of BRL-CAD at
Debian, at least in Aug 2010? Nice! It would be nice to think it's
still there. |
| 16:10.35 |
dli_ |
--prefix=/usr |
| 16:18.00 |
KimK |
dli_: What's
that? |
| 16:19.31 |
dli_ |
KimK, redo it
:( |
| 16:20.50 |
dli_ |
./configure
--prefix=/opt/brlcad --with-opengl=/usr/lib --with-tcl=/usr/lib
--disable-strict-build |
| 16:21.04 |
dli_ |
KimK, this is
what I use for archlinux |
| 16:28.44 |
dli_ |
KimK,
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --libdir=/usr/brlcad/lib64
--prefix=/usr/brlcad --enable-strict-build
--datadir=/usr/brlcad/share --mandir=/usr/brlcad/man
--disable-almost-everything --disable-regex-build
--disable-png-build --disable-zlib-build --disable-urt-build
--disable-tcl-b |
| 16:28.44 |
dli_ |
uild
--disable-tk-build --disable-itcl-build --disable-tkimg-build
--disable-jove-build --disable-tnt-install
--disable-iwidgets-install --enable-opennurbs-build
--with-ldflags=-L/usr/lib64/itcl3.4 -L/usr/lib64/itk3.4 --with-x
--with-x11 --disable-debug --disable-optimization
--disable-runtime-debug --disable-verbose --disable-warnings
--disable-progress --disable-documentation --enable-models-install
--enable-parallel --with-ogl --with-jdk=/opt/ |
| 16:28.45 |
dli_ |
sun-jdk-1.6.0.24 |
| 16:29.42 |
dloman |
wow, thats a
heck of a config line... why you need all that? |
| 16:31.54 |
KimK |
OK, it ran
the benchmarks in 9:23 and mged gives me a big black screen and a
smaller white screen. Of course, I have no clue what to do with
either of them, lol! But I think it's working. And I do thank all
you guys for your help, I really appreciate it. I'll keep hanging
around here, but first I've got a lot of intro manuals and
tutorials to look at. Thanks! |
| 16:32.44 |
dli_ |
dloman, not
sure, it's autogenerated from gentoo ebuild |
| 16:49.37 |
KimK |
I have to go
now, but I'll leave this window open in case you guys think of any
advice for me while I'm gone. Thanks again. |
| 16:52.27 |
dli_ |
Benchmark
results indicate an approximate VGR performance metric of
4859 |
| 18:16.42 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.138.203) |
| 18:16.42 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:27.13 |
starseeker |
dloman: as
long as I'm asking dumb questions, is this of any interest to us?
http://s11n.net/ |
| 18:30.37 |
dloman |
maybe, i had
looked at generalized object serialization, but thre are some
limitations associated with it. Not to mention that we really dont
need to send an entire object across the net, usually just specific
pieces fo data. |
| 19:23.31 |
CIA-14 |
BRL-CAD:
03starseeker * r43866
10/geomcore/trunk/src/GS/testclient/gstestclient.c: Nothing useful
yet with testclient - just a note that raw msg types down the
socket isn't going to cut it for any msg type, even simple
cases. |
| 21:26.59 |
CIA-14 |
BRL-CAD:
03starseeker * r43867 10/geomcore/trunk/src/GS/testclient/
(CMakeLists.txt gstestclient.c tpl.c tpl.h): OK, start over with
testclient. First job is to put together a valid GSNet Msg to send.
Have a look at tpl and see if it can be of any help for
this. |
| 21:53.41 |
CIA-14 |
BRL-CAD:
03starseeker * r43868
10/geomcore/trunk/src/GS/testclient/gstestclient.c: get as far as
getting what's expected into a struct. |
| 22:04.06 |
CIA-14 |
BRL-CAD:
03starseeker * r43869 10/geomcore/trunk/tests/CMakeLists.txt: Don't
want the value in the cache - just set it locally so only the tests
directory gets it. |
| 22:46.39 |
starseeker |
O.o http://automagically.de/g3dviewer/ |
| 23:34.55 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 01:04.12 |
*** join/#brlcad Nohla
(~Nohla@64.76.19.227) |
| 04:16.11 |
starseeker |
O.o https://github.com/pyb/zen |
| 04:16.26 |
starseeker |
too bad it's
GPL, but that's still nifty |
| 06:57.52 |
Ralith |
oo,
neat |
| 06:58.08 |
Ralith |
mightn't it
be better to target that X replacement canonical is backing
though? |
| 07:37.49 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 07:42.48 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 09:07.45 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.6.40) |
| 09:07.45 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:03.06 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 11:10.21 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 11:32.13 |
dloman |
Mernin |
| 11:36.54 |
dloman |
brlcad:
gource is a fun little tool =D |
| 11:37.20 |
dloman |
brlcad: did
you do all of the brlcad commit history? If, so, I'd love to see
the visualization! |
| 12:30.18 |
brlcad |
dloman: yeah,
the whole thing -- had to modify the source to get it to behave,
but it works reasonably well |
| 12:31.29 |
brlcad |
the physics
unfortunately goes nuts with the whole tree causing the graph to
get stuck |
| 12:37.22 |
dloman |
so did it
turn out at all? |
| 12:37.54 |
brlcad |
oh yeah, it
works great "most" of the time |
| 12:38.27 |
brlcad |
it might work
if it's allowed to incrementally build up from scratch |
| 12:38.52 |
brlcad |
it'll rebuild
the tree from any point on the timeline, which is how you skip
forward/backward .. and those tend to get stuck |
| 12:39.01 |
brlcad |
trying to
rebuild the massive tree after massive edits |
| 12:39.18 |
dloman |
cool, drop
something on youtube if/when you get a chance :) |
| 12:39.31 |
brlcad |
haven't found
a good way to capture to video yet |
| 12:40.21 |
brlcad |
plus, even
sped up to about 4days per sec, it's still like a half-hour video
:) |
| 12:40.38 |
brlcad |
any faster
and it's just a ton of whizzing about |
| 12:41.00 |
dloman |
tee
hee |
| 12:43.55 |
starseeker |
hah, that is
cool |
| 12:44.12 |
starseeker |
like how it
uses the little figures to indicate who's changing what |
| 12:45.20 |
starseeker |
brlcad: if
you could capture video(s), that'd be a really cool briefing
tool |
| 12:45.32 |
starseeker |
dloman: you
in today? |
| 12:46.08 |
brlcad |
starseeker:
I'm working on getting video .. I have one video screencast tool
working, but it's shareware and watermarks the video |
| 12:46.31 |
brlcad |
the tool
itself will output ppm that would be a hell of a lot of frame
data |
| 12:46.44 |
starseeker |
brlcad: ah.
I think I stumbled on one or two tools that do opengl video
specifically |
| 12:47.18 |
starseeker |
http://taksi.sourceforge.net/ |
| 12:47.31 |
brlcad |
just found
that :) |
| 12:48.24 |
brlcad |
the question
du jour is whether it'll run .... bah, looks like it's windows
only? |
| 12:48.47 |
brlcad |
dloman: so
we're good to go needing a poster ;) |
| 12:49.08 |
brlcad |
one page of
awesome |
| 12:49.10 |
dloman |
starseeker:
not today no, tomorrow. Whats up? |
| 12:49.16 |
starseeker |
yukon might
be an option: https://devel.neopsis.com/projects/yukon/ |
| 12:49.38 |
starseeker |
dloman: I'm
wondering how close we are to having commands in geomclient that
could retrieve and send .g files |
| 12:49.47 |
dloman |
brlcad: I can
work on it *after* march 31 =D |
| 12:49.51 |
dloman |
close. |
| 12:50.03 |
brlcad |
oh, that's
way too late :( |
| 12:50.07 |
dloman |
can't promise
COB today, but def by COB tomrrrow |
| 12:50.39 |
Ralith |
looks like
gource can output a ppm stream itself |
| 12:50.46 |
Ralith |
which could
then be encoded |
| 12:50.47 |
starseeker |
is trying to remember if yukon is how he made the videos of
g3d... |
| 12:51.07 |
brlcad |
Ralith: 08:46
< brlcad> the tool itself will output ppm that would be a
hell of a lot of frame data |
| 12:51.27 |
brlcad |
missing a
'but' in there |
| 12:51.47 |
dloman |
brlcad:
sorry, but RL has kicked me square in the nuts and I have had to
take a lot of time off... so i am behind with the GS. |
| 12:54.21 |
brlcad |
someone else
will have to come up with something then, hopefully |
| 12:54.22 |
Ralith |
that's what I
get for not keeping up. |
| 12:54.24 |
brlcad |
students are
submitting applications by the 28th, so that's just way too
late |
| 12:54.31 |
Ralith |
still, too
much data? |
| 12:55.24 |
starseeker |
brlcad: ah -
https://devel.neopsis.com/projects/yukon/wiki/RewriteBranch |
| 12:55.36 |
brlcad |
looks |
| 12:56.51 |
brlcad |
starseeker:
looks like that only works with x11 glx contexts? |
| 12:57.36 |
starseeker |
possibly |
| 12:57.56 |
brlcad |
I'd hate to
go through all the steps again, but I might be able to crunch the
frames out on a remote linux box with tons of disk, and convert to
video there |
| 12:58.53 |
brlcad |
it was just a
bit of a time sink to compile with all its deps, paying some lil
shareware dev becomes appealing :) |
| 12:58.55 |
starseeker |
nods - surprisingly, there just aren't a whole lot of good
solutions (that I know of, anyway) |
| 13:01.25 |
starseeker |
dloman: do
you think you could spare a little time from the java side to get
the .g files moving back and forth? |
| 13:04.25 |
dloman |
that's what
Im doing ;) |
| 13:04.36 |
starseeker |
dloman: cool,
thanks :-) |
| 13:05.06 |
starseeker |
got his butt kicked by a bunch of topics he knows
disturbingly little about last week - sorry for not being of more
concrete assistance |
| 13:05.21 |
dloman |
no
worries |
| 13:05.33 |
dloman |
i havent
exactly been productive recently |
| 13:06.04 |
starseeker |
dloman:
that's not up to you - hope everything is going a little
bette |
| 13:06.07 |
starseeker |
better
even |
| 13:07.54 |
dloman |
heh, its when
things start going better that i get scared. Murphey and his laws
are having a field day ;) |
| 13:09.07 |
dli |
starseeker,
like undo/redo? |
| 13:09.25 |
starseeker |
dli: how's
that? |
| 13:09.53 |
dli |
starseeker,
when you mentioned 'moving back and forth' |
| 13:10.31 |
starseeker |
dli: the most
basic function of any client/server system is to communicate
between client and server |
| 13:10.53 |
dloman |
brlcad: is
there a quick way to print a bu_vlb to console or string as HEX
? |
| 13:11.01 |
starseeker |
dli: we have
that (thanks to dloman) but we need to be able to send geometry
back and forth |
| 13:11.29 |
starseeker |
dli: once we
can communicate geometry files, we can think about how to store
revisions of them |
| 13:12.15 |
starseeker |
dli: the next
stage beyond that is to communicate just specific changes to parts
of the .g files, and be able to retrieve specific versions of
geometry from the server |
| 13:12.27 |
starseeker |
dli: the
latter means revision control and is not easy |
| 13:13.31 |
starseeker |
dloman: yeah,
if I ever run into Murphy I'm gonna have a word with
him... |
| 13:13.51 |
dli |
starseeker,
not easy with .g format :( maybe, easier as database
entries |
| 13:14.31 |
starseeker |
dli:
basically what's needed is to customize version control software
for our specific purposes |
| 13:16.41 |
starseeker |
gathers up his stuff and heads in - first stop
gym... |
| 13:25.09 |
``Erik |
unsigned char
*p = bu_vlb_addr(myvlb); for(i=0;i<bu_vlb_buflen(myvlb);i++){
printf("%02x ",*p); p++; } |
| 13:28.07 |
dloman |
``Erik:
thanks |
| 13:30.37 |
``Erik |
(there're
tricks to make that shorter, but starseeker starts sobbing when I
do those) |
| 13:36.08 |
CIA-52 |
BRL-CAD:
03brlcad * r43890 10/brlcad/trunk/src/libbu/bitv.c: don't try to
cat the str/title if it is null |
| 13:38.37 |
CIA-52 |
BRL-CAD:
03brlcad * r43891 10/brlcad/trunk/ (include/bu.h
src/libbu/vlb.c): |
| 13:38.37 |
CIA-52 |
BRL-CAD: add
a new bu_pr_vlb() routine for printing out diagnostic information
for vlb |
| 13:38.37 |
CIA-52 |
BRL-CAD:
structures. optionally prefixed with a title, this prints out each
byte as a |
| 13:38.37 |
CIA-52 |
BRL-CAD:
space-separated hex value. could probably use some pretty printing
to group |
| 13:38.38 |
CIA-52 |
BRL-CAD:
together for readability, but go simple for starters. |
| 13:38.55 |
brlcad |
dloman:
turned erik's one-liner into a new bu routine, bu_pr_vlb(), see if
that's suitable |
| 13:40.43 |
dloman |
kk will
try |
| 13:40.44 |
brlcad |
dli: unless I
missed part of the conversation, it's not specific to .g
data |
| 13:41.34 |
brlcad |
the service
allows transactional edits with history preserved, so it's just a
matter of how to encode the transactions as commits |
| 13:42.55 |
brlcad |
the simple
way is to commit the honking .g file after each change, but that's
not really efficient since it's an opaque entity to revision
control systems - it's not easy to extract the semantic differences
between two changes |
| 13:47.42 |
dli |
brlcad, does
it make sense to use a database backend, so, database queries can
be logged (reverted), efficiency problem left to the database
side |
| 13:48.26 |
brlcad |
that's
basically what's being done with the revision control system -- it
uses a database backend |
| 13:49.23 |
dli |
brlcad, oh,
didn't realize that :( |
| 13:49.37 |
brlcad |
we could
implement revision tracking on top of some existing rdbms, but then
that would basically amount to reimplementing a version control
system (like git, svn, whatever) |
| 13:50.09 |
brlcad |
and even
then, you'd still have the problem of storing/retrieving *semantic*
information from the commit |
| 14:00.13 |
CIA-52 |
BRL-CAD:
03davidloman * r43892
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/
(GSConnection.java msg/AbstractNetMsg.java): Move message
serialization entirely over to AbstractNetMsg. Consolidates
serialization logic. |
| 14:16.44 |
*** join/#brlcad Nohla
(~Nohla@64.76.19.227) |
| 14:26.42 |
CIA-52 |
BRL-CAD:
03davidloman * r43893
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java:
Forgot to serialize type. Ooops. |
| 14:27.22 |
CIA-52 |
BRL-CAD:
03davidloman * r43894
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java:
Remove debug printing. Kills performance when trying to print large
bytebuffers. |
| 14:27.54 |
brlcad |
could maybe
add a size parameter |
| 14:28.30 |
dloman |
it was a
t-shooting debug print statement anyways :) |
| 14:28.48 |
dloman |
turns out,
printing a 1 meg byte array to console is slow. who
knew?! |
| 14:32.23 |
brlcad |
probably
someone ;) |
| 14:32.33 |
dloman |
most likely
everyone :) |
| 14:54.58 |
``Erik |
a lot faster
if you dump it in a screen and swap, or pipe through less O.o the
effort to display a linux kernel build in an xterm was a
significant slowdown on my old 120mhz cyrix, went way faster when I
put it in a screen and dropped it :) |
| 14:56.41 |
dloman |
now that's a
new one. localhost just resolved to 127.0.1.1 |
| 14:57.07 |
``Erik |
neat |
| 16:02.17 |
dloman |
oh bloody
hell. the silly null character at the end of the string has the
UUID parsing all bent out of shape :/ |
| 16:06.35 |
CIA-52 |
BRL-CAD:
03davidloman * r43895
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferReader.java:
Validate parsed string is == 36 characters long to allow for proper
UUID generation. The UUID 'standard' for the GSNet Proto needs to
be standardized. |
| 16:09.50 |
CIA-52 |
BRL-CAD:
03davidloman * r43896
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java:
Fill out the NetMsgFactory's switching table so that NetMsg's can
actually be deserialized |
| 17:13.07 |
CIA-52 |
BRL-CAD:
03starseeker * r43897 10/brlcad/trunk/BUGS: Need to do some testing
and confirm this, but have a report that keep is changing units to
unknown on output files and dbconcating a file with unknown units
wipes out the units in the parent .g |
| 17:34.55 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.135.62) |
| 17:34.56 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:02.45 |
*** join/#brlcad chinu
(~chinu@27.97.161.172) |
| 19:11.32 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.134.3) |
| 19:26.47 |
*** join/#brlcad chinu
(~chinu@27.97.124.40) |
| 19:28.15 |
*** join/#brlcad sofichinu
(~sofichinu@27.97.124.40) |
| 19:46.10 |
sofichinu |
hii all, can
anyone help me out for gsoc 2011 project idea - Qt Display
Manager |
| 19:47.13 |
starseeker |
sofichinu:
you've seen the posting on the website? |
| 19:48.27 |
starseeker |
http://brlcad.org/wiki/Qt_Display_Manager |
| 19:51.12 |
sofichinu |
yes i have
gone through that link, and it says to review current display
manager code. From where do i get to access that code? |
| 19:51.36 |
starseeker |
BRL-CAD's
subversion repository: http://sf.net/projects/brlcad |
| 19:51.48 |
starseeker |
specifically,
the trunk branch: |
| 19:52.01 |
starseeker |
svn co
https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 19:52.42 |
starseeker |
also a good
idea to get BRL-CAD (specifically MGED) compiled and running to see
what a display manager does |
| 19:52.46 |
sofichinu |
thnx
:) |
| 19:52.58 |
starseeker |
no
problem |
| 19:56.01 |
sofichinu |
do one has to
use any ide for compiling the code, because I usually use g++
compiler in ubuntu for coding in c++ |
| 19:56.23 |
starseeker |
nope - most
of use go with command line gcc |
| 19:57.10 |
sofichinu |
ok |
| 19:57.48 |
starseeker |
sofichinu:
you have Qt experience? |
| 19:59.11 |
sofichinu |
nopes, I
started using it only after getting to know about it via
gsoc |
| 19:59.33 |
starseeker |
nods. Just curious - what appealed to you about that
project? |
| 20:01.08 |
sofichinu |
to be honest
, requirement skills for the project is C++ and I am good at this
only :P |
| 20:01.46 |
sofichinu |
this all made
me interested in this |
| 20:02.00 |
starseeker |
fyi, OGRE is
also C++ |
| 20:03.17 |
sofichinu |
yes, many
other organizations are, and I am trying to go deep into project
ideas to find out which one is best for me. |
| 20:03.35 |
starseeker |
I was
thinking more about the other display manager task - the OGRE
display manager :-P |
| 20:04.10 |
sofichinu |
oh i am
sorry, |
| 20:04.19 |
sofichinu |
I had started
using Qt |
| 20:04.29 |
starseeker |
the openNURBS
library is also C++, if you're into mathematical stuff |
| 20:04.33 |
starseeker |
sofichinu: Qt
is fine too |
| 20:04.34 |
sofichinu |
before and
heard about OGRE now only |
| 20:04.48 |
starseeker |
we're
interested in both - if you're more comfortable with Qt that's
great |
| 20:05.28 |
starseeker |
openNURBS
would pertain to the NURBS tasks on that list |
| 20:06.24 |
sofichinu |
which one
gives more chance for getting into gsoc ? |
| 20:06.38 |
starseeker |
depends on
your proposal and the other proposals |
| 20:07.02 |
starseeker |
Qt vs. OGRE
won't be a make-or-break |
| 20:07.09 |
sofichinu |
hm... |
| 20:08.30 |
sofichinu |
do i need to
make out some patch like usually many organizations demand
that? |
| 20:08.31 |
starseeker |
sofichinu:
I'd suggest taking a quick look at both and see which one looks
more managable to you |
| 20:09.18 |
starseeker |
see step 9:
http://brlcad.org/wiki/Google_Summer_of_Code/Checklist |
| 20:10.21 |
starseeker |
sofichinu:
what's your background/interest? |
| 20:11.07 |
sofichinu |
I am a
student of 2nd year in Computer Science and Engineering |
| 20:13.20 |
starseeker |
well, my
advice would be to take a very quick look at Qt and OGRE - get a
basic window up and draw a line, say, in both - just to get a feel
which one you would prefer working with |
| 20:14.55 |
sofichinu |
ok |
| 20:15.39 |
starseeker |
OGRE is an
accelerated 3D context, and Qt is unaccelerated but runs (or should
run) pretty much anywhere without requiring any fancy
hardware |
| 20:16.09 |
starseeker |
sort of the
difference between our dm-ogl and dm-X |
| 20:16.44 |
starseeker |
(which is why
OpenGL embedded in Qt is ruled out - the point of a Qt display
manager would be "it always works") |
| 20:17.03 |
sofichinu |
sorry but i
did not get the difference still. |
| 20:17.55 |
starseeker |
OpenGL
provides an accelerated graphics context - when you see objects
rotating around in real time in 3D, it's usually OpenGL based
(unless you're on Windows, which tends to use DirectX more these
days) |
| 20:18.15 |
starseeker |
typically,
the graphics card in the computer is assisting with the drawing
when OpenGL is used |
| 20:18.42 |
starseeker |
Raw X11
(dm-X) does NOT use any specialized acceleration hardware - it uses
only the X calls themselves |
| 20:19.41 |
starseeker |
which means
the CPU has to do a lot of work instead of offloading it to the
graphics card, but ALSO means if the graphics card (or drivers)
aren't working you can still bring up the display |
| 20:20.29 |
sofichinu |
so can we say
that Qt is better |
| 20:21.12 |
starseeker |
Qt will work
under more conditions |
| 20:21.40 |
starseeker |
but it also
won't be able to do things like shaded display and take advantage
of graphics hardware when displaying really large
models |
| 20:21.52 |
starseeker |
it's a
tradeoff - that's why we're interested in both |
| 20:22.13 |
starseeker |
Ideally, you
do accelerated when it's available and fall back to unaccelerated
when it's not |
| 20:23.10 |
sofichinu |
hmm.... |
| 20:23.43 |
starseeker |
so Qt would
be using the 2D graphics stack: http://cworth.org/talks/lca_2009/html/lca-2009-006.html |
| 20:23.57 |
starseeker |
and OGRE
would be using the 3D http://cworth.org/talks/lca_2009/html/lca-2009-007.html |
| 20:24.23 |
starseeker |
(OK so those
are Linux specific, but the general idea is the same) |
| 20:25.40 |
sofichinu |
and what
about in windows terms |
| 20:27.12 |
starseeker |
The Windows
stacks look similar, just with different components at the various
stages |
| 20:27.14 |
starseeker |
(e.g. DirectX
instead of OpenGL) |
| 20:27.24 |
starseeker |
OGRE and Qt
should abstract all that for us |
| 20:27.38 |
sofichinu |
ok |
| 20:28.29 |
sofichinu |
cant we
implement the similar thing for OpenGL too? |
| 20:28.35 |
starseeker |
sofichinu:
I'd try playing with QtCanvas and see how it behaves - for example,
can you get it to draw and update 2D lines quickly? |
| 20:29.01 |
starseeker |
sofichinu: we
can (in fact, we do - that's dm-ogl and dm-wgl) but OpenGL itself
is not a fully cross platform API |
| 20:29.36 |
starseeker |
that's why we
have one for wgl (Windows), one for GLX (Linux), and we would need
one for Mac if we wanted to get the native Aqua interface
running |
| 20:30.33 |
sofichinu |
oh, I am
actually downloading Qt, for sum reasons, I lost it |
| 20:31.14 |
starseeker |
Ideally, we
would replace all of the platform specific display managers with
one accelerated (OGRE) and one unaccelerated (Qt) display manager -
between those two, we should get broad coverage of machine
configurations and operating systems for minimal code |
| 20:32.34 |
starseeker |
My guess
would be that the main challenge with Qt will be figuring out how
to do "fast enough" 2D drawing without relying on
OpenGL |
| 20:33.22 |
dli |
or ogre
simply figure out how to run without no 3d support
underneath |
| 20:33.54 |
starseeker |
dli: that's a
bit like saying you're going to figure out how to drive without a
car :-P |
| 20:34.22 |
dli |
starseeker,
yes, because a bike is always available |
| 20:34.54 |
starseeker |
the main
point and benefit of OGRE is that it does take advantage of 3D
acceleration |
| 20:35.57 |
starseeker |
if someone
wants to propose an alternative toolkit for either the
unaccelerated or the accelerated display manager that's fine, but
they'll need to make a very good case for it |
| 20:37.40 |
starseeker |
issues to
consider there are license compatibility, portability, how well
maintained and widely used the toolkit is, etc. |
| 20:38.34 |
starseeker |
we don't want
to take over maintainance for a cross platform graphical toolkit -
we want to use one that is already in good shape |
| 20:39.02 |
starseeker |
OGRE and Qt
have a lot of momentum behind them and are licensed in a way we can
use them |
| 20:39.51 |
sofichinu |
Its just like
making a best deal from both of them. |
| 20:46.57 |
starseeker |
sofichinu:
this may be of interest:
http://labs.qt.nokia.com/2009/12/16/qt-graphics-and-performance-an-overview/ |
| 20:52.30 |
*** join/#brlcad niels_horn
(~niels@187.14.62.166) |
| 22:32.38 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 22:32.38 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 ETA 20110321 || BRL-CAD is participating
in the 2011 Google Summer of Code! Students: speak up, ask
quesions! :) |
| 23:23.12 |
brlcad |
thinks we're good with a simple socket connection for the
forseeable next couple years |
| 23:23.54 |
brlcad |
local port
performance is going to be the main customer at first, not even
over tcp, for the beginning (e.g., mged use) |
| 23:24.57 |
brlcad |
getting
beyond that and I'd want to start considering more advanced network
services like automatic replication and persistance .... but only
long after the protocol is established for simple net |
| 00:24.54 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2609
10/wiki/Google_Summer_of_Code: /* [[Google_Summer_of_Code/2009|GSoC
2011]] */ |
| 00:25.09 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2610
10/wiki/Google_Summer_of_Code: accepted |
| 00:29.33 |
brlcad |
in theory,
you should be able to get an accelerated and non-accelerated
context from both Qt and OGRE -- it's really just what toolkit does
someone want to use and which one will integrate best (be easiest
to maintain) |
| 00:30.21 |
*** join/#brlcad Ralith
(~ralith@d142-058-172-039.wireless.sfu.ca) |
| 00:30.42 |
brlcad |
e.g., qt with
an ogl context could be accelerated or it could be a pure raster
context; ogre might be harder to get unaccelerated, but there's
always software render ogl :) |
| 00:32.41 |
starseeker |
ah, ok - I
had assumed we would want to go with something like OGRE for
accelerated in order to support more advanced work to
come |
| 00:37.59 |
CIA-52 |
BRL-CAD:
03starseeker * r43898 10/geomcore/branches/fossil/: Add a branch
for some experiments |
| 00:38.43 |
brlcad |
ogl for the
dm definitely makes the most sense |
| 00:38.55 |
brlcad |
something
that has scenegraph management |
| 00:38.58 |
starseeker |
plain
opengl? |
| 00:39.18 |
brlcad |
plain ogl
with custom scenegraph management is a bitch |
| 00:39.33 |
brlcad |
that's where
ogre becomes a big win over qt for the dm side |
| 00:39.41 |
brlcad |
for the fb
side, either would be a win |
| 00:39.48 |
brlcad |
fossil
scm? |
| 00:39.48 |
starseeker |
oh, you mean
OGRE for the dm? |
| 00:39.54 |
starseeker |
yes |
| 00:39.59 |
brlcad |
heh,
neat |
| 00:40.06 |
starseeker |
BSD licensed
as of mid last year |
| 00:40.16 |
brlcad |
nods |
| 00:40.22 |
starseeker |
I didn't
notice at the time - would have hopped on it quicker |
| 00:40.35 |
brlcad |
you know it's
almost entirely built on sqlite? |
| 00:40.37 |
starseeker |
yep |
| 00:41.30 |
starseeker |
wasn't so worried about its backend storage mechanism as long
as it doesn't cause us some kind of significant
trouble |
| 00:42.06 |
starseeker |
more annoying
is his fondness for global variables |
| 00:42.12 |
starseeker |
that's what I
was grousing about earlier |
| 00:47.40 |
CIA-52 |
BRL-CAD:
03starseeker * r43899 10/geomcore/branches/fossil/ (17 files in 6
dirs): For now, clear other contents - keep the build logic simple
during early phases. |
| 00:53.22 |
CIA-52 |
BRL-CAD:
03starseeker * r43900 10/geomcore/branches/fossil/ (48 files in 8
dirs): |
| 00:53.22 |
CIA-52 |
BRL-CAD: Add
what work has been done so far - the first goal is to get db.c
and |
| 00:53.22 |
CIA-52 |
BRL-CAD:
everything it needs compiling without warnings about implicit
definitions. No |
| 00:53.22 |
CIA-52 |
BRL-CAD:
global 'g' structure with settings either - pass it properly, even
if it does |
| 00:53.22 |
CIA-52 |
BRL-CAD: mean
updating all the functions to do it. |
| 01:08.11 |
CIA-52 |
BRL-CAD:
03starseeker * r43901 10/geomcore/branches/fossil/ (CMakeLists.txt
src/CMakeLists.txt): comment out dirs not active yet |
| 01:15.41 |
CIA-52 |
BRL-CAD:
03starseeker * r43902 10/geomcore/branches/fossil/ (3 files in 2
dirs): add a content.h header to manifest and diff, fix
accordingly. |
| 01:56.57 |
brlcad |
ah,
yeah |
| 01:57.20 |
brlcad |
it's endemic
of fast but lazy coding |
| 01:57.54 |
brlcad |
great for
getting things done, but crazy maintainability for new
developers |
| 01:58.32 |
starseeker |
my favorite
bit is he generates the headers based on what the .c files
need |
| 01:59.40 |
starseeker |
brlcad: is
sqlite a concern? |
| 02:00.02 |
brlcad |
nope |
| 02:00.25 |
starseeker |
breaths a sigh of relief |
| 02:00.31 |
brlcad |
implementation detail that might affect
scalability, but not a problem until it's a problem |
| 02:01.16 |
brlcad |
have trouble
seeing it scale to multiGB databases, but maybe |
| 02:01.33 |
starseeker |
yeah, huge
meshes could be a problem |
| 02:01.50 |
brlcad |
single models
could be a problem |
| 02:02.06 |
brlcad |
not to even
consider hundreds or thousands |
| 02:02.45 |
starseeker |
well, ``Erik
has some wicked test cases we can toss in |
| 02:03.06 |
starseeker |
brlcad: I was
kind of thinking one sqlite file per .g namespace... |
| 02:04.23 |
starseeker |
under the
hood, of course |
| 02:04.31 |
brlcad |
single db by
itself is probably fine, thinking db with full revision history,
hundreds of edits like you'd have if you start from scratch -
that's where it'd get big |
| 02:04.39 |
brlcad |
yeah,
possibly |
| 02:04.48 |
brlcad |
that'd
definitely be better than one honking db |
| 02:05.14 |
brlcad |
but then
merging/branching and linking across namespaces becomes really
nasty, no? |
| 02:05.23 |
starseeker |
ah, yeah -
was thinking a few rotates and translates at the toplevel plus lots
of xpushing for edit testing |
| 02:05.26 |
brlcad |
with svn it
was just across files using path convention |
| 02:05.36 |
brlcad |
all still
within the revision system |
| 02:06.09 |
brlcad |
either way,
interesting test |
| 02:06.09 |
starseeker |
brlcad: not
sure how nasty it would be - I've been thinking about it, but
nothing concrete to toss on the whiteboard yet |
| 02:06.48 |
brlcad |
get stuck
with svn libs? |
| 02:07.04 |
brlcad |
or looking
for better performance? |
| 02:07.14 |
brlcad |
or just
having fun? :) |
| 02:07.37 |
starseeker |
heh -
combination of the latter two |
| 02:08.42 |
starseeker |
I was hoping
a "speak .g language" approach to the revision control would let us
avoid the region breakout and still have reasonable performance,
but looking at that level of subversion/apr just got downright
scary |
| 02:09.22 |
starseeker |
fossil
appealed because it's smaller, distributed and for a bonus has that
web server stuff integrated |
| 02:09.50 |
starseeker |
thought it
might be more practical to get it commiting individual geometry
objects as binary blobs and checking out into .g files |
| 02:10.45 |
starseeker |
however
screwed up its "yay global variables" approach is, once
straightened out it should build portably and without fun like the
apr libs |
| 02:12.49 |
brlcad |
be sure to
consider the big picture management advantages/disadvantages too
then, user management isn't nearly as well integrated, generic
properties, proven stability across massive dbs, repository
mirroring, efficient binary management, .. ;) |
| 02:14.06 |
starseeker |
actually it
does seem to have some user management abilities, although I
haven't looked hard at that |
| 02:14.30 |
starseeker |
I'm assuming
it's got to be fairly good at mirroring, being a
dvcs... |
| 02:14.31 |
brlcad |
if
performance were the only consideration, that new libgit toy would
be a viable candidate |
| 02:14.38 |
brlcad |
it has user
management |
| 02:14.41 |
starseeker |
<snort>
I took a look at that |
| 02:14.45 |
brlcad |
it's not just
nearly as well integrated |
| 02:14.46 |
starseeker |
doesn't have
the feature set yet |
| 02:14.56 |
brlcad |
svn's is
pretty extensive |
| 02:15.19 |
brlcad |
there's a
whole lib dedicated to it that can be coupled to the various remote
connection mechanisms |
| 02:15.55 |
starseeker |
brlcad: is
user management a big deal at the revision control level? I
thought user management stuff was gonna live higher up the food
chain, but maybe I was wrong |
| 02:16.13 |
brlcad |
initial stab
was a complete punt, just let svn do what it does |
| 02:16.32 |
brlcad |
anything we
do higher up is just going to suck |
| 02:16.38 |
starseeker |
ah |
| 02:16.52 |
brlcad |
that's
trickty to get right, even stupid username+password
management |
| 02:17.14 |
starseeker |
fossil does
have at least some capability for username+password |
| 02:17.20 |
brlcad |
it has to
:) |
| 02:17.39 |
brlcad |
it's an
unintegrated home-grown solution iirc |
| 02:18.12 |
starseeker |
yeah, it's
self-containment is one of its selling points |
| 02:18.23 |
brlcad |
yep |
| 02:18.30 |
brlcad |
it's a plus
and a negative tradeoff |
| 02:18.42 |
brlcad |
super
limited, but super simple |
| 02:19.42 |
brlcad |
to me spells
"super inadequate" for long-term without hacking a completely
separate user management layer on top, but that's not a concern for
a while |
| 02:20.00 |
brlcad |
it's worth
testing regardless |
| 02:20.33 |
brlcad |
anything we
implement shouldn't be so tightly integrated that we cannot switch
out to a different versioning engine without a couple weeks
effort |
| 02:21.48 |
starseeker |
my plan was
to get it refactored/reworked to the point where I could directly
pass it librt's db byte arrays as objects, and check them out into
a .g file instead of files |
| 02:22.05 |
starseeker |
then see what
performance was like |
| 02:32.48 |
CIA-52 |
BRL-CAD:
03starseeker * r43903 10/geomcore/branches/fossil/src/libgeomvcs/
(CMakeLists.txt checkin.c): Still problems with this file, but
can't continue tonight - check in what I've got. |
| 02:33.50 |
brlcad |
starseeker:
the scrolledwidget ttk fix .. is that from upstream? |
| 02:34.07 |
brlcad |
worth pushing
to upstream? |
| 03:50.22 |
starseeker |
brlcad: if
you can call it a "fix" - just going for uniform ttk usage when
possible |
| 05:28.52 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 06:53.06 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 06:53.06 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:21.59 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 08:14.11 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 08:14.11 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:38.49 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 10:22.03 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 10:37.15 |
dloman |
Mernin
all. |
| 10:50.16 |
brlcad |
so
approximately 92 seconds of that 30min animation took up about 5GB
of disk in image frames... think I'm going to need a bigger
disk |
| 10:51.16 |
brlcad |
or I'm going
to need to make a smaller animation (was aiming for
720p) |
| 10:52.23 |
dloman |
yikes. |
| 10:52.31 |
dloman |
that's
totally raw image data i take it? |
| 10:53.12 |
brlcad |
basically,
it's a ppm stream |
| 10:53.20 |
dloman |
at 5GB per 92
seconds, you're looking at about 100GB for the 30 min
stretch. |
| 10:53.42 |
dloman |
I've got a
2TB external you can borrow if ya need :) |
| 10:54.18 |
brlcad |
yeah, which
by itself isn't too shabby, except it's not exactly something I can
upload to vimeo :) |
| 10:54.40 |
brlcad |
i'll figure
something out |
| 10:56.22 |
dloman |
I have Adobe
Premere elements and I *think* it can encode a ppm stream to
something like mp4, avi, wmv, etc. |
| 10:56.26 |
dloman |
if ya
need. |
| 10:57.33 |
brlcad |
that part I'm
actually not worried about at all, plenty of ways to encode from
the stream |
| 10:57.51 |
brlcad |
more the
processing size and size of end result video |
| 10:58.33 |
dloman |
well, its not
ideal, but you can always hack it into parts if its too big for
upload. |
| 10:58.40 |
brlcad |
this should
work.. just need to make some room :) |
| 10:59.14 |
dloman |
hehehe. |
| 10:59.45 |
dloman |
on that note:
I am seriously considering picking up a pair of 2TB internals...
time for some upgrading of the data server! |
| 11:00.28 |
dloman |
<Tangent> brlcad: Have you neard of
a group called Improv Everywhere? |
| 11:06.49 |
*** join/#brlcad sofichinu
(~sofichinu@115.69.147.65) |
| 11:15.10 |
dloman |
http://www.youtube.com/watch?v=lYJ9zOyzI4w&feature=player_embedded |
| 11:15.18 |
dloman |
That's the
kinda stuff IE does :) |
| 11:15.25 |
dloman |
basically,
hilarious stuff :) |
| 12:04.09 |
CIA-52 |
BRL-CAD:
03Tbrowder 07http://brlcad.org *
r2611 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 12:15.06 |
CIA-52 |
BRL-CAD:
03Rossberg 07http://brlcad.org *
r2612 10/wiki/Google_Summer_of_Code: probable a copy-and-paste
error |
| 12:21.21 |
CIA-52 |
BRL-CAD:
03davidloman * r43904 10/geomcore/trunk/ (include/Config.h
src/utility/Config.cxx): Added some zero length string checks for
the UInt and UShort helper functions in Config class to keep from
attempting to parse an empty string. Added a hasConfigValue() for
performing simple mapping checks. |
| 12:27.14 |
CIA-52 |
BRL-CAD:
03davidloman * r43905 10/geomcore/trunk/src/utility/Config.cxx:
Made getConfigValue() perform a check to see if the internal config
map actually has the key prior to attempting to return the
value. |
| 12:29.08 |
CIA-52 |
BRL-CAD:
03davidloman * r43906 10/geomcore/trunk/src/GS/geomserv.cxx:
Simplify startup of geomserv by making Config do all the data
conversions for the 'port' parameter. |
| 12:29.15 |
starseeker |
brlcad: I'll
try and sync to stable today |
| 12:41.10 |
CIA-52 |
BRL-CAD:
03davidloman * r43907 10/geomcore/trunk/ (3 files in 3 dirs):
Reordered GemetryService args to be more intuitive. Removed
GeometryService's need to store a localnodename as it was redundant
(it was being stored as the thread name anyways) |
| 12:43.54 |
CIA-52 |
BRL-CAD:
03davidloman * r43908 10/geomcore/trunk/src/GS/geomserv.cxx:
Geomserv now correctly parses config file for listenAddy and
listenPort. If not present, use defaults. |
| 13:12.40 |
starseeker |
here's a
quick stab at a poster - I don't expect it'll pass muster but maybe
it'll prod somebody: |
| 13:12.44 |
starseeker |
http://bzflag.bz/~starseeker/poster_2011_1st_draft.png |
| 13:13.16 |
dloman |
Im instantly
grooving on the TRON font =D |
| 13:13.41 |
``Erik |
yeah, int he
lower right, that's cool |
| 13:14.04 |
``Erik |
but the drop
shadows? ortho view of a ginormous screenshot? (not saying I could
do better, just being the peanut gallery) |
| 13:14.16 |
starseeker |
that's the
GSoC logo - I'm not sure how to do that font |
| 13:14.32 |
starseeker |
``Erik:
that's why it's to prod, not proposed as a final |
| 13:15.10 |
``Erik |
hm, matt
wanted to do german today, you should call him up and go, bring up
the poster, he or nikki might be interested in chattering about it,
if not helping :) |
| 13:15.23 |
starseeker |
``Erik:
heh |
| 13:15.34 |
starseeker |
unfortunately, I doubt I'll be up there in
time |
| 13:15.39 |
``Erik |
we're
programmers, not artists :D |
| 13:15.41 |
``Erik |
ah,
bummer |
| 13:15.44 |
starseeker |
amen |
| 13:15.59 |
``Erik |
(or, rather,
our art is code and math, not visual) |
| 13:16.06 |
starseeker |
the drop
shadow effect was a stand in until someone figures out how to do
that google font thing |
| 13:16.36 |
``Erik |
looks like
the tron font done in gimp with the glow and outline script-fu
smacked on it? |
| 13:16.48 |
starseeker |
shrugs - maybe |
| 13:16.56 |
``Erik |
script-fu is
neat, it used to all be scheme, d'no if they've "fixed"
that |
| 13:16.59 |
starseeker |
doesn't have strong script-fu |
| 13:17.21 |
starseeker |
``Erik: if
you want to hack around with it I can send you the xcf |
| 13:17.38 |
``Erik |
nah, getting
ready to shower and head down to union memorial |
| 13:17.52 |
starseeker |
a good visual
for this might be a nice full-screen isst view of something
cool |
| 13:18.55 |
``Erik |
hm, what
about a handful of keen images (archer, isst, stryker/rise, a few
rt's) canted at like ~20 degrees in the z (so they're all
parallelograms in outline) |
| 13:19.18 |
starseeker |
cool - can
you do that? |
| 13:19.21 |
``Erik |
semi-randomly
placed |
| 13:19.23 |
``Erik |
um, no?
:D |
| 13:19.30 |
``Erik |
just throwing
ideas, dude |
| 13:19.32 |
dloman |
starseeker:
you in today? |
| 13:19.37 |
starseeker |
later today,
yes |
| 13:19.39 |
dloman |
kk |
| 13:19.40 |
starseeker |
dloman:
what's up? |
| 13:20.09 |
dloman |
well brlcad
is here already, so i figure the three of us + Photoshop CS5 can
get hte job done relatively quickly. |
| 13:20.24 |
starseeker |
dloman: you
don't need me for that |
| 13:20.31 |
starseeker |
you and
brlcad can handle it fine |
| 13:20.36 |
dloman |
collective
input |
| 13:20.47 |
dloman |
is stupid busy. |
| 13:21.04 |
starseeker |
nods - I won't speed up the process much, trust
me |
| 13:21.36 |
``Erik |
photo shop?
that's the windows imitation of gimp, rgiht? :> |
| 13:21.56 |
dloman |
lol |
| 13:22.04 |
dloman |
i use both
pretty extensively |
| 13:22.21 |
dloman |
and, this is
the one area where the Commercial package spanks the FOSS
version. |
| 13:22.46 |
starseeker |
``Erik: I
know - we could use a snapshot from brlcad's gource visualization
:-P should be guaranteed to scare off the weak |
| 13:25.21 |
``Erik |
hm, don't
hvae gimp on my laptop, compiling it and it's chain would take too
long, and sketchup looks wrong for what I want to say,
damn |
| 13:25.36 |
starseeker |
inkscape? |
| 13:25.52 |
starseeker |
or xfig?
:-P |
| 13:26.13 |
dloman |
``Erik: you
run a gui of any sorts? |
| 13:26.35 |
``Erik |
dlo:
mac. |
| 13:26.50 |
dloman |
..theres no
precompiled GIMP binaries? |
| 13:26.54 |
``Erik |
probably
are |
| 13:27.00 |
dloman |
kk |
| 13:27.09 |
``Erik |
http://www.gimp.org/macintosh/
heh |
| 13:27.21 |
CIA-52 |
BRL-CAD:
03starseeker * r43909 10/brlcad/branches/STABLE/ (27 files in 17
dirs): Sync STABLE to trunk r43908 |
| 13:27.31 |
starseeker |
there we
go |
| 13:27.36 |
starseeker |
gets moving |
| 13:27.47 |
starseeker |
lots to do,
too few hours... |
| 13:30.37 |
``Erik |
mebbe brlcad
will go to prost and talk to matt about critiquing what we do or
hints on how to not suck? |
| 13:31.20 |
``Erik |
hits the rainlocker and heads off, hasta |
| 13:43.29 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 13:54.38 |
CIA-52 |
BRL-CAD:
03davidloman * r43910 10/geomcore/trunk/ (4 files in 2 dirs):
Rework DataSource interface to better represent current repo design
initiative. (plus cascading changes.) |
| 14:05.54 |
CIA-52 |
BRL-CAD:
03davidloman * r43911 10/geomcore/trunk/ (3 files in 2 dirs): Stub
in SvnDataSource class |
| 14:06.55 |
``Erik |
10:06AM up
313 days, 16:43, 2 users, load averages: 0.05, 0.11,
0.14 |
| 14:07.18 |
``Erik |
doh, wrong
machine :D |
| 14:07.21 |
dloman |
thats good to
know ``Erik , thanks! |
| 14:07.22 |
``Erik |
10:06AM up
414 days, 4:55, 17 users, load averages: 1.91, 2.03,
2.02 |
| 14:07.44 |
``Erik |
starting to
get heavy again, might break the old record |
| 14:08.25 |
dloman |
``Erik: whats
your FB post about? |
| 14:08.56 |
``Erik |
just
everything all happening at once, crazy couple of
months |
| 14:09.03 |
dloman |
ah, got
ya. |
| 14:09.35 |
``Erik |
I mean, that
whole area is lighting up like ww3 is about to start, natural
disasters of unprecidented scale elsewhere, ... |
| 14:10.33 |
dloman |
maybe, just
maybe, there will be some finality to the (seemingly) endless
conflict in/around the middle easy. |
| 14:10.36 |
dloman |
lol |
| 14:10.37 |
dloman |
east |
| 14:11.19 |
``Erik |
perhaps, if
they modernize, but we're regressing on the flipside,
so... |
| 14:11.48 |
``Erik |
(mebbe that's
the REAL pole shift to be scared about :D ) |
| 14:12.03 |
dloman |
=D |
| 14:12.55 |
dloman |
That would
make a decent 'what if' scifi story: Earth's axial tilt gets
knocked to near 90 degrees..... |
| 14:15.03 |
``Erik |
ever read
"lucifers hammer"? pournelle and niven, I think? |
| 14:15.15 |
dloman |
can't say
that I have. |
| 14:15.28 |
``Erik |
similar
situation, amusing enough book :) |
| 14:16.07 |
dloman |
wonders if there is an audiobook for
it..... |
| 14:16.47 |
dloman |
if pournelle
can tame niven's habit for painful science detail, then it could be
good :) |
| 14:17.13 |
``Erik |
hehehe, I dig
niven, I like the detail |
| 14:17.19 |
dloman |
the ringworld
series was interesting, but it felt like i was reading a tech
manual / textbook at times ;) |
| 14:17.36 |
dloman |
"Screw plot
development, lets talk about cool geeky things" |
| 14:17.40 |
``Erik |
needs to pick up pratchets discworld
series |
| 14:17.40 |
dloman |
=D |
| 14:17.51 |
dloman |
heh, we have
all of them |
| 14:17.54 |
dloman |
well, most of
them. |
| 14:18.04 |
dloman |
he got really
preachy in his latests books. |
| 14:18.34 |
dloman |
He's a
faithfully devout Athiest and started to use his books to
evangelize :/ |
| 14:18.55 |
``Erik |
hm |
| 14:19.00 |
dloman |
that was
kinda annoying, but the first, oh, 8-10 books in the series were
great. |
| 14:19.09 |
``Erik |
also need to
restock on harry harrison and mercedes lackey O.o |
| 14:19.20 |
``Erik |
does robert
asprin still write? is he still alive? O.o |
| 14:19.23 |
dloman |
I have a few
audio books for pratchet if you want. |
| 14:19.31 |
``Erik |
oh, he died
in '08 :( |
| 14:19.33 |
dloman |
no idea.
Who's that? |
| 14:19.46 |
``Erik |
the 'myth'
series and 'phules company' |
| 14:19.54 |
``Erik |
camp comedy
scifi |
| 14:20.15 |
``Erik |
http://en.wikipedia.org/wiki/MythAdventures
was his big series |
| 14:20.54 |
``Erik |
kinda mel
brookes goofy |
| 14:21.30 |
dloman |
hrm, looks
interesting. |
| 14:21.37 |
dloman |
bookmarks. |
| 14:21.52 |
dloman |
so I was
wondering... |
| 14:21.57 |
``Erik |
the blue
pill |
| 14:22.05 |
dloman |
i found a
website pertaining to the whole Ringworld thing |
| 14:22.22 |
dloman |
some guy,
back in the 80's, tried to do a simulation of the
Ringworld. |
| 14:22.34 |
dloman |
but hit a
wall due to computer limitations |
| 14:22.44 |
dloman |
....think we
could model it in brlcad? |
| 14:22.46 |
``Erik |
hm, we do
have a hair more computational power these days, I
think |
| 14:22.50 |
dloman |
simply of
course |
| 14:23.06 |
``Erik |
model it?
sure, um |
| 14:23.12 |
dloman |
although, an
algo that would generate terrain in addition to the ring would be
neat. |
| 14:23.15 |
``Erik |
accuracy will
get gimpy due to the sizes |
| 14:23.26 |
``Erik |
I thought we
had a few of those |
| 14:23.37 |
dloman |
....but on
that scale? :) |
| 14:23.44 |
``Erik |
fractal noise
generators that create dsp's, etc |
| 14:23.53 |
``Erik |
sure, big
enough fractal, it's just a memory constraint |
| 14:24.12 |
dloman |
ponders |
| 14:24.22 |
dloman |
down to what
resolution though.... |
| 14:24.31 |
dloman |
1km ? 10m
? |
| 14:24.36 |
``Erik |
could alter
one to do 'bound' fractals to chain them along by preseeding one
side and generate a metric buttload of dsps' to cover the inner
surface |
| 14:25.04 |
dloman |
i think its
funny how you can spew tech stuff and still work the word
'buttload' into it. |
| 14:25.10 |
dloman |
=D |
| 14:25.39 |
``Erik |
10m should be
okish, I'd start getting nervous about 1m... um, the estimated
orbital distance is about jupiters orbit, and we store purely in
mm |
| 14:26.11 |
``Erik |
I'm under the
impression that jupiter is (let me figure a better word) a whole
metric assload of mm's from the center of the sun |
| 14:26.28 |
``Erik |
so double
precision will start stretching out a fair bit |
| 14:26.43 |
dloman |
right, but we
have 64 bits of storage to work with right? And with doubles, we
get what.... 15 decimals of precision? |
| 14:26.54 |
``Erik |
15 decimals
is a falacy |
| 14:27.09 |
dloman |
...hence the
question mark :P |
| 14:27.18 |
``Erik |
it's a
logorithmic encoding, with the most accuracy right at
1.0ish |
| 14:27.34 |
``Erik |
if you get
too small or too big, the discernable difference
increases |
| 14:27.44 |
dloman |
well forget
float then, why not go with pure integer? |
| 14:28.36 |
``Erik |
I was
actually trying to come up with a system in the late 90's, wanting
to right an xwing/wingcommander type game for an entire solar
system, did the math and double was 'good enough', after being
mocked for trying to come up with a tiered integer
system |
| 14:29.25 |
``Erik |
but that was
a space fighter sim, the speeds and distances were assumed to be
significant, so mapping between model and world space ... I don't
recall :/ |
| 14:29.27 |
dloman |
what was your
minimum accuracy with that system? 1m 10m? |
| 14:29.58 |
``Erik |
I want to
think a full double was down to a handful of cm, but I really don't
remember |
| 14:30.17 |
``Erik |
that's 64b
packed, 80b computation, the norm for intel |
| 14:31.10 |
``Erik |
of course, a
ringworld model could hold translation matrices all up the chain to
gain accuracy, ya just might get weirdness if you
xpush'd |
| 14:31.23 |
dloman |
hehehe |
| 14:31.43 |
``Erik |
might be a
fun diversion in april :D |
| 14:31.53 |
dloman |
that'd be a
pretty awesome ISST demo |
| 14:32.00 |
dloman |
april ==
offsite? |
| 14:32.29 |
``Erik |
nah, offsite
should be serious, but we all have too much to worry about this
month, can't have diversions like that |
| 14:33.23 |
``Erik |
(mebbe we
shoulda made geomserv the offsite, it was postponed because
geomserv was more important, from what I understand) |
| 14:42.09 |
dloman |
well now,
work on the Infinity engine has certainly come along nicely. Eye
candy: http://www.youtube.com/watch?v=h7eREddMjt4 |
| 14:52.54 |
CIA-52 |
BRL-CAD:
03davidloman * r43912 10/geomcore/trunk/ (5 files in 4 dirs):
Modify GeometryReqMsg to carry 'Path' and 'Recurse' vars instead of
'ReqType' and 'Path' vars |
| 15:08.55 |
*** part/#brlcad sofichinu
(~sofichinu@115.69.147.65) |
| 15:09.17 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 16:23.07 |
CIA-52 |
BRL-CAD:
03starseeker * r43913 10/brlcad/branches/cmake/ (5 files in 4
dirs): MFC r43912 |
| 16:57.06 |
CIA-52 |
BRL-CAD:
03davidloman * r43914 10/geomcore/trunk/src/GS/ (geomserv.config
geomserv.cxx): Clean up and standardize Datasource declarations in
the .config file |
| 17:02.45 |
CIA-52 |
BRL-CAD:
03davidloman * r43915 10/geomcore/trunk/ (include/DataManager.h
src/GS/DataManager.cxx): Simplify DataManager by only allowing it
to handle a single DataSource.... for now. |
| 17:42.57 |
CIA-52 |
BRL-CAD:
03starseeker * r43916 10/brlcad/trunk/src/ (libbu/booleanize.c
libged/red.c): Two things to fix red behavior - need blank and not
space in one place in the regex matching, and recognize (null) as a
boolean 0 in bu_str_true |
| 17:48.01 |
starseeker |
pwd |
| 17:48.10 |
starseeker |
whoops |
| 17:50.41 |
CIA-52 |
BRL-CAD:
03starseeker * r43917 10/brlcad/branches/STABLE/src/
(libbu/booleanize.c libged/red.c): Sync STABLE to trunk
r43916 |
| 17:52.48 |
CIA-52 |
BRL-CAD:
03starseeker * r43918 10/brlcad/branches/cmake/src/
(libbu/booleanize.c libged/red.c): MFC r43917 |
| 18:09.14 |
CIA-52 |
BRL-CAD:
03davidloman * r43919 10/rt^3/trunk/ (27 files in 25 dirs): Purge
out all GeometryService related stuff. This now lives in the
GeomCore module. |
| 18:10.16 |
*** join/#brlcad Nohla
(~Nohla@64.76.19.227) |
| 18:11.37 |
CIA-52 |
BRL-CAD:
03starseeker * r43920 10/brlcad/trunk/src/libged/color.c: edcolor
was eating the colors - check for the right number of digits in the
scan line |
| 18:14.38 |
CIA-52 |
BRL-CAD:
03starseeker * r43921 10/brlcad/trunk/NEWS: edcolor was removing
old color tables and not accepting new ones - fixed scan logic to
expect the actual number of digits being scanned for. |
| 18:16.50 |
CIA-52 |
BRL-CAD:
03starseeker * r43922 10/brlcad/branches/cmake/ (NEWS
src/libged/color.c): MFC r43921 |
| 18:17.45 |
CIA-52 |
BRL-CAD:
03starseeker * r43923 10/brlcad/branches/STABLE/ (NEWS
src/libged/color.c): Sync STABLE to trunk r43921 |
| 19:23.31 |
*** join/#brlcad bhinesley
(~bhinesley@adsl-99-125-83-101.dsl.bkfd14.sbcglobal.net) |
| 19:44.19 |
bhinesley |
Hello
everyone, I'm a student participating in the GSoC. I would
appreciate any suggestions for project proposals. I have about 5
years of professional experience in 3d CAD design (designing
commercial plumbing systems in AutoCAD). I have minimal experience
with C++ and Java, but I have coded dozens of VBA programs for the
companies I have worked for. I use Linux all the time, personally,
and I also have about 3 years of |
| 19:44.19 |
bhinesley |
experience
administering a Linux server on a ~25 workstation
network. |
| 19:45.49 |
bhinesley |
Also, I am
somewhat familiar with Python, and I believe I could get up to
speed quickly. |
| 19:50.50 |
*** join/#brlcad yukonbob_
(~bch@20-144.wireless.kamloops.net) |
| 19:50.53 |
starseeker |
do you have
particular interests? |
| 19:51.56 |
starseeker |
bhinesley: if
you have experience with modeling interfaces, you might want to
take a look at our ideas for GUI enhancement |
| 19:52.42 |
starseeker |
We're using
Tcl/Tk, which is a bit different from Python, but not tremendously
difficult |
| 19:54.35 |
starseeker |
http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas |
| 19:55.00 |
bhinesley |
I don't have
any particular interests, that I can think of yet. I don't have
experience with modeling interfaces. |
| 19:55.15 |
starseeker |
well, you
used AutoCAD yes? |
| 19:55.17 |
bhinesley |
Learning a
new language isn't really a problem |
| 19:55.23 |
bhinesley |
yes |
| 19:55.29 |
starseeker |
that's
experience :-) |
| 19:56.00 |
starseeker |
bhinesley:
the first thing I'd suggest is compiling BRL-CAD and taking a look
at MGED and Archer |
| 19:56.11 |
starseeker |
they're where
the current GUI development action is |
| 19:56.31 |
bhinesley |
I think I
misunderstood you, I thought you meant programmer-modeling user
interfaces |
| 19:56.51 |
bhinesley |
okay |
| 19:56.55 |
starseeker |
Was your pipe
design work in 2D or 3D (drawings, or three space)? (there's no
wrong answer) |
| 19:57.01 |
bhinesley |
3d |
| 19:57.07 |
bhinesley |
for
fabrication |
| 19:57.09 |
starseeker |
nods |
| 19:57.42 |
bhinesley |
although,
obviously I am proficient in 2d drawings as well |
| 19:57.55 |
starseeker |
If you're not
afraid to get down and dirty with Tcl/Tk, I'd suggest taking a look
at the sketch editing task and possibly the Ayam task |
| 19:58.05 |
starseeker |
do you have
any mathematical background? |
| 19:58.29 |
bhinesley |
yes, I have
finished calculus 2 (out of 3; I'm on a semester
system) |
| 19:58.48 |
starseeker |
OK - Ayam is
related to NURBS, which is pretty heavy duty in the mathematical
department |
| 20:00.29 |
bhinesley |
interesting... I am assuming it involves
more mathematics than I am familiar with(?) |
| 20:01.42 |
starseeker |
It depends...
the mathemathical requirements may not be absolutely essential for
mapping Ayam nurbs editing to our nurbs editing, but you'll have to
become familiar with NURBS structures |
| 20:03.12 |
starseeker |
Our sketch
editor needs help rather badly, so if you're more comfortable with
2D drafting you can take a look at our sketch editor, at what TkCAD
can do, and where to go from there |
| 20:04.33 |
starseeker |
http://brlcad.org/wiki/MGED_Sketch_Editor_Migration_and_Enhancement |
| 20:04.44 |
starseeker |
http://brlcad.org/wiki/Ayam_Editor_Feature_Integration |
| 20:05.13 |
starseeker |
those will
have links to get you started |
| 20:05.18 |
bhinesley |
thank
you |
| 20:05.44 |
bhinesley |
not sure if
this helps, but here is a picture of some of my work: http://stashbox.org/manage_file/1087048/pipe |
| 20:05.48 |
starseeker |
remember
those are just suggestions - be sure to pick something you find
interesting |
| 20:06.12 |
bhinesley |
certainly |
| 20:06.49 |
starseeker |
I base those
suggestions on the fact that you've worked at modeling tasks
before, and thus have background interacting with graphical
modeling tasks |
| 20:07.40 |
bhinesley |
that's great,
that is exactly what I was looking for |
| 20:08.16 |
starseeker |
If you're
familiar with Python Tcl/Tk shouldn't seem too alien, although
Archer in particular makes heavy use of Itcl/Itk |
| 20:09.31 |
starseeker |
bhinesley:
you'll want to get BRL-CAD built first and foremost, since
everything follows from that, and get MGED and Archer
running |
| 20:09.47 |
bhinesley |
yes, I'll do
that right now. |
| 20:10.17 |
starseeker |
then explore
the sketch editor (I'll offer a shortcut - when you have mged
running, create a basic sketch and then edit it to get the
gui) |
| 20:11.00 |
starseeker |
from the MGED
command line: |
| 20:11.03 |
starseeker |
make sketch.s
sketch |
| 20:11.14 |
starseeker |
sed
sketch.s |
| 20:11.51 |
starseeker |
(remember to
compile using --with-ogl to get Archer working) |
| 20:12.19 |
starseeker |
bhinesley: I
can't seem to see that stashbox.org link |
| 20:14.05 |
bhinesley |
Hmm, I was
afraid of that. I'm trying to find an alternative. |
| 20:16.22 |
bhinesley |
try this:
https://picasaweb.google.com/lh/photo/_dWpWLr1esGb16X7_4DlNHMyrgI048JfNwPx7Dl9cn0?feat=directlink |
| 20:17.11 |
bhinesley |
that doesn't
show much solids modeling, but I've done that too |
| 20:17.37 |
bhinesley |
let me
clarify: a tool was used for sizing the pipe |
| 20:17.58 |
bhinesley |
all
routing/placement was done manually |
| 20:18.36 |
bhinesley |
I modeled all
of the pumps/tanks to spec though |
| 20:21.05 |
starseeker |
cool |
| 20:26.45 |
bhinesley |
so what kind
of stuff do you do for BRL-CAD, if you don't mind me
asking/ |
| 20:26.49 |
bhinesley |
*? |
| 20:29.29 |
starseeker |
bug fix,
development, support |
| 20:30.11 |
starseeker |
the guy to
really listen to is brlcad, he'll probably appear in channel
later |
| 20:30.38 |
bhinesley |
oh okay.
founder? |
| 20:30.58 |
starseeker |
he's the lead
of the open source project |
| 20:31.08 |
starseeker |
the actual
founder of BRL-CAD itself is Mike Muuss |
| 20:31.43 |
starseeker |
it's a very
old project: http://brlcad.org/d/about |
| 20:32.05 |
starseeker |
is a newbie, relatively speaking :-) |
| 20:33.06 |
starseeker |
bhinesley: if
you want to ask questions, go ahead and post them - it may be a few
hours before anyone responds, but that's normal - we read
backlogs |
| 20:33.36 |
bhinesley |
hey, that's
cool |
| 20:33.37 |
bhinesley |
is a newbie, in absolute terms |
| 20:33.51 |
bhinesley |
thanks for
your help |
| 20:34.00 |
starseeker |
no problem -
any of that look interesting? |
| 20:34.58 |
bhinesley |
I haven't
looked yet, I'm working on getting the source |
| 20:35.09 |
starseeker |
nods |
| 20:35.25 |
starseeker |
remember not
to check out the whole thing - you only want the latest development
sources: |
| 20:35.38 |
starseeker |
svn co
https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 20:35.53 |
bhinesley |
oh thanks, I
wasn't sure which to checkout |
| 20:37.04 |
starseeker |
the toplevel
files have instructions for building - ideally, ./autogen.sh
&& ./configure --enable-all --with-ogl && make
&& make install will do it |
| 20:39.10 |
CIA-52 |
BRL-CAD:
03starseeker * r43924 10/geomcore/branches/fossil/ (4 files in 3
dirs): Get checking building, albeit with a lot of implicit
warnings |
| 20:39.59 |
starseeker |
bhinesley: be
sure you review the checklist - do you have a sourceforge
account? |
| 20:41.38 |
bhinesley |
I will in
about 30 seconds |
| 20:51.33 |
CIA-52 |
BRL-CAD:
03starseeker * r43925 10/geomcore/branches/fossil/ (4 files in 2
dirs): Add find_option to basic, but this does not belong in a
library (none of the argc/argv stuff does) and will be part of a
restructuring |
| 20:56.01 |
CIA-52 |
BRL-CAD:
03starseeker * r43926
10/geomcore/branches/fossil/src/libgeomvcs/checkin.c: update
find_option |
| 21:31.51 |
*** join/#brlcad Emma
(~Emma@p5.eregie.pub.ro) |
| 22:30.35 |
CIA-52 |
BRL-CAD:
03starseeker * r43927 10/geomcore/branches/fossil/ (10 files in 2
dirs): Declare some more functions. |
| 03:17.17 |
*** part/#brlcad niels_horn
(~niels@187.14.62.166) |
| 03:26.00 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
| 03:26.08 |
*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) |
| 03:26.31 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 03:26.36 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 03:33.57 |
*** mode/#brlcad [+o brlcad] by ChanServ |
| 03:42.08 |
brlcad |
starseeker:
thanks for the sync to stable, can hopefully test
tomorrow |
| 03:45.06 |
*** join/#brlcad IriX64
(~IriX64@bas2-sudbury98-1096601295.dsl.bell.ca) |
| 03:45.44 |
brlcad |
bhinesley:
welcome |
| 03:47.08 |
bhinesley |
brlcad: thank
you, hello |
| 03:50.06 |
brlcad |
bhinesley: so
I read the backlog, have you had a chance to look around at things
in BRL-CAD yet? |
| 03:50.40 |
brlcad |
there really
are nearly a limitless range of areas where valuable projects can
be worked |
| 03:51.44 |
bhinesley |
I actually
just got back from class. Before I left, I was working on getting
BRL-CAD compiled; still a couple errors, but close. |
| 03:51.49 |
brlcad |
from a
project-perspective, I can share that this year there is a strong
emphasis on projects that are tightly integrated and part of
BRL-CAD, refacting and improvements being more interesting than new
code that could be developed in isolation |
| 03:52.03 |
brlcad |
errors?
pastebin? |
| 03:52.11 |
brlcad |
should be a
clean checkout/build from latest svn |
| 03:53.00 |
bhinesley |
I didn't save
it, but I'm re-"make"ing right now |
| 03:58.08 |
bhinesley |
I will
hopefully have more to say about the projects that were presented
to me, soon. I feel that I should do a bit more research before I
understand. |
| 03:58.28 |
bhinesley |
*will need to
to a bit more research |
| 04:05.37 |
bhinesley |
I am
certainly interested in contributing to BRL-CAD, though. Now that I
know more about it, I will try to help where I can, GSoC or
no. |
| 04:05.54 |
bhinesley |
here we go:
http://pastebin.com/8SgPkDtK |
| 04:07.51 |
brlcad |
huh,
interesting -- that's from svn trunk? |
| 04:07.58 |
brlcad |
what version
of gcc is that? |
| 04:08.15 |
bhinesley |
4.5.1 |
| 04:08.33 |
brlcad |
mm, nice 'n
fresh |
| 04:08.35 |
bhinesley |
it's from
here: https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 04:08.38 |
brlcad |
k |
| 04:10.10 |
bhinesley |
that is the
version that came with the stable brach of Fedora. Should I try a
newer version? |
| 04:14.12 |
CIA-52 |
BRL-CAD:
03brlcad * r43928
10/brlcad/trunk/src/proc-db/clutter.c: |
| 04:14.12 |
CIA-52 |
BRL-CAD:
clear a strict compilation warning from gcc 4.5.1 (reported by
bhinesley via |
| 04:14.12 |
CIA-52 |
BRL-CAD: irc)
where a warning about an operation within the random number
generator may |
| 04:14.12 |
CIA-52 |
BRL-CAD: be
undefined. it's undoubtedly due to multiple increment calls being
passed as |
| 04:14.12 |
CIA-52 |
BRL-CAD:
function args, so evaluation order might not be what one would
expect. simple |
| 04:14.13 |
CIA-52 |
BRL-CAD:
enough to get the random number prior to the function. |
| 04:14.15 |
brlcad |
so that's
just a compilation warning, halting because we specify "cc1:
warnings being treated as errors" |
| 04:14.22 |
brlcad |
fixes are
usually trivial |
| 04:16.39 |
bhinesley |
that's what I
thought, but I figured the "warnings being treated as errors" was
there for a valid reason |
| 04:18.04 |
bhinesley |
oh, I see
now. I'll remove it. |
| 04:18.39 |
brlcad |
the
--disable-strict configure flag will get you past those warnings,
though there really shouldnt be many/any .. it's almost complete in
your build to have gotten as far as it did only halting in proc-db
(one of the last dirs) |
| 04:19.20 |
brlcad |
it's there to
weed those issues out by default, instead of ignoring and/or
allowing to accumulate |
| 04:19.30 |
bhinesley |
makes
sense |
| 04:21.13 |
brlcad |
took several
months to bring the code base into full compliance |
| 04:22.06 |
brlcad |
but in the
end, having rigid conformance to all warnings across multiple
configurations, platforms, and compilation environments really
helps maintainability |
| 04:22.25 |
brlcad |
and pushes
back against lazy coding habits |
| 04:24.22 |
bhinesley |
hard to argue
against paying attention to warnings |
| 04:26.29 |
brlcad |
bhinesley: so
in addition to the project ideas page, there is also http://brlcad.org/~sean/ideas.html |
| 04:27.13 |
bhinesley |
wow,
great |
| 04:27.17 |
brlcad |
of everything
in that list and the project ideas page, priority is generally
given to topics that fall into one of our four major focus areas
(described in detail at http://brlcad.org/BRL-CAD_Priorities.png
) |
| 04:29.09 |
brlcad |
our main
interest isn't so much in getting code, but towards getting you
actively developing (long after gsoc is over) |
| 04:32.01 |
bhinesley |
assisting in
active development is precisely what I am interested in |
| 04:32.04 |
brlcad |
if that
interest is mutual, then the project is really just a catalyst
excuse to keep you fed while you code and becaome a proper new dev
and we can make a lot more headway on a successful gsoc
submission |
| 04:38.50 |
bhinesley |
to be honest,
though, with all the hype surrounding the competitive nature of the
GSoC, I feel like I am competing with a bunch of guys polishing up
the last 6 months of their PhD's |
| 04:39.21 |
bhinesley |
not to say
that I am not going to put forth the maximum effort. |
| 04:39.40 |
brlcad |
it's a really
wide range of talent and experience |
| 04:39.45 |
bhinesley |
has used a double negative |
| 04:40.57 |
brlcad |
having worked
with a couple students in previous years whose projects loosely
related to their dissertation, I can say that is definitely not
something very interesting to entertain again this year unless it
was just an outright stellar proposal |
| 04:41.27 |
brlcad |
those
students tend to work on their project and disappear |
| 04:41.55 |
bhinesley |
expensive,
then |
| 04:48.17 |
brlcad |
feel free to
probe any questions on what you might be interested in working on,
whether it's something on the list or not -- keeping in mind the
"prefer to fix/improve/integrate existing code over writing new
code" inclination as a general guideline |
| 04:50.02 |
bhinesley |
will do; when
are you usually here? |
| 04:50.06 |
brlcad |
and of
course, ask all the questions that come to mind - several of us
read backlog and comment when time is available |
| 04:50.14 |
brlcad |
usually all
the time ;) |
| 04:50.18 |
bhinesley |
:) |
| 04:50.25 |
brlcad |
just
sometimes too busy to talk |
| 04:51.09 |
brlcad |
UTC-4 at the
moment |
| 04:52.02 |
bhinesley |
good to know,
I'm -8 |
| 04:54.42 |
brlcad |
really??
that's alaska |
| 04:55.09 |
brlcad |
maybe
+8? |
| 04:55.49 |
bhinesley |
california
http://upload.wikimedia.org/wikipedia/commons/3/39/Timezones2008_UTC-8.png |
| 04:59.24 |
bhinesley |
compile
successful :) |
| 05:01.57 |
brlcad |
ah right, so
actually UTC-7 then .. (daylight savings) |
| 05:02.51 |
bhinesley |
huh, I didn't
realize the UTC code changed for daylight savings |
| 05:03.05 |
bhinesley |
makes
sense |
| 05:29.10 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 08:14.52 |
brlcad |
finishes our gsoc flyer: http://brlcad.org/gsoc/BRL-CAD_GSoC2011_flyer.pdf |
| 08:15.13 |
brlcad |
feedback
welcome, holding off sending it in to google until after
morning |
| 08:16.47 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 09:24.41 |
bhinesley |
looks
good/professional. Maybe change the color of "GET PAID".
Goodnight. |
| 10:46.53 |
starseeker |
brlcad: nice,
I like it |
| 10:47.19 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
| 10:55.31 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 11:06.27 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 11:17.26 |
dloman |
mernin |
| 11:47.54 |
starseeker |
morning |
| 12:55.54 |
yiyus |
I'm thinking
about applying for the gsoc project "GED Transactions" |
| 12:56.08 |
yiyus |
looking at
libged source it looks like a lot of work |
| 12:57.47 |
yiyus |
I think most
of the transactions would be trivial, but there will probably be
some difficult ones... |
| 12:58.04 |
yiyus |
any idea of
where i should be looking at to figure out the dimension of the
project? |
| 12:59.53 |
brlcad |
yiyus:
hello! |
| 13:00.05 |
yiyus |
hi |
| 13:02.39 |
brlcad |
yiyus: the
general idea is to incrementally unroll how each of the commands so
they no longer modify geometry |
| 13:02.51 |
brlcad |
it's a LOT of
refactoring, but not hard code fortunately |
| 13:03.47 |
brlcad |
so, for
example, there is a 'kill' command for deleting geometry
.. |
| 13:04.26 |
brlcad |
presently,
that command will search for the specified object(s) and it deletes
them from the geometry file if it finds them |
| 13:05.30 |
brlcad |
tranactionally, that would change to
having the kill command still search for the specified object(s)
like it was doing before, but when it finds them, it records a
"delete OBJECT" action |
| 13:06.46 |
yiyus |
i have worked
in text editors with infinite undo before, we made something
similar (though a bit simpler): apply the modification and push the
inverse function to an undo stack |
| 13:07.08 |
yiyus |
iiuc your
idea is the same, but having also a "done" stack |
| 13:07.51 |
brlcad |
a wrapper
function kill would have been called through gets a resulting
action list back from every command, which would then revalidate
that all actions can be performed, perform them on a copy, then
make the copy replace the original |
| 13:08.50 |
yiyus |
ah, ok, i
think i got it |
| 13:08.57 |
brlcad |
it's similar
to infinite undo (and the wrapper function would also need to
record the action and the inverse action to a log) |
| 13:09.21 |
yiyus |
validating
that the operations can be performed would be refactored or would i
have to write it from scratch? |
| 13:09.23 |
brlcad |
the only
complexity is that the transactions are nestable |
| 13:10.25 |
yiyus |
nestable, in
the same sense that solidworks transformations are nestable, for
example? |
| 13:10.35 |
brlcad |
I might call
one command, which might call another, which might call another,
etc.. each of them potentially pushing actions of delete, create,
or modify of geometry and views |
| 13:10.49 |
brlcad |
yes |
| 13:11.25 |
yiyus |
well,
everything sounds quite well, i will have a deeper look to get some
familiarity with brlcad and the libged code |
| 13:11.33 |
yiyus |
one last
thing |
| 13:11.56 |
yiyus |
I also saw
the "Geometry Selection Functionality" project |
| 13:12.25 |
yiyus |
which of them
would be preferable? ged transactions or geometry
selection? |
| 13:13.03 |
brlcad |
yes
:) |
| 13:13.07 |
brlcad |
both are high
priority |
| 13:13.56 |
brlcad |
geometry
selection is a lot more tangible for gsoc in terms of
complexity |
| 13:14.06 |
brlcad |
so what's
your background? |
| 13:14.52 |
yiyus |
i'm
industrial engineer. programming all my real experience is in
C |
| 13:15.05 |
yiyus |
though i also
know some other languages |
| 13:15.26 |
yiyus |
i
participated in gsoc 2010, with Plan 9 from Bell Labs, writing a
virtual machine |
| 13:15.38 |
yiyus |
but I don't
think that can be applied here |
| 13:15.52 |
yiyus |
i also know
many other languages, but not c++ |
| 13:15.57 |
brlcad |
how did you
like working with the plan 9 guys? |
| 13:16.20 |
yiyus |
it was great.
actually, i have been quite involved in plan9 related projects for
some years |
| 13:16.32 |
brlcad |
are you still
working on plan9 too? |
| 13:17.08 |
yiyus |
yes |
| 13:17.25 |
yiyus |
i still
maintain what i wrote last year, and we have some plans to improve
it |
| 13:17.47 |
yiyus |
as a matter
of fact, i'm considering applying there again too |
| 13:18.29 |
dli |
plan9 still
alive? I thought they have stopped it |
| 13:20.17 |
yiyus |
it is alive,
but the team working on it at the labs is very small |
| 13:20.17 |
brlcad |
dli: oh yeah,
their core devs are quite committed .. |
| 13:21.09 |
yiyus |
there is not
any interest in turning it into a mainstream os (which i think is
fine) |
| 13:21.27 |
brlcad |
i've wanted
to attempt of port of brl-cad to plan9 |
| 13:21.43 |
brlcad |
we'd probably
compile right out of the box with 80% functionality |
| 13:21.59 |
brlcad |
tk would be
the one tough part |
| 13:22.16 |
brlcad |
so probably
no gui services, but all command-line commands |
| 13:22.32 |
brlcad |
or at least
most, the non-curses ones |
| 13:22.47 |
yiyus |
there is a tk
port for inferno, which runs on top of plan9 |
| 13:22.54 |
yiyus |
but it is not
tcl/tk, it is in limbo |
| 13:24.15 |
brlcad |
yiyus: so for
gsoc submission, both sound like great ideas -- if you were going
to tackle the libged one, I'd want to see a lot of up-front
planning and testing on just one command before hitting up the 399+
other commands, maybe even having an initial refactoring plan
spelled out in the application |
| 13:24.35 |
brlcad |
that's an
important one to "get right" so there's not a lot of time wasted
refactoring over and over and over |
| 13:24.53 |
brlcad |
libged
refactoring is another project all in itself (and also high
priority) :) |
| 13:26.12 |
brlcad |
that's also a
project that would extend beyond gsoc so it'd be good to hear what
dev plans would look like for beyond gsoc timeframe |
| 13:26.40 |
yiyus |
i will have
to get familiar with libged before i can say too much, but will
definitively have a look |
| 13:27.05 |
brlcad |
if that
sounds like a lot of work (and it frankly IS, but would rather both
of us be honest about it) .. then select may be a much better
proposal or a library refactoring proposal since they're much more
incremental |
| 13:31.59 |
yiyus |
may i ask
what is your approximate student proposals/gsoc slots
ratio? |
| 13:33.41 |
brlcad |
never know
exactly, it really depends on the quality of the proposals more
than the count |
| 13:34.00 |
brlcad |
we do a quick
culling to the quality proposals |
| 13:35.05 |
brlcad |
one year that
knocked 50 applications down to about 10 where we selected 4,
another year that knocked 35 down to about 15 and we selected
5 |
| 13:35.37 |
yiyus |
thanks,
that's all i wanted to know |
| 13:36.02 |
yiyus |
some projects
cooperate with university departments and such, and have hundreds
of applications per slot |
| 13:36.05 |
brlcad |
if it's a
high quality application from a student we've been interacting with
and we think is willing to be committed beyond gsoc, will instantly
be in that final running |
| 13:36.37 |
brlcad |
ah yeah, no
.. we're way more niche |
| 13:37.19 |
brlcad |
those sorts
of applications rarely result in students that hang around after
the summer is up .. interesting for getting academic code, but not
so hot for growing the dev team |
| 13:37.44 |
yiyus |
i would like
to stick on the project after gsoc |
| 13:38.07 |
brlcad |
we would like
that as well :) |
| 13:38.08 |
yiyus |
i work at a
department in the university (phd student) and would like to
convince my collegues to use free software |
| 13:38.27 |
yiyus |
that's why
i'd prefer brlcad over plan9 |
| 13:40.11 |
brlcad |
brl-cad's in
production use today, but our usability is really tough especially
compared to commercial cad systems, very steep learning
curve |
| 13:40.27 |
brlcad |
something
actively being worked on, but that's a lot of work that's going to
take several years to address |
| 13:42.21 |
yiyus |
well, i don't
expect to substitue autocad this year, but i'm sure it is good
enough for easy tasks like test samples |
| 13:42.27 |
brlcad |
http://brlcad.org/BRL-CAD_Priorities.png
is a useful read to know how the various gsoc projects fit into our
"big picture" overarching priorities |
| 13:42.39 |
brlcad |
libged fits
in under geometry services |
| 13:50.20 |
starseeker |
brlcad: so
for an undo system, the delete OBJECT action would also record the
inverse action (e.g. create OBJNAME OBJTYPE [params...]) in a log
somewhere? |
| 14:00.10 |
brlcad |
right |
| 14:25.59 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
| 14:30.38 |
brlcad |
howdy
PrezKennedy |
| 14:30.54 |
PrezKennedy |
howdy! how's
life treating you brlcad? |
| 14:31.02 |
brlcad |
pretty
fantastic |
| 14:31.28 |
PrezKennedy |
great! |
| 14:31.39 |
brlcad |
hows
work? |
| 14:32.06 |
PrezKennedy |
meh, we're
wrapping up at the 5 sided building come august |
| 14:32.34 |
PrezKennedy |
we're at the
beginning of a dev cycle so it's not hectic at the
moment |
| 14:32.40 |
brlcad |
nods |
| 14:32.57 |
brlcad |
hopefully
employment is not reduced after the 5side is completed
;) |
| 14:33.25 |
PrezKennedy |
hopefully,
but ive been looking at things up there |
| 14:33.37 |
PrezKennedy |
im not
opposed to moving back, not much keeping me down here |
| 14:33.45 |
brlcad |
bhinesley:
good suggestion, added a little color |
| 14:34.13 |
brlcad |
PrezKennedy:
your brother might appreciate this: http://brlcad.org/gsoc/BRL-CAD_GSoC2011_flyer.pdf |
| 14:35.09 |
starseeker |
brlcad: how'd
you do the blue halo? |
| 14:36.02 |
PrezKennedy |
brlcad,
something he worked on? |
| 14:56.13 |
brlcad |
PrezKennedy:
yeah, he made that model and rendered the image from
scratch |
| 14:57.37 |
brlcad |
went to the
ordnance museum, took measurements, modeled it, set up all the
rendering infrastructure, did several massive distributed
renderings -- this one being one of the more awesome lighting
setups |
| 14:58.10 |
brlcad |
starseeker: I
used the blue pill |
| 14:58.17 |
starseeker |
heh |
| 14:58.26 |
brlcad |
i mean, blue
'part'icles |
| 14:59.39 |
brlcad |
it's actually
several composite effects -- a 0-offset shadow, a 2px antialiased
stroke, and a light underglow effect |
| 15:00.18 |
starseeker |
cool |
| 15:02.50 |
starseeker |
hmm... it
looks like I may have been using svn_add very very
badly... |
| 15:03.10 |
brlcad |
heh |
| 15:03.17 |
starseeker |
or was I...
hmm... |
| 15:03.30 |
brlcad |
wondered that .. an order of magnitude overhead is pretty
substantial :) |
| 15:10.51 |
starseeker |
commit is
still an IO hog |
| 15:12.18 |
brlcad |
one commit or
N commits? |
| 15:12.27 |
brlcad |
hopefully
just one |
| 15:12.44 |
starseeker |
well, I added
the full breakout of havoc recursively, and am committing the whole
thing |
| 15:12.47 |
CIA-52 |
BRL-CAD:
03davidloman * r43929 10/geomcore/trunk/ (include/ByteArray.h
src/utility/ByteArray.cxx): Add a printHexString(...) method. Helps
a tons during t-shooting. |
| 15:15.12 |
CIA-52 |
BRL-CAD:
03davidloman * r43930 10/geomcore/trunk/src/libNet/Portal.cxx: Add
in some commented out ByteArray printHex calls. There's some issue
with c++ and java not liking eachother byte orders. T-Shooting
continues... |
| 15:16.24 |
starseeker |
so yeah, just
doing one commit ;-) |
| 15:17.58 |
CIA-52 |
BRL-CAD:
03starseeker * r43931 10/geomcore/trunk/tests/svntest/main.c: Let's
not individually add everything - use the svn_depth_infinity
parameter setting, and go back to a full breakout - still
expensive, but add is a lot quicker |
| 15:19.25 |
dloman |
so,
realistically, are we viewing full model commits as a common
occurance? |
| 15:19.42 |
dloman |
I always
invisioned them as part of the 'upfront' cost for using the svn
backend. |
| 15:21.08 |
dloman |
starseeker:
if i wanted to 'steal' a root level CMakeList.txt for reworkign the
cmake system in rt3, which would be a better fit? the
CMakeLists.txt from geomcore or brlcad? |
| 15:21.25 |
starseeker |
geomcore |
| 15:21.54 |
starseeker |
dloman: full
model commits are only a common occurance if you do things like
frequent xpushing :-P |
| 15:22.29 |
brlcad |
starseeker:
it'd be interesting to see what the cost difference is after an
xpush, how long commit takes |
| 15:22.51 |
brlcad |
whether the
cost is in the book-keeping to add new nodal entries or whether
it's the commit book-keeping itself |
| 15:23.14 |
starseeker |
once I get
the point where I can do something with the broken out .g I can try
- my guess is it'll be murder |
| 15:23.45 |
starseeker |
I edited one
primitive and committed it, and it took a while (less than a
minute, but still) |
| 15:25.01 |
starseeker |
maybe 10-12
seconds |
| 15:53.26 |
CIA-52 |
BRL-CAD:
03davidloman * r43932 10/rt^3/trunk/ (6 files in 4 dirs): Steal
Starseeker's geomcore cmake work and apply it to RT3. This is the
first step in making RT3 into 'the GeometryEngine'
module. |
| 15:53.53 |
starseeker |
dloman: were
you planning to move the ogre/Qt work elsewhere? |
| 15:55.44 |
dloman |
Dunno.... |
| 15:55.56 |
dloman |
its currently
disabled from any build system.... so.... |
| 15:56.13 |
dloman |
i think it
would warrent discussion at some point :) |
| 15:56.48 |
starseeker |
liked the idea of having a toplevel geomengine module, that
is svn:external included in geomcore |
| 15:57.35 |
starseeker |
or failing
that, scrap geomcore and have two toplevels - geomengine and
geomservice |
| 15:58.17 |
starseeker |
as I
understand it, the idea is to reduce temptation to mingle GE and GS
code and libraries? |
| 15:59.41 |
dloman |
nods |
| 15:59.55 |
dloman |
and singe
coreInterface calls rt3 home.... |
| 15:59.58 |
dloman |
wow |
| 16:00.04 |
dloman |
s/singe/since/ |
| 16:00.34 |
starseeker |
I like
leaving rt3 as the "repository for random ideas"... geometry engine
and geometry service are starting to firm up |
| 16:01.31 |
starseeker |
conceptual
neatness aside, I prefer to have the GE and GS build logic stay
fully clean and not be polluted with "other" stuff that may be
commented out |
| 16:02.00 |
starseeker |
but brlcad
may have a different take |
| 16:03.28 |
dloman |
to be fair,
the rt3 module was not intended to be the 'sandbox' that it has
become. so why not make a 'sandbox' repo? |
| 16:03.47 |
starseeker |
that's fine
too |
| 16:03.48 |
dloman |
err not repo,
but module |
| 16:04.16 |
starseeker |
would still prefer calling it geomengine or GE instead of
rt^3, but I suppose that's a bikeshed issue |
| 16:04.41 |
dloman |
agreed |
| 16:04.51 |
dloman |
'ge' is nice
and short :) |
| 16:05.01 |
starseeker |
dloman: want
me to set it up that way? |
| 16:05.09 |
starseeker |
ge, gs and
sandbox? |
| 16:05.34 |
dloman |
lets get some
buy in from brlcad and perhaps Ed et al. |
| 16:05.42 |
starseeker |
nods - fair enough |
| 16:05.45 |
dloman |
renaming rt3
effects more than just us :) |
| 16:06.15 |
dloman |
...although
we could pull a nice prank on Dr Daniel by removing RT3
:) |
| 16:06.24 |
starseeker |
winces |
| 16:06.46 |
starseeker |
point - we
should probably get GE at least up to parity with his existing rt3
functionality first |
| 16:16.05 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:BRL-CAD GSoC2011
flyer.png]]": This flyer was designed by Christopher Sean Morrison
with Google logo and Goliath rendering provided with permission by
Google Inc and Stephen Kennedy respectively. |
| 16:16.39 |
dloman |
currently,
all i plan on doing is copying the GeometryEngine class files over
(which are stubs) and then make a libge that is nothing but
coreInterface files. |
| 16:16.59 |
dloman |
so, in
essence, libge == coreInterface |
| 16:17.05 |
dloman |
..initially |
| 16:17.13 |
dloman |
we will/can
grow libge from there. |
| 16:17.38 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2614
10/wiki/Google_Summer_of_Code/2011: add a link to this year's flyer
with details on acceptance |
| 16:17.58 |
starseeker |
nods |
| 16:18.18 |
dloman |
almost got
rt3 to that point. |
| 16:21.00 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2615
10/wiki/Google_Summer_of_Code: link to 2011 flyer, scaled
appropriately for landscape |
| 16:21.14 |
*** join/#brlcad phani
(7ab32f27@gateway/web/freenode/ip.122.179.47.39) |
| 16:22.27 |
starseeker |
dloman: go
ahead and do what you need to - we can always sort it out
later |
| 16:22.32 |
phani |
i am student
interested in participating in Google Summer of Code ... are there
any admins around ? |
| 16:22.56 |
starseeker |
the
fundamental cleanup was handled in rt3->geomcore, so subsequent
refactoring should be fairly simple |
| 16:22.59 |
starseeker |
phani:
howdy! |
| 16:23.29 |
phani |
Hi ! I am
good . I am a masters student from india. |
| 16:23.33 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2616
10/wiki/Google_Summer_of_Code: /* [[Google_Summer_of_Code/2011|GSoC
2011]] */ |
| 16:23.44 |
phani |
My area of
spcialization in image processing |
| 16:23.46 |
dloman |
starseeker:
nice assertion that I'm going to screw it up :P |
| 16:23.55 |
starseeker |
dloman: hehe
- I didn't mean it like that |
| 16:24.06 |
starseeker |
phani: have
you looked over our projects page? |
| 16:24.14 |
phani |
yes
.. |
| 16:24.21 |
starseeker |
what do you
find interesting? |
| 16:24.24 |
phani |
http://brlcad.org/wiki/Complete_bu_image/libicv_and_redo_all_pix_tools_to_use_it |
| 16:24.26 |
dloman |
..although,
with the run of luck i've been having lately, its probably not a
bad assertion to make :) |
| 16:24.30 |
phani |
i am
interested in this |
| 16:24.45 |
starseeker |
dloman: I
just ment sorting out directory organization and
whatnot |
| 16:25.02 |
starseeker |
phani: ah -
``Erik knows the most about that subject |
| 16:25.08 |
dloman |
heh, i added
a libge/ dir to src/ .....thats about it! |
| 16:25.26 |
starseeker |
dloman: cool,
that should be fine for now |
| 16:26.04 |
phani |
ok... will
contact eric then |
| 16:26.07 |
starseeker |
phani: did
you have any particular questions? |
| 16:27.01 |
starseeker |
phani:
another image related task would be openexr support |
| 16:27.07 |
phani |
i wanted to
ask more about the project |
| 16:27.33 |
starseeker |
phani: go
ahead - ``Erik and brlcad both read backlogs |
| 16:28.02 |
phani |
i could not
find any other project on image processing there |
| 16:28.05 |
starseeker |
IRC isn't
always real-time communication - you generally stay logged in, post
a question, and sometimes get a response later |
| 16:28.07 |
phani |
can you give
me the link to it ? |
| 16:28.36 |
starseeker |
http://brlcad.org/wiki/High_Dynamic_Range_Support |
| 16:29.17 |
phani |
thanks |
| 16:30.05 |
starseeker |
phani: one of
the first things to do for any project is to make sure you can
compile and run BRL-CAD |
| 16:30.53 |
starseeker |
the work that
has been done so far for the libbu image task is in src/libbu and
src/libicv, if I recall correctly |
| 16:30.54 |
phani |
ok. Will do
that now. |
| 16:31.40 |
starseeker |
phani: since
any project will involve a lot of work in the codebase, you want to
make sure it's something you feel like you can work
in/with |
| 16:32.34 |
phani |
i like image
processing very much and i have considerable command over it. I
would like to get some experience on open source coding on that
subject |
| 16:32.46 |
starseeker |
phani: when
you check out the subversion source, be sure to get just
trunk: |
| 16:32.57 |
starseeker |
svn co
https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 16:33.27 |
starseeker |
phani: note
that BRL-CAD is a solid modeler, not primarily an image related
system |
| 16:34.01 |
phani |
yes, of
course ... |
| 16:34.10 |
CIA-52 |
BRL-CAD:
03davidloman * r43933 10/rt^3/trunk/src/ (5 files in 3 dirs): Okay,
I think i have libGE piggybacking ontop of coreInterface correctly
now. Changes to build system have been made. Daniel, please let me
know if I broke anything for ya! |
| 16:34.44 |
dloman |
okay, so how
does one setup an svn external? |
| 16:35.19 |
starseeker |
phani: not to
drive you away, but in the interests of covering your options
you've also looked at the OpenCV project? |
| 16:37.02 |
starseeker |
you can
submit multiple applications |
| 16:37.54 |
CIA-52 |
BRL-CAD:
03davidloman * r43934 10/geomcore/trunk/src/ (13 files in 10 dirs):
Move some older dev files into an appropriate directory for
now. |
| 16:38.35 |
phani |
yes ...
opencv and astronomy.net are the other organizations i am
interested in ... |
| 16:47.01 |
CIA-52 |
BRL-CAD:
03davidloman * r43935 10/geomcore/trunk/src/ (CMakeLists.txt GE/
libNet/CMakeLists.txt): Remove GE from Geomcore. Its going to be
its own module.... eventually. |
| 16:47.53 |
dloman |
Okay, there.
GE should be completely in rt3 now, and is piggy backed off of
coreInterface. |
| 16:48.32 |
dloman |
Now on to
wiring up geomcore to find libGE and start working the
DataManager/DataSource stuff..... |
| 16:48.44 |
starseeker |
nods |
| 16:53.09 |
brlcad |
how about
simply ge, gs, and gui? |
| 16:53.42 |
starseeker |
works for
me |
| 16:53.43 |
brlcad |
not really
fond of the word sandbox as it implies there are few/no rules and
that shouldn't really be the case for any code committed to the
repository |
| 16:53.56 |
brlcad |
relaxed,
sure, but sandbox implies more free-for-all to me |
| 16:54.41 |
brlcad |
hello
phani |
| 16:55.14 |
starseeker |
ge/gs/gui
works for me |
| 16:56.54 |
brlcad |
phani: there
are lots of potential image processing related projects in
BRL-CAD |
| 16:57.42 |
brlcad |
there are a
few other orgs that are interested in image processing, fwiw, but
we definitely have at least two of high interest -- the two
mentioned already |
| 16:59.43 |
phani |
i am looking
at the links given by starseeker ... I am also compiling BRL-CAD
now. |
| 16:59.51 |
brlcad |
phani: if
you're looking through our source tree, also of interest will be
src/util where there are more than 100 image processing tools from
image converters, wavelet transforms, filters, scalers, and much
more |
| 17:00.31 |
brlcad |
most of them
have man pages and are simply one file per binary |
| 17:00.43 |
brlcad |
so you can
just scan through the *.c or *.1 files |
| 17:00.54 |
phani |
ok... |
| 17:01.24 |
starseeker |
brlcad: I
chimed in in the Qt discussion on the list, so you may need to
smack me down ;-) |
| 17:01.31 |
brlcad |
there's also
src/sig for more general "signal processing" which generally
applies to 1D data stremas, but sometimes to 2D streams as
well |
| 17:02.58 |
phani |
I will look
at these things now and will contact you back as soon as possible.
Its already late night here. |
| 17:02.58 |
brlcad |
phani: as
you're probably already finding out, BRL-CAD is a *very* large
system -- we know that and don't expect you to know what's there or
how to find things easily, so please do ask questions if you have
them |
| 17:03.02 |
CIA-52 |
BRL-CAD:
03Willdye 07http://brlcad.org *
r2617 10/wiki/Building_from_SVN: Give an example for Ubuntu users
who don't have autoconf installed |
| 17:03.36 |
phani |
Thanks for
letting me know where to start. I got a very good intro. Will look
at it in detail |
| 17:03.47 |
phani |
and will ask
you doubts soon |
| 17:03.51 |
brlcad |
starseeker:
comments sounded spot on to me |
| 17:03.59 |
brlcad |
matched up
with what I was saying in not so many words |
| 17:04.04 |
starseeker |
brlcad:
heh |
| 17:04.40 |
starseeker |
had viewed the Qt approach as replacing the X11 dm, in the
same way that OGRE "replaces" dm-ogl/wgl |
| 17:05.41 |
starseeker |
growls at subversion... come on, how do I get a list of
files... |
| 17:05.48 |
brlcad |
phani: if
you're really into image processing, you have the potential to turn
BRL-CAD into your playground (regardless of GSoC) implementing
ideas, research, new tools, etc |
| 17:06.46 |
brlcad |
so while
libicv might be something we're interested in from an architecture
standpoint, we're more interested getting new long term developers
-- so if you have a long term interest there -- then cater your
project proposal around that long term interest so you can and will
want to keep working on it long after GSoC is over |
| 17:07.05 |
brlcad |
we want devs
more than we want their code ;) |
| 17:08.02 |
brlcad |
gsoc
participants that can convince us of that are an easy
shoe-in |
| 17:17.53 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 ETA 20110325 || Welcome GSoC 2011
participants! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 17:33.42 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2618
10/wiki/Google_Summer_of_Code: /* Overview */ |
| 17:44.02 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2619
10/wiki/Google_Summer_of_Code: don't repeat ourselves, we list the
application guidelines on the checklist. link to the 2011
page. |
| 17:48.32 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2620
10/wiki/Google_Summer_of_Code/2011: link back to main
page |
| 18:16.51 |
*** join/#brlcad crazy_imp
(~mj@a89-182-15-254.net-htp.de) |
| 18:16.53 |
crazy_imp |
heyho |
| 18:17.08 |
crazy_imp |
is it
possible to export everything from a .g file with g-stl
? |
| 18:31.17 |
CIA-52 |
BRL-CAD:
03starseeker * r43936 10/geomcore/trunk/tests/svntest/main.c:
Switch back to ktank, make some initial progress on listing out
directory contents. |
| 18:32.37 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2621
10/wiki/Google_Summer_of_Code: mention 2010 |
| 18:34.12 |
brlcad |
crazy_imp:
sure, assuming there are no geometry errors and you don't hit a
problematic conversion case |
| 18:34.38 |
brlcad |
you need to
know the names of the top-level objects, which can be obtained
with: mged -c file.g tops |
| 18:37.15 |
crazy_imp |
brlcad: i
thought of something like this: g-stl .. -o foo.stl foo.g `mged -c
foo.g tops` but it doesn't work |
| 18:37.46 |
crazy_imp |
(i really
want something like "g-stl .... foo.g \*" :) |
| 19:12.22 |
brlcad |
crazy_imp:
mged's output by default goes to stderr, so you'd have to run mged
-c foo.g tops 2>&1 for that to work |
| 19:13.45 |
brlcad |
a problem and
one of the reasons why you have to specify which geometry objects
is because the .g container supports multiple models (multiple
hierarchies of models at that) whereas STL only supports a single
model |
| 19:15.07 |
crazy_imp |
brlcad: so i
should simply design everything inside one file (at least if it's
logical to do so) inside one group for easier
converting? |
| 19:17.34 |
brlcad |
IFF you
convert your model to BoT (mesh) format, you might have better luck
with something like: mged -c foo.g bot_dump -t stl -o
foo.stl |
| 19:17.42 |
brlcad |
that will
dump all BoT objects to files |
| 19:18.13 |
brlcad |
converting
objects to BoT beforehand is done with the facetize command or
during import from a polygonal converter |
| 19:19.10 |
brlcad |
and yes, you
very likely will design everything in one file and construct
objects together based on their material compositions that need to
be differentiated |
| 19:19.31 |
brlcad |
the
principles of effective modeling go into proper modeling best
practices in more detail |
| 19:20.34 |
*** join/#brlcad Ralith
(~ralith@d142-058-175-170.wireless.sfu.ca) |
| 19:20.42 |
crazy_imp |
right now i
just want to use it for 2.5D modeling ;) |
| 19:44.37 |
CIA-52 |
BRL-CAD:
03starseeker * r43937 10/geomcore/trunk/tests/svntest/main.c:
Re-assemble ktank.g into a staging area. |
| 20:17.10 |
PrezKennedy |
brlcad, i
sent my brother a link to that picture you showed me |
| 21:03.18 |
*** join/#brlcad dli
(~dli@dyn-216-087.wireless.concordia.ca) |
| 21:14.03 |
CIA-52 |
BRL-CAD:
03bob1961 * r43938 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Minor mod to Ged::handle_data_move to not load data for
_pane. |
| 21:22.10 |
CIA-52 |
BRL-CAD:
03brlcad * r43939 10/brlcad/trunk/HACKING: add CADCAM insider to
our distribution list |
| 21:24.38 |
CIA-52 |
BRL-CAD:
03starseeker * r43940
10/geomcore/trunk/tests/svntest/main.c: |
| 21:24.38 |
CIA-52 |
BRL-CAD:
Handle naming (very) slightly better. Maybe need UUID to ensure
each connection |
| 21:24.38 |
CIA-52 |
BRL-CAD: can
get its own workspace for assembling geometry from checkouts for
return |
| 21:24.38 |
CIA-52 |
BRL-CAD:
shipment down the socket? Or do I need recursive checkout and
dbconcat based on |
| 21:24.39 |
CIA-52 |
BRL-CAD: comb
contents for sub-checkouts? (or both?) |
| 21:33.12 |
CIA-52 |
BRL-CAD:
03starseeker * r43941 10/geomcore/trunk/tests/svntest/main.c:
Supply the .g file as an argument, so we can try multiple files
without recompiling |
| 22:16.49 |
brlcad |
starseeker:
where do all of the palloc() allocations in src/librt/search.c get
freed? |
| 22:20.51 |
CIA-52 |
BRL-CAD:
03brlcad * r43942 10/brlcad/trunk/NEWS: per r43399, bob fixed a bug
in the wgl display manager where it was broken when drawing strings
with line breaks in them. now skips no pixels or rows. |
| 22:23.47 |
CIA-52 |
BRL-CAD:
03brlcad * r43943 10/brlcad/trunk/src/burst/grid.c: VINIT_ZERO
instead of constant init. |
| 22:24.40 |
starseeker |
brlcad: hmm -
I think it's up to the function that called db_search_formplan to
free it |
| 22:25.02 |
brlcad |
starseeker:
also plan on submitting the iwidgets ttk change upstream, any
reason not to? |
| 22:26.04 |
brlcad |
hm, so
search.c has a leak then? it doesn't free the dbplan that it
received |
| 22:26.12 |
brlcad |
looks like
it's some sort of nested allocation structure? |
| 22:26.45 |
starseeker |
brlcad: urm,
yeah it's possible search has a leak (may have always had it, for
that matter) |
| 22:27.06 |
starseeker |
brlcad: I can
try - don't know what the iwidgets take is on ttk |
| 22:27.15 |
brlcad |
if you have a
valgrind handy, that'd probably be a good one to slip in
sometime |
| 22:27.40 |
brlcad |
don't know
how much allocation that is, or if it's just a matter of free'ing
the main pointer |
| 22:28.45 |
brlcad |
it can't
introspect it at the libged level because it's a void*, all callers
can do is free that |
| 22:30.53 |
starseeker |
nods - I'm knee deep in subversion at the moment, but I'll
try to take a look) |
| 22:31.05 |
brlcad |
np |
| 22:35.11 |
brlcad |
yeah, looks
like the db_plan_t is a linked list |
| 22:45.07 |
brlcad |
starseeker:
huh, the find implementation that you used apparently never bothers
to free any memory |
| 22:45.22 |
starseeker |
oops |
| 22:45.23 |
brlcad |
undoubtedly
because the application quickly exits |
| 22:45.31 |
starseeker |
sorry about
that |
| 22:45.34 |
brlcad |
which is
fine, bad form but fine, for a binary |
| 22:45.45 |
brlcad |
problem for a
library, since the leak will accumulate |
| 22:45.52 |
brlcad |
not your
fault |
| 22:45.57 |
starseeker |
should have checked that <puts on programmer dunce
cap> |
| 22:55.33 |
CIA-52 |
BRL-CAD:
03starseeker * r43944 10/geomcore/trunk/tests/svntest/main.c: Add
some timing code in. Also try to get cute and call g_diff on the
reassembled file, but that's not perfect yet. |
| 22:58.03 |
CIA-52 |
BRL-CAD:
03brlcad * r43945 10/brlcad/trunk/ (include/raytrace.h
src/librt/search.c): |
| 22:58.03 |
CIA-52 |
BRL-CAD:
implement a db_search_freeplan() to go with the
db_search_formplan() function. |
| 22:58.03 |
CIA-52 |
BRL-CAD:
releases the allocated db_plan_t linked list structures acquired
during a given |
| 22:58.03 |
CIA-52 |
BRL-CAD: plan
formulation. looks like the original source code for find never
bothered |
| 22:58.03 |
CIA-52 |
BRL-CAD: to
release any memory, but we have to be more careful since we're in a
library. |
| 22:58.36 |
starseeker |
brlcad:
awesome, thanks for swatting that |
| 23:00.14 |
CIA-52 |
BRL-CAD:
03brlcad * r43946 10/brlcad/trunk/src/libged/search.c: call
db_search_free() to release our dbplan allocations. this should
prevent/reduce memory leakness across subsequent calls. untested
but testing now. |
| 23:00.38 |
brlcad |
nods |
| 23:03.49 |
CIA-52 |
BRL-CAD:
03brlcad * r43947 10/brlcad/trunk/NEWS: bob added pix2fb and
corresponding fb2pix commands to archer as a means to capture the
contents of the framebuffer to a pix image file. useful for
screenshots and image overlaying |
| 23:03.54 |
brlcad |
all commits
now reviewed, testing release |
| 23:05.46 |
starseeker |
brlcad: this
should be up your alley: http://pastebin.mozilla.org/1190541 |
| 23:07.16 |
brlcad |
starseeker:
what was the benefit for the ttk scrollbar change? |
| 23:07.36 |
brlcad |
looks |
| 23:08.17 |
brlcad |
hm,
odd |
| 23:08.25 |
brlcad |
shouldn't
take 38 seconds to reassemble |
| 23:09.24 |
brlcad |
cat **/*.g
only took 0.05 seconds or something from the shell, that's the base
time to scan all dirs, open all files, read/write all file
data |
| 23:09.38 |
brlcad |
(for
havoc) |
| 23:10.29 |
starseeker |
I'm using the
svn list function, which may introduce some overhead |
| 23:10.43 |
starseeker |
I don't think
I'm going to keep doing it with that function, it's not well suited
to this use |
| 23:11.09 |
starseeker |
is cat faster
than db_concat? |
| 23:11.21 |
brlcad |
not much
difference |
| 23:11.27 |
starseeker |
brlcad:
uniformity of appearance in archer |
| 23:11.46 |
starseeker |
we had
switched all our other scrollbars to ttk - the iwidget window was
the odd man out |
| 23:11.53 |
brlcad |
don't want to
just cat them, that's more to understand that it's not in the file
I/O at least |
| 23:12.02 |
brlcad |
dbconcat
makes sure there aren't name collisions |
| 23:12.15 |
brlcad |
that might
take a sec or two, but definitely not 38s |
| 23:12.18 |
starseeker |
nods |
| 23:12.31 |
brlcad |
okay, cool
wrt iwidgets |
| 23:12.37 |
brlcad |
was just
wondering what I should write them :) |
| 23:12.43 |
starseeker |
heh |
| 23:12.49 |
brlcad |
you make the
edits or bob or both? |
| 23:13.08 |
starseeker |
thinks back... that was me, but Bob told me where to
look |
| 23:13.18 |
starseeker |
and what to
remove to avoid some errors |
| 23:13.55 |
brlcad |
k |
| 23:14.12 |
starseeker |
has yet to integrate itcl into his working knowledge
base |
| 23:15.30 |
brlcad |
https://sourceforge.net/tracker/?func=detail&aid=3238914&group_id=13244&atid=383689 |
| 23:15.32 |
starseeker |
I was trying
to use svn's list command as a convenient way to get a list of the
files I needed to work with, but it's optimized to print out
results to the command line |
| 23:16.15 |
starseeker |
brlcad: cool,
thanks! |
| 23:16.44 |
brlcad |
http://www.devmaster.net/news/index.php?storyid=2663 |
| 23:16.46 |
starseeker |
bets they're surprised to see anyone still using
it |
| 23:17.21 |
brlcad |
bets they're not |
| 23:17.26 |
brlcad |
have you met
any of the tcl guys? :) |
| 23:17.31 |
starseeker |
hehe -
point |
| 23:18.16 |
starseeker |
had kind of gotten the impression that tcllib and tklib were
gaining more of a following |
| 23:18.27 |
starseeker |
http://www.tcl.tk/software/tcllib/ |
| 23:21.41 |
starseeker |
'course,
bwidget still gets used too... oh, well |
| 23:21.48 |
starseeker |
if it works
it works |
| 23:24.09 |
brlcad |
cool, looks
like I didn't bust search |
| 23:47.24 |
CIA-52 |
BRL-CAD:
03starseeker * r43948 10/geomcore/trunk/tests/svntest/main.c: Add a
note on what to do about replacing svn_client_list2 |
| 00:11.20 |
bhinesley |
what handles
the main mged exit "X" GUI button? |
| 00:13.33 |
bhinesley |
is done grepping :) |
| 00:13.58 |
starseeker |
heh - you
found it? |
| 00:14.10 |
bhinesley |
no, I've been
looking for a while |
| 00:14.21 |
bhinesley |
I figured it
was time to ask |
| 00:14.52 |
starseeker |
IIRC that
involves either signal handling or Tk bindings |
| 00:15.22 |
starseeker |
take a look
at the exit or quit commands |
| 00:15.55 |
bhinesley |
yeah, that's
what I've been doing. That, and the tcl files |
| 00:16.17 |
starseeker |
I'll have to
ask our expert tomorrow - I confess I don't know the details of
that right offhand |
| 00:16.40 |
starseeker |
Tcl/Tk is
kind of annoying in that respect - debugging usually involves lots
of print statements |
| 00:17.04 |
starseeker |
most of the
debuggers I know about are commercial :-( |
| 00:17.47 |
starseeker |
The only open
source one I know of is http://www.compassis.com/ramdebugger/ |
| 00:18.00 |
starseeker |
and I've
never actually gotten it working with MGED or Archer |
| 00:18.10 |
starseeker |
('course I
didn't try real hard) |
| 00:20.37 |
starseeker |
bhinesley:
oh, I'll bet this is it - look for instances of
WM_DELETE_WINDOW |
| 00:21.02 |
bhinesley |
I have
been |
| 00:21.33 |
starseeker |
http://www.tcl.tk/man/tcl8.5/TkCmd/wm.htm |
| 00:21.50 |
bhinesley |
I guess I'll
pursue that a little further |
| 00:21.58 |
starseeker |
the details
of the window distruction are handled by Tk, IIRC |
| 00:22.44 |
starseeker |
the "X"
button is actually the responsibility of the window
manager |
| 00:23.17 |
starseeker |
so when you
click on that "X", a WM_DELETE_WINDOW event (or something similar)
is generated |
| 00:23.57 |
starseeker |
supposes if he's suggesting Tcl/Tk projects he should make
another stab at figuring out how to hook up
RamDebugger... |
| 00:24.35 |
starseeker |
bhinesley:
are you running into problems with closing windows? |
| 00:25.26 |
bhinesley |
well, I was
trying to work on a bug |
| 00:25.37 |
starseeker |
ah, very good
:-) |
| 00:25.40 |
starseeker |
which
bug? |
| 00:26.42 |
bhinesley |
I believe
these two may be related, and not specific to Windows as it
appears: |
| 00:26.44 |
bhinesley |
https://sourceforge.net/tracker/?func=detail&aid=2278072&group_id=105292&atid=640802 |
| 00:26.44 |
bhinesley |
https://sourceforge.net/tracker/?func=detail&aid=1961127&group_id=105292&atid=640802 |
| 00:28.25 |
starseeker |
bhinesley:
note that at least the second one reports using a VERY old version
of BRL-CAD, so it might be worth trying to reproduce the problem
first |
| 00:28.59 |
bhinesley |
I am
experiencing a similar problem in Fedora |
| 00:29.07 |
starseeker |
ah,
really! |
| 00:29.12 |
bhinesley |
actually...
I've tested it in windows, too |
| 00:29.21 |
starseeker |
very
good |
| 00:29.53 |
starseeker |
brlcad may
have more insight on how all that's wired together |
| 00:30.41 |
starseeker |
bhinesley: a
possible suggestion would be to try to simplify the problem down -
if you create a tk window displaying a png file (say) and close it,
does it have the same problem? |
| 00:30.56 |
starseeker |
that might
indicate a Tk issue |
| 00:31.33 |
bhinesley |
hmm, okay, I
will try that in a little bit If I cannot isolate it to one of the
WM_DELETE_WINDOW's |
| 00:32.15 |
starseeker |
another
question is is it Tk specific? |
| 00:32.20 |
bhinesley |
the code for
the 'q', 'quit', and 'exit' commands works properly |
| 00:32.37 |
bhinesley |
so does
file-> exit (oddly) |
| 00:32.53 |
starseeker |
so one
possibility is to make sure the WM_DELETE_WINDOW calls are
triggering the same logic |
| 00:33.05 |
starseeker |
if you want
to try without Tk, do mged -c |
| 00:33.10 |
starseeker |
then pick
nu |
| 00:33.17 |
starseeker |
non-graphical
mged ;-) |
| 00:33.58 |
starseeker |
do that in
one terminal, close the terminal without quitting, the check the
status of the file from a different terminal |
| 00:34.41 |
brlcad |
bhinesley:
which platform are you on? |
| 00:34.59 |
brlcad |
ah, fedora ..
just catching up |
| 00:35.10 |
bhinesley |
:)
hello |
| 00:35.37 |
brlcad |
yeah, the
issue is cross platform -- I think our code that used to pick up
with window-close event from tk-land is no longer being handled or
at least no longer being handled sufficiently, so mged doesn't shut
down |
| 00:37.27 |
brlcad |
lets see if I
can get this right -- it's supposed to close the application if the
graphics window is closed, but keep mged running if only the
command window is closed |
| 00:38.06 |
starseeker |
blinks - really? is there a way to start up a new command
window from the GUI? |
| 00:38.28 |
brlcad |
I'm not real
keen on that behavior frankly, so it's fair game to change -- I
think it should either close both windows if you close either, or
not shut down mged until both windows are closed regardless of
which is closed first |
| 00:38.59 |
brlcad |
yeah, it
would make total sense the other way around since you can keep
reattaching new graphics windows |
| 00:39.17 |
brlcad |
I think the
old reasoning was that you'd shut down the command window and just
end up with a pure viewer |
| 00:39.41 |
starseeker |
votes for the other way |
| 00:39.52 |
brlcad |
that's fine,
but closing the graphics window shouldn't close the command
window.. |
| 00:39.55 |
starseeker |
the minimize
button is a powerful tool |
| 00:39.59 |
bhinesley |
if closing
the command window closes the graphics window, then perhaps the
command window should just be modal, and only allow closing from
the graphics window |
| 00:40.18 |
bhinesley |
wait, closing
the graphics window should leave the command window up? |
| 00:40.39 |
starseeker |
that would be
my vote. you can launch multiple graphics windows from the command
prompt |
| 00:40.56 |
bhinesley |
hm okay,
sounds backwards to me, but I'm from AutoCAD-world |
| 00:41.12 |
starseeker |
we're a
trifle command line centric :-P |
| 00:41.16 |
bhinesley |
yeah |
| 00:41.43 |
brlcad |
depends if
we're talking about what it "should" do, what it's "supposed" to
do, or what it "presently" does? :) |
| 00:42.19 |
starseeker |
Archer is
currently organized more around the traditional desktop app
paradigm, but we hadn't gotten to addressing desired behavior there
with respect to this question |
| 00:43.19 |
bhinesley |
well the
Archer command window is embedded |
| 00:43.28 |
brlcad |
if we ignore
"presently" and "supposed" behavior, what I'd want it to do is not
have either the graphics window or command window close button quit
the application unless it's the last window open |
| 00:43.30 |
starseeker |
bhinesley:
you can detach it :-) |
| 00:43.34 |
bhinesley |
ah I see now
:) |
| 00:44.14 |
bhinesley |
brlcad:
ok |
| 00:44.17 |
starseeker |
brlcad: yeah,
I was thinking that too - as long as you can launch display
managers from the command prompt, and command prompts from the
display, you're fully up as long as you have a window |
| 00:44.21 |
bhinesley |
I have to
leave guys, I'll bbl |
| 00:44.27 |
bhinesley |
thanks,
bye |
| 00:44.30 |
starseeker |
bhinesley:
bye! |
| 00:44.37 |
brlcad |
bhinesley:
something to keep in mind while testing is you can "attach X" as
many times as you like from the command window, you can also run
mged -c to get classic mode and then run "gui" to start up the
tcl/tk gui |
| 00:45.23 |
starseeker |
realizes he has to get up at 5am and heads
home... |
| 00:45.32 |
brlcad |
wee |
| 00:45.48 |
brlcad |
encounters compilation success! |
| 00:57.04 |
brlcad |
pretty
impressive mesh manipulation tool http://www.meshmixer.com/ |
| 01:02.53 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2622
10/wiki/Google_Summer_of_Code/Project_Ideas: de-emphasize an idea
of their own. want integrated code |
| 01:09.03 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2623
10/wiki/Google_Summer_of_Code/Project_Ideas: add programming
languages potentially involved |
| 01:09.56 |
*** join/#brlcad crazy_imp
(~mj@a89-183-78-5.net-htp.de) |
| 03:27.15 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2624
10/wiki/OGRE_Display_Manager: combine ogre and qt into the same
topic |
| 03:27.24 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Qt Display Manager]]":
merged in with the ogre idea |
| 03:27.50 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[OGRE Display Manager]] moved to [[Cross
Platform Display Manager]]: rename post-merge |
| 03:28.13 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2627
10/wiki/Google_Summer_of_Code/Project_Ideas: merged |
| 03:29.12 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Other Cross Platform Framebuffer]]
moved to [[Cross Platform Framebuffer]]: simplify |
| 03:36.46 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2630
10/wiki/Cross_Platform_Framebuffer: merge in qt |
| 03:37.06 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Qt Framebuffer]]": no longer
needed, merged with the more general cross-platform
tasker |
| 03:37.39 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2631
10/wiki/Google_Summer_of_Code/Project_Ideas: merged framebuffer
tasks, only need one |
| 03:44.24 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2632
10/wiki/Google_Summer_of_Code/Project_Ideas: recategorize the gui
projects |
| 03:48.44 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 04:09.56 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Cross Platform Display Manager]] moved
to [[New Cross-Platform 3D Display Manager]] |
| 04:10.13 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Cross Platform Framebuffer]] moved to
[[New Cross Platform 2D Framebuffer]] |
| 04:10.53 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[New Cross Platform 2D Framebuffer]]
moved to [[New Cross-Platform 2D Framebuffer]] |
| 04:12.33 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2639
10/wiki/Google_Summer_of_Code/Project_Ideas: make the task
descriptions sub-context information |
| 04:22.28 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:BRL-CAD
Priorities.png]]": Overview of our project scope, vision, mission,
and main priorities. |
| 04:28.25 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2641
10/wiki/Google_Summer_of_Code/Project_Ideas: link in project
priorities image |
| 04:43.42 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2642
10/wiki/Google_Summer_of_Code/Project_Ideas: bump up nurbs,
priority |
| 06:16.43 |
bhinesley |
brlcad: is
the project idea labeled "MGED to Archer Command Migration"
considered a priority? |
| 06:25.26 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 06:47.23 |
bhinesley |
I'm leaning
towards the MGED Sketch Editor Migration and Enhancement project,
as suggested by starseeker |
| 06:54.56 |
*** join/#brlcad bhinesley
(~bhinesley@99.125.83.101) |
| 07:19.50 |
bhinesley |
is there a
mentor assigned to the MGED Sketch Editor Migration and Enhancement
project? |
| 08:04.08 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 08:57.40 |
*** join/#brlcad piksi
(piksi@83.145.207.200) |
| 09:55.40 |
CIA-52 |
BRL-CAD:
0399.125.83.101 07http://brlcad.org
* r2643 10/wiki/User:Bhinesley: First profile post |
| 11:26.35 |
dloman |
Mernin
all |
| 11:30.14 |
dloman |
bah, blast it
all! I can't 'apply' to be a mentor cause their application
process is 'down' in preps for the launch of their new GUI later
this week. :/ |
| 11:40.40 |
*** part/#brlcad cjdevlin
(~devlin@d118-75-70-176.try.wideopenwest.com) |
| 12:22.03 |
brlcad |
dloman: it's
been that way since monday |
| 12:23.25 |
brlcad |
bhinesley:
note that I would consider that project "hard" so you should define
lots of small milestones |
| 12:24.14 |
brlcad |
we generally
perform group mentoring so that you're not reliant upon getting
answers from any one mentor |
| 12:24.34 |
brlcad |
bhinesley: as
the current code is all Tcl and archer is predominantly Tcl, I hope
you like Tcl :) |
| 12:25.40 |
brlcad |
that said,
the three people most likely able to help you or get answers to
your questions are going to be myself, starseeker, and "bob" who
you'll probably only be able to talk to via e-mail (but is the
foremost knowledgeable on all things Tcl) |
| 12:28.17 |
brlcad |
bhinesley:
ah, missed your first question -- I would consider the command
migration higher priority than sketch editing |
| 12:28.51 |
brlcad |
intends to spend a lot more time hashing out more ideas onto
the ideas list today |
| 12:39.31 |
dloman |
brlcad: can
the project lead send invites? ...or is that disabled
also? |
| 12:42.08 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2644
10/wiki/New_Cross-Platform_3D_Display_Manager: |
| 12:43.56 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2645
10/wiki/Google_Summer_of_Code/Project_Ideas: put the ideas into a
table for more concise readability |
| 12:48.48 |
CIA-52 |
BRL-CAD:
03davidloman * r43949 10/geomcore/trunk/ (2 files in 2 dirs):
Verbage change: 'Data' to 'Path' ...makes more better
cents. |
| 12:52.20 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2646
10/wiki/Google_Summer_of_Code/Project_Ideas: impact |
| 12:52.46 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2647
10/wiki/Google_Summer_of_Code/Project_Ideas: tablify |
| 12:54.09 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2648
10/wiki/Google_Summer_of_Code/Project_Ideas: Undo revision 2647 by
[[Special:Contributions/Sean|Sean]] ([[User
talk:Sean|Talk]]) |
| 12:55.43 |
dloman |
brlcad: are
there any file IO functions in the brlcad libs for reading/writing
plain ol files? |
| 12:59.31 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2649
10/wiki/Google_Summer_of_Code/Project_Ideas: tablify
redux |
| 13:04.18 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2650
10/wiki/New_Cross-Platform_3D_Display_Manager: |
| 13:05.36 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2651
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Graphical User
Interface (GUI) Projects */ |
| 13:05.56 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2652
10/wiki/New_Cross-Platform_2D_Framebuffer: new layout |
| 13:08.34 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2653
10/wiki/MGED_to_Archer_Command_Migration: new layout |
| 13:10.07 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2654
10/wiki/MGED_Sketch_Editor_Migration_and_Enhancement: new
layout |
| 13:11.42 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2655
10/wiki/New_Cross-Platform_3D_Display_Manager: ogre/qt as
refs |
| 13:12.26 |
brlcad |
dloman: also
disabled |
| 13:13.35 |
brlcad |
dloman: if
they're really "plain", then libc would be the most
appropriate |
| 13:14.14 |
brlcad |
otherwise we
have routines to read lines from files and map files to memory
buffers that are commonly used |
| 13:16.48 |
brlcad |
routines for
creating temp files, locating files, logging to a file,
reading/writing strings to files |
| 13:17.31 |
brlcad |
what are you
trying to do? |
| 13:19.38 |
dloman |
simple check
if a directory exists |
| 13:19.54 |
dloman |
wanted to use
a brlcad way to do it since there's a larger chance it will be
cross platform ;) |
| 13:20.05 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2656
10/wiki/Google_Summer_of_Code/Project_Ideas: bgcolor |
| 13:21.06 |
*** join/#brlcad Elrohir
(~kvirc@p5B14BA4E.dip.t-dialin.net) |
| 13:23.14 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2657
10/wiki/Google_Summer_of_Code/Project_Ideas: smaller priorites
link, push to top |
| 13:28.45 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2658
10/wiki/New_Cross-Platform_3D_Display_Manager: medium |
| 13:30.43 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2659
10/wiki/NURBS_Intersections: new layout, add references |
| 13:32.47 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2660
10/wiki/Google_Summer_of_Code/Project_Ideas: kiss |
| 13:34.50 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2661
10/wiki/NURBS_Tessellation: new layout, add references |
| 13:35.37 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2662
10/wiki/NURBS_Tessellation: redundant to repeat title |
| 13:36.05 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2663
10/wiki/NURBS_Intersections: dry |
| 13:36.23 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2664
10/wiki/New_Cross-Platform_3D_Display_Manager: dry |
| 13:38.01 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2665
10/wiki/CSG_to_NURBS_conversion: refs |
| 13:41.56 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2666
10/wiki/New_Cross-Platform_3D_Display_Manager: dry |
| 13:42.08 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2667
10/wiki/NURBS_Intersections: dry |
| 13:42.19 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2668
10/wiki/NURBS_Tessellation: dry |
| 13:43.59 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2669
10/wiki/Plate_Mode_NURBS_raytracing: code refs |
| 13:46.33 |
brlcad |
dloman:
search include/bu.h for "directory" .. there are two or three
specifically for that |
| 13:49.19 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2670
10/wiki/Google_Summer_of_Code/Project_Ideas: CSG is the operator,
not the entity type |
| 13:49.48 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[CSG to NURBS conversion]] moved to
[[Implicit to NURBS conversion]]: CSG is an operator, not a
type |
| 14:05.11 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2673
10/wiki/Google_Summer_of_Code/Project_Ideas: add a code refactoring
section, move refactoring tasks up into it |
| 14:05.31 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2674
10/wiki/New_Cross-Platform_2D_Framebuffer: dry |
| 14:05.53 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2675
10/wiki/MGED_to_Archer_Command_Migration: dry |
| 14:06.09 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2676
10/wiki/MGED_Sketch_Editor_Migration_and_Enhancement:
dry |
| 14:08.16 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2677
10/wiki/Ayam_Editor_Feature_Integration: new layout, add
refs |
| 14:09.10 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2678
10/wiki/New_Cross-Platform_2D_Framebuffer: consistency |
| 14:10.44 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2679
10/wiki/Analytical_Raytracing_Visualization: new layout,
refs |
| 14:13.21 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2680
10/wiki/Level_of_Detail_Wireframes: new layout, add
references |
| 14:14.17 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2681
10/wiki/BoT_Editing: new layout, add references |
| 14:15.52 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2682
10/wiki/NMG_Editing: new layout, add references |
| 14:16.23 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2683
10/wiki/NMG_Editing: /* Requirements */ |
| 14:17.31 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2684
10/wiki/Graph_layout_based_geometry_hierarchy_view: new layout, add
references |
| 14:18.07 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2685
10/wiki/Graph_layout_based_geometry_hierarchy_view: /* References
*/ |
| 14:29.42 |
dloman |
starseeker:
http://svnbook.red-bean.com/en/1.5/svn.developer.usingapi.html#svn.developer.usingapi.urlpath |
| 14:30.20 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2686
10/wiki/Google_Summer_of_Code/Project_Ideas: expand all of the gui
projects |
| 14:46.33 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2687
10/wiki/Google_Summer_of_Code/Project_Ideas: expand the rest of the
sections with table views, impact, and difficulty |
| 14:48.16 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2688
10/wiki/Google_Summer_of_Code/Project_Ideas: move step
up |
| 15:04.21 |
dloman |
brlcad:
thanks! |
| 15:05.35 |
bhinesley |
brlcad:
thanks for all of the info and new updates. I will reconsider my
project choice in the light of this. |
| 15:08.32 |
starseeker |
brlcad: has
subversion moved to the Apache license? |
| 15:09.56 |
starseeker |
http://svn.apache.org/repos/asf/subversion/trunk/LICENSE |
| 15:11.01 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2689
10/wiki/Google_Summer_of_Code/Project_Ideas: terse is so much more
informative here. combine title with description and reduce to no
more than two lines (on my wide screen) |
| 15:12.52 |
starseeker |
ah, crap -
yep
http://svn.apache.org/viewvc/subversion/trunk/LICENSE?revision=878444&view=markup |
| 15:14.35 |
starseeker |
yeah, this
was the old one:
http://svn.apache.org/viewvc/subversion/trunk/COPYING?revision=875073&view=markup&pathrev=878443 |
| 15:16.26 |
*** join/#brlcad dli
(~dli@dsl-173-248-203-45.acanac.net) |
| 15:16.33 |
dloman |
...so are we
incompatable with apache? |
| 15:19.06 |
starseeker |
http://www.apache.org/legal/3party.html |
| 15:19.33 |
CIA-52 |
BRL-CAD:
0399.125.83.101 07http://brlcad.org
* r2690 10/wiki/User:Bhinesley: reconsidering project
choice |
| 15:21.34 |
CIA-52 |
BRL-CAD:
0399.125.83.101 07http://brlcad.org
* r2691 10/wiki/User:Bhinesley: /* BRL-CAD Project Proposal */
remove superfluous blank line |
| 15:22.19 |
dloman |
starseeker:
that really reads for people trying to package stuff instde Apache
products... not the other way around. :/ |
| 15:25.59 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2692
10/wiki/Google_Summer_of_Code/Project_Ideas: another awesome
reduction |
| 15:36.46 |
starseeker |
dloman: yeah,
but it works both ways, unless I'm missing something |
| 15:36.55 |
starseeker |
(quite
possible) |
| 15:41.29 |
starseeker |
brlcad: I
don't suppose you have those scripts you used to benchmark breaking
up a file and reassembling it from the command line? Those might
be a good way to try fossil with just a little tweaking |
| 15:45.32 |
brlcad |
using apache
isn't a problem because we're not deriving or integrating, no more
compatible/incompatible than a proprietary system using an apache
product |
| 15:46.22 |
brlcad |
now that
they've switched from a bsd-like license to apache, that does
represent a problem to us in terms of integrating their code into
ours and making updates -- has to stay separate or we have to
change our license |
| 15:46.29 |
brlcad |
we can,
however, still use them |
| 15:46.43 |
brlcad |
they can't
use us is the bigger incompatibility |
| 15:47.03 |
dloman |
so... what
about the eventual plan to make a FS-G back end? |
| 15:47.19 |
dloman |
with the
current liscense... isn't that plan now out the window? |
| 15:47.20 |
starseeker |
brlcad: I
thought we had been avoiding apache licensed stuff to avoid
uncertainties about what code moved where... |
| 15:47.24 |
brlcad |
that's fine,
we just can't bundle their sources together with ours |
| 15:47.52 |
starseeker |
so I should
take the subversion directory out of geomcore |
| 15:48.26 |
brlcad |
if it's the
full sources, probably -- should be fine in a separate module with
svn:external set up |
| 15:49.04 |
brlcad |
source repo
isn't a big deal, it's any published/distributed source tarballs
where we'd have to be careful and not bundle them
together |
| 15:49.22 |
brlcad |
and that's
more just for perception, not necessarily legal
requirement |
| 15:49.39 |
dloman |
So, if we put
the svn code in a top level module licensed Apache, and make our
FS-G code there.... then that's okay? |
| 15:50.03 |
dloman |
so long as GS
and the FS-G 'products' are distinctly different... even though GS
requires the FS-G ? |
| 15:50.21 |
dloman |
(Just making
sure I understand things....) |
| 15:51.09 |
brlcad |
yeah, that
can work |
| 15:51.35 |
brlcad |
it's really
not that big a problem for us because apache is not viral like
gpl/lgpl in imposing requirements on code it's combined
with |
| 15:52.27 |
brlcad |
their license
merely applies to their code, so if we ever combined their code
with ours, the license terms would conflict (lgpl isn't a superset
of apache) |
| 15:53.36 |
brlcad |
our lgpl
can't apply to their code and their license can't apply to our
code |
| 15:53.43 |
dloman |
okay then, so
if our mythical fs-g module needs to have brlcad libraries as a
dependancy... that's okay since the LGPL won't impose any
restrictions on the fs-g's Apache license? |
| 15:54.15 |
brlcad |
so we can't
make a blanket statement if it was bundled into a source tarball to
say that "this collective work is lgpl" .. because we can't apply
lgpl to their code -- it would merely be two projects with two
licenses in one tarball |
| 15:55.05 |
brlcad |
it's "okay"
in the sense that we can develop that module, make it lgpl, use our
libs .. but it could never be integrated into svn
proper |
| 15:55.58 |
dloman |
I am pretty
sure the fs-g would need to be a *modified* version of svn, rather
than something that uses svn as a dep |
| 15:56.38 |
starseeker |
would tend to agree |
| 15:59.02 |
brlcad |
it'd probably
make more sense for fs-g to be apache licensed, and merely use
brl-cad's libs as an installed but not bundled
dependency |
| 15:59.31 |
brlcad |
as we'd be
deriving from their existing fs-fs or other code
anyways |
| 16:00.49 |
brlcad |
notes that many of these concerns become moot if we switched
to the BSD license :) |
| 16:01.06 |
dloman |
'we' being
brlcad code? |
| 16:02.54 |
brlcad |
all brl-cad
code, yes |
| 16:03.13 |
brlcad |
or
mit |
| 16:03.19 |
brlcad |
or apache 2.0
for the patent grant |
| 16:03.27 |
brlcad |
either way,
more flexibility |
| 16:03.56 |
starseeker |
brlcad: the
original motivator for LGPL was to ensure some reciprocity,
correct? |
| 16:05.25 |
brlcad |
and to abate
concerns at the time of any entity forking brl-cad, making
extensive valuable modifications, then trying to sell that derived
version back to the gov't |
| 16:05.54 |
brlcad |
thinks he might have picked up whatever ed
has |
| 16:06.01 |
starseeker |
doesn't that
risk still exist? |
| 16:06.05 |
starseeker |
uh-oh |
| 16:07.25 |
brlcad |
sure, it
still exists |
| 16:07.31 |
brlcad |
but it's not
nearly as much of a concern any more |
| 16:08.06 |
starseeker |
we've
established enough momentum now? |
| 16:08.20 |
brlcad |
after 7 years
open source, I think so |
| 16:08.42 |
brlcad |
at worse, the
risk is minimized as much as reasonably possible |
| 16:08.51 |
starseeker |
nods |
| 16:09.30 |
brlcad |
moreover, the
benefits of allowing unencumbered use, whether commercial or not,
would still benefit the brl-cad open source community and gov't
regardless |
| 16:10.12 |
brlcad |
even if their
changes were never released or integrated, it would be more .g
files floating around, brl-cad libraries being used,
etc |
| 16:10.18 |
brlcad |
anyways, not
a problem that needs solving today |
| 16:10.23 |
starseeker |
right |
| 16:47.47 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2693
10/wiki/Google_Summer_of_Code/Project_Ideas: more
awesome |
| 16:51.21 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2694
10/wiki/General_Tree_Walker: new layout, add references |
| 16:52.20 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2695
10/wiki/Rework_of_libbu/libbn_to_not_require_Tcl: new layout, add
references |
| 16:55.18 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2696
10/wiki/Complete_bu_image/libicv_and_redo_all_pix_tools_to_use_it:
new layout, add references |
| 16:55.58 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Complete bu image/libicv and redo all
pix tools to use it]] moved to [[Consolidate image
processing]] |
| 16:57.09 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2699
10/wiki/Google_Summer_of_Code/Project_Ideas: new name |
| 16:57.50 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2700
10/wiki/Consolidate_image_processing: |
| 17:02.18 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[MGED Sketch Editor Migration and
Enhancement]] moved to [[2D Sketch Editor]] |
| 17:04.36 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Analytical Raytracing Visualization]]
moved to [[GUI Integration of Analysis Tools]] |
| 17:05.02 |
starseeker |
brlcad: wow
that looks nice |
| 17:05.09 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Graph layout based geometry hierarchy
view]] moved to [[Visualizing Constructive Solid Geometry
(CSG)]] |
| 17:05.27 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2707
10/wiki/Google_Summer_of_Code/Project_Ideas: new names |
| 17:07.53 |
``Erik |
hm, apache
license 2.0 is compatible with GPLv3, if that means
anything |
| 17:08.09 |
starseeker |
``Erik: yeah,
I think it primarily has to do with the patent stuff |
| 17:08.53 |
starseeker |
sucky that
some projects are LGPL2 only, some are LGPL3 only - makes me
appreciate the simplicity of BSD/MIT |
| 17:09.20 |
starseeker |
I finally
(belatedly) contacted the NURBS++ author, but wasn't able to sell
him on BSD |
| 17:11.14 |
``Erik |
the fork risk
is probably greatly diminished, there was a core competency
migration from the dangerous group O.o :D |
| 17:12.01 |
starseeker |
hehe |
| 17:12.31 |
starseeker |
'course,
NURBS++ was LGPL2 with the later version clause, so that's somewhat
better |
| 17:12.36 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2708
10/wiki/Google_Summer_of_Code/Project_Ideas: another one bites the
dust |
| 17:12.38 |
starseeker |
s/was/is |
| 17:14.12 |
starseeker |
wish I could
have found him before the takeover request went through, but only
dug up his contact info months later |
| 17:14.22 |
starseeker |
oh, well -
not like there was much going on with it |
| 17:14.56 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2709
10/wiki/Geometry_Conversion_Library: new layout, add
references |
| 17:16.29 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2710
10/wiki/Voxelize: new layout, add references |
| 17:17.47 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43950 10/geomcore/trunk/src/GS/DataManager.cxx:
getData changed to getPath |
| 17:20.42 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2711
10/wiki/IGES_import_improvements: |
| 17:21.50 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2712
10/wiki/STEP_Libraries: new layout, add references |
| 17:22.01 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2713
10/wiki/IGES_import_improvements: ws |
| 17:22.24 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2714
10/wiki/IGES_import_improvements: |
| 17:36.21 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2715
10/wiki/Google_Summer_of_Code/Project_Ideas: more awesome
expansion |
| 17:36.49 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2716
10/wiki/GED_Transactions: new layout, add references |
| 17:37.49 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2717
10/wiki/Add_exec_option_to_search: new layout, add
references |
| 17:38.54 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2718
10/wiki/Geometry_Selection_Functionality: new layout, add
references |
| 17:40.45 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2719
10/wiki/Geometric_Constraint_Solver: new layout, add
references |
| 17:43.38 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2720
10/wiki/Space_Partitioning_for_Tessellation: new layout, add
references |
| 17:46.33 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2721
10/wiki/Libsvn_within_Geometry_Database_Format: new layout, add
references |
| 17:56.39 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2722
10/wiki/Google_Summer_of_Code/Project_Ideas: final awesome
restructure |
| 17:57.43 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2723
10/wiki/Shader_Enhancements: new layout, add references |
| 17:58.36 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2724
10/wiki/Shader_Enhancements: refs |
| 17:59.40 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2725
10/wiki/Material_and_Shader_Objects: new layout, add
references |
| 18:01.21 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2726
10/wiki/NMG_Raytracing_Performance_Improvement: new layout, add
references |
| 18:02.25 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2727
10/wiki/Generalized_abstracted_spacial_partitioning_capability: new
layout, add references |
| 18:03.59 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2728
10/wiki/High_Dynamic_Range_Support: new layout, add
references |
| 18:05.23 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2729
10/wiki/Vector_output_from_raytracing: new layout, add
references |
| 18:07.01 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2730
10/wiki/Analysis_Library: new layout, add references |
| 18:08.01 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2731
10/wiki/Analysis_Library: /* References */ |
| 18:11.44 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2733
10/wiki/Google_Summer_of_Code/Project_Ideas: overlap tool is
geometry processing |
| 18:12.55 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2734
10/wiki/Overlap_tool: new layout, add references |
| 18:13.31 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2735
10/wiki/Google_Summer_of_Code/Project_Ideas: ws |
| 18:25.22 |
CIA-52 |
BRL-CAD:
03davidloman * r43951 10/geomcore/trunk/ (3 files in 2 dirs): Move
DataManager Initialization over to the DataManager
itself. |
| 18:28.59 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.129.170) |
| 18:29.08 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:30.12 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 18:40.16 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2736
10/wiki/Google_Summer_of_Code/Project_Ideas: add
mentors |
| 18:40.50 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2737
10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 18:40.58 |
brlcad |
woot,
done |
| 18:42.29 |
brlcad |
"the patent
thing" is actually what makes it incompat with gpl/lgpl v2, adds a
new requirement which those licenses say you can't do |
| 18:42.38 |
dloman |
Nice! Im an
'expert modeler' ! |
| 18:42.43 |
dloman |
nice page btw
brlcad ! |
| 18:42.52 |
brlcad |
also why gpl
v2 and v3 are only compat in one direction |
| 18:42.58 |
brlcad |
thanks
dloman |
| 18:43.21 |
brlcad |
starseeker
and ``Erik did most of the hard work writing up all those
topics |
| 18:44.30 |
brlcad |
felt kinda dirty putting 'guru' after NMG, but the poor guy
needed something there |
| 18:45.04 |
CIA-52 |
BRL-CAD:
03starseeker * r43952
10/geomcore/trunk/tests/svntest/main.c: |
| 18:45.05 |
CIA-52 |
BRL-CAD:
Start major reworking of our approach to svn - use lower level api.
Whole new |
| 18:45.05 |
CIA-52 |
BRL-CAD:
learning curve here, so everything that was previously working
isn't - got it to |
| 18:45.05 |
CIA-52 |
BRL-CAD:
compile, so checkpointing. Also gut all the old svn client code we
were using |
| 18:45.05 |
CIA-52 |
BRL-CAD: to
avoid license questions - figure out how to use the APIs from
scratch with |
| 18:45.05 |
CIA-52 |
BRL-CAD:
examples. |
| 18:45.38 |
brlcad |
heh |
| 18:46.04 |
starseeker |
one step
forward, two steps back... sigh |
| 18:46.42 |
dloman |
and turn your
self around... that's what its all about! |
| 18:47.10 |
starseeker |
oh, I'm
alredy dizzy |
| 18:47.39 |
brlcad |
paula abdul
loves you |
| 18:48.31 |
starseeker |
aaand another
reference sails right over my head... :-P |
| 18:48.57 |
brlcad |
heh |
| 18:49.00 |
brlcad |
opposites
attract! |
| 18:49.13 |
brlcad |
http://www.youtube.com/watch?v=xweiQukBM_k |
| 18:49.25 |
starseeker |
safe for
work? |
| 18:49.29 |
brlcad |
just a
song |
| 18:51.09 |
brlcad |
ahh, good ol'
80's music videos |
| 18:53.41 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43953
10/geomcore/trunk/src/GS/testclient/gstestclient.c: start cleaning
up and simplying things |
| 18:56.30 |
``Erik |
is there any
reason to be pushing strings across the pipe as unicode16 instead
of ascii? |
| 18:57.00 |
starseeker |
I was doing
that because of the definition of the string type on the
wiki |
| 18:57.04 |
starseeker |
or were you
asking dloman ? |
| 18:57.10 |
``Erik |
open
question |
| 18:57.20 |
dloman |
i down graded
them to 1 byte char strings.... last week i think. |
| 18:57.21 |
``Erik |
suspects it's a qstring thing |
| 18:57.38 |
dloman |
qstring and
java thing |
| 18:57.54 |
starseeker |
http://brlcad.org/wiki/GSNet_String |
| 18:58.06 |
``Erik |
java has some
dandy unicode16/ascii conversion stuff already in it |
| 18:58.25 |
dloman |
starseeker:
thats out of date :( |
| 18:59.26 |
CIA-52 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2738 10/wiki/GSNet_String: |
| 18:59.26 |
starseeker |
oh - are we
all agreed on GS, GE and GUI for toplevel modules? |
| 18:59.49 |
dloman |
shakes magic 8ball. |
| 18:59.59 |
dloman |
.....Sounds
good starseeker! |
| 19:00.26 |
starseeker |
magic8
ball... haven't seen one of those for many years |
| 19:02.45 |
CIA-52 |
BRL-CAD:
03davidloman * r43954 10/geomcore/trunk/ (include/FileDataSource.h
src/GS/FileDataSource.cxx): Stub in init routine for
FileDataSource |
| 19:06.23 |
CIA-52 |
BRL-CAD:
03davidloman * r43955 10/rt^3/trunk/include/ (70 files): Dump all
the old GS header files. No longer needed here. |
| 19:14.26 |
CIA-52 |
BRL-CAD:
03starseeker * r43956 10/geomcore/trunk/tests/svntest/main.c: Oh
yeah, need to init apr and friends. |
| 19:21.21 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2739
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Geometry Conversion
Projects */ |
| 19:25.32 |
CIA-52 |
BRL-CAD:
03starseeker * r43957 10/geomcore/trunk/tests/svntest/main.c:
Somewhat surprisingly, this approach to subdirectory addition works
too. Files still aren't right |
| 19:27.27 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2740
10/wiki/Google_Summer_of_Code/Project_Ideas: add a couple more STEP
tasks |
| 19:28.06 |
CIA-52 |
BRL-CAD:
03starseeker * r43958 10/geomcore/trunk/tests/svntest/main.c: And
we can create empty files. |
| 19:28.45 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2741
10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 19:35.59 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2742
10/wiki/STEP_exporter: New page: STEP is the current standard for
exchange of CAD data between different software packages. BRL-CAD
makes use of the NIST STEP Class Libraries code to support its
step-g converter, but we ... |
| 19:40.22 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2743
10/wiki/STEP_importer_improvements: New page: STEP is the current
standard for exchange of CAD data between different software
packages. BRL-CAD makes use of the NIST STEP Class Libraries code
to support its step-g converter, but th... |
| 19:42.45 |
*** join/#brlcad hyarion
(c05ben@peppar.cs.umu.se) |
| 20:09.58 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43959 10/geomcore/trunk/src/GS/testclient/
(CMakeLists.txt gstestclient.c): complete rewrite. (hey, it
works) |
| 20:11.59 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2744
10/wiki/Benchmark_Performance_Database: initial benchmark web
interface idea |
| 20:17.14 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2745
10/wiki/Materials_Database: New page: BRL-CAD uses simple material
properties, presently limited to density, for calculating weights,
moments of inertia and other geometric analyses. There is presently
no centralized reposito... |
| 20:18.23 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43960
10/geomcore/trunk/src/GS/testclient/gstestclient.c: cleanup the
socket |
| 20:19.19 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2746
10/wiki/Materials_Database: |
| 20:19.55 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2747
10/wiki/Google_Summer_of_Code/Project_Ideas: add a couple web tasks
with discouraging wording |
| 20:28.02 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2748
10/wiki/Fix_Bugs: initial bugs idea |
| 20:35.12 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43961
10/geomcore/trunk/src/GS/testclient/gstestclient.c: parse and print
response packet |
| 20:37.06 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2749
10/wiki/Code_Reduction: code reduction |
| 20:37.16 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2750
10/wiki/Google_Summer_of_Code/Project_Ideas: add code
reduction |
| 20:38.20 |
brlcad |
awesome, up
to 42 project ideas now -- 47 if you count the other tool projects
.. I think that's sufficient now :) |
| 20:38.33 |
brlcad |
has the new
catch-all ones too |
| 20:39.59 |
brlcad |
starseeker:
I'd prefer lowercase for top-level modules just for consistency
(probably less error-prone for newbies), but not strong
preference |
| 20:41.07 |
brlcad |
16 byte
strings across the wire will be 50% waste 99.9% of the time
:) |
| 20:42.07 |
brlcad |
don't know of
anyone even attempting to deal with 16-bit stringery at the
moment |
| 20:42.23 |
brlcad |
maybe catia,
but then they're french |
| 21:02.40 |
starseeker |
brlcad: sure,
lower is fine |
| 21:06.11 |
starseeker |
ouch - Apple
is now going to avoid Samba because of GPLv3 |
| 21:07.40 |
starseeker |
brlcad: the
dynamic range one... IIRC (and I may not) another point there was
to generate output images that fit better into image processing
pipelines that make use of HDR |
| 21:08.23 |
starseeker |
not that that
changes priority or anything, but I think that may have been the
envisioned immediate practical consequence |
| 21:08.34 |
starseeker |
(HDR displays
would be neat though...) |
| 21:08.59 |
``Erik |
or like CMYK
or YUV for printing or something |
| 21:46.05 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2751
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Mentors
*/ |
| 21:48.06 |
brlcad |
starseeker:
the labels aren't really weighted well |
| 21:48.49 |
brlcad |
in the big
scheme of things with the dozens of other "high" priority high
impact topics on there, I think HDR is still *relatively* low
impact yet it'd still be useful and cool to have |
| 21:48.54 |
brlcad |
immediately
useful even |
| 21:49.09 |
brlcad |
the
description can be reworded, didn't mean to downplay it if it comes
off that way |
| 21:49.33 |
starseeker |
nah, it's
cool |
| 21:49.46 |
starseeker |
don't know
how much role it will play in submissions anyway |
| 21:49.54 |
brlcad |
as for the
high/medium/low, I was actually considering a simple two-level
instead of three |
| 21:50.24 |
brlcad |
HIGH and LOW
do sound like they're being discouraged, though, when it's really
meant to just emphasize the high ones |
| 21:50.26 |
starseeker |
baby-bottle
and skull+crossbones? :-P |
| 21:50.33 |
brlcad |
heh |
| 21:51.06 |
brlcad |
maybe BIG and
BIGGER |
| 21:52.04 |
brlcad |
ha, winner ..
BIG and HUGE |
| 21:55.03 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2752
10/wiki/Google_Summer_of_Code/Project_Ideas: BIG AND
BIGGEREST! |
| 21:58.08 |
starseeker |
wangs his head on the wall... why can't I get file content
into files??? auugh |
| 22:30.03 |
*** join/#brlcad dli
(~dli@dyn-217-029.wireless.concordia.ca) |
| 22:35.21 |
CIA-52 |
BRL-CAD:
03starseeker * r43962 10/geomcore/trunk/tests/svntest/main.c: OK,
we're getting non-zero sized files now. No way to know if they're
anything like correct yet. |
| 23:53.14 |
CIA-52 |
BRL-CAD:
03starseeker * r43963 10/geomcore/trunk/tests/svntest/
(CMakeLists.txt main.c): start working out how to reassemble using
the lower level api... |
| 00:52.30 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 01:10.34 |
*** join/#brlcad crazy_imp
(~mj@a89-182-14-228.net-htp.de) |
| 02:33.28 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 02:58.06 |
*** join/#brlcad IriX64
(~IriX64@bas2-sudbury98-1096601295.dsl.bell.ca) |
| 03:00.46 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
| 03:12.43 |
*** join/#brlcad dli_
(~dli@dsl-173-248-203-45.acanac.net) |
| 04:09.01 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 06:02.25 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 06:02.25 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:02.19 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 10:10.31 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 12:29.25 |
CIA-52 |
BRL-CAD:
03Rossberg 07http://brlcad.org *
r2753 10/wiki/Google_Summer_of_Code/Project_Ideas: corrected my irc
name |
| 13:26.07 |
CIA-52 |
BRL-CAD:
0368.34.98.23 07http://brlcad.org *
r2754 10/wiki/Google_Summer_of_Code/Project_Ideas: group method of
communicatio together |
| 13:41.06 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2755
10/wiki/Google_Summer_of_Code/Project_Ideas: extra info |
| 13:53.19 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 13:53.19 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 15:09.55 |
*** join/#brlcad AbhijitKane7
(~Abhijit@111.93.5.194) |
| 15:22.52 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 15:23.27 |
AbhijitKane |
Hi, I intend
to apply to BRLCAD thru the GSOC program, and work for the
"Materials Database" project. |
| 15:23.37 |
AbhijitKane |
Is there any
specific mentor associated with the project? |
| 15:32.13 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 15:38.33 |
brlcad |
hi
AbhijitKane, what draws you to that particular project? |
| 15:38.47 |
brlcad |
hello
Zaebos |
| 15:39.02 |
brlcad |
saw your
message on the mailing list as well |
| 15:40.10 |
AbhijitKane |
I've always
been interested in web-related projects, and I think that a web
interface would help a lot of people access the data that you
have. |
| 15:40.31 |
Zaebos |
hi |
| 15:40.32 |
brlcad |
AbhijitKane:
what are your thoughts for that project? |
| 15:40.41 |
brlcad |
what do you
envision it entailing? |
| 15:41.46 |
AbhijitKane |
actually,
thats what I wanted to clear |
| 15:41.52 |
*** part/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 15:42.11 |
AbhijitKane |
At first
glance, i thought it was a simple front-end to query the
database |
| 15:43.03 |
AbhijitKane |
but I'm not
sure what else is required to be done |
| 15:43.42 |
brlcad |
how much do
you know about materials? |
| 15:43.49 |
brlcad |
and material
properties |
| 15:44.15 |
brlcad |
it is a
simple front-end to the database, but it also entails establishing
the database |
| 15:44.28 |
brlcad |
setting up
the schema |
| 15:44.58 |
AbhijitKane |
Not much.
I've just done one course related to material properties - I
haven't got any other exposure to the subject |
| 15:45.02 |
brlcad |
there was
someone that actually worked on this project five or so years ago,
but they never finished |
| 15:45.15 |
brlcad |
made great
progress, but never got to production status |
| 15:45.34 |
AbhijitKane |
Oh, is that
the "proof-of-concept web work of relevance" mentioned on the
website? |
| 15:45.40 |
brlcad |
yes |
| 15:46.19 |
brlcad |
so your
project could either leverage all that previous work as a starting
point or you could start from scratch |
| 15:47.24 |
brlcad |
if you start
from scratch, you'll need to do some basic research on materials
science, so our database captures common properties
sufficiently |
| 15:47.24 |
AbhijitKane |
Is the
database schema / website source code included in the BRLCAD
code? |
| 15:47.29 |
brlcad |
it is
not |
| 15:47.52 |
brlcad |
I'll have to
dig around for it in our archives -- it was quite a while
ago |
| 15:48.10 |
brlcad |
it's
available (somewhere), it'll just take a little while to find
it |
| 15:48.26 |
brlcad |
regardless --
it was a homegrown setup |
| 15:48.37 |
brlcad |
how were you
envisioning the implementation? |
| 15:49.11 |
brlcad |
using a
content management system, rapid dev toolkits, or also from
scratch? something else? |
| 15:49.48 |
AbhijitKane |
I have the
most experience with MySQL. I also have a fair idea about UML, so
if there are UML diagrams that I could look at, it would be
advantageous. |
| 15:50.24 |
AbhijitKane |
Not a CMS,
but I could take a look at the old code or work from
scratch |
| 15:50.34 |
brlcad |
heh, no
UML |
| 15:51.41 |
brlcad |
personally
(and others may have different opinions), I'd prefer that IFF you
are not going to use any web toolkits or CMS that you then leverage
the old code and pick up where they left off |
| 15:51.55 |
brlcad |
otherwise
there'd be no difference if it was all just from scratch again,
effort wasted |
| 15:52.09 |
brlcad |
rather,
duplicate effort .. not necessarily wasted |
| 15:52.19 |
AbhijitKane |
i
agree |
| 15:52.55 |
brlcad |
have you ever
used a revision control system before for web
development? |
| 15:53.10 |
AbhijitKane |
I used
subversion for a project that I did last year |
| 15:53.26 |
brlcad |
it'll be
required for this, as will creating a simple patch showing your
ability |
| 15:53.33 |
brlcad |
oh? |
| 15:53.36 |
brlcad |
who'd you
work with? |
| 15:53.56 |
AbhijitKane |
It wasn't a
part of gsoc. I was interning with a start-up |
| 15:55.14 |
brlcad |
anything
on-line that we can take a look at? |
| 15:56.33 |
brlcad |
AbhijitKane:
also, what got you interested in BRL-CAD? |
| 15:56.41 |
AbhijitKane |
I helped with
this: http://www.vindev.net/phototourv2/public/apps/html5 |
| 15:56.51 |
AbhijitKane |
its an HTML5
implementation of www.phototour.in |
| 15:56.59 |
brlcad |
be sure to
put that in your application |
| 15:57.19 |
AbhijitKane |
ok |
| 15:58.16 |
AbhijitKane |
I was just
looking through all the organisations that wanted back-end web
development, and BRL-CAD was one of the few |
| 16:00.05 |
brlcad |
nods |
| 16:01.05 |
AbhijitKane |
Is there any
reading material related to material properties that you can
recommend? |
| 16:02.05 |
brlcad |
there are
some references on the detail page |
| 16:02.34 |
brlcad |
there are
several online commercial material database websites that you could
look through for comparison/reference, see what all they
include |
| 16:02.48 |
AbhijitKane |
ok |
| 16:02.52 |
brlcad |
few google
searches will lead you to two or three of them |
| 16:03.56 |
AbhijitKane |
i'll take a
look at them |
| 16:04.14 |
AbhijitKane |
I have to go
- be back in an hour or so |
| 16:04.22 |
brlcad |
nods |
| 16:04.24 |
brlcad |
cya
later! |
| 16:04.28 |
AbhijitKane |
bye! |
| 16:04.45 |
brlcad |
can't wait to
see the proposal |
| 16:07.19 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 16:09.59 |
adityag |
i am pretty
fluent in C & web related projects. i would love to contribute
if im guided by some one experienced |
| 16:10.44 |
adityag |
brlcad : i
would love to work here |
| 16:11.11 |
brlcad |
adityag:
howdy and welcome |
| 16:11.34 |
brlcad |
the C
background is great, we have tons of C projects ;) |
| 16:11.49 |
brlcad |
suggest you
scan down through our project ideas page and see if anything
catches your interest |
| 16:11.59 |
adityag |
in fact, i
won a national level C/C++ programming contest |
| 16:12.10 |
brlcad |
which nation?
:) |
| 16:14.47 |
*** join/#brlcad dli
(~dli@dsl-173-248-203-45.acanac.net) |
| 16:15.04 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 16:16.26 |
brlcad |
adityag1:
connection problems? :) |
| 16:16.40 |
brlcad |
waves hello to dli |
| 16:17.02 |
dli |
brlcad,
hi |
| 16:18.11 |
dli |
brlcad, I am
trying to become a gentoo developer to update the brlcad package,
but they are very slow there |
| 16:18.24 |
brlcad |
dli:
awesome! |
| 16:18.31 |
starseeker |
dli: my
sympathies |
| 16:18.33 |
brlcad |
I was just
about to ask if you were you |
| 16:19.07 |
brlcad |
a Lin Di just
messaged the mailing list, thought they might have used your irc
nick :) |
| 16:20.06 |
dli |
brlcad,
couldn't be me :( my family name is Li :( |
| 16:22.09 |
dli |
brlcad, the
gentoo story, andreas Huettel told me he would be my mentor for
gentoo-scicence, but I have to wait for him to start the recuiting
process |
| 16:22.32 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 16:22.52 |
starseeker |
adityag:
welcome back :-) |
| 16:24.22 |
brlcad |
his peers
don't like him |
| 16:24.48 |
adityag |
brlcad
starseeker: connection problem + dinner time |
| 16:25.24 |
brlcad |
dli: that's
great news either way, you're well on your way |
| 16:25.37 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 16:25.43 |
brlcad |
adityag:
understandable |
| 16:26.17 |
brlcad |
we're here
all day -- we don't expect immediate and perpetual
connectivity/responses, neither should you ;) |
| 16:26.57 |
adityag |
yes
cool |
| 16:29.02 |
dli |
brlcad, for
me to test the intersection program (from previous GSoC?), is it
possible for me to skip building the whole brlcad package. my
gentoo is on a slow core 2 thinkpad, got to speed up the
process |
| 16:30.58 |
brlcad |
dli: you can
build by hand, you just cd to the dir and build from
there |
| 16:32.18 |
brlcad |
"make
depends" and "make" in src/proc-db should get you built |
| 16:34.49 |
dli |
brlcad,
maybe, I should write some cmake or autotools for the folder
first |
| 16:35.45 |
starseeker |
dli: it
shouldn't be necessary |
| 16:36.10 |
brlcad |
dli: what's
the problem? |
| 16:36.24 |
brlcad |
cmake branch
should work as should trunk's autotools build |
| 16:37.09 |
brlcad |
adityag: so
if you didn't see my question, which nation? :) |
| 16:38.06 |
dli |
brlcad, want
to limit the range of code base for me to work on |
| 16:39.56 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 16:40.40 |
starseeker |
dli: just cd
into the directory with the code in question and type make there -
it should only build what is needed |
| 16:40.41 |
adityag |
brlcad:
India.... & u ? |
| 16:41.24 |
adityag |
brlcad: for
more info about me http://aditya.ritzsoftec.com |
| 16:41.57 |
dli |
starseeker,
let me play with it more |
| 16:42.11 |
brlcad |
adityag:
maryland (usa) |
| 16:45.25 |
brlcad |
adityag:
thanks (also good to include in your proposal) |
| 16:45.38 |
brlcad |
adityag: what
platform do you work on? |
| 16:46.42 |
adityag |
<PROTECTED> |
| 16:48.02 |
brlcad |
k |
| 16:48.11 |
brlcad |
what is
slmbk? |
| 16:50.01 |
adityag |
its a social
network site which i had lauched in 2008 which revolves around
filling scrap/slam books for students |
| 16:54.19 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 16:54.46 |
adityag1 |
brlcad: i
tried working on a few start ups.. i failed every time, so i want
to contribute now |
| 16:56.15 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 16:59.00 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 17:01.27 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 17:02.30 |
brlcad |
adityag: okay
thanks! |
| 17:03.44 |
AbhijitKane |
brlcad: hi
again |
| 17:04.09 |
AbhijitKane |
went thrrough
a few material database sites - most of them focus on their
querying abilities |
| 17:04.24 |
AbhijitKane |
ranges for
value of various properties and things like that |
| 17:05.23 |
AbhijitKane |
:adityag: hi!
where are you from? |
| 17:06.57 |
brlcad |
AbhijitKane:
great |
| 17:07.13 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 17:09.06 |
brlcad |
AbhijitKane:
it'd be great to include a rough mock-up of the layout with your
application -- wouldnt' have to be anything too complex or fancy
but it would give the reviewers a sense of the project
goal |
| 17:09.55 |
AbhijitKane |
ok
sure |
| 17:10.21 |
AbhijitKane |
i don't know
if im supposed to ask - but is adityag applying for the same
project? |
| 17:10.35 |
brlcad |
no idea
:) |
| 17:10.42 |
brlcad |
sounded like
he was interested in a C project |
| 17:10.49 |
AbhijitKane |
ohk |
| 17:11.03 |
adityag |
im interested
in any cool projects |
| 17:11.33 |
adityag |
brlcad :
suggest me the coolest idea from brlcad's list |
| 17:12.17 |
brlcad |
helps to
include the '-' when referring to the project and without when
referring to me .. otherwise just gets confusing ;) |
| 17:12.36 |
brlcad |
hm, depends
how you defined 'cool' |
| 17:13.24 |
brlcad |
the first one
on the list, NURBS surface-surface intersection calculations is
pretty freaking cool, but really frickin' hard too |
| 17:13.43 |
adityag |
:-D. Whats
the best idea about brl-cad ? |
| 17:13.48 |
brlcad |
otherwise,
what's cool to me isn't necessarily cool to you :) |
| 17:13.58 |
adityag |
let me check
out |
| 17:14.39 |
brlcad |
spend an hour
or so and go down the list |
| 17:14.50 |
brlcad |
if the short
summary doesn't catch your attention, move on to the next
one |
| 17:15.35 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 17:16.09 |
brlcad |
might have
missed me saying "spend an hour of so and go down the list, if the
short summary doesn't catch your attention, move on to the next
one.." |
| 17:16.22 |
brlcad |
should have a
great idea by the end which two or three sound the most
interesting |
| 17:16.34 |
brlcad |
rather you
pick something YOU like, than it be something I like |
| 17:17.06 |
brlcad |
even if it's
something simple sounding like cleanup or something complex like
nurbs |
| 17:17.25 |
adityag |
ok
cool |
| 17:18.08 |
brlcad |
we don't
really care what you work on -- we want you to become a brl-cad
developer merely enjoying what you work on, so maybe you'll keep
working on it |
| 17:19.20 |
CIA-52 |
BRL-CAD:
03starseeker * r43964 10/geomcore/trunk/tests/svntest/main.c: OK,
get as far as printing out what's in the toplevel
directory... |
| 17:26.29 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 17:37.38 |
*** join/#brlcad Ralith
(~ralith@d142-058-094-084.wireless.sfu.ca) |
| 17:38.28 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 17:41.32 |
adityag |
brlcad : can
i get my couple of my friends to work with me on Code Refactoring,
GUI, Web Developments ? we can work on others too but im pretty
sure that we can work on the mentioned topics. |
| 17:47.42 |
*** join/#brlcad Ralith
(~ralith@d142-058-094-084.wireless.sfu.ca) |
| 17:58.07 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 18:31.53 |
*** join/#brlcad Ralith
(~ralith@d142-058-094-084.wireless.sfu.ca) |
| 18:45.45 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43965
10/geomcore/trunk/src/GS/testclient/gstestclient.c: try to send a
disconnect request |
| 18:50.37 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43966
10/geomcore/trunk/src/GS/testclient/gstestclient.c: glue header
magic together. make package display a little more
readable |
| 19:03.32 |
CIA-52 |
BRL-CAD:
03bob1961 * r43967 10/brlcad/trunk/src/libged/ged.c: Initialize
libged's _FreeSolid list if not already initialized. |
| 19:12.26 |
brlcad |
adityag: if
they're gsoc students, their work has to be independent of yours,
but otherwise they're welcome to apply too |
| 19:13.28 |
brlcad |
there's no
guarantee that any student will be selected really, it really
depends how each student is evaluated, how many proposals, what
sort of interest there is, etc |
| 19:17.38 |
adityag |
brlcad : we
could apply to 3 different projects as i mentioned you. |
| 19:27.53 |
*** join/#brlcad kunigami
(~kunigami@201.53.192.197) |
| 19:32.51 |
brlcad |
you could
apply to 3 different projects each -- they'll all still be
evaluated independently ;) |
| 19:33.25 |
brlcad |
do generally
recommend that seriously interested students should apply to at
least two topics in case there is a conflict that needs
resolving |
| 19:35.12 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43968
10/geomcore/trunk/src/GS/testclient/gstestclient.c: read node name
msg and test magics |
| 19:39.39 |
kunigami |
hi, I'm
interested in the vector output from raytracing: http://brlcad.org/wiki/Vector_output_from_raytracing
-- Question: do I have to know beforehand algorithms to fit curves
to points or I could learn them during the project? |
| 19:40.16 |
brlcad |
kunigami:
hello! saw your message to the mailing list |
| 19:41.05 |
brlcad |
you can learn
them during the project, but you should have some basic references
already researched |
| 19:41.39 |
kunigami |
Perfect! |
| 19:41.52 |
brlcad |
two or three
research papers that do exactly that, understanding the tradeoffs
so that you spend most of your time figuring out how to implement
the algorithm |
| 19:42.56 |
brlcad |
then your
proposal should reflect that time with baby milestone steps, more
than pure coding projects, so that we can make sure you're making
progress |
| 19:43.00 |
kunigami |
Ok! I'll
research some papers on the subject and ask back if they are
enough! |
| 19:43.13 |
brlcad |
like if you
find a particular paper, break the algo up into a bunch of steps
that could all be testable |
| 19:45.02 |
kunigami |
hmm ok.
splitting the algorithm is also good for debugging purposes
:) |
| 19:56.46 |
brlcad |
kunigami:
how'd you come to our project ideas page? what's your
interest? |
| 20:06.44 |
kunigami |
well, I found
BRL-CAD through GSoC page - I didn't know BRL-CAD before. I just
searched for "computer graphics" keyword. which is also my
interest. |
| 20:09.35 |
kunigami |
I've also
interest in computational geometry. Last year I tried CGAL, but I
couldn't get in touch with them, so I sent my proposal without
their review :( Obvisusly it was rejected. |
| 20:11.53 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 20:13.25 |
kunigami |
I've a
particular interest in raytracers. I was going to contribute to
yafaray, but this year they didn't get accepted to gsoc. glad to
see there's another project that involves ray-tracing
\o/ |
| 20:18.00 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43969 10/geomcore/trunk/include/Portal.h:
5309!=0x5309, change this to match the spec. |
| 20:23.46 |
CIA-52 |
BRL-CAD:
03starseeker * r43970 10/geomcore/trunk/tests/svntest/main.c: not
working, but checkpointing |
| 21:21.18 |
CIA-52 |
BRL-CAD:
03starseeker * r43971 10/geomcore/trunk/tests/svntest/main.c: Ah,
right - path from root, not from model_name |
| 21:46.35 |
Ralith |
brlcad: would
it be worthwhile for me to apply to work on the toolpath generator?
I'd be happy to discuss the results of my previous participation,
if it'd help. |
| 21:50.33 |
CIA-52 |
BRL-CAD:
03starseeker * r43972 10/geomcore/trunk/tests/svntest/main.c: Woot!
re-assembles the file, althought we're losing some information at
the moment. |
| 21:55.00 |
starseeker |
about one
minute fifty seconds with that code to process havoc.g |
| 21:56.14 |
starseeker |
that's
disassembly and insertion, committing, and
reconstruction |
| 21:56.50 |
starseeker |
not handling
units correctly yet, or _GLOBAL - probably some other
issues |
| 21:58.25 |
starseeker |
this API
communication may be below the "safe for multiple clients" level,
but does give a decent baseline. There are no working copies used
either for insertion or reassembly. A traditional svn checkout
does succeed |
| 22:03.37 |
CIA-52 |
BRL-CAD:
03starseeker * r43973 10/geomcore/trunk/tests/svntest/main.c:
Remove some debug statements, use 1 for unit conversion
factors... |
| 22:08.42 |
starseeker |
humph. OK,
not preserving title, units, color tables, or "region_id"
attributes - otherwise g_diff reports nothing |
| 22:10.01 |
starseeker |
that's a good
note to call it a week on |
| 22:38.18 |
brlcad |
starseeker:
wow, so 4.5 min reduciton |
| 22:38.21 |
brlcad |
that's
substantial. |
| 22:40.52 |
brlcad |
pretty
awesome progress, so that's apparently as fast as it'll get for the
svn server overhead |
| 22:41.43 |
brlcad |
presumably
most of that time is spent inserting and committing |
| 22:44.55 |
brlcad |
kunigami:
that's cool, those are sister projects we don't interact with very
often, but are in related domains |
| 22:46.01 |
brlcad |
cgal mostly
just because their license is incompatible |
| 22:46.18 |
brlcad |
kunigami: did
you see our yafaray-related project? |
| 22:49.12 |
kunigami |
no, I didn't.
Is it listed in the project ideas? |
| 22:49.20 |
brlcad |
not sure..
;) |
| 22:50.27 |
brlcad |
there was an
idea at one point to hook into yafaray using our raytracer to shoot
the ray, find hit point, then pass off to yafray (I need to get
used to using their new name...) for optics
calculations |
| 22:50.59 |
brlcad |
basically so
we can render our geometry using their global illumination model as
a plugin to our tracer |
| 22:51.26 |
kunigami |
interesting! |
| 22:51.30 |
brlcad |
yeah
very |
| 22:51.33 |
brlcad |
BUT
...probably wouldn't recommend it for gsoc unless you were already
really familiar with |
| 22:51.38 |
brlcad |
brl-cad or
yafray |
| 22:51.55 |
brlcad |
at the source
code level, since it's undoubtedly a tricky integration of data
management |
| 22:52.30 |
brlcad |
though that
could be a great out-year project after becoming familiar with the
code this summer |
| 22:52.42 |
kunigami |
hmm ok. I'll
consider helping with it afterwards |
| 22:53.17 |
brlcad |
the first
render project would be a good step towards becoming familiarized
with the code |
| 22:53.24 |
kunigami |
yes! I hope
to learn a lot about ray-tracers :) |
| 22:54.06 |
kunigami |
you mean the
"shader enhancements" one? |
| 22:54.11 |
brlcad |
yeah |
| 22:54.26 |
kunigami |
hmmm, I'll
take a look on it too |
| 22:54.29 |
brlcad |
hooking in
something like OSL would cover related code |
| 22:55.27 |
kunigami |
ok! |
| 22:56.25 |
brlcad |
kunigami:
what projects were you considering before I mentioned that?
:) |
| 22:58.34 |
kunigami |
actually only
the "vector output from raytracing", but when I joined the room, I
got the end of a conversation about applying to more than one
project |
| 22:58.39 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2756
10/wiki/Shader_Enhancements: link to main wikipedia article and
yafaray |
| 22:58.51 |
brlcad |
ah
excellent |
| 22:58.55 |
kunigami |
so I'm
looking for two projects |
| 22:59.10 |
brlcad |
yeah, that's
perfect |
| 22:59.47 |
brlcad |
because
usually we narrow down to the individual first, then pray we've not
narrowed down to two students that have proposed the same
project |
| 22:59.59 |
brlcad |
submitting
two makes that never an issue |
| 23:00.35 |
kunigami |
hmm ok. good
to know that |
| 23:01.02 |
brlcad |
wow,
wikipedia page on shaders doesn't mention OSL |
| 23:01.38 |
brlcad |
they're the
hot cool new kid on the block for ray tracing |
| 23:02.40 |
kunigami |
OSL = open
shading language? |
| 23:03.06 |
brlcad |
yeah |
| 23:03.21 |
brlcad |
sony
imageworks released that project about two or three years
ago |
| 23:03.37 |
brlcad |
it's a shader
language specifically tuned to ray tracing |
| 23:03.46 |
kunigami |
hmm nice!
didn't know it |
| 23:04.08 |
brlcad |
unlike
renderman, which was designed for pixar-style micropolygon raster
engines |
| 23:05.46 |
brlcad |
ahh, that's
why it's not on our ideas list .. it was a discussion with the
yafaray devs |
| 23:06.21 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2757
10/wiki/Shader_Enhancements: typo |
| 23:24.05 |
starseeker |
brlcad: I'll
probably have to have a third go at it using the svn_ra layer
(svn_fs most likely doesn't have the multi-client safty
features) |
| 23:24.55 |
starseeker |
that requires
a little more understanding of things like batons though, so I went
for the svn_fs approach as faster (and the same
split-and-recombine-without-using-files issues had to be addressed,
so that will apply) |
| 23:26.45 |
starseeker |
I think the
majority of the time was committing, but inserting was also
significant |
| 23:33.08 |
brlcad |
ok |
| 23:33.49 |
brlcad |
locking
wouldn't amount to 4 min of activity .. had to be lots of i/o,
book-keeping, unnecessary allocations, etc |
| 23:34.02 |
brlcad |
hard to say,
would need to profile |
| 23:34.14 |
brlcad |
the good news
is that the raw server layer is very promising |
| 23:34.48 |
brlcad |
if we had to,
we lock the write session or even lock per node |
| 23:35.05 |
brlcad |
or profile
and optimize their code |
| 23:35.11 |
brlcad |
either way,
very promising |
| 23:35.36 |
brlcad |
still waiting
for that magical "holy crap" moment where it drops to sub 5sec
:) |
| 08:25.30 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 08:25.30 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 ETA 20110325 || Welcome GSoC 2011
participants! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 08:27.57 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 08:47.23 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 08:58.08 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 10:14.56 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 13:00.16 |
*** join/#brlcad kunigami
(~kunigami@201.53.192.197) |
| 13:50.28 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 15:16.17 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 15:23.50 |
kunigami |
hi all, I'm
studing mged code in order to fix the bug "gets stdin myinVar"
fails - ID: 3087665
http://sourceforge.net/tracker/?func=detail&aid=3087665&group_id=105292&atid=640802 |
| 15:24.01 |
kunigami |
<PROTECTED> |
| 15:24.05 |
kunigami |
I though that
input was read through a callback too (stdin_input) but it seems
that in mode interactive and not classic_mged, the callback isn't
set |
| 15:24.09 |
kunigami |
<PROTECTED> |
| 15:24.12 |
kunigami |
thanks! |
| 15:39.45 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 16:02.31 |
brlcad |
AbhijitKane:
glad to hear the research continues, and expected regarding alloys
and polymers -- from our perspective we treat materials as strictly
homogeneous matter |
| 16:03.23 |
brlcad |
bhinesley:
yeah, don't worry about line length |
| 16:04.38 |
brlcad |
kunigami:
oof, that's a tricky one since mged input is handled in a variety
of ways |
| 16:04.48 |
brlcad |
input is left
up to tcl most of the time iirc |
| 16:44.15 |
kunigami |
hmm ok. One
thing I noticed is that when we don't redirect stdout/stderr to
tclchannels (I commented out in the code). The output, now printed
to terminal, does not show that bug |
| 16:52.55 |
kunigami |
I'll try to
go back to this bug another time. I'm switching to the to-do list
of brlcad :) |
| 16:53.04 |
kunigami |
There's this
one: bu_basename() says it'll return things that it probably
won't |
| 16:53.05 |
kunigami |
<PROTECTED> |
| 16:53.05 |
kunigami |
<PROTECTED> |
| 16:53.05 |
kunigami |
<PROTECTED> |
| 16:54.21 |
kunigami |
indeed, it
says that "/" should return "/" and "a/" return "a", but for both
cases the actual code is returning the empty string |
| 16:54.42 |
kunigami |
what is to be
done: change commentaries or the code? |
| 17:14.50 |
brlcad |
kunigami: the
redirection is definitely the "cause" of the bug -- it's more
making sure the logic is appropriate for both console mode (where
there shouldn't be redirection) and graphical mode (where there is
redirection) and console mode that invokes the graphical mode
(where there are multiple output streams) |
| 17:15.10 |
brlcad |
kunigami: the
code should be fixed |
| 17:15.55 |
brlcad |
for
bu_basename() .. it should basically behave identical to
basename(); it's really just a wrapper for platforms that don't
have basename() |
| 17:16.18 |
brlcad |
the initial
naive implementation was just a little too hastily
coded |
| 17:17.00 |
brlcad |
that would
should be pretty easy to code from scratch or find a bsd reference
impl |
| 17:19.22 |
kunigami |
I see. I'll
do it then! thanks |
| 17:34.40 |
brlcad |
thank you,
awesome |
| 18:05.34 |
kunigami |
hmm there are
some issues though: I need to modify the string if it is for
instance "a/" (it should return "a"). An option would be allocating
space for a new char array, it that ok? |
| 18:06.29 |
kunigami |
this memory
will probably never be deallocated, but I not sure if it's a
problem |
| 18:06.32 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 18:09.45 |
AbhijitKane |
brlcad: any
updates on the database schema? |
| 18:20.19 |
starseeker |
for those
interesting in watching an animation of part of the BRL-CAD source
code history (a small part, admittedly): |
| 18:20.26 |
starseeker |
http://bzflag.bz/~starseeker/brlcad-gource.avi |
| 18:20.40 |
starseeker |
that's the
gource tool brlcad found |
| 18:23.05 |
brlcad |
starseeker:
awesome! |
| 18:23.39 |
brlcad |
starseeker:
what settings did you use? |
| 18:23.49 |
brlcad |
and how did
it take you to render it to video? |
| 18:29.55 |
brlcad |
AbhijitKane:
I found everything, so no worries there |
| 18:30.30 |
starseeker |
brlcad: was a
combination of yukon video capture, seom-filter,
mencoder |
| 18:30.33 |
brlcad |
in fact, the
dev site is still on-line .. just no means for online
auth |
| 18:30.36 |
brlcad |
mater.brlcad.org |
| 18:30.41 |
starseeker |
don't seem to
have the exact settings used for gource |
| 18:31.28 |
starseeker |
grabbed
mencoder settings from here: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html |
| 18:31.43 |
starseeker |
seom-filter
yukon.seom | mencoder - -ovc x264
subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b
-vf scale=512:384 -o file.avi |
| 18:32.23 |
brlcad |
oh, it's not
the whole video |
| 18:32.28 |
starseeker |
right |
| 18:32.44 |
AbhijitKane |
brlcad:
great. i checked a few material databases - they bascially divide
all their data into polymers and alloys |
| 18:32.52 |
starseeker |
just thought
I'd put up a subset for those interested in seeing
something |
| 18:32.53 |
brlcad |
ahh, looks
like you have the same settings too |
| 18:33.01 |
AbhijitKane |
then there
are different methods for searching through each subset |
| 18:33.04 |
brlcad |
i made a few
source code mod improvements |
| 18:33.23 |
brlcad |
never used
seom-filter |
| 18:33.34 |
starseeker |
it goes along
with the yukon thing |
| 18:33.47 |
starseeker |
https://devel.neopsis.com/projects/yukon/wiki/HowTo/Install?version=15 |
| 18:33.49 |
brlcad |
also a tiny
video relative to what I was trying to capture |
| 18:33.54 |
brlcad |
was going for
720p |
| 18:34.01 |
brlcad |
well,
originally 1080p :) |
| 18:34.09 |
starseeker |
https://devel.neopsis.com/projects/yukon/wiki/HowTo/Capture |
| 18:34.09 |
brlcad |
that would
have filled this hd fast |
| 18:34.42 |
starseeker |
nods - yeah, mine is just the "here's something cool" sample,
not the canonical video |
| 18:34.43 |
brlcad |
maybe I can
just send you my mods and settings.. :) |
| 18:35.09 |
starseeker |
heh - and
watch my pathetic little PC fry ;-) Still may be worth a
shot |
| 18:35.28 |
starseeker |
however, the
raw capture on just that part of the animation was 8
gigs |
| 18:35.46 |
brlcad |
well your
video still looks better than mine, I was going to resort to the
built-in ppm stream |
| 18:36.26 |
starseeker |
what were
your source mods? |
| 18:36.48 |
brlcad |
nothing
major, the big one was to make the nodes have a little more
separation |
| 18:36.54 |
brlcad |
and I think
that one was a data mod |
| 18:37.04 |
brlcad |
the other was
control on the font size |
| 18:37.21 |
starseeker |
nods - cool. If you want to tar it up, I can give it a
whirl |
| 18:37.32 |
brlcad |
there is an
advanced font-size option, but it doesn't affect any of the node
labels, just the title |
| 18:37.58 |
starseeker |
did you send
them back upstream? |
| 18:38.03 |
brlcad |
the way it is
now, it's a jumbled mess if the dir has more than about a dozen
files in it and they're all edited |
| 18:38.33 |
brlcad |
with this,
you can read most of them without overlap just by increasing the
spacing slightly and decreasing the font slightly |
| 18:38.34 |
starseeker |
oh, there's
my gource terminal |
| 18:38.41 |
starseeker |
yukon
~/gource-0.32/gource -p 0.8 -a 1 -s 1 |
| 18:39.35 |
starseeker |
this thing
would make an awesome screensaver |
| 18:39.48 |
brlcad |
erm, now to
remember what the short-hand opts were |
| 18:40.31 |
starseeker |
I think those
were just to keep things moving rather than pause while waiting for
the time to advance to the next commit |
| 18:40.37 |
brlcad |
settings I
was using last: brlcad.org/tmp/CONFIG.gource |
| 18:40.45 |
brlcad |
though I was
constantly tweaking |
| 18:41.21 |
brlcad |
ah right
hilighting too |
| 18:41.39 |
brlcad |
made it so
that commiters were slightly larger and always highlighted so you
could distinguish them from the source nodes |
| 18:41.53 |
brlcad |
they get
really lost with the defaults and a big tree |
| 18:42.00 |
starseeker |
nods |
| 18:42.13 |
brlcad |
lemme see if
I can pull a patch |
| 18:42.32 |
starseeker |
can gource
handle our full history? |
| 18:43.05 |
starseeker |
that's a
stress test and a half |
| 18:43.53 |
brlcad |
if you skip
forward in time, it gets totally screwed up -- the layout engine
can't solve a suitable graph fast enough so it oscillates
horribly |
| 18:44.09 |
brlcad |
it does
handle the full history, takes a couple min to load |
| 18:44.22 |
brlcad |
if you let it
build up the graph incrementally, works just fine |
| 18:44.51 |
brlcad |
wanted to
compare two videos, one where we don't remove any nodes -- let the
additions and deletions remove them instead of the time-based
removal it uses by default |
| 18:45.06 |
brlcad |
then let it
do something more like the default for unchanged nodes face
away |
| 18:45.29 |
brlcad |
so you see
where the action is at, instead of full view of the
project |
| 18:45.45 |
brlcad |
AbhijitKane:
haven't forgotten about you -- just a few secs |
| 18:45.52 |
AbhijitKane |
haha...sure |
| 18:46.08 |
starseeker |
brlcad: if it
can do the full node graph, that'd be cool |
| 18:46.56 |
brlcad |
I think it
can .. that's where the ppm stream frame dump may be required
though |
| 18:47.17 |
brlcad |
on mine it
really bogs down to < 1fps if there's a massive tree
edit |
| 18:47.26 |
starseeker |
ah, so
definitely beyond my machine for that one then |
| 18:47.28 |
brlcad |
like in 2004
during the conversion |
| 18:47.44 |
brlcad |
it catches
back up, just slows the animation to a halt |
| 18:47.58 |
brlcad |
so if you're
capturing video directly from the window, it'd suck |
| 18:48.00 |
starseeker |
yeah, that's
gonna need a ppm dump |
| 18:48.08 |
brlcad |
but letting
it take its time and compute frames, it'd be fine |
| 18:48.14 |
brlcad |
how much disk
you have? |
| 18:48.15 |
brlcad |
:) |
| 18:48.21 |
starseeker |
not that much
:-P |
| 18:48.47 |
starseeker |
my biggest
drive is an external 1 terabyte, and that's got all my backup
stuff |
| 18:48.51 |
brlcad |
I think I
calculated it'd be around 90GB for the stream at 720p |
| 18:48.53 |
starseeker |
plus it's
slow as a dog |
| 18:49.11 |
starseeker |
ah - I've got
over a 100 gigs on my main drive |
| 18:49.32 |
brlcad |
that should
compress down to less than 1GB for the full video |
| 18:49.43 |
brlcad |
but just take
a day or so to process |
| 18:50.08 |
brlcad |
uploaded to
http://brlcad.org/tmp/gource |
| 18:50.16 |
starseeker |
how much disk
space do you have handy? |
| 18:50.17 |
brlcad |
replaces one
of the files in data/ |
| 18:50.24 |
brlcad |
i only have
5GB at the moment |
| 18:50.43 |
starseeker |
can gource
give me ppm frames as it currently stands? |
| 18:50.49 |
brlcad |
yep |
| 18:50.52 |
brlcad |
one of the
options |
| 18:51.34 |
brlcad |
ffmpeg will
read the ppm stream as is |
| 18:52.05 |
starseeker |
uh... I don't
have a config file in data |
| 18:52.41 |
brlcad |
gource
--load-config CONFIG.gource --output-ppm-stream
frames.ppm |
| 18:52.56 |
brlcad |
no, that
config file is a cmd-line option |
| 18:52.57 |
starseeker |
oh,
gotcha |
| 18:53.01 |
brlcad |
the file.png
goes into data |
| 18:53.08 |
starseeker |
(thought that
was one of the source code mods) |
| 18:54.41 |
kunigami |
hi, I just
sent a patch to the patch tracker. Any commentaries and suggestions
are welcome. Thanks :) |
| 18:55.23 |
brlcad |
starseeker:
pulling the source mods now |
| 18:57.54 |
starseeker |
ah, ok -
you're filtering out src/other I see |
| 18:58.21 |
brlcad |
starseeker:
uploaded patch.diff |
| 18:59.05 |
brlcad |
kunigami:
fantastic .. it'll definitely get reviewed |
| 18:59.36 |
brlcad |
kunigami:
include a web link in your application to your patch, that helps
save some time figuring out who is who |
| 18:59.59 |
brlcad |
(not to
mention your irc name, contact info, etc..) |
| 19:00.14 |
starseeker |
bhinesley: be
sure to link to your patch(es) too |
| 19:00.58 |
brlcad |
AbhijitKane:
glad to hear the research continues, and expected regarding alloys
and polymers -- from our perspective we treat materials as strictly
homogeneous matter |
| 19:02.06 |
AbhijitKane |
oh, so i
guess you don't store many of the properties that the other
databases do |
| 19:02.41 |
brlcad |
AbhijitKane:
right now today, we only really care about density directly, and
indirectly care about a half dozen other props like young's
modulus |
| 19:02.55 |
kunigami |
ok! |
| 19:03.28 |
kunigami |
I'll turn now
on composing my proposal. |
| 19:03.42 |
brlcad |
great |
| 19:04.00 |
AbhijitKane |
ohk |
| 19:04.35 |
AbhijitKane |
so the
searching will just be based on these properties right? |
| 19:04.42 |
brlcad |
starseeker:
patch apply alright? |
| 19:04.54 |
brlcad |
I didn't
scrutinize it too closely |
| 19:04.59 |
starseeker |
the sketch
one? Haven't had a chance to try it yet |
| 19:05.07 |
brlcad |
no, the
gource patch |
| 19:05.14 |
starseeker |
oh
:-) |
| 19:05.31 |
starseeker |
yep, just my
ftgl.h was in a slightly different location then configure.ac
wanted |
| 19:05.42 |
brlcad |
my patch
changed that too |
| 19:05.54 |
brlcad |
just turned
off the check and linked -lftgl :) |
| 19:06.01 |
starseeker |
ah
:-) |
| 19:06.21 |
starseeker |
well, just
compiled file - so about to give it it's initial trial |
| 19:06.36 |
brlcad |
was nice to
see that it works cleanly against ftgl trunk |
| 19:07.02 |
brlcad |
we'd
restructured things quite a bit, but trying to preserve the
compile-time interface |
| 19:07.19 |
brlcad |
even run-time
should be backwards-compatible |
| 19:08.58 |
starseeker |
brlcad:
where's a good place to grab BRL-CAD_64x64.png? |
| 19:09.09 |
brlcad |
oh
right |
| 19:09.21 |
brlcad |
http://brlcad.org/images/logo/ |
| 19:11.06 |
brlcad |
skips
src/other, also skips dpk commits (jove dev) |
| 19:11.14 |
starseeker |
nods |
| 19:11.32 |
starseeker |
bit of a
shame to skip the step and opennurbs work, but saves a lot of other
cruft |
| 19:11.45 |
brlcad |
yeah |
| 19:12.05 |
brlcad |
could get
more creative with the regex, but it's pretty darn complex as it
is |
| 19:12.15 |
starseeker |
nods |
| 19:12.24 |
brlcad |
bigger issue
is the length and speed of the animation |
| 19:12.29 |
starseeker |
alrightie,
let's see what happens here... |
| 19:12.35 |
starseeker |
Reading
Log... |
| 19:13.05 |
starseeker |
is this the
config that keeps all the nodes? |
| 19:13.10 |
brlcad |
next thing I
was going to try was allowing a bigger timescale .. it won't let
you go over 4x right now .. 4 days per second |
| 19:13.44 |
brlcad |
I think
so |
| 19:14.09 |
starseeker |
can I get
away with piping this into ffmpeg, or will that preserve all the
pauses for the long builds? |
| 19:15.15 |
brlcad |
ah, this one
was a balance .. keeps nodes for 5min .. which should pretty much
keep the whole graph most of the time |
| 19:15.50 |
brlcad |
since 5min is
300 sec is 1200 days is a lil over 3 years |
| 19:16.02 |
starseeker |
nods |
| 19:16.26 |
brlcad |
all source
code is edited annually for the copyright update, so should keep
the bulk of the tree at least from 2000 forward |
| 19:16.38 |
brlcad |
you should be
able to pipe directly |
| 19:16.52 |
brlcad |
but I'd check
the output first, letting it run |
| 19:17.07 |
brlcad |
hm! |
| 19:17.23 |
brlcad |
didn't think
of that.. that might even be a way to avoid writing out 100GB ..
duh |
| 19:17.28 |
starseeker |
still
loading... |
| 19:17.38 |
brlcad |
yeah, takes a
couple min |
| 19:18.48 |
starseeker |
is going with the default ffmpeg string on their site for
now |
| 19:20.05 |
brlcad |
cool |
| 19:20.11 |
starseeker |
brlcad: you
realize I won't be able to give ``Erik a hard time when he
complains about how much space docbook takes up? |
| 19:20.43 |
brlcad |
I'm motivated
to try it streaming here myself, but need to get my butt over to
the gym.. haven't been sick like this in a while, probably due to
gym slacking |
| 19:20.59 |
starseeker |
winces - I should be in the gym too |
| 19:21.53 |
starseeker |
ah, there we
go |
| 19:21.59 |
starseeker |
it begins
with mike |
| 19:22.27 |
brlcad |
yep |
| 19:22.36 |
starseeker |
1993 |
| 19:22.40 |
brlcad |
the begining
year or two is actually pretty cool |
| 19:22.54 |
brlcad |
I had it skip
.1 |
| 19:23.33 |
brlcad |
was initial
attempt at skipping dpk's commits, but then later found the other
option, so can probably remove it back to skipping 0 |
| 19:24.06 |
brlcad |
how does it
look? |
| 19:24.28 |
starseeker |
on screen
it's OK - not sure about the video yet |
| 19:25.18 |
starseeker |
will stop it and restart - that shoudl be enough to
test |
| 19:25.54 |
starseeker |
hah,
awesome |
| 19:26.03 |
starseeker |
that should
do it! |
| 19:26.09 |
starseeker |
sets up for the full run |
| 19:36.51 |
brlcad |
awesome |
| 19:36.53 |
brlcad |
set the skip
to zero? |
| 19:41.06 |
starseeker |
uh - opps -
was just using your settings |
| 19:42.21 |
starseeker |
restarts again |
| 19:44.54 |
starseeker |
brlcad: which
setting are you referring to? |
| 19:44.56 |
starseeker |
start
potition? |
| 19:45.03 |
starseeker |
er
start-position? |
| 19:45.04 |
brlcad |
the one that
says 0.1 |
| 19:45.07 |
brlcad |
or
.1 |
| 19:45.10 |
starseeker |
ok, I see
it |
| 19:45.56 |
starseeker |
hopefully
screensaver won't bother this... not sure how to disable power
save... |
| 20:08.18 |
*** join/#brlcad sachi1325
(75d3557b@gateway/web/freenode/ip.117.211.85.123) |
| 20:57.25 |
*** join/#brlcad sachi1325_
(75d3557b@gateway/web/freenode/ip.117.211.85.123) |
| 21:07.33 |
*** part/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 22:52.09 |
kunigami |
is there any
reference on brlcad system or do I have to study the
code? |
| 22:53.01 |
kunigami |
oops |
| 22:53.17 |
kunigami |
I mean brlcad
shader system |
| 22:53.47 |
``Erik |
going to just
have to look, they're in src/liboptical/ |
| 22:54.35 |
kunigami |
ok |
| 22:54.38 |
kunigami |
thanks |
| 22:57.15 |
kunigami |
forgive my
ignorance, but there are two distinct things: shader language and a
shader system, right? |
| 00:12.47 |
brlcad |
kunigami:
they imply different concepts, so yes |
| 00:13.07 |
brlcad |
the language
just describe *how* something should be rendered |
| 00:13.21 |
brlcad |
the shader
system implements the rendering |
| 00:23.11 |
kunigami |
hmm, in
liboptical we have a shader language or a shader
system? |
| 00:33.38 |
brlcad |
heh,
system |
| 00:35.38 |
brlcad |
the shader
strings we set on objects could be construed as a primitive
language, example: "plastic di=0.4 sp=0.2" another "stack
{{plastic} {texture src="file" name="foo.png"}}" |
| 00:39.42 |
kunigami |
cool. I think
I'm understanding |
| 01:05.44 |
kunigami |
I saw your
commentary on my patch. I'm switching from malloc/strncpy to the
wrapped version. bu_malloc has a const char *parameter, but I
couldn't get its meaning from the commentaries. Looking its
definition, it seems that it has debug purposes (or not?). So I'm
passing NULL to this function. Is that ok? |
| 01:10.44 |
*** join/#brlcad crazy_imp
(~mj@a89-182-222-119.net-htp.de) |
| 02:25.29 |
*** part/#brlcad kunigami
(~kunigami@201.53.192.197) |
| 03:21.48 |
starseeker |
full movie
clocks in at just over a gig |
| 03:34.14 |
starseeker |
and just over
45 minutes |
| 03:34.36 |
starseeker |
layout's a
bit skewed by trunk and brlcad always being present |
| 03:36.25 |
starseeker |
brlcad: I'll
probably have to bring you a dvd - I don't know that my upload
connection will tolerate such a huge upload even if bzflag has
room |
| 06:18.42 |
*** join/#brlcad bhinesley
(~bhinesley@adsl-99-125-83-101.dsl.bkfd14.sbcglobal.net) |
| 06:20.51 |
bhinesley |
I'm having
build issues in Windows/Cygwin. Is Cygwin used to build the
releases of BRL-CAD? |
| 06:23.58 |
bhinesley |
*windows
releases |
| 06:33.39 |
CIA-52 |
BRL-CAD:
0399.125.83.101 07http://brlcad.org
* r2761 10/wiki/User:Bhinesley: /* Checklist */ Updated
status |
| 06:34.33 |
CIA-52 |
BRL-CAD:
0399.125.83.101 07http://brlcad.org
* r2762 10/wiki/User:Bhinesley: /* Checklist */ removed item no
longer working on |
| 06:43.12 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 06:52.58 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 07:28.05 |
bhinesley |
Nevermind,
found README.Windows |
| 10:05.04 |
brlcad |
starseeker:
more importantly, does the graph go nuts after 2004? |
| 10:06.13 |
brlcad |
bhinesley:
it's not, but it 'should' build .. it's just not a configuration
that's tested very often at all. shouldn't be more than a few
minor tweaks but if it is, that could be a patch
submission |
| 10:12.42 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 10:13.16 |
brlcad |
hello
sachinjain, what's your question? |
| 10:13.57 |
sachinjain |
yeah... |
| 10:14.27 |
sachinjain |
I was talking
about the project....."Vector output from raytracing" |
| 10:15.31 |
sachinjain |
I wanted to
know.....how does brlcad generates raster images? |
| 10:15.40 |
brlcad |
through
raytracing :) |
| 10:16.05 |
dloman |
Mernin
all! |
| 10:16.14 |
sachinjain |
so....it
generates a set of pixels? |
| 10:16.17 |
brlcad |
so a ray is
fired for every pixel, if it hits something, that pixel is shaded
according to the properties of what it hits |
| 10:16.21 |
brlcad |
hello
dloman |
| 10:16.46 |
sachinjain |
ok... |
| 10:17.22 |
sachinjain |
so...what do
u mean by "generate vector drawings" |
| 10:17.42 |
sachinjain |
we can only
generate vector drawings if we assume that we have raster
image |
| 10:18.12 |
brlcad |
the idea with
getting vector output is two-fold -- you either are going to still
shoot rays and interpolate vector lines (i.e., edge/object
detection) ... OR ... you're not really going to shoot rays but
instead extrace outline representations "somehow" and project those
onto a vector image plane |
| 10:18.44 |
brlcad |
s/extrace/extract/ |
| 10:20.07 |
sachinjain |
I have done a
project....where I have to a construct a vector image out of raster
image |
| 10:20.18 |
sachinjain |
by using
bezier splines |
| 10:20.30 |
brlcad |
that would be
the first method I mentioned |
| 10:20.37 |
sachinjain |
hmmm |
| 10:21.08 |
brlcad |
it can work
that way, but you have to be really careful about how those curves
are constructed |
| 10:21.36 |
brlcad |
they don't
tend to sample well for small resolution images |
| 10:21.43 |
sachinjain |
yeah |
| 10:21.57 |
sachinjain |
how small
resolution images are we talkin about? |
| 10:22.07 |
brlcad |
you either
need to really increase the grid size or you need adaptive sampling
where there are areas of large derivatives |
| 10:22.24 |
brlcad |
it's
user-specified, so pretty much anything |
| 10:22.33 |
brlcad |
it should
still give a sensible result though |
| 10:22.59 |
brlcad |
if it's
basically giving the raster image scaled, that's rather
useless |
| 10:23.18 |
brlcad |
the whole
point is to have smooth edges that scale and interpolate
cleanly |
| 10:24.43 |
brlcad |
that's why
the method that doesn't involve sampling is superior, but a bit
harder |
| 10:25.09 |
sachinjain |
so what other
method you can suggest? |
| 10:25.33 |
brlcad |
you extract
outline representations "somehow" and project those onto a vector
image plane |
| 10:25.45 |
sachinjain |
you mean the
second approach |
| 10:25.45 |
sachinjain |
? |
| 10:26.01 |
brlcad |
that would be
the other method |
| 10:26.35 |
brlcad |
note that
there are lots of degrees of freedom here |
| 10:27.14 |
sachinjain |
what do you
mean by "extracting outline representations"? |
| 10:27.31 |
brlcad |
you could,
for example, query each individual primitive, shoot a grid of rays
at it, evaluate bezier curves for that outline, then perform
boolean evaluation of the bezier curves all the way back up to the
resulting vector iamge |
| 10:28.28 |
brlcad |
or instead of
shooting a grid of rays, you could use the conversion to a boundary
representation format (NURBS) and then calculate the edge contours
from the NURBS surface, and once again, perform boolean eval of
those curves up the hierarchy |
| 10:30.45 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 10:31.44 |
brlcad |
sachinjain:
feel free to post any more questions if they come up -- it's a
tricky subject but if you already know how to interpolate bezier
curves then you already have an advantage |
| 10:31.57 |
sachinjain |
yeah.....I
know |
| 10:32.01 |
brlcad |
otherwise, I
have to go walkabout for a bit to tame this congestion |
| 10:32.02 |
sachinjain |
how to
interpolate |
| 10:32.54 |
sachinjain |
but...I am
still trying to understand your above suggestion |
| 10:37.10 |
sachinjain |
ok.... |
| 10:37.21 |
sachinjain |
so what I
understood from your explaination |
| 10:37.24 |
sachinjain |
is
that |
| 10:37.36 |
sachinjain |
for every
object in a scene |
| 10:37.51 |
sachinjain |
we find the
outline of that object |
| 10:38.09 |
sachinjain |
construct a
bezier curve on that outline |
| 10:38.10 |
brlcad |
yes |
| 10:38.29 |
sachinjain |
n then do
some...."boolean evaluation" |
| 10:38.41 |
sachinjain |
what is this
boolean evaluation? |
| 10:39.12 |
brlcad |
http://en.wikipedia.org/wiki/Constructive_solid_geometry |
| 10:39.42 |
brlcad |
so look at
that image on the bottom right |
| 10:40.04 |
brlcad |
that's
basically our CSG hierarchy, with primitives at the bottom, boolean
operations that combine them up to the final image on the
top |
| 10:40.10 |
sachinjain |
http://en.wikipedia.org/wiki/File:Csg_tree.png |
| 10:40.12 |
sachinjain |
this
one? |
| 10:40.16 |
brlcad |
we want a
vector version of what is on top |
| 10:40.24 |
brlcad |
yes |
| 10:41.08 |
sachinjain |
hmm |
| 10:41.15 |
sachinjain |
that seems
pretty interesting |
| 10:41.22 |
brlcad |
gotta run,
others in here should be able to help further .. look forward to
talking more! |
| 10:42.21 |
sachinjain |
yeah
sure |
| 10:42.26 |
sachinjain |
some specific
time? |
| 10:43.01 |
sachinjain |
last
question...what do I need to have...to work upon this
project? |
| 10:44.44 |
sachinjain |
Hi
starseeker |
| 10:45.52 |
dloman |
sachinjain:
'what do I need to have' ....as in software installed on your
computer? |
| 10:46.24 |
sachinjain |
dloman: I
didn't got u |
| 10:46.25 |
sachinjain |
? |
| 10:48.00 |
dloman |
your
question: "What do I need to have...to work upon this
project?" |
| 10:48.12 |
sachinjain |
yeah |
| 10:48.15 |
dloman |
do you mean:
"What software do i need to have installed to work on this
project?" |
| 10:48.30 |
sachinjain |
I already
have that software installed |
| 10:48.51 |
sachinjain |
trying to go
through its documentation |
| 10:49.16 |
sachinjain |
is there any
specific part of documentation which I need to go through...for
this project |
| 10:50.25 |
dloman |
you are
working on the "generate vector drawings" that you and brlcad were
talking about just a few minutes ago? |
| 10:50.35 |
sachinjain |
yup |
| 10:50.54 |
sachinjain |
I think I got
the whole idea of the project |
| 10:51.38 |
dloman |
I'm no
expert, but I'd suggest diving into the code. libbu was the most
informative library for me when I started, and I'd imagine libRT
will be very good for you also. |
| 10:54.42 |
sachinjain |
where can I
find these libraries? |
| 10:55.04 |
dloman |
in the source
code: /src/libbu and /src/librt |
| 10:55.32 |
dloman |
their header
files would also be good to start with: /include/bu.h and
/include/rt.h |
| 10:59.46 |
sachinjain |
there is no
such file in this path |
| 10:59.57 |
sachinjain |
:-/ |
| 11:00.16 |
sachinjain |
I am working
on windows |
| 11:00.33 |
sachinjain |
and the
version installed is 7.14.8 |
| 11:00.45 |
dloman |
ah,
winderz. |
| 11:00.59 |
sachinjain |
should I do
my work in linux? |
| 11:01.03 |
dloman |
okay then,
wherever you have it installed: |
| 11:01.13 |
dloman |
<installpath>/include/bu.h |
| 11:01.25 |
dloman |
<installpath>/include/rtfunc.h |
| 11:01.32 |
dloman |
<installpath>/include/rtgeom.h |
| 11:01.33 |
sachinjain |
no file with
name "bu.h" |
| 11:01.58 |
sachinjain |
I can only
find "rtgeom.h" |
| 11:01.59 |
dloman |
well that's
not right |
| 11:02.11 |
dloman |
did you
download binaries or the source? |
| 11:02.32 |
sachinjain |
just the exe
files |
| 11:02.33 |
sachinjain |
:D |
| 11:02.36 |
sachinjain |
file* |
| 11:02.47 |
dloman |
ah, well then
that's the issue. |
| 11:02.58 |
dloman |
if you are
going to develop, you are going to need to get an SVN
checkout |
| 11:02.59 |
sachinjain |
hmm |
| 11:03.08 |
sachinjain |
on
eclipse? |
| 11:03.41 |
dloman |
that's one
way to do it, however, I have never built brlcad using eclipse...
so i dunno if its possible. |
| 11:03.55 |
dloman |
most windows
developers for brlcad use some flavor of visual studio |
| 11:04.02 |
sachinjain |
ohhh |
| 11:04.14 |
sachinjain |
btw...is it
easy to do through linux? |
| 11:04.28 |
dloman |
in my
opinion, yeah, much easier. |
| 11:05.03 |
sachinjain |
ok...so I can
work on one of my servers.... |
| 11:05.06 |
sachinjain |
it has got
linux |
| 11:05.40 |
sachinjain |
how do I get
binaries or source on linux? |
| 11:05.56 |
dloman |
how familiar
with *nix are you? |
| 11:06.22 |
sachinjain |
never heard
of it |
| 11:06.24 |
sachinjain |
:-/ |
| 11:06.45 |
dloman |
*nix == unix,
linux, bsd, etc |
| 11:06.48 |
dloman |
general
term |
| 11:06.52 |
dloman |
aka 'not
windows' |
| 11:06.56 |
sachinjain |
kk |
| 11:06.57 |
sachinjain |
kk |
| 11:07.09 |
sachinjain |
very
familiar |
| 11:07.10 |
sachinjain |
then |
| 11:07.25 |
sachinjain |
I do all my
coding on unix only |
| 11:07.42 |
dloman |
just get an
svn checkout of the brlcad repository. |
| 11:08.27 |
dloman |
http://sourceforge.net/scm/?type=svn&group_id=105292 |
| 11:08.59 |
dloman |
aka: svn co
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
directoryOnYourHD |
| 11:10.13 |
sachinjain |
so...I have
to just run this command.... |
| 11:10.18 |
sachinjain |
"svn co
https://brlcad.svn.sourceforge.net/svnroot/brlcad
brlcad" |
| 11:10.40 |
dloman |
well, that's
the generic 'svn checkout' command that sourceforge
gives |
| 11:10.49 |
dloman |
the proper
version of it is what i wrote above |
| 11:11.03 |
dloman |
are you
familiar with using Subversion at all? |
| 11:11.12 |
sachinjain |
kk |
| 11:11.19 |
sachinjain |
I have used
once |
| 11:11.24 |
sachinjain |
while
building a compiler |
| 11:11.31 |
dloman |
okie |
| 11:11.42 |
dloman |
there's
plenty of tutorials on the net |
| 11:11.49 |
dloman |
but all you
really need to know are: |
| 11:12.02 |
dloman |
svn checkout
(or: svn co) |
| 11:12.10 |
dloman |
svn commit
(or: svn ci) |
| 11:12.12 |
dloman |
and |
| 11:12.15 |
dloman |
svn
up |
| 11:12.20 |
sachinjain |
okie |
| 11:12.32 |
sachinjain |
I am
following them |
| 11:12.58 |
dloman |
however,
commit permissions are not automatically granted and you will
likely have to 'submit a patch' via the sourceforge
website. |
| 11:13.14 |
dloman |
once you get
the code checked out, lemme know. |
| 11:13.21 |
sachinjain |
kk |
| 11:13.23 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 11:13.26 |
dloman |
i *should* be
here for the next 8 (ish) hours. |
| 11:13.44 |
sachinjain |
I will try to
do that...as soon as possible |
| 11:15.00 |
dloman |
is diggin the new GSoC web UI. |
| 11:24.32 |
dloman |
hrm...
where's my profile editing link? Not liking the new UI that much
anymore... its pretty, but that's about it. |
| 11:27.33 |
dloman |
Nice... I
can't 'apply' to be a mentor without first applying to be part of
GSoC. But the only way to be part of GSoC is to apply to be a
mentor. LOL i love it. |
| 11:30.30 |
sachinjain |
hey
dloman....where are you from? |
| 11:30.53 |
dloman |
I am
currently living in Pennsylvania, USA |
| 11:30.54 |
dloman |
you? |
| 11:31.30 |
sachinjain |
I am living
in Hyderabad, india |
| 11:32.21 |
sachinjain |
so...you are
one of the developer in BRL-CAD? |
| 11:33.58 |
dloman |
A newbie, but
yeah :) |
| 11:34.24 |
sachinjain |
it seems a
very big open source project |
| 11:39.05 |
sachinjain |
how much time
does it generally takes to download all the source and
binaries... |
| 11:39.19 |
sachinjain |
through
brl-cad repository |
| 11:39.48 |
sachinjain |
its taking a
hell lot of time |
| 11:43.54 |
dloman |
its abig
repo. we maintain nearly all required deps internally in case they
are not present on the current system. |
| 11:54.52 |
sachinjain |
okie....while
other files are being downloaded |
| 11:54.57 |
sachinjain |
I
have |
| 11:55.01 |
sachinjain |
"ru.h" |
| 11:55.09 |
sachinjain |
"rtedge.h" |
| 11:55.15 |
sachinjain |
n
"rgeom.h" |
| 11:55.22 |
sachinjain |
what should I
do with them? |
| 11:55.39 |
dloman |
I'd say read
them. Get to know the code base a bit. |
| 11:56.04 |
dloman |
before you
can do any develop that's worth anything, you have to get familiar
with the existing code. |
| 11:56.18 |
dloman |
not *all* of
it, but enough to know where you will be primarily
working. |
| 11:57.53 |
sachinjain |
"ru.h" is
very big |
| 11:58.05 |
sachinjain |
how can I get
familiar with something like that |
| 11:58.07 |
dloman |
bu.h? |
| 11:58.12 |
sachinjain |
yeah.... |
| 11:58.15 |
sachinjain |
"bu.h" |
| 11:58.52 |
dloman |
I'd think
that looking at the build system, seeing what executables and
libraries are made is a good start |
| 11:59.19 |
dloman |
launch mged
and get a feel for what brlcad's primary modeler looks
like. |
| 11:59.39 |
dloman |
then start
tracing backwards from the build system. |
| 11:59.50 |
dloman |
see what the
app touches in the way of source files. |
| 12:00.15 |
dloman |
that should
give you a feel for where your project fits in to the big picture,
'source-wise' |
| 12:00.54 |
dloman |
its a big
code base and takes years to get familiar with, so don't sweat it
if its still mostly foriegn to you at the end of hte summer
:) |
| 12:01.14 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 12:04.04 |
CIA-52 |
BRL-CAD:
03davidloman * r43974 10/geomcore/trunk/include/IDataSource.h:
Require classes implementing IDataSource to have a init() fn. (Even
if its a stub). This is needed for both the FS data source(DS) and
SVN DS. |
| 12:05.06 |
CIA-52 |
BRL-CAD:
03davidloman * r43975 10/geomcore/trunk/ (include/FileDataSource.h
src/GS/FileDataSource.cxx): Implement minimal init() checks for the
FS DataSource. |
| 12:05.53 |
sachinjain |
is there any
README file? |
| 12:06.06 |
dloman |
yes, should
be in the root of the checkout. |
| 12:12.34 |
CIA-52 |
BRL-CAD:
03davidloman * r43976 10/geomcore/trunk/include/FileDataSource.h:
Oops. Can't make an interface mandated function private. Change
visibility to public. |
| 12:22.42 |
CIA-52 |
BRL-CAD:
03davidloman * r43977 10/geomcore/trunk/src/GS/FileDataSource.cxx:
Log success/failure of IO tests on the repo path. |
| 12:24.37 |
dloman |
brlcad: How
does Ohloh know about the brlcad repo? Did you have to add the url
to ohloh's database or did it just all happen
automagically? |
| 12:25.00 |
dloman |
I only ask
cause it seems that ohloh isn't seeing the /geomcore
module. |
| 12:25.13 |
dloman |
and was
wondering if that new module needs to be added
somewhere |
| 12:26.40 |
dloman |
hah,
nevermind. |
| 12:58.19 |
CIA-52 |
BRL-CAD:
03davidloman * r43978 10/geomcore/trunk/src/GS/GeometryService.cxx:
Quick Type Fix |
| 12:59.53 |
CIA-52 |
BRL-CAD:
03davidloman * r43979 10/geomcore/trunk/src/GS/DataManager.cxx:
Wire in FileDataSource init() call and return check. |
| 13:08.51 |
dloman |
digs into coreInferface. Need to get ejumakated on
dis. |
| 13:15.43 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 13:30.23 |
CIA-52 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2763 10/wiki/TypeOnlyMsg: Enter the simple wiki page for
TYPEONLYMSG |
| 13:32.03 |
CIA-52 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2764 10/wiki/NetMsgTypes: Admit that this list is not up to date
:( |
| 13:36.02 |
``Erik |
*readreadread* yowza, blew out my buffer
this weekend O.o |
| 13:37.28 |
CIA-52 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2765 10/wiki/GenericFourBytesMsg: Remove caps |
| 13:37.40 |
sachinjain |
Dloman: From
where should I start checking binary files |
| 13:37.45 |
sachinjain |
I am stuck
all along |
| 13:37.53 |
dloman |
'stuck'
? |
| 13:38.00 |
dloman |
as in you are
lost in the code ? |
| 13:38.06 |
sachinjain |
I mean...I
dont know from where should I start |
| 13:38.17 |
sachinjain |
which file
should I look into |
| 13:38.28 |
sachinjain |
first |
| 13:38.42 |
dloman |
have you
compiled yet? |
| 13:38.45 |
CIA-52 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2766 10/wiki/GenericEightByteMsg: Write up description for
GenericEightByteMsg |
| 13:39.12 |
sachinjain |
I have
run.... |
| 13:39.15 |
sachinjain |
sh
autogen.sh |
| 13:39.19 |
sachinjain |
./configure |
| 13:39.22 |
CIA-52 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2767 10/wiki/GenericEightByteMsg: Drat! CopyPaste strikes again!
Fixed. |
| 13:39.31 |
sachinjain |
n now.."make"
is running |
| 13:40.17 |
dloman |
``Erik: any
'esssssspert' advice on where a good starting point for learning
the code is? |
| 13:40.42 |
``Erik |
um, to what
end? there're lots of good starting points for different end
pionts |
| 13:40.43 |
``Erik |
points |
| 13:41.13 |
dloman |
"generate
vector drawings" |
| 13:41.45 |
sachinjain |
yeah...erik... |
| 13:41.46 |
``Erik |
hrm, like an
svg outputting tool with an rt interface? lemme read the
wiki |
| 13:41.49 |
sachinjain |
please
help |
| 13:42.57 |
``Erik |
obviously,
check out http://brlcad.org/wiki/Google_Summer_of_Code/Checklist |
| 13:42.59 |
CIA-52 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r2768 10/wiki/NetMsgTypes: Add in some descriptions for the simpler
messages |
| 13:43.45 |
dloman |
``Erik: FYI
the wiki was correct on the PING and PONG. HEADER + a single 8byte
field. |
| 13:43.56 |
``Erik |
doh, musta
missed that |
| 13:44.11 |
``Erik |
http://brlcad.org/wiki/Vector_output_from_raytracing
lists some useful tools/files to look at |
| 13:44.32 |
dloman |
no worries, i
only write wiki pages in bad-engilsh and stupid. You should feel
good you're not fluent in those :) |
| 13:45.18 |
``Erik |
nah, I'm used
to seeing pings only done as "send a ping, save my time locally...
wait for the response, compare it to the local time", since clock
drift between two machines is inevitable |
| 13:46.13 |
``Erik |
my guess is
that brlcad means to take an approach similar to rtedge
(src/rt/viewedge.c) to sample and then string it together into a
vector set by line/curve fitting |
| 13:47.02 |
``Erik |
so running
rtedge and looking at viewedge.c would be the right beginning point
for the BRL-CAD side, the papers good for the algorithm, then
figuring out the ps/pdf/svg format for the write phase |
| 13:47.18 |
sachinjain |
just these
two files |
| 13:47.28 |
sachinjain |
"src/rt/viewedge.c" |
| 13:47.36 |
sachinjain |
"src/rt/view.c" |
| 13:47.37 |
sachinjain |
?? |
| 13:47.54 |
``Erik |
that's the
starting point... in understanding how it works, many other files
will be involved :) all the way down to libbu stuff |
| 13:48.33 |
``Erik |
a tool like
cscope (or an IDE that does that kind of thing) can be very useful
in exploring |
| 13:50.38 |
``Erik |
I wonder if
finishing up the 'time per ray' raytracer would be a good
"acceptance patch" |
| 13:52.58 |
dloman |
hey brlcad:
Can i write the GS in java? I'd be done by the end of the day!
;) |
| 13:53.16 |
dli |
looks like
brlcad need to update 7.18.4 ETA daily :) |
| 14:00.14 |
d_rossberg |
dloman: any
questions about the coreInferface? |
| 14:00.28 |
*** join/#brlcad sachi1325_
(75d3557b@gateway/web/freenode/ip.117.211.85.123) |
| 14:02.52 |
dloman |
d_rossberg:
not yet, still reading :) |
| 14:09.30 |
starseeker |
dloman:
depending on where we are Wednesday, you may have to try it
:-/ |
| 14:09.53 |
dloman |
i just cant
seem to program fast in c or c++ :/ |
| 14:10.13 |
starseeker |
is down the svn rabbithole |
| 14:10.41 |
starseeker |
dloman: if it
really would help, can you prototype the whole thing in java in a
day and have something working? |
| 14:10.55 |
dloman |
quite
likely |
| 14:11.26 |
starseeker |
unless ``Erik
disagrees, I'd say having SOMETHING that runs is critical right
now |
| 14:11.42 |
dloman |
currently, it
runs just fine =D |
| 14:11.50 |
starseeker |
geometry is
moving across the wire? |
| 14:12.05 |
dloman |
.... it runs
just fine! =D |
| 14:12.23 |
starseeker |
lol |
| 14:13.05 |
starseeker |
I can
disassemble and reassemble most (not all) of the .g, but I can't
yet apply changes |
| 14:13.37 |
starseeker |
that's what
I'll be having to tackle over the next few days |
| 14:14.39 |
starseeker |
I'm hoping
the file backend will suffice to iron out the "moving bits of
geometry across the wire" issues (even if the .g file is a
rather... large bit of geometry) |
| 14:15.50 |
starseeker |
dloman: I'm
guessing byte arrays of the bu_external variety are well suited to
your needs? |
| 14:16.22 |
dloman |
so long as
its got ALL the data for the dbobject, yup! |
| 14:16.43 |
starseeker |
one of the
outstanding issues is why the region_id information is getting
stripped by the approach I am taking |
| 14:17.27 |
starseeker |
I'm using the
internal to external and external to internal routines, which is
pretty much the same level the dbio layer uses |
| 14:18.12 |
starseeker |
unfortunately, that means where precisely
I'm losing the region_id info is a bit murky |
| 14:19.08 |
dloman |
``Erik: lynx
is pretty neat :) |
| 14:20.52 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43980
10/geomcore/trunk/src/GS/testclient/gstestclient.c: add start
(clientside) timestamp |
| 14:22.00 |
CIA-52 |
BRL-CAD:
03davidloman * r43981 10/geomcore/trunk/prototyping/: Add in a
prototyping directory for in process work. |
| 14:33.45 |
dloman |
starseeker:
so what did we descide: we are, or are NOT compatable with the
Apache license? |
| 14:33.53 |
dloman |
Apache v2.0
that is. |
| 14:33.57 |
starseeker |
we're fine to
use it, we just can't mix code |
| 14:34.32 |
starseeker |
that's why
the big change with the svnTest app |
| 14:34.57 |
starseeker |
I originally
started by taking the svn client code and modifying, but now I'm
just using the library APIs |
| 14:35.21 |
dloman |
kk |
| 14:35.42 |
starseeker |
which would
have had to happen eventually anyhow, since the client APIs are too
high level for us, but it kills two birds with one
stone |
| 14:36.13 |
starseeker |
if we ever do
a geometry specific backend, that'll probably have to be
Apache |
| 14:36.14 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 14:36.32 |
starseeker |
but as with
most things, we'll do that if/when need to so it's not an immediate
concern |
| 14:36.59 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43982
10/geomcore/trunk/src/GS/testclient/gstestclient.c: woops, bufp,
not buf |
| 14:38.32 |
starseeker |
``Erik: do
you know enough about the db read/write interface to know why
rt_db_cvt_to_external5 would strip out region_id? |
| 14:39.43 |
starseeker |
I thought the
functions it called would preserve attributes... |
| 14:42.05 |
starseeker |
I know why
_GLOBAL information isn't there, but the region_id thing I don't
get |
| 14:59.10 |
``Erik |
region_id
isn't an attribute, though.. it's a field, no? |
| 15:03.21 |
``Erik |
hrm, hm,
looks like it's also in the standard attribute set |
| 15:06.30 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 15:06.30 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 15:06.49 |
CIA-52 |
BRL-CAD:
03davidloman * r43983 10/geomcore/trunk/ (3 files in 2 dirs): Stub
in interface requirements for and FileDataSource implementation of
putObj(...), the ability to put a single db object into the
datasource |
| 15:07.27 |
``Erik |
looks like
there's stuff to set the attribute to be the same as the GIFT
region_id code in rt_comb_export5 |
| 15:07.47 |
``Erik |
librt/comb/comb.c:405 |
| 15:14.36 |
dloman |
d_rossberg:
are there samples of how to use your classes to load/save/create .g
files anywhere? |
| 15:14.54 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 15:20.21 |
d_rossberg |
http://brlcad.org/wiki/CoreInterface_PrintTitle_Example
is a simple example of how to load a database and perform a simple
operation on it |
| 15:21.07 |
dloman |
awesome
thanks |
| 15:21.20 |
d_rossberg |
however,
first you have to decide which kind of database you
want: |
| 15:21.41 |
d_rossberg |
readonly
file, read/write file or in memory |
| 15:21.54 |
dloman |
reading thru
your code, I think 'memory' is best for what I am working
on. |
| 15:22.07 |
d_rossberg |
there it
depends if you may or have to save you changes |
| 15:22.31 |
dloman |
just looking
to to read/write from/to disk quickly |
| 15:24.35 |
d_rossberg |
to get an in
memory database in the above example you have to replace
BRLCAD::ConstDatabase by BRLCAD::MemoryDatabase, that's
all |
| 15:25.17 |
dloman |
and, to
verify, i can still dump an in memory dtaabase to file simply by
calling save()... correct? |
| 15:25.33 |
d_rossberg |
correct |
| 15:25.41 |
dloman |
awesome.
thanks! =D |
| 15:25.54 |
d_rossberg |
for creating
elements and saving the database see e.g. http://brlcad.org/wiki/CoreInterface_Hallo_World_Example |
| 15:28.13 |
d_rossberg |
and http://brlcad.org/wiki/CoreInterface_Tree_Walker_Example
for walking down the tree and writing the elements names to stdout
(as an example) |
| 15:29.27 |
dloman |
nice. just
read all your wiki pages. Dunno why i didn't think to check there,
lol |
| 15:30.45 |
d_rossberg |
you may find
the Get(objectName) and Set(object) methods handy too (in
Constdatabase.h and Database.h) |
| 15:39.48 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 15:44.56 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43984
10/geomcore/trunk/src/GS/testclient/gstestclient.c: add more
display stuff |
| 15:57.28 |
*** part/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 15:59.09 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43985
10/geomcore/trunk/src/GS/testclient/gstestclient.c:
indent |
| 16:00.11 |
CIA-52 |
BRL-CAD:
03davidloman * r43986 10/geomcore/trunk/include/ (brlcad/ conf/):
Drop unused headers |
| 16:00.30 |
dloman |
``Erik: got a
second to swing by? |
| 16:00.41 |
``Erik |
sure |
| 16:01.21 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43987 10/geomcore/trunk/src/GS/ (21 files in 2
dirs): indent |
| 16:05.56 |
*** part/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 16:09.06 |
dloman |
Hrm... too
bad d_rossberg logged off. it looks like his common.h is trying to
clobber brlcad's common.h :/ |
| 16:12.57 |
dloman |
never mind on
that, it looks as thought coreInterface's common.h isn't being
installed! Ack! |
| 16:16.39 |
CIA-52 |
BRL-CAD:
03davidloman * r43988 10/rt^3/trunk/ (7 files in 3 dirs): Change
core interface's common.h to cicommon.h and add it to cmake's
install routine. It is needed for using the coreInterface
libraries. |
| 16:17.30 |
dloman |
There.
that's a quick fix. renamed common.h to cicommon.h and installed
it :) |
| 16:18.27 |
dloman |
``Erik: FYI,
im wiring up geomcore to have libge as an external dep. So soon,
you will need to have rt3 compilied and installed for geomcore to
compile nad link. |
| 16:18.36 |
dloman |
i haven't
committed that yet, just giving a heads up |
| 16:18.59 |
dloman |
'compile nad
link' ....lol that paints a funny picture. |
| 16:36.09 |
dloman |
starseeker:
you still around? |
| 16:37.39 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 16:38.13 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43989
10/geomcore/trunk/src/GS/testclient/gstestclient.c: add
login |
| 16:42.25 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.137.238) |
| 16:42.25 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:45.52 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43990
10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: print msgType as
hex |
| 17:06.36 |
*** join/#brlcad siddharth
(~siddharth@117.211.88.150) |
| 17:13.52 |
dloman |
starseeker:
Had a thought. You could hack that video into 10 minute segments
and put it on youtube.... let them deal with the
storage. |
| 17:20.04 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2769
10/wiki/NetMsgTypes: guessing at payloads |
| 17:20.33 |
starseeker |
figured to run it by brlcad and see what he thinks of it -
probably more tweaking to do |
| 17:20.50 |
starseeker |
now that the
streaming thing appears to work, he can tweak it on his own box
too |
| 17:25.59 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43991 10/geomcore/trunk/src/utility/GSUuid.cxx:
Tricky, uuid returns the length including the trailing 0 where
std::string does NOT want it. Was causing an extra byte to be
written into the packets. |
| 17:29.01 |
dloman |
``Erik: was
that was was causing the lockup? |
| 17:29.21 |
dloman |
...cause I
thought I fixeded that one already... :/ |
| 17:29.48 |
brlcad |
thx
starseeker -- I was thinking that there'd probably need to be some
more tweaking |
| 17:30.24 |
brlcad |
i guess
sachinjain was having quite a tough time with some basic
concepts |
| 17:31.22 |
``Erik |
nah, but it
was causing issues... caused an extra 0 to be written behind the
uuid, since the geomclient used the same function, it worked (both
sides expected the extra byte) O.o |
| 17:31.49 |
dloman |
righto, but I
caught that one with the java junk i was making for the guys
upstairs.... |
| 17:31.55 |
dloman |
guess i didnt
commit it :/ |
| 17:32.24 |
``Erik |
hm, *shrug*
goes to show that completely seperate implementations are valuable
:D |
| 17:32.24 |
brlcad |
region_id is
stored as an attribute in v5 during comb export, but in memory,
it's both an attribute and a field in the comb internal
structure |
| 17:33.58 |
brlcad |
dloman:
anyone can add new projects to ohloh, I forget how brl-cad was
added but I took ownership and set up the svn repo
links |
| 17:34.07 |
brlcad |
you do
specify checkout points for them to track |
| 17:34.33 |
dloman |
yeah, i saw
that right after i posted in the channel :) |
| 17:34.56 |
brlcad |
for the
statistics to work, the specifically mention not listing branches
unless they're fully self-contained/separate codes |
| 17:35.18 |
starseeker |
brlcad: I'm
using rt_db_cvt_to_external5 to export and
rt_db_external5_to_internal5 to import, but somehow g_diff is
reporting region_id differences |
| 17:35.26 |
brlcad |
which
geomcore would qualify, but not rt^3 with all of the other
code |
| 17:35.37 |
brlcad |
starseeker:
why so low? |
| 17:36.19 |
starseeker |
getting
miminal bu_external byte arrays to feed directly into the
subversion fs |
| 17:38.08 |
brlcad |
db_get_external() should give you the
appropriate bu_external() |
| 17:38.34 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 17:39.23 |
starseeker |
do I still
use rt_db_external5_to_internal5 to reassemble? |
| 17:39.40 |
brlcad |
not sure what
rt_db_external5_to_internal5()'s purpose specifically
is |
| 17:39.45 |
brlcad |
have to look
it up |
| 17:39.49 |
starseeker |
k |
| 17:39.49 |
brlcad |
I've used
db5_get_raw_internal_ptr() in the past |
| 17:40.09 |
brlcad |
it'll take
that raw bu_external and give you an uncracked internal |
| 17:40.10 |
starseeker |
actually,
looking closer it's only the region_id -1 cases where it didn't
preserve it |
| 17:40.39 |
brlcad |
you still
probably uncovered api inconsistency |
| 17:40.47 |
brlcad |
what'd it do
with then? |
| 17:41.08 |
starseeker |
either didn't
preserve them or didn't assign them on import, not sure
which |
| 17:41.23 |
starseeker |
wonder if
it's a signed/unsigned assumption somewhere |
| 17:41.25 |
brlcad |
so just no
attribute |
| 17:41.29 |
starseeker |
right |
| 17:41.59 |
starseeker |
region_id WAS
preserved on regions that had region flag and non-negative region
id, from the looks of it |
| 17:42.51 |
brlcad |
there's no
definition of valid region_id values, so technically, that's just
like it dropping a region id of 1000 |
| 17:43.11 |
starseeker |
nods |
| 17:43.36 |
starseeker |
I can try the
db_get_external and db5_get_raw_internal and see if that does the
trick... |
| 17:43.50 |
sachinjain |
hi
brlcad |
| 17:44.11 |
starseeker |
is a little itchy operating at this level of dbio - new
turf |
| 17:44.31 |
starseeker |
plus I've
still got to start slogging through how to do and apply
diffs... |
| 17:44.36 |
dloman |
brlcad: if I
wanted to get the byte equivalent of a memory database out of an
rt_i, where would I look? |
| 17:44.59 |
*** join/#brlcad sachi1325
(75d3557b@gateway/web/freenode/ip.117.211.85.123) |
| 17:45.03 |
brlcad |
starseeker:
looks like your routine calls my routine :) |
| 17:45.14 |
starseeker |
heh |
| 17:45.16 |
starseeker |
phooey |
| 17:45.21 |
brlcad |
plus does
some more work |
| 17:45.26 |
starseeker |
so much for
dodging the bullet that way |
| 17:45.37 |
sachinjain |
brlcad : do
you remember me |
| 17:45.43 |
sachinjain |
we had a
talk |
| 17:45.44 |
starseeker |
what I am
doing seems to work surprisingly well, except for that one
case |
| 17:45.48 |
brlcad |
the docs on
rt_db_external5_to_internal5() sound like it should do what you
want |
| 17:45.57 |
brlcad |
so it's more
who's messing up |
| 17:46.07 |
starseeker |
nods - was afraid of that |
| 17:46.12 |
brlcad |
sachinjain:
yes |
| 17:46.15 |
starseeker |
yech - bug
hunt |
| 17:46.39 |
starseeker |
at least that
-1 thing is a clue |
| 17:46.42 |
brlcad |
isolated and
trivial to reproduce... doesn't get much better |
| 17:46.55 |
sachinjain |
brlcad : what
should I do to get myself considered for that project? |
| 17:47.04 |
starseeker |
mutter... I
suppose |
| 17:47.09 |
brlcad |
dloman: what
do you mean by the "byte equivalent"? |
| 17:47.11 |
starseeker |
starts setting up the simple test case |
| 17:47.38 |
brlcad |
sachinjain:
we provide a detailed checklist and lots of info on the
website |
| 17:48.23 |
dloman |
brlcad:
preferably, a byte array of bytes read from disk that constitute
the database file |
| 17:48.48 |
brlcad |
starseeker:
db5_import_attributes() seems to be completely unaware of attribute
values so it's got to be during export |
| 17:48.52 |
dloman |
im working
with Daniel's classes now, and am planning on using them to load a
.g in |
| 17:49.14 |
dloman |
at that
point, i'd like to simply dump the entire DB into a byte array and
sling it down the socket. |
| 17:49.56 |
dloman |
or could i
just read the entire db_i struct from memory? |
| 17:50.00 |
starseeker |
brlcad:
sounds good - I did a keep with one of the -1 combs and am stepping
through now |
| 17:50.13 |
brlcad |
dloman: there
are lots of routines related to this (several that starseeker and I
are talking about right now) ... it depends |
| 17:50.23 |
brlcad |
dloman: do
you want there to be object awareness? |
| 17:50.31 |
dloman |
not at this
point no. |
| 17:50.37 |
brlcad |
as in, "im
expecting 10 and I received 10 objects"? |
| 17:50.53 |
brlcad |
then it has
absolutely nothing to do with the rt_i |
| 17:51.24 |
brlcad |
the db_i has
a pointer to both a disk pointer and a byte array |
| 17:51.27 |
dloman |
well right
now, I am trying to just get an entire file read and sent. next
step is to break the db into objects then send. |
| 17:51.45 |
brlcad |
dloman: the
g_transfer tool does the latter already |
| 17:51.48 |
dloman |
and be able
to cat it togeher on the other side. |
| 17:51.59 |
brlcad |
src/gtools/g_transfer.c |
| 17:52.06 |
brlcad |
that's a
sender and a receiver all in one |
| 17:52.13 |
brlcad |
with object
counting |
| 17:52.13 |
dloman |
kk |
| 17:52.17 |
dloman |
danke |
| 17:53.11 |
brlcad |
it also works
entirely with in-memory databases on the receiving in, which is
what you want for service handling |
| 17:53.24 |
brlcad |
starseeker:
curious, what has a -1 region_id set? |
| 17:53.45 |
dloman |
heh,
g_transfer looks strikingly similar to a pkg test file i saw
once..... ;) |
| 17:53.51 |
brlcad |
that could
very well be some signed/unsigned nasty |
| 17:54.29 |
brlcad |
dloman: yeah,
it was based off of it .. tpkg implemented ttcp over libpkg,
g_transfer implements the same thing but with .g object
awareness |
| 17:54.58 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.136.134) |
| 17:55.27 |
starseeker |
brlcad:
ktank.g has a number of assemblies that have that
setting |
| 17:55.36 |
brlcad |
very
preliminary "geometry service" work way back when long before
geometry service was being pushed, making sure that in-memory
database processing worked |
| 17:55.39 |
starseeker |
possibly
havoc too, but haven't confirmed that yet |
| 17:55.40 |
brlcad |
(it didn't
originally) |
| 17:55.47 |
brlcad |
k |
| 17:56.55 |
starseeker |
Oooo! |
| 17:57.11 |
starseeker |
a keep on the
same object also wipes out that region_id setting |
| 17:57.26 |
starseeker |
so it's not
just my low level stuff, it looks like a legit bug |
| 18:00.28 |
brlcad |
so now, does
the in-mem have it set as -1? |
| 18:01.03 |
brlcad |
looks like
the attribute import/export code is ignorant, just treats them as
strings |
| 18:01.18 |
brlcad |
that leaves
the comb code |
| 18:02.54 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2770
10/wiki/NetMsgTypes: GSPONG is 0x62, not 0x61 |
| 18:05.41 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2771
10/wiki/GeometryServiceNetworkProtocol: Message Length does not
include magic/length values. |
| 18:06.35 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43992
10/geomcore/trunk/src/GS/testclient/gstestclient.c: add
transmission of remote node name. Fix off by 8 error causing
lockup. Formatting cleanup |
| 18:06.46 |
dloman |
brlcad:
looking at Daniel's code. He loads a database by calling
rt_dirbuild and getting back a db_i* |
| 18:06.57 |
dloman |
and a
err, |
| 18:07.14 |
dloman |
i ment 'and
getting back an rt_i*' |
| 18:07.55 |
dloman |
since you're
the expert, will the db_i* that the rt_i* have be in a condition
where I can use it to get the data I need? |
| 18:08.02 |
CIA-52 |
BRL-CAD:
03brlcad * r43993 10/brlcad/trunk/src/librt/comb/comb.c: use atol()
instead of atoi() since the fields are long. adjust printing
routines to print long too. |
| 18:08.20 |
brlcad |
dloman:
yes |
| 18:08.30 |
brlcad |
an rt_i
contains a db_i |
| 18:08.40 |
dloman |
sexy,
thanks! |
| 18:09.00 |
dloman |
btw, heard
you're under the weather. Hope you feel better soon! |
| 18:09.45 |
brlcad |
the db_i is
your handle to the database, it uses a plain FILE * or memory
buffer or mapped file, depending on how the data is being managed
(e.g., an in-memory-only database has no FILE *) |
| 18:09.58 |
brlcad |
there are
routines for getting the memory buffer or traversing objects on a
db_i |
| 18:10.16 |
brlcad |
it's easy to
get both but iterating over objects is actually problably a little
easier |
| 18:10.27 |
brlcad |
yeah, I think
ed gave me a cold |
| 18:10.46 |
dloman |
well, if its
any form of justice, he's out again today. ;) |
| 18:10.47 |
brlcad |
at least, I'm
comfortable blaming him for it :) |
| 18:10.51 |
dloman |
lol |
| 18:10.52 |
dloman |
nice |
| 18:11.08 |
brlcad |
I slept for
14 hours last night trying to recover |
| 18:11.25 |
dloman |
see, now
you've gone and made me insanely jealous |
| 18:11.51 |
brlcad |
I'll gladly
come in and cough all over you so you too can feel this
"blessing" |
| 18:11.57 |
dloman |
aahahaha. |
| 18:12.14 |
dloman |
i have 1600%
DV c vitamins coursing thru my veins |
| 18:12.26 |
dloman |
(dont forget
i have virus generators, err, kids, at home) |
| 18:13.00 |
brlcad |
I rarely ever
get sick and get tons of exposure to sick kids too |
| 18:13.36 |
brlcad |
I'm chaulking
this one up to weakened immune system from the long travel combined
with complete lack of exercise |
| 18:14.30 |
dloman |
brlcad: how
familiar are you with Daniel's coreInterface stuff? |
| 18:14.44 |
brlcad |
i've read
through it a few times |
| 18:14.48 |
dloman |
kk |
| 18:14.57 |
brlcad |
pretty
awesome use of in-mem db's |
| 18:15.17 |
dloman |
is an
rt_db_internal* the representation of an object? |
| 18:15.45 |
brlcad |
that gets a
database object in "internal representation" form |
| 18:15.53 |
sachinjain |
brlcad : is
it necessary to submit a patch? |
| 18:16.09 |
brlcad |
sachinjain:
it's highly recommended, however small and simple |
| 18:16.17 |
brlcad |
just to make
sure you can actually read and write code |
| 18:17.14 |
brlcad |
most orgs
have a similar request of applicants, it helps characterize your
ability to become familiarized with the source code and communicate
a trivial change |
| 18:18.08 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43994
10/geomcore/trunk/src/GS/testclient/gstestclient.c: more display
stuff |
| 18:18.29 |
brlcad |
dloman: there
are two types of internal representation -- an uncracked and a
cracked form -- the GS should never have to deal with a cracked
form (i.e. where it becomes aware of the radius value on a
sphere) |
| 18:19.03 |
dloman |
nods. |
| 18:19.05 |
brlcad |
iirc,
rt_db_get_internal is going to be the uncracked from, where you
have the name and entity type |
| 18:19.49 |
brlcad |
major
performance win to not deserialize fully |
| 18:19.55 |
dloman |
right
no. |
| 18:20.01 |
dloman |
err, right
on. |
| 18:20.53 |
dloman |
I am trying
to use coreInterface as much as possible, fyi. The Object class
has a db_i* pointer, rt_db_internal*, directory* and
resource* |
| 18:21.02 |
*** part/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 18:21.28 |
brlcad |
sounds like
the appropriate minimum |
| 18:21.50 |
dloman |
from what
little I know (via crash course over the last 24 hours) I think i
have to grab the 'serialized' data out of the rt_db_internal....
correct? |
| 18:22.46 |
brlcad |
db_i is a
pointer to the object's container, rt_db_internal is a pointer to
the object's data, directory is a pointer to a tree-prep'd record
from the db_i, and resource is "magic" that makes it all work
faster on multiprocessor systems |
| 18:23.16 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2772
10/wiki/NewSessionReqMsg: New page: Two (GS style network order
uint32_t followed by ascii, no terminating 0) strings First is
username Second is password (in plain text) |
| 18:23.29 |
dloman |
"Object's
Container" ... as in the database file? |
| 18:23.36 |
brlcad |
the
rt_db_internal IS the object in a half-serialized,
half-deserialized form .. for schlepping it over the wire, you want
to convert from internal to external form |
| 18:23.41 |
starseeker |
ok,
rt_db_get_intern returns an intern that DOES have a populated
idb_avs structure... |
| 18:23.49 |
brlcad |
dloman: it's
not necessarily a file, but yes |
| 18:23.56 |
brlcad |
it's just
"the database" |
| 18:24.09 |
dloman |
doh. I used
the word file. ;) |
| 18:24.40 |
starseeker |
and correctly
populated |
| 18:25.18 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2773
10/wiki/Common_NetMsg_Exchanges: list initial connect
pattern |
| 18:25.35 |
dloman |
brlcad: the
internal->external conversion somewhere in raytrace.h
? |
| 18:26.08 |
``Erik |
rt_*_export5 |
| 18:26.45 |
brlcad |
dloman: of
course :) |
| 18:26.53 |
brlcad |
dloman: see
send_to_server() in g_transfer.c |
| 18:27.03 |
brlcad |
does exactly
what you should be needing |
| 18:27.28 |
siddharth |
hello |
| 18:27.37 |
``Erik |
ah,
db_get_external |
| 18:27.50 |
siddharth |
for the patch
thing,what should we do exactly? |
| 18:27.54 |
siddharth |
any
ideas? |
| 18:28.04 |
brlcad |
you can go
lower-level and use the export routines, but db_get_external() is a
lot simpler, just taking a directory pointer |
| 18:28.18 |
brlcad |
siddharth:
it's entirely up to you |
| 18:28.30 |
brlcad |
the more
impressive your patch, the more impressive your
submission |
| 18:28.39 |
dloman |
``Erik:
thanks for all the wiki-fu. My heads spinning :/ |
| 18:28.46 |
brlcad |
something
simple to show that you can read/write code is a minimum basic,
siddharth |
| 18:28.57 |
siddharth |
ok thanks
:) |
| 18:29.06 |
brlcad |
siddharth:
you can start with just about anything in our BUGS file or TODO
file or something in one of our trackers |
| 18:29.12 |
``Erik |
complete
circles? will there be split pea soup vomit, I skipped lunch
:/ |
| 18:29.38 |
brlcad |
starseeker:
jeez, I'm not seeing anything reading code on my end |
| 18:29.41 |
dloman |
okay, see...
there's the 'line'... and you just crossed it. |
| 18:29.49 |
brlcad |
hopefully you
have better luck with the debugger |
| 18:30.56 |
siddharth |
Ok..one more
question,what can we do in BUGS file? |
| 18:31.35 |
brlcad |
siddharth:
next you're going to ask me where and how to fix the
bug? |
| 18:31.38 |
brlcad |
is this 20
questions? :) |
| 18:31.48 |
siddharth |
lol
:P |
| 18:31.57 |
brlcad |
you can do
any of them... |
| 18:32.33 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 18:32.34 |
brlcad |
some are
hard, some are easy -- you have to figure that out |
| 18:32.35 |
siddharth |
ok ill try
them out :) |
| 18:32.40 |
starseeker |
brlcad: yeah,
this is an annoying bugger |
| 18:33.10 |
brlcad |
siddharth: if
you need more specific hand-holding, there are some code projects
listed at http://brlcad.org/wiki/Quickies |
| 18:33.39 |
siddharth |
thanks |
| 18:33.47 |
brlcad |
some of
those, however, are harder than the BUGS and TODO items |
| 18:34.33 |
starseeker |
brlcad: ah
HAH |
| 18:34.48 |
starseeker |
the internal
representation is being altered by rt_comb_export5 |
| 18:35.09 |
starseeker |
that's where
the ip->idb_avs.count changes from 1 to 0 |
| 18:39.03 |
dloman |
Hrm, hitting
a C++ knowledge wall. The only way to know what type class you are
dealing with is to attempt a dynamic_cast<> and then check
the result for NULL ? |
| 18:39.08 |
dloman |
...anyone? |
| 18:39.29 |
starseeker |
brlcad: I
think I've got it |
| 18:39.43 |
starseeker |
not sure what
to do about it though |
| 18:40.14 |
starseeker |
comb.c:358 -
encodes "other stuff" as attributes |
| 18:40.37 |
starseeker |
the region_id
of the comb itself (internally) is out of sync with the region_id
string attribute |
| 18:41.38 |
starseeker |
line 405
checks for a non-zero comb->region_id |
| 18:42.05 |
starseeker |
it doesn't
find it (because it's checking the comb's data structure, not the
string attribute) |
| 18:42.36 |
starseeker |
so it runs
bu_avs_remove on the avsp and strips region_id |
| 18:44.14 |
starseeker |
in effect,
this aspect of the comb export makes it impossible to have separate
values in the comb data structure and the associated
attribute |
| 18:44.45 |
starseeker |
dloman: uh,
not sure |
| 18:45.07 |
``Erik |
for c++, you
can enable rtti and do 'isInstanceOf()' or something |
| 18:45.32 |
``Erik |
but there's
overhead to enabling rtti |
| 18:45.35 |
dloman |
just looked
it up. FYI dynamic cast will return a NULL if a type cast fails
and you're dealing with pointers, but throws an Exception if you're
dealing with references. |
| 18:45.45 |
starseeker |
does typeid
help any? |
| 18:46.27 |
starseeker |
http://en.wikipedia.org/wiki/Typeid |
| 18:56.06 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43995
10/geomcore/trunk/src/GS/testclient/gstestclient.c: hoist time
function |
| 19:05.40 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 19:06.45 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-70-176.try.wideopenwest.com) |
| 19:07.33 |
brlcad |
starseeker:
it's saying you have to create a profile before I can add you (on
socghop.appspot.com) |
| 19:07.58 |
starseeker |
k, one
sec |
| 19:08.50 |
brlcad |
same thing
for ed's account |
| 19:09.03 |
brlcad |
dloman: did
you create a link_id yet? |
| 19:09.09 |
dloman |
neat.
coreInterface just bombed me out: http://pastebin.mozilla.org/1193575 |
| 19:09.17 |
dloman |
....can't say
that I have. |
| 19:09.31 |
dloman |
socghop.appspot.com? |
| 19:10.02 |
dloman |
I've
registered that site and applied to be a brlcad mentor. |
| 19:10.07 |
dloman |
...is that a
link_id ? |
| 19:10.46 |
dloman |
man, what a
terrible day. |
| 19:11.02 |
dloman |
im missing
blantantly obivous things |
| 19:11.09 |
dloman |
brlcad: yes,
i have a link_id |
| 19:11.14 |
dloman |
do you want
it? |
| 19:11.14 |
starseeker |
brlcad: uh...
where do I create a profile? |
| 19:11.16 |
brlcad |
dloman: when
did you submit the request? |
| 19:11.21 |
starseeker |
this new site
is less than helpful |
| 19:11.34 |
dloman |
http://socghop.appspot.com/gsoc/profile/google/gsoc2011 |
| 19:11.37 |
brlcad |
if you sent
it before the site change, then you'll have to resubmit
it |
| 19:11.49 |
dloman |
brlcad: this
morning, if it didn't mess up on me. |
| 19:11.56 |
brlcad |
regardless
you'll need to resubmit it because you're not in the pending
requests queue :) |
| 19:11.59 |
dloman |
brlcad: am i
not showing up? |
| 19:12.05 |
dloman |
okie, will
do. |
| 19:12.11 |
brlcad |
daniel's came
through |
| 19:12.21 |
starseeker |
dloman: that
site isn't accessible because I don't have a profile |
| 19:12.38 |
starseeker |
Oh, I see
it |
| 19:12.45 |
starseeker |
growl |
| 19:12.50 |
brlcad |
likes the new look |
| 19:12.56 |
brlcad |
work in
progress, but it's better |
| 19:13.10 |
dloman |
i like the
look also, the navigation needs a bit of work |
| 19:13.12 |
brlcad |
just not
quite ready for production |
| 19:13.18 |
dloman |
brlcad:
submitted |
| 19:13.36 |
brlcad |
got it and
approved |
| 19:13.47 |
dloman |
smashing old
chap! |
| 19:15.37 |
brlcad |
note that
anything that redirects to www.google-melange.com may be blocked
... but socghop.appspot.com works, just edit the url
manually |
| 19:15.58 |
brlcad |
someone needs
to send a request in to get it unblocked |
| 19:17.04 |
``Erik |
beat, I broke
it :D |
| 19:17.07 |
``Erik |
neat,
even |
| 19:17.15 |
brlcad |
yeah I see
that |
| 19:17.33 |
brlcad |
I can
withdraw it, but not approve |
| 19:17.41 |
brlcad |
looks like
admins are auto-mentors this year |
| 19:17.41 |
``Erik |
when I click
anything either 'accept' or 'reject', I get "You cannot be a mentor
for BRL-CAD to access this page." |
| 19:18.12 |
brlcad |
heh, it let
me withdraw the request |
| 19:18.12 |
starseeker |
brlcad:
sent |
| 19:19.22 |
brlcad |
just need to
get ed, larry, tom, and curly registered |
| 19:20.00 |
dloman |
Moe? |
| 19:20.08 |
brlcad |
that'd be
ed |
| 19:20.15 |
dloman |
*snicker* |
| 19:20.29 |
brlcad |
although he
does a great curly |
| 19:21.50 |
starseeker |
brlcad: what
do you think about comb and attributes? |
| 19:21.57 |
brlcad |
was just
looking at that |
| 19:24.02 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 19:35.35 |
bhinesley |
FYI, ACM
student membership is dirt cheap, and it comes with a MSDN Academic
Alliance account, which provides Visual Studio 2005 Professional
(and many others) for free. |
| 19:42.01 |
brlcad |
dloman:
FileDataSource::getObj() .. when is the iterator
incremented? |
| 19:42.41 |
brlcad |
during
Good()?? |
| 19:42.48 |
dloman |
nice catch,
thanks :) |
| 19:43.01 |
brlcad |
same in
FileDataSource::getObjs() |
| 19:43.31 |
dloman |
getObj() is
only supposed to get ONE object, so no inrementing
needed. |
| 19:43.44 |
dloman |
this is still
just a 'proof' that I can actually do this :) |
| 19:43.50 |
dloman |
cleanup to
follow |
| 19:43.56 |
*** part/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 19:44.25 |
brlcad |
should
toss-in FIXME's though when the code doesn't do what the function
suggests, so it's not lost down the road |
| 19:44.36 |
dloman |
right
on |
| 19:44.37 |
brlcad |
and ends up
being a multi hour/day debugging |
| 19:45.21 |
dloman |
Hrm, even
with the iterator incrementor, it still bombs. |
| 19:45.48 |
brlcad |
it's bombing
an uninitialized vls .. which could be lots of things |
| 19:46.09 |
dloman |
righto. I'll
check it out tomarrow.... I'm fried :( |
| 19:46.11 |
CIA-52 |
BRL-CAD:
03davidloman * r43996 10/geomcore/trunk/CMake/FindBRLCAD.cmake:
Make FindBRLCAD.cmake find libge. Likely not the best spot for this
lib, since its in the rt3 module, but it works for now. |
| 19:46.13 |
CIA-52 |
BRL-CAD:
03davidloman * r43997 10/geomcore/trunk/ (8 files in 2 dirs): Wire
in libge (aka coreInterface) classes for loading and saving .g
databases. Implement bare bones read/write for .g files in the
FileDataSource class. |
| 19:46.35 |
CIA-52 |
BRL-CAD:
03davidloman * r43998 10/geomcore/trunk/tests/GS/ (CMakeLists.txt
FileDataSourceTest.cxx): |
| 19:46.35 |
CIA-52 |
BRL-CAD:
Implement basic test for FileDataSource class. A database with a
primitive at |
| 19:46.35 |
CIA-52 |
BRL-CAD: top
works fine, however a combination at top with a primitive as a
child causes |
| 19:46.36 |
CIA-52 |
BRL-CAD: a
bomb: http://pastebin.mozilla.org/1193575
Will investigate asap. |
| 19:46.36 |
dloman |
well that
took a while. |
| 19:52.42 |
``Erik |
this is
requiring rt^3 now? |
| 19:53.29 |
dloman |
ya, just put
that in |
| 19:53.40 |
dloman |
rt3 should
compile and install with no problem. |
| 20:03.19 |
``Erik |
heh, libge
doesn't seem to be linking libbu :/ |
| 20:08.45 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r43999 10/rt^3/trunk/src/
(coreInterface/CMakeLists.txt libge/CMakeLists.txt): add BRL-CAD
link libraries |
| 20:25.58 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2774
10/wiki/GSNet_String: mention lack of terminating NULL |
| 20:26.34 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2775
10/wiki/Category:Geometry_Service: New page: Pages related to the
GeometryService |
| 20:28.36 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2776
10/wiki/NetMsgTypes: fix link |
| 20:29.24 |
kunigami |
hi, how do I
add a regression test? I want to implement one for a function of a
library. Should I provide a code with main function calling this
function and perform some assertions? |
| 20:31.58 |
``Erik |
<PROTECTED> |
| 20:33.19 |
kunigami |
ok!
thanks! |
| 20:33.35 |
brlcad |
kunigami: if
it's only testing the interface, then it's just a unit test and can
be added as a noinst binary in any directory (e.g. the examples
erik mentioned) |
| 20:34.01 |
brlcad |
if it's going
to compare an interface with known good input that might change
down the road, then it can be added as a regression test in the
regress/ directory |
| 20:34.24 |
brlcad |
most of those
are shell scripts that perform integration testing and/or
regression testing |
| 20:36.05 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44000 10/rt^3/trunk/src/
(coreInterface/CMakeLists.txt libge/CMakeLists.txt): woops, old
cache, update to new variable names |
| 20:44.02 |
kunigami |
the function
I'm referring to is 'bu_basename', which I think lies on "testing
interface" case. What do you mean by 'noinst' binary? |
| 20:44.36 |
starseeker |
a noinst
binary refers to a binary that has build logic to create it but not
install it |
| 20:44.44 |
starseeker |
e.g. a "make
install" won't do anything with it |
| 20:45.03 |
starseeker |
check the
Makefile.am in src/libbn for bntester, for example |
| 20:45.40 |
kunigami |
hmm perfect!
thank you |
| 21:02.22 |
kunigami |
ok, so I also
have to modify Makefile.am template. I need to add a rule to
compile my tester program and declare it to be noinst_PROGRAM. one
more doubt: what means FAST_OBJECTS on the Makefile at
src/libbu? |
| 21:02.40 |
kunigami |
*Makefile.am |
| 22:51.51 |
*** join/#brlcad Ralith
(~ralith@d142-058-175-056.wireless.sfu.ca) |
| 00:51.01 |
starseeker |
huh -
asymptote has the ability to plot a NURBS surface, apparently:
http://asymptote.sourceforge.net/gallery/ |
| 01:10.22 |
*** join/#brlcad crazy_imp
(~mj@a89-182-15-178.net-htp.de) |
| 01:40.23 |
brlcad |
kunigami: you
don't really need to worry about FAST_OBJECTS -- you can either
list there or not, inconsequential |
| 01:44.45 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 01:56.59 |
brlcad |
how goes the
application sachinjain |
| 02:08.18 |
sachinjain |
I just woke
up |
| 02:08.34 |
sachinjain |
I have
started to get familiar with the application |
| 02:08.58 |
sachinjain |
even the
installation tool so much of my time |
| 03:14.29 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 03:14.29 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 03:18.16 |
*** join/#brlcad bhinesley
(~bhinesley@adsl-99-125-83-101.dsl.bkfd14.sbcglobal.net) |
| 03:18.21 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 03:18.49 |
*** join/#brlcad crazy_imp
(~mj@a89-182-15-178.net-htp.de) |
| 03:18.49 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-70-176.try.wideopenwest.com) |
| 03:18.49 |
*** join/#brlcad dli
(~dli@dsl-173-248-203-45.acanac.net) |
| 03:18.49 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
| 03:18.49 |
*** join/#brlcad poolio_
(~poolio@BZ.BZFLAG.BZ) |
| 03:19.14 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 03:19.15 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 03:19.15 |
*** join/#brlcad kanzure_
(~kanzure@bioinformatics.org) |
| 03:19.15 |
*** join/#brlcad vtts
(~vytautas@diz.ktu.lt) |
| 03:19.16 |
*** join/#brlcad hyarion_
(c05ben@peppar.cs.umu.se) |
| 03:19.16 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 03:19.16 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 03:19.35 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 03:19.35 |
*** join/#brlcad siddharth
(~siddharth@117.211.88.150) |
| 03:20.04 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
| 03:20.35 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
| 03:56.17 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 04:18.55 |
*** part/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 04:37.27 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 04:57.40 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 05:00.36 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 05:30.57 |
CIA-52 |
BRL-CAD:
03davidloman * r44001 10/geomcore/trunk/src/GS/FileDataSource.cxx:
Remove the simplistic (likely poor) read/write locks in
FileDataSource for now. |
| 05:44.18 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 05:47.52 |
*** part/#brlcad siddharth
(~siddharth@117.211.88.150) |
| 05:56.23 |
dloman |
Anyone still
around? |
| 05:57.21 |
bhinesley |
probably not
who you're looking for, but I am :) |
| 05:57.59 |
dloman |
Well now,
you're correct, but nice to meet ya :) |
| 05:58.33 |
bhinesley |
you
too |
| 05:59.30 |
dloman |
so, hang out
here much? |
| 05:59.39 |
bhinesley |
pretty much
constantly |
| 06:00.13 |
dloman |
quiet then?
I don't see you chatting much. |
| 06:00.45 |
bhinesley |
I try not to
interfere unless I have an important question, or significant
contribution to the conversation. |
| 06:01.34 |
bhinesley |
I'm working
on understanding the source, patches, and my GSoC
proposal. |
| 06:01.53 |
dloman |
how long you
been involved with brlcad? |
| 06:02.17 |
bhinesley |
just a week
or two |
| 06:03.30 |
bhinesley |
probably
closer to a week |
| 06:03.32 |
bhinesley |
how about
you? |
| 06:04.06 |
dloman |
oh wow....
um. close to 3 years now, i think? |
| 06:04.11 |
dloman |
i lost track
a long time ago |
| 06:04.14 |
dloman |
heh |
| 06:04.52 |
bhinesley |
that's cool.
where are you? |
| 06:05.00 |
bhinesley |
(geographically) |
| 06:05.20 |
dloman |
'south
central' PA, usa. joo? |
| 06:05.34 |
bhinesley |
California |
| 06:06.24 |
dloman |
brlcad: I've
narrowed that vls bad magic down to a bu_vls_free() call on lin 757
of Combination.cpp (coreInterface) |
| 06:06.57 |
dloman |
brlcad: I
just don't know where to go from here (at this point), although Im
gonna keep picking away at it. |
| 06:07.07 |
dloman |
bhinesley:
first year at GSoC? |
| 06:07.46 |
bhinesley |
yeah |
| 06:08.33 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 06:08.33 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:09.23 |
dloman |
well enjoy
it, its a blast. |
| 06:09.56 |
dloman |
we got a good
crew here, so i hope you stick around |
| 06:10.08 |
dloman |
what caught
your interest in brlcad anyways? |
| 06:10.16 |
bhinesley |
I plan to,
and I hope I can help. |
| 06:11.16 |
bhinesley |
I have a fair
amount of experience modeling 3D in AutoCAD, which I really loved
doing. I like coding even more. |
| 06:12.07 |
bhinesley |
putting the
two together sounds like a lot of fun |
| 06:12.44 |
dloman |
could be
:) |
| 06:14.08 |
dloman |
where oh
where is d_rossberg when ya need him! :) |
| 06:32.46 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 06:34.27 |
dloman |
hullo
d_rossberg ! |
| 06:34.52 |
dloman |
if you got a
few moment's, I'd like to chat a bit. |
| 06:35.02 |
d_rossberg |
dloman: ?
it's half past two! |
| 06:35.23 |
d_rossberg |
about
common.h? |
| 06:35.36 |
dloman |
actually its
a bu_vls failure |
| 06:36.20 |
d_rossberg |
ok, where is
the problem? |
| 06:37.36 |
dloman |
Combination.cpp:757 is seemingly causing a
'ERROR: bad pointer 0x1454eb10: s/b bu_vls(x89333bbb), was
Zero_Magic_Number(x0)' failure |
| 06:38.30 |
dloman |
geomcore/trunk/tests/GS/FileDataSourceTest.cxx
is the file I was using to perform a simple test |
| 06:38.47 |
dloman |
to open a .g,
and iterate over the top items |
| 06:38.55 |
dloman |
err, 'top
objects' |
| 06:39.01 |
dloman |
with a single
object it works just fine |
| 06:39.34 |
dloman |
with two
objects in the db, it bombs out with this backtrace: http://pastebin.mozilla.org/1193575 |
| 06:40.06 |
dloman |
I am
admittedly not very familiar with the inner workings of the brlcad
libraries. |
| 06:40.14 |
dloman |
all the C and
Macros really really confuse me. |
| 06:41.24 |
d_rossberg |
i'm looking
at it right now, may take some moments ... |
| 06:41.40 |
dloman |
I appriciate
it! |
| 06:59.32 |
CIA-52 |
BRL-CAD:
03d_rossberg * r44002
10/rt^3/trunk/src/coreInterface/Combination.cpp: improved test for
an only partly generated m_internalp (rt_comb_internal) after a
long jump (C exception) |
| 06:59.49 |
d_rossberg |
this is not
the entire solution, it only solves the error after the long
jump |
| 07:00.41 |
d_rossberg |
i think, that
db_dup_subtree fails if the database was removed (or something like
this) |
| 07:03.52 |
d_rossberg |
i'll test it
... |
| 07:11.38 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 07:18.12 |
dloman |
thanks
d_rossberg ! |
| 07:18.24 |
dloman |
i got a bit
side tracked from the irc window, my apologies! |
| 07:41.56 |
CIA-52 |
BRL-CAD:
03d_rossberg * r44003
10/rt^3/trunk/src/coreInterface/Combination.cpp: initialize the VLS
before first usage (in bu_vls_strcpy here) |
| 07:42.15 |
d_rossberg |
this should
solve it, sorry ;} |
| 07:47.43 |
dloman |
Awesome
thanks! |
| 07:48.07 |
dloman |
I'm gonna
crash get some sleep, but I'll check it out later today. Thanks
d_rossberg!! |
| 07:56.06 |
d_rossberg |
dloman:
something for the notes: |
| 07:57.34 |
d_rossberg |
you should
delete the object at the end with its Delete() method (not so
important for your example, but if you have a real server
...) |
| 08:25.40 |
d_rossberg |
the
common.hs: i've never installed the basic BRL-CAD's and and the C++
interface's headers into the same directory, i.e. there was always
a distinction between common.h and brlcad/common.h |
| 08:42.38 |
d_rossberg |
see also the
rt^3/include/brlcad/readme.txt file |
| 08:44.37 |
d_rossberg |
if there is a
need to install both into the same directory i need to think over
the C++ interface's naming conventions |
| 09:11.19 |
d_rossberg |
next: every
Object has a static ClassName() and virtual Type() method (see
Object.h) |
| 09:12.01 |
d_rossberg |
they can be
compared by == (guess why ;) |
| 09:12.42 |
d_rossberg |
e.g.: if
(obj->Type() == BRLCAD::Combination::ClassName()) then
... |
| 10:23.23 |
dloman |
d_rossberg:
great stuff! You really did a bang up job on the
coreInterface. |
| 10:50.48 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 11:23.35 |
CIA-52 |
BRL-CAD:
03davidloman * r44004 10/geomcore/trunk/src/GS/FileDataSource.cxx:
Add iterator incr for proper iterating. |
| 12:07.50 |
CIA-52 |
BRL-CAD:
03davidloman * r44005
10/geomcore/trunk/tests/GS/FileDataSourceTest.cxx: Expand test out
to getting a single object and then getting a list of all objects
at top. |
| 12:09.24 |
dloman |
so... who can
pick me up a Mt Dew on the way to work? ;) |
| 12:09.46 |
dloman |
has the need... the need for caffene! |
| 12:11.19 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 12:19.56 |
dloman |
d_rossberg:
still around? |
| 12:21.53 |
d_rossberg |
yes |
| 12:22.20 |
dloman |
okay, so I've
moved on to Add() ing objects to a memorydatabase. |
| 12:22.27 |
d_rossberg |
and probable
the next 3 hours |
| 12:22.30 |
dloman |
and, as
usual, i broke things, lol |
| 12:23.00 |
dloman |
made an Arb8
using two vector3d objects, but failed to give the arb8 a
name. |
| 12:23.18 |
dloman |
and
attempting to add that is causing a segfault. |
| 12:24.16 |
dloman |
I can see why
at Database.cpp:229 |
| 12:24.19 |
d_rossberg |
the name is a
property of the Object |
| 12:24.36 |
d_rossberg |
see http://brlcad.org/wiki/CoreInterface_Hallo_World_Example
for example |
| 12:24.38 |
dloman |
where the
call to object.Name() is returning a null char* |
| 12:24.56 |
dloman |
okie. Is
this expected behavior then? |
| 12:26.06 |
dloman |
btw, great
wiki entries. They'ev been most helpful. |
| 12:27.10 |
dloman |
I am
wondering, in the event that someone like me attempts to .Add() an
Object before setting its name, should there be a check or default
name? |
| 12:27.28 |
d_rossberg |
that Name()
returns 0 is OK, but i should probable test for a valid name before
calling wdb_export |
| 12:32.10 |
CIA-52 |
BRL-CAD:
03d_rossberg * r44006 10/rt^3/trunk/src/coreInterface/Database.cpp:
test for the presence of a name before trying to add a new object
to the database |
| 12:49.28 |
d_rossberg |
dloman: every
Object has a virtual Valid() method to test if it's ok |
| 12:51.21 |
dloman |
alirghty,
good to know |
| 12:51.28 |
dloman |
hehe, more
questions: |
| 12:53.27 |
dloman |
it seems that
if I try to add two Arb8's in a row, the second one clobbers the
first. |
| 12:54.03 |
CIA-52 |
BRL-CAD:
03d_rossberg * r44007
10/rt^3/trunk/src/coreInterface/Database.cpp: |
| 12:54.03 |
CIA-52 |
BRL-CAD:
corrected the test for a non empty object name |
| 12:54.03 |
CIA-52 |
BRL-CAD: not
using object.Valid() here because it should be possible to add
"broken" objects e.g. during copying a broken database |
| 12:54.30 |
d_rossberg |
it looks like
you add the arb8s always to an empty database |
| 12:54.59 |
dloman |
so should I
add, save, add ? |
| 12:56.14 |
d_rossberg |
BRLCAD::MemoryDatabase md; creates an
empty database |
| 12:56.47 |
dloman |
lol, duh.
Okay. Thanks, i see my mistake. |
| 12:57.35 |
d_rossberg |
if you want
to save the database after every operation you should consider
using FileDatabase instead |
| 12:58.05 |
dloman |
Righto, I
have seen my mistake. Error with the wetware :) |
| 13:03.09 |
CIA-52 |
BRL-CAD:
03davidloman * r44008 10/rt^3/trunk/ (3 files in 2 dirs): Make the
GeometryEngine header file installable since this will serve as an
excellent search point for FindLibGE.cmake |
| 13:17.52 |
CIA-52 |
BRL-CAD:
03davidloman * r44009 10/geomcore/trunk/ (CMake/FindBRLCAD.cmake
CMake/FindLIBGE.cmake CMakeLists.txt): Give libGE its own cmake
FIND file. Un-hack the ge find routines out of
FindBRLCAD.cmake |
| 13:17.55 |
dloman |
there we go
``Erik give it a shot now. Unless you installed rt3 in some silly
place, it should be found. Also, you will need to update rt3 as i
changed it a bit so it will install GeometryEngine.h |
| 13:20.00 |
dloman |
oh dayum:
http://www.cnn.com/2011/WORLD/asiapcf/03/29/japan.nuclear.reactors/index.html |
| 13:20.22 |
dloman |
100 R water
in a tunnel. Oh yeah, that's a core containment
breach.... |
| 13:27.49 |
kunigami |
hi, I've
updated my patch to basename. Comments are welcome.
thanks. |
| 13:40.51 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44010 10/geomcore/trunk/CMake/FindLIBGE.cmake:
allow libge directory to be fed explicitely |
| 13:41.05 |
dloman |
didnt work
eh? |
| 13:42.52 |
``Erik |
not quite
yet |
| 13:43.25 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44011 10/geomcore/trunk/src/GS/CMakeLists.txt:
add LIBGE_INCLUDE_DIRS |
| 13:49.35 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44012 10/geomcore/trunk/CMake/FindLIBGE.cmake:
we already refer to brlcad/header.h, so do not include the brlcad/
in the search path |
| 13:53.54 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44013 10/geomcore/trunk/ (CMake/FindLIBGE.cmake
src/GS/CMakeLists.txt): adjust include dir name to be
consistent |
| 13:56.26 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44014 10/geomcore/trunk/src/GS/CMakeLists.txt:
link libraries from Find* variables |
| 13:56.43 |
``Erik |
there we
go |
| 13:56.58 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44015 10/geomcore/trunk/tests/GS/CMakeLists.txt:
add new libge stuff |
| 13:59.10 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44016
10/geomcore/trunk/src/libNet/netMsg/GenericEightBytesMsg.cxx: fix
type warning |
| 14:01.14 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 14:28.31 |
CIA-52 |
BRL-CAD:
03starseeker * r44017 10/geomcore/trunk/tests/svntest/main.c: Start
figuring out repo level commits, as opposed to doing it manually -
not working yet |
| 14:29.20 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 14:29.20 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:39.33 |
brlcad |
first couple
applications are in! |
| 14:39.45 |
brlcad |
thinks this cold nonesense needs to stop |
| 14:40.59 |
*** join/#brlcad Jesselnz
(~jesse@ool-435573a5.dyn.optonline.net) |
| 14:41.10 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011
Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 14:41.23 |
brlcad |
hello
Jesselnz |
| 14:41.28 |
Jesselnz |
Hi |
| 14:42.54 |
Jesselnz |
A summer of
code application involves doing a small task and sending in a
patch, correct? |
| 14:42.56 |
brlcad |
starseeker:
so a refresher from yesterday now that my head has cleared up a
little bit and the tiny little hammers have taken a lunch
break |
| 14:43.12 |
Jesselnz |
Do you have
any suggestions for a task to get started with? |
| 14:43.12 |
brlcad |
Jesselnz: not
*strictly* required, but highly highly recommended |
| 14:43.29 |
Jesselnz |
Alright |
| 14:43.32 |
brlcad |
you should
get your proposal in first and say you're working on a patch at a
minimum |
| 14:44.06 |
brlcad |
otherwise,
I'd suggest just picking something tangible from our BUGS list or
TODO file |
| 14:44.29 |
Jesselnz |
Okay |
| 14:45.12 |
Jesselnz |
I'm still
trying to familiarize myself with the codebase for my
proposal. |
| 14:45.16 |
brlcad |
sure |
| 14:45.25 |
CIA-52 |
BRL-CAD:
03brlcad * r44018 10/brlcad/trunk/TODO: there is a pending patch
from Guilherme Kunigami (kunigami-dev) that should fix this issue,
so remove the todo on bu_basename() |
| 14:45.27 |
brlcad |
if you find
some that sound easy and want confirmation, just speak
up |
| 14:45.54 |
Jesselnz |
I was
planning to work on the conversion library, but I noticed it
involves C++ (which I have no experience with) |
| 14:46.29 |
brlcad |
the patch
shouldn't take more than a couple hours -- we just want to make
sure you can actually code, at it gives you the opportunity to
shine above other applicants if everything else is
equal |
| 14:46.42 |
brlcad |
Jesselnz:
what languages do you have experience with? |
| 14:47.02 |
brlcad |
it doesn't
have to involve C++, it could be pure C |
| 14:47.09 |
Jesselnz |
Aside from
scripting languages (Javascript, Per, Tcl), only C |
| 14:47.16 |
Jesselnz |
*
Perl |
| 14:47.30 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
| 14:47.42 |
brlcad |
at least one
of our converters has an implementation in C++, so that's why C++
is also listed, not because the library has to be in C or
C++ |
| 14:47.50 |
brlcad |
a good design
can arise from either |
| 14:47.54 |
Jesselnz |
Alright |
| 14:49.59 |
brlcad |
so are you
really from new zealand? :) |
| 14:50.25 |
Jesselnz |
Me? |
| 14:50.34 |
brlcad |
you |
| 14:50.44 |
Jesselnz |
No, I'm from
New Jersey |
| 14:50.52 |
brlcad |
aha,
k |
| 14:51.23 |
*** join/#brlcad Elrohir
(~kvirc@p5B14B1EA.dip.t-dialin.net) |
| 14:52.06 |
brlcad |
Jesselnz: how
strong is your math? |
| 14:52.34 |
Jesselnz |
Well,
first-year university level |
| 14:52.36 |
Jesselnz |
I'm a math
major |
| 14:52.38 |
brlcad |
and do you
have any computational geometry or computer graphics
background? |
| 14:52.47 |
brlcad |
okay,
cool |
| 14:53.14 |
Jesselnz |
Not really,
but I've researched the basics |
| 14:54.06 |
brlcad |
instead of
the geometry conversion library, you might want to consider
proposing the image conversion library |
| 14:54.28 |
brlcad |
or the de-tcl
project |
| 14:54.43 |
Jesselnz |
I'll look
into those |
| 14:54.50 |
brlcad |
both don't
involve any c++ |
| 14:55.30 |
brlcad |
what brought
your interest to brl-cad? |
| 14:55.50 |
Jesselnz |
I just find
CAD interesting |
| 14:56.00 |
Jesselnz |
Since I'm
going into engineering, and I enjoy math |
| 14:56.40 |
brlcad |
how'd you
come to learn Tcl as a first-year? |
| 14:56.55 |
brlcad |
covered in
some first semester scripting class or something? |
| 14:57.30 |
Jesselnz |
I haven't
taken any programming classes - just projects I've done on the
side |
| 14:57.41 |
brlcad |
interesting |
| 14:58.30 |
Jesselnz |
I tried to
write a 2d CAD program in high school using Tcl's C
library |
| 14:58.47 |
brlcad |
then I'd
definitely like to see some code or even work through some code
with you, just to see exactly where you're at -- all skill levels
are welcome if you have the passion, but need to make sure the
project is scoped accordingly |
| 14:59.55 |
Jesselnz |
From the
project I just mentioned? |
| 15:00.01 |
brlcad |
hah, then
removing Tcl C api calls from our core library would essentially be
the opposite :) |
| 15:00.25 |
brlcad |
no, I mean in
terms of developing a patch to go with your proposal |
| 15:00.38 |
brlcad |
and scoping
your proposal appropriately |
| 15:00.38 |
Jesselnz |
Alright |
| 15:01.18 |
Jesselnz |
Yeah, after
looking through what exists of the gometry conversion library, it's
a bit more algorithm-intensive than I was expecting |
| 15:03.16 |
brlcad |
and huge,
that project entails wrangling up over 250k lines of code into an
API |
| 15:03.33 |
brlcad |
the image
processing library is less than half that |
| 15:18.01 |
CIA-52 |
BRL-CAD:
03davidloman * r44019 10/geomcore/trunk/ (4 files in 3 dirs):
Implement FileDataSource's putObj() function. |
| 15:31.00 |
CIA-52 |
BRL-CAD:
03davidloman * r44020 10/geomcore/trunk/tests/GS/ (CMakeLists.txt
SimpleCoreInterfaceTest.cxx): Implement a simple core interface
test. |
| 15:36.39 |
*** join/#brlcad |Elrohir|
(~kvirc@p5B14B378.dip.t-dialin.net) |
| 16:08.50 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 16:37.33 |
CIA-52 |
BRL-CAD:
03davidloman * r44021 10/geomcore/trunk/ (3 files in 3 dirs):
GeometryChunk needs to be aware of its path. Added a path field,
modified associated test. |
| 16:42.54 |
dloman |
brlcad: i
get a byte[] from a socket... whats the quickest way to turn it
into a brlcad struct that i can write to disk as a .g ? |
| 16:45.31 |
dloman |
i just
noticed that starseeker isn't around today. |
| 16:51.16 |
CIA-52 |
BRL-CAD:
03r_weiss * r44022 10/brlcad/trunk/src/conv/dem-g.c: Fixed two bugs
in the dem-g converter which were introduced in recent edits. One
was a correction to the parameters for 'bu_calloc/bu_malloc' and
the other was several duplicate 'bu_free'. |
| 16:56.54 |
starseeker |
brlcad: I
took a look at the red problems on OSX 10.6.7 - it's a bit
scary |
| 16:57.12 |
starseeker |
it's not
anything I can pin down - the gedp pointer itself seems to have
corrupt information |
| 16:57.40 |
starseeker |
at least
according to gdb, but if it were going to wipe out I would have
expected it to do so sooner than what I saw |
| 16:57.57 |
starseeker |
do you have a
10.6 mac by any chance? |
| 17:02.06 |
starseeker |
dloman: I'm
around, just getting yanked here, there and everywhere |
| 17:12.45 |
brlcad |
dloman:
you've really not spent any time reading g_transfer.c have you?
once again, the answer to your question is in there,
server_geom() |
| 17:13.52 |
brlcad |
there are a
few ways you can turn (presumably bu_exported bytes) back into an
object |
| 17:14.04 |
dloman |
i'm very
tired, i got no sleep last night and am having trouble
concentraiting. thanks for the reminder where it was. |
| 17:14.25 |
brlcad |
sure
:) |
| 17:14.58 |
brlcad |
transfer uses
a low-level method, cliff's test program used a slightly higher
level function call that should work too |
| 17:15.31 |
brlcad |
starseeker: I
do, although I've not updated to .7 yet |
| 17:15.50 |
brlcad |
any specific
reproduction steps to try? |
| 17:22.53 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:27.29 |
CIA-52 |
BRL-CAD:
03brlcad * r44023 10/brlcad/trunk/ (doc/deprecation.txt
include/raytrace.h): formally deprecate the GIFT field elements on
rt_comb_internal objects: region_id, aircode, GIFTmater, and los.
they are now stored as attributes. |
| 17:31.58 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.136.132) |
| 17:38.52 |
brlcad |
starseeker:
what steps were you using to debug the keep issue? |
| 17:40.00 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.150.102) |
| 17:40.00 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:43.38 |
brlcad |
man, the
comb5 export function is messed up |
| 17:43.58 |
brlcad |
forcibly
deconsts, clobbers data |
| 17:44.04 |
brlcad |
hate to fix
this before a release |
| 17:44.41 |
brlcad |
starseeker:
all of that logic in comb.c doesn't even belong there |
| 18:04.38 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.139.178) |
| 18:04.38 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:09.29 |
starseeker |
brlcad: for
red, just try to edit a combination - hard crashes mged |
| 18:09.47 |
starseeker |
for keep -
tried a keep of computer in ktank.g |
| 18:10.17 |
starseeker |
was watching
the status of the avs list |
| 18:10.38 |
brlcad |
okay |
| 18:11.17 |
brlcad |
I'm getting a
handle on the import/export problem |
| 18:11.25 |
starseeker |
awesome |
| 18:11.41 |
CIA-52 |
BRL-CAD:
03brlcad * r44024 10/brlcad/trunk/TODO: two issues to resolve
now |
| 18:11.41 |
starseeker |
sorry we kept
pestering you yesterday when you felt like crap :-/ |
| 18:11.53 |
brlcad |
comb export
sucks, but that's old code so I don't want to edit any more than I
have to this release |
| 18:12.02 |
starseeker |
nods |
| 18:12.15 |
starseeker |
it's not any
more broken than it ever was |
| 18:12.27 |
starseeker |
only shows up
when region_id and the comb struct aren't in sync |
| 18:12.28 |
brlcad |
no way to
verify that :) |
| 18:12.35 |
brlcad |
well, there
is a way, but would take too much time |
| 18:12.51 |
brlcad |
so the
question is exactly when/where they get out of sync |
| 18:13.01 |
brlcad |
because that
export code is just fine assuming they are in sync |
| 18:13.11 |
brlcad |
still sucks,
but it's not wrong with that assumption |
| 18:13.25 |
brlcad |
so the
problem is either during import or elsewhere |
| 18:19.01 |
starseeker |
I suppose in
principle you might have some asc2g type thing where you import a
comb and then set the region_id to -1 after creating the comb
itself |
| 18:20.36 |
starseeker |
iirc red was
capable of doing things like that before I added all that sync
logic... and the .g files ktank.g and havoc.g are the product of
running asc2g |
| 18:22.09 |
starseeker |
interesting -
getting a more useful backtrace |
| 18:24.25 |
starseeker |
http://pastebin.mozilla.org/1194067 |
| 18:26.15 |
starseeker |
wooot - it
DOES crash on my 10.5 mac |
| 18:26.21 |
starseeker |
wonder when
that happened? |
| 18:26.24 |
starseeker |
ok,
phew |
| 18:26.30 |
starseeker |
starts binary search |
| 18:36.31 |
brlcad |
while you're
progressing from that direction, i'll see if I can find where the
two get out of sync |
| 18:37.40 |
starseeker |
k - it looks
like (surprise) some of the recent regex tweaking for red broke
something |
| 18:39.34 |
starseeker |
yep -
r43832 |
| 18:41.01 |
brlcad |
hmmm,
interesting |
| 18:43.04 |
brlcad |
so either
freeing something that shouldn't be or not initializing something
after free |
| 18:46.40 |
CIA-52 |
BRL-CAD:
03brlcad * r44025 10/brlcad/trunk/src/libged/red.c: revert r43832
since it reportedly is causing red to crash. needs more
investigating since this should have been a safe refactoring
change. |
| 18:48.09 |
brlcad |
waits for builds to recompile so he can debug
appropriately |
| 18:51.09 |
CIA-52 |
BRL-CAD:
03starseeker * r44026 10/brlcad/branches/cmake/ (14 files in 10
dirs): MFC r44025 |
| 18:51.46 |
brlcad |
oh
shizzle |
| 18:51.51 |
brlcad |
how'd that
happen |
| 18:52.08 |
brlcad |
looks like an
== 0 got turned into a != 0 in that commit |
| 18:52.58 |
starseeker |
ah, line
164? |
| 18:53.21 |
brlcad |
yeah |
| 18:53.50 |
brlcad |
if that's the
culprit, then r44025 should still crash |
| 18:54.00 |
brlcad |
since it's
still != |
| 18:54.21 |
starseeker |
it's not - at
least not in my build here - 44025 works |
| 18:54.30 |
starseeker |
(well, 44026
in cmake0 |
| 18:54.36 |
brlcad |
huh |
| 18:55.09 |
brlcad |
per the
logic, == 0 should be right == if regex is successful |
| 18:55.29 |
brlcad |
i think
:) |
| 18:55.43 |
starseeker |
it may not
handle a matrix right, but it doesn't crash and does apply the
changes in the simple case |
| 18:56.58 |
starseeker |
Ohhhhh |
| 18:57.21 |
starseeker |
I think my
logic on red.c around line 425 may be screwy |
| 18:57.46 |
starseeker |
you have
ret=0, and I was counting on -1 or 1 |
| 18:58.23 |
brlcad |
it was ret 0
previously |
| 18:58.26 |
brlcad |
I see what i
did |
| 18:58.36 |
brlcad |
I swapped the
if/else so != become an == case |
| 18:58.47 |
brlcad |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libged/red.c?r1=43830&r2=43832&pathrev=43832 |
| 18:58.53 |
starseeker |
oh,
ok |
| 18:59.22 |
brlcad |
so it's just
back to being confusing as to why one works and the other
doesn't |
| 18:59.47 |
brlcad |
functionally
equivalent ... unless... |
| 19:01.04 |
starseeker |
matrix_substring is inited inside an if
test... |
| 19:01.34 |
starseeker |
no, that
doesn't look like it... |
| 19:04.22 |
brlcad |
smelling more
like red herring |
| 19:10.03 |
CIA-52 |
BRL-CAD:
03starseeker * r44027 10/brlcad/trunk/src/libged/red.c: Take
another stab at the refactor - this seems to work, but needs more
testing |
| 19:13.35 |
brlcad |
hm, I just
don't believe that to be the direct cause of any crash |
| 19:13.46 |
brlcad |
that's
functionally equivalent |
| 19:14.10 |
brlcad |
init of the
vls earlier was the only change, but that vls isn't accessed
outside that one block |
| 19:14.18 |
starseeker |
nods |
| 19:14.27 |
starseeker |
can you
confirm the crash prior to 44025? |
| 19:14.40 |
brlcad |
haven't
tested |
| 19:14.46 |
starseeker |
k |
| 19:16.00 |
brlcad |
oh there's
something different |
| 19:16.12 |
brlcad |
you made it
always return 1 :) |
| 19:16.20 |
brlcad |
ignoring the
ret var |
| 19:17.07 |
brlcad |
now that I'd
believe .. that code elsewhere is at fault for not handling other
return values correctly |
| 19:17.13 |
starseeker |
ah
whooops |
| 19:18.28 |
CIA-52 |
BRL-CAD:
03brlcad * r44028 10/brlcad/trunk/src/libged/red.c: return the
value that was set |
| 19:22.17 |
starseeker |
urm... still
working here |
| 19:23.10 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:24.35 |
starseeker |
I take that
back - it's not handling an example with a matrix right |
| 19:24.38 |
starseeker |
growl... |
| 19:31.32 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.133.184) |
| 19:31.32 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:36.10 |
starseeker |
blast it the
full matrix regex isn't matching |
| 19:36.18 |
starseeker |
I could have
sworn I tested all that |
| 19:36.30 |
CIA-52 |
BRL-CAD:
03brlcad * r44029 10/brlcad/trunk/src/librt/db5_io.c: init the
external before trying to fill it. random stack memory is
evil. |
| 19:36.43 |
CIA-52 |
BRL-CAD:
03brlcad * r44030 10/brlcad/trunk/src/librt/dir.c: save some time,
don't init until we need to |
| 19:36.56 |
brlcad |
starseeker:
maybe also related to the [:blank:] vs [:space:] change |
| 19:37.15 |
brlcad |
should be the
same for any value that might continue to another line |
| 19:37.27 |
brlcad |
this begs for
a proper regression |
| 19:37.35 |
brlcad |
bunch of
input red files |
| 19:38.35 |
CIA-52 |
BRL-CAD:
03brlcad * r44031 10/brlcad/trunk/src/librt/db5_io.c:
ws |
| 19:39.28 |
CIA-52 |
BRL-CAD:
03brlcad * r44032 10/brlcad/trunk/src/librt/dir.c: ws
cleanup |
| 19:40.58 |
starseeker |
"[[:space:]]+([+-]?[0-9]*[.]?[0-9]+([eE][+-]?[0-9]+)?[[:space:]]+)
{15}([+-]?[0-9]*[.]?[0-9]+([eE][+-]?[0-9]+)?)" |
| 19:42.02 |
brlcad |
for what it's
worth, I get a rather different stack trace from yours |
| 19:42.41 |
brlcad |
same all the
way up to rt_db_put_internal5(), mine never gets to
rt_db_free_internal() |
| 19:43.10 |
brlcad |
so it's going
wrong somewhere before there |
| 19:43.15 |
starseeker |
hmm |
| 19:45.35 |
starseeker |
hates regex |
| 19:48.23 |
starseeker |
it's not
blank vs space |
| 19:49.15 |
brlcad |
we must gain
deeper understanding as to what is failing and why, not just chase
symptoms |
| 19:49.39 |
starseeker |
brlcad: I
know - I'm after why it's not matching the matrix |
| 19:50.01 |
starseeker |
that has to
be fixed toto |
| 19:50.03 |
starseeker |
to
even |
| 19:50.06 |
brlcad |
nods |
| 19:50.24 |
starseeker |
I take it
you're still crashing? |
| 19:50.37 |
brlcad |
i've been in
the debugger on the same crash |
| 19:50.44 |
starseeker |
ah |
| 19:50.59 |
brlcad |
cleaning up
code as I review up and down the stack |
| 19:50.59 |
starseeker |
jeez what a
lousy time for this |
| 19:51.09 |
starseeker |
nods |
| 19:58.35 |
CIA-52 |
BRL-CAD:
03brlcad * r44033 10/brlcad/trunk/src/librt/db5_io.c: cleanup
rt_db_cvt_to_external5(). make sure we check all inputs and
initialize our bu_externals. |
| 20:09.09 |
CIA-52 |
BRL-CAD:
03starseeker * r44034 10/brlcad/trunk/src/libged/red.c: Ooops. one
logical if statement error and a stray space in the full_matrix
regex string |
| 20:13.28 |
kunigami |
brlcad: I'm
taking a look at your comments of my patch. How do I enforce that
callers of bu_basename release memory? Are there something like
smart_pointers in c? |
| 20:14.03 |
brlcad |
kunigami: no
way to enforce, just have to give them a quick sanity
check |
| 20:14.14 |
brlcad |
s/way/need/ |
| 20:14.36 |
brlcad |
it's only
because it's an api change (and deviation from basename()) that it
even needs to occur |
| 20:14.49 |
starseeker |
bhinesley:
did you get a chance to play with the Tcl/Tk code? |
| 20:15.56 |
kunigami |
hmm, what do
you mean by "sanity check"? |
| 20:18.15 |
brlcad |
kunigami: a
grep through the code to find all the callers, make sure the string
is released or copied and released |
| 20:19.07 |
brlcad |
iirc, that
routine is not called in more than a couple places -- if it's more
than 15 min work, lemme know |
| 20:20.00 |
kunigami |
ok! |
| 20:20.00 |
kunigami |
One thing: if
we're going to change interface, I'd suggest we also change the
input to non-const (like basename). I think it would do less harm.
Also, it would be compliant with basename (3), which may change the
input string. |
| 20:20.49 |
kunigami |
then there's
no need to allocate memory |
| 20:28.02 |
CIA-52 |
BRL-CAD:
03starseeker * r44035 10/brlcad/branches/cmake/src/ (libged/red.c
librt/db5_io.c librt/dir.c): MFC r44034 |
| 20:31.30 |
bhinesley |
starseeker:
Yes, I changed the export->ASCII to a tk_getSaveFile. It stands
alone without the bug fix, so I'm submitting it in a few
minutes. |
| 20:31.53 |
bhinesley |
I have gotten
closer to finding the bug, but it is not in Tcl/Tk. |
| 20:32.04 |
starseeker |
brlcad:
awesome :-) |
| 20:32.14 |
starseeker |
er bhinesley:
awesome :-) |
| 20:32.41 |
starseeker |
note to self
- read then post :-P |
| 20:33.12 |
bhinesley |
at least he
wasn't talking about a family member dying or something |
| 20:33.48 |
starseeker |
heh |
| 20:36.36 |
brlcad |
kunigami:
that's a good thought but then there are a couple
issues |
| 20:36.41 |
bhinesley |
part of the
problem, is that Windows 7 moves files into VirtualStore that are
exported anywhere but the user profile. To the user, they're just
not there. |
| 20:37.13 |
brlcad |
one being
that dirname/basename suck .. they're the way they are because they
were implemented that way a LONG time ago and it's painful to
change API that old |
| 20:37.17 |
bhinesley |
the other
problem is incorrect handling of windows paths, which is what I'm
still tracking down |
| 20:37.24 |
brlcad |
they're not
re-entrant or thread-safe, for example |
| 20:38.04 |
starseeker |
bhinesley: ah
yes, Windows paths |
| 20:38.34 |
starseeker |
bhinesley:
how are you building on Windows? |
| 20:38.40 |
brlcad |
kunigami: the
other issue is consistency -- we have to be self-consistent so
whatever is done for bu_basename() needs to be done for
bu_dirname() too |
| 20:39.37 |
brlcad |
kunigami: so
either both match dirname/basename or both match each other,
provide thread safety, but require callers to bu_free() |
| 20:39.49 |
bhinesley |
starseeker: I
started with Cygwin, but ran into build errors. Anyways, once I
read that releases are built in Visual Studio, that's what I
started using. I just finished building for the first time, and
there are some errors. I have yet to see how bad. |
| 20:40.48 |
kunigami |
wow I didn't
think of these issues! ok. I'll keep the interface and add a
commentary at bu.h and also perform sanity checks. do we have any
such automatic checker, where I could add these tests? |
| 20:42.04 |
brlcad |
kunigami:
what sort of tests? |
| 20:42.05 |
starseeker |
bhinesley:
the cmake branch may be a good bet for building on Windows with
Visual C++ |
| 20:42.35 |
brlcad |
kunigami:
bu_dirname() already takes const, returns nonconst, and documents
the need for bu_free() so it would be a good example to
follow |
| 20:42.59 |
brlcad |
the issue is
just making sure bu_basename() callers are calling bu_free() like
bu_dirname() callers are |
| 20:43.31 |
bhinesley |
starseeker:
in the repo? |
| 20:44.32 |
kunigami |
brlac: hhm
nevermind I don't think such sanity checkings could be
automated. |
| 20:44.33 |
bhinesley |
I see it
now |
| 20:44.47 |
kunigami |
brlcad: ok.
I'll follow that example |
| 20:45.15 |
starseeker |
bhinesley:
svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/branches/cmake
brlcad-cmake |
| 20:46.47 |
*** join/#brlcad siddharth_
(~siddharth@117.211.88.150) |
| 20:47.31 |
siddharth_ |
brlcad, How
to apply for gsoc brlcad? |
| 20:48.17 |
brlcad |
siddharth_:
see http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 20:49.25 |
starseeker |
bhinesley:
you'll need cmake (2.8.4 is probably a good idea) and Visual C++
(or Visual Studio should work) |
| 20:49.37 |
starseeker |
If you want
to build the installer you'll also need NSIS |
| 20:50.09 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44036 10/geomcore/trunk/src/interfaces/cl/ (.
gsclient.asd gsclient.lisp): quick and dirty lithp
client |
| 20:50.17 |
bhinesley |
starseeker:
alright, thank you |
| 20:57.20 |
*** join/#brlcad Marjo_
(~Marjo@71.141.133.50) |
| 20:57.46 |
starseeker |
``Erik:
that's pretty cool, actually |
| 21:04.08 |
Marjo_ |
Hello,
everyone! |
| 21:05.51 |
brlcad |
hello
Marjo_ |
| 21:23.21 |
CIA-52 |
BRL-CAD:
03brlcad * r44037 10/brlcad/trunk/src/librt/comb/comb.c: check in
the order passed |
| 21:26.47 |
CIA-52 |
BRL-CAD:
03Markhobley 07http://brlcad.org *
r2777 10/wiki/MGED_CMD_who: displayed objects |
| 21:38.25 |
brlcad |
there's a
gsoc project I forgot to add .. syncronize wiki pages with doxygen
pages ;) |
| 21:39.35 |
brlcad |
er,
docbook |
| 21:40.04 |
starseeker |
yeah! that's
a really good candidate for those interested in web
stuff |
| 21:42.54 |
Marjo_ |
I'm very
intersted in the code maintenance project. Filling out a proposal
right now. |
| 21:44.04 |
brlcad |
Marjo_:
fantastic, which one? |
| 21:44.30 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2778
10/wiki/Google_Summer_of_Code/Project_Ideas: sync docbook and wiki
docs |
| 21:45.06 |
Marjo_ |
brlcad: I'm
very interested with Code Reduction / General Tree Walker / Fixing
Bugs under Code Refactoring Projects. |
| 21:45.46 |
Marjo_ |
I'm only a
2nd year Computer Engineering Undergrad so I'm still a
novice. |
| 21:56.13 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2779
10/wiki/Synchronize_Wiki_with_Docbook: initial wikidocbook
idea |
| 21:56.21 |
brlcad |
Marjo_: then
code refactoring sounds like a great place to begin |
| 21:56.30 |
brlcad |
that said,
you could have 10 years experience and still be a novice
;) |
| 21:57.33 |
brlcad |
if experience
is limited, I wouldn't necessarily recommend starting with code
reduction since that usually entails a lot of careful testing and
API design |
| 21:57.36 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 21:57.45 |
brlcad |
the other two
ideas, however, bug fixes and tree walking, are more
tangible |
| 21:58.11 |
Marjo_ |
brlcad: Haha,
agreed. I would love to get a small taste of what real-world
programming looks like. |
| 21:59.11 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r2780
10/wiki/Main_Page: there is no support, neat showing dead links in
red erik |
| 22:00.36 |
brlcad |
Marjo_: it's
mostly about taking things to completion -- proof-of-concept is
never enough |
| 22:01.14 |
brlcad |
docs,
testing, performance profiling, tweaking, more docs, more
testing |
| 22:02.54 |
Marjo_ |
brlcad: To
test this code, what kind of IDE would you recommend? Is either
Microsoft Visual C++ 2010 or Eclipse on Ubuntu a proper
IDE? |
| 22:03.17 |
brlcad |
whatever
you're comfortable and productive with is fine |
| 22:03.28 |
brlcad |
it's worth
investing the time and effort to learning how to use one of them
well, though |
| 22:03.51 |
brlcad |
personally, I
prefer emacs, eclipse, or vim (in probably that order) |
| 22:04.49 |
brlcad |
most
graphical IDEs are just a crutch, and tend to get in the way more
than they help -- learn the underlying concepts first and it won't
matter |
| 22:07.56 |
brlcad |
if you end up
not understanding build failures or avoiding looking into
compilation failures, then you probably shouldn't be using an IDE
yet |
| 22:11.16 |
Marjo_ |
How would
students address code maintenance if they don't see the errors
through an IDE? Throughout the duration of my 2 years we've only
been using Eclipse and Visual Studio to write code and
debug. |
| 22:19.01 |
brlcad |
Marjo_: your
confusion is exactly what I'm referring to :) |
| 22:19.22 |
brlcad |
the IDE isn't
a magical black box, it's making calls and performing operations
under the hood |
| 22:20.06 |
brlcad |
as a young
developer, it's critical to learn what those things are otherwise
"when things go wrong", deciphering what's going wrong can seem
impossible |
| 22:20.14 |
brlcad |
or worse,
lead to cargo cult programming |
| 22:20.45 |
Marjo_ |
brlcad: OH! I
see what you're talking about. Does it basically boil down to white
box testing? |
| 22:21.25 |
brlcad |
you should be
able to write and debug software with a simple text editor, a
compiler, and a linker .. next learn a decent debugger and you'll
be more experienced than most developers |
| 22:22.12 |
brlcad |
it's not
related to white box testing -- it's knowing how your tools
work |
| 22:23.53 |
Marjo_ |
Ahh, my
current Data Structures and Algorithms professor touched upon this
subject during the beginning of the semester, but she said that is
probably too advanced for our class right now. |
| 22:23.54 |
brlcad |
car analogy:
it's like being a car mechanic but not knowing how to use a wrench,
avoiding wrenches or even anything with a bolt on it because you've
never used a wrench before |
| 22:24.39 |
Marjo_ |
I wonder why
we didn't start out our curriculum by "learning the insides"
first... |
| 22:25.09 |
brlcad |
a power
wrench might save time and effort, but damn .. it's just a wrench
.. don't fear learning how to use a wrench first ;) |
| 22:26.18 |
brlcad |
Marjo_:
that's because the average CS student is stupid (because the
average person is stupid) and they try to not scare people away too
quickly, ease them into core concepts |
| 22:26.46 |
Marjo_ |
Haha, I fully
understand. :) |
| 22:26.48 |
brlcad |
decades of
people before you learned the basic tools just fine, you'll do just
fine too |
| 22:34.24 |
CIA-52 |
BRL-CAD:
03brlcad * r44038 10/brlcad/trunk/include/raytrace.h: (log message
trimmed) |
| 22:34.24 |
CIA-52 |
BRL-CAD: yay
understanding. document how RT_GET_TREE() and RT_FREE_TREE()
are/were |
| 22:34.24 |
CIA-52 |
BRL-CAD:
working. it's basically a linked list that reuses free'd tree items
so we never |
| 22:34.24 |
CIA-52 |
BRL-CAD:
allocate more than the largest amount in use at any one time.
pretty nifty. |
| 22:34.24 |
CIA-52 |
BRL-CAD:
(allocating in batches might be even better) add a new RT_INIT_TREE
macro that |
| 22:34.25 |
CIA-52 |
BRL-CAD: will
initialize a union tree to zero with the magic set, make
RT_GET_TREE init |
| 22:34.26 |
CIA-52 |
BRL-CAD:
every tree returned so callers never have to deal with the magic
number |
| 22:35.13 |
CIA-52 |
BRL-CAD:
03brlcad * r44039 10/brlcad/trunk/src/librt/ (comb/db_comb.c
db_tree.c tree.c): now that RT_GET_TREE initializes, we don't need
to manually set RT_TREE_MAGIC any more. should also help guarantee
that reused tree nodes have zero'd memory. |
| 22:37.39 |
Marjo_ |
Wow, thank
you for the inspiration. I will still apply for the project so that
I can learn of the different ways to program. |
| 22:45.58 |
adityag |
brlcad: is it
cool if i have not submitted patches in BRL-CAD ? . i have submited
a few patches in drupal. will that help ? |
| 22:49.51 |
brlcad |
Marjo_:
great, look forward to seeing your application |
| 22:50.52 |
brlcad |
again, you
can use whatever you like |
| 22:50.54 |
brlcad |
we'll only
push you towards specific tools if you're taking too
long |
| 22:51.08 |
brlcad |
the tool is
just a tool, better to obsess over code than over the tools
:) |
| 22:51.19 |
brlcad |
adityag: are
you serious? :) |
| 22:53.25 |
brlcad |
"is it cool
if I didn't do the assignment for your class ? . i did the
assignment for another class. will that help ?" |
| 22:53.28 |
brlcad |
you tell me
;) |
| 22:55.04 |
adityag |
<PROTECTED> |
| 23:01.20 |
brlcad |
a patch isn't
technically "required", so you should submit your application with
or without it regardless (you can attach a link to the patch
later) |
| 23:01.48 |
brlcad |
but trying to
pawn off work for another org isn't cool or useful, the point is
seeing how you deal with our code |
| 23:04.37 |
CIA-52 |
BRL-CAD:
03brlcad * r44040 10/brlcad/trunk/src/librt/ (4 files in 3 dirs):
no longer need to set RT_TREE_MAGIC now that RT_GET_TREE() sets
it. |
| 23:05.57 |
CIA-52 |
BRL-CAD:
03brlcad * r44041 10/brlcad/trunk/src/libged/ (8 files): no longer
need to set RT_TREE_MAGIC in here too now that RT_GET_TREE() sets
the magic. |
| 23:09.22 |
adityag |
brlcad: yeah
cool. |
| 23:17.00 |
CIA-52 |
BRL-CAD:
03brlcad * r44042 10/brlcad/trunk/src/libged/red.c: functions that
use zero for success result in reverse boolean expressions. less
error-prone to explicitly test for zero. go a step further and
document intent with matched/no match labels. |
| 23:21.10 |
CIA-52 |
BRL-CAD:
03brlcad * r44043 10/brlcad/trunk/src/libged/red.c: aha, source of
the errant space. auto-formatting sees the ){ and wants to clean up
the formatting. break up the string. |
| 23:57.09 |
starseeker |
brlcad: nice.
I didn't realize you could feed two separate strings into the
printf logic like that |
| 23:58.01 |
adityag |
brlcad: Im
interested in these project ideas : Code Reduction, Fix Bugs,
Benchmark Performance Database. Can i submit multiple applications
? |
| 00:02.52 |
brlcad |
adityag: you
sure can |
| 00:03.08 |
brlcad |
you can
submit up to 20 apps total to any number of orgs |
| 00:03.22 |
brlcad |
I don't
recommend submitting more than three |
| 00:03.32 |
brlcad |
focus on
quality, not quantity |
| 00:03.53 |
adityag |
ok cool
thanks |
| 00:03.55 |
brlcad |
better to
have two really good applications with a strong patch than four
crappy applications with a crappy patch ;) |
| 00:05.16 |
brlcad |
starseeker:
*nod* all string literals are equivalent to the concatenation of
them broken up like that |
| 00:05.48 |
brlcad |
so you can't
use it to get over the 509 char limit in C90, but it is useful if
you need to inject comments or assist with layout |
| 00:07.33 |
CIA-52 |
BRL-CAD:
03starseeker * r44044 10/brlcad/trunk/src/libged/red.c: Rename to
avoid confusion - the point of that regex is to look for anything
except whitespace, not whitespace. |
| 00:13.02 |
starseeker |
please please
please let this be the last of the showstopper red
bugs... |
| 00:15.31 |
brlcad |
i'm still
chasing the logic through for how it was causing that crash in the
first place |
| 00:15.59 |
brlcad |
for my trace,
it was deep in libbn checking if a mat is identity .. so it was
bogus memory |
| 00:16.06 |
brlcad |
hopefully the
zero-init will make that not happen |
| 00:16.50 |
starseeker |
nods |
| 00:17.08 |
starseeker |
maybe that
would explain why the different crash on 10.6 vs. 10.5? |
| 00:19.26 |
brlcad |
sure, it's
just random memory |
| 00:19.38 |
brlcad |
something is
wrong with the tree structure |
| 00:19.50 |
brlcad |
i'm guessing
that the regex fails to parse a matrix, so it never sets the
matrix |
| 00:19.58 |
brlcad |
then gets to
code that attempts to validate the matrix |
| 00:20.10 |
brlcad |
and
boom |
| 00:20.38 |
brlcad |
but you could
also get a boom from any of the other fields too, or the tree
structure might happen to be a valid previous tree node and you'd
get further, etc |
| 00:22.18 |
brlcad |
so far,
though, I don't see how we've actually fixed a bug yet other than
you finding the space in the regex |
| 00:25.38 |
starseeker |
one if the if
statements was backwards too |
| 00:25.57 |
starseeker |
but yeah,
neither of those seem to relate directly to that weird
issue |
| 00:28.40 |
brlcad |
it wasn't
though, the return statements was swapped |
| 00:28.47 |
brlcad |
unless it was
wrong before all of this too |
| 00:28.57 |
brlcad |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libged/red.c?r1=43830&r2=43832&pathrev=43832
flipped them |
| 00:34.18 |
CIA-52 |
BRL-CAD:
03brlcad * r44045 10/brlcad/trunk/src/ (30 files in 12 dirs):
consistently call BU_GETUNION() to allocate a new union tree node
and RT_INIT_TREE() to initialize that node instead of setting the
magic value directly. |
| 00:36.20 |
brlcad |
okay, now to
rebuild and see if that makes any difference whatsoever |
| 00:52.05 |
starseeker |
brlcad: oh, I
was referring to a different one - I think it was wrong to start
with |
| 00:54.46 |
brlcad |
starseeker:
so recap, you can't change the name during red right? |
| 00:57.57 |
brlcad |
also, matrix
edits during red are not working in my testing, they get
ignored |
| 00:58.34 |
brlcad |
good/bad
news, though .. can't get it to crash |
| 01:00.49 |
CIA-52 |
BRL-CAD:
03brlcad * r44046 10/brlcad/trunk/TODO: keep seems to be working,
red is no longer crashing but isn't editing matrices
either |
| 01:01.03 |
brlcad |
at least,
keep tested clean on linux |
| 01:09.08 |
*** join/#brlcad yukonbob
(~bch@S0106002129e399fc.ok.shawcable.net) |
| 01:09.18 |
yukonbob |
hello,
#brlcad |
| 01:11.02 |
*** join/#brlcad crazy_imp
(~mj@a89-182-208-48.net-htp.de) |
| 01:27.03 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 01:57.29 |
brlcad |
howdy
yukonbob |
| 01:57.54 |
brlcad |
starseeker:
just noticed that your crash report was on the same tree node
member, the matrix |
| 01:58.10 |
brlcad |
so
undoubtedly related to setting it during red |
| 02:09.48 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) |
| 02:26.28 |
CIA-52 |
BRL-CAD:
03brlcad * r44047 10/brlcad/trunk/src/libbu/stat.c: |
| 02:26.28 |
CIA-52 |
BRL-CAD:
treat empty strings the same as null, i.e., a special case similar
to NaN |
| 02:26.28 |
CIA-52 |
BRL-CAD:
implying not a file so never will match true even if stat() might.
similarly, |
| 02:26.28 |
CIA-52 |
BRL-CAD: for
comparing to files, empty strings should never match. (two empty
string |
| 02:26.29 |
CIA-52 |
BRL-CAD:
filenames are not the same file, they are no file). |
| 02:29.38 |
starseeker |
brlcad:
that's very odd - I was able to edit a matrix earlier
today... |
| 02:30.17 |
starseeker |
yeah, logic
for name change isn't present yet |
| 02:30.30 |
CIA-52 |
BRL-CAD:
03brlcad * r44048 10/brlcad/trunk/include/bu.h: document the
behavior on empty strings |
| 02:31.25 |
brlcad |
k |
| 02:31.36 |
CIA-52 |
BRL-CAD:
03brlcad * r44049 10/brlcad/trunk/src/libged/red.c: |
| 02:31.38 |
CIA-52 |
BRL-CAD:
another attempt at a logic cleanup, this time consolidating the
memory cleanup |
| 02:31.38 |
CIA-52 |
BRL-CAD: and
unlinking of the temp file to one place so that the file is
consistently |
| 02:31.38 |
CIA-52 |
BRL-CAD:
closed. some conditions weren't closing the file. this only
modifies ged_red() |
| 02:31.38 |
CIA-52 |
BRL-CAD: and
shouldn't be a change to flow logic. |
| 02:34.12 |
starseeker |
unfortunately, something about the ged
string handling results in the error messages from ged_red getting
squashed |
| 02:34.27 |
starseeker |
I recall Bob
saying something about why that was once, but I don't
recall |
| 02:34.59 |
brlcad |
all part of
the refactoring suck |
| 02:35.10 |
brlcad |
some ged
functions reset the result string, some don't |
| 02:35.23 |
brlcad |
so if you
have a ged func that calls another ged func, it may or may not
reset the result |
| 02:35.30 |
starseeker |
ah |
| 02:35.45 |
brlcad |
if the clean
refactoring was complete, there'd be no need to reset the result in
any func |
| 02:36.13 |
brlcad |
except the
one top-level wrapper executing the main command |
| 02:36.32 |
brlcad |
if even then,
could be a result array |
| 02:39.29 |
CIA-52 |
BRL-CAD:
03starseeker * r44050 10/brlcad/branches/cmake/ (46 files in 19
dirs): MFC r44049 |
| 02:39.42 |
brlcad |
starseeker:
another curiosity, I edited a region with red and it listed rgb and
color as an attribute |
| 02:39.55 |
starseeker |
both of
them? |
| 02:39.57 |
brlcad |
looking at
the logic in write_comb(), that shouldn't be possible since it's a
standard attribute |
| 02:40.01 |
brlcad |
yep |
| 02:40.08 |
starseeker |
growl... |
| 02:40.34 |
starseeker |
it might be
doing that if a pre-existing region has both... I don't
recall |
| 02:41.02 |
brlcad |
fwiw, it was
havoc, rt_r.pyl1 |
| 02:41.41 |
brlcad |
attr show
only lists rgb |
| 02:42.25 |
starseeker |
if it's
pulling color from the comb struct and rgb from attributes that
MIGHT do it |
| 02:42.29 |
starseeker |
more likely I
screwed up |
| 02:42.55 |
brlcad |
looks like
write_comb() doesn't look at the struct members |
| 02:43.35 |
starseeker |
it's probably
in the standardization routines then |
| 02:46.15 |
brlcad |
curious that
you manually list the standard attributes just to get the max
length for pretty printing |
| 02:47.38 |
starseeker |
brlcad: those
routines are certainly candidates for improvement |
| 02:49.22 |
brlcad |
if I'm
reading the correctly, it looks like it may even potentially update
a read-only database |
| 02:49.44 |
starseeker |
winces |
| 02:50.02 |
brlcad |
ah, it'll try
but then get bitched at lower-level by librt |
| 02:50.16 |
brlcad |
still.. the
in-mem is modified |
| 03:01.40 |
CIA-52 |
BRL-CAD:
03brlcad * r44051 10/brlcad/trunk/TODO: note a few of the red
issues remaining |
| 03:04.32 |
CIA-52 |
BRL-CAD:
03brlcad * r44052 10/brlcad/trunk/src/libged/ (ged_private.h
put_comb.c): delims is only used in put_comb.c so it doesn't need
to be an extern'd global. same for ged_tmpcomb. |
| 03:05.49 |
CIA-52 |
BRL-CAD:
03brlcad * r44053 10/brlcad/trunk/src/libged/red.c: |
| 03:05.49 |
CIA-52 |
BRL-CAD:
delims was moved to put_comb, not used here. refactor the
Combination Tree |
| 03:05.49 |
CIA-52 |
BRL-CAD:
separator so it's only in one place. put the matching regexp up
next to it so |
| 03:05.49 |
CIA-52 |
BRL-CAD:
changes to one can be reflected in the other, otherwise will be
brittle to |
| 03:05.49 |
CIA-52 |
BRL-CAD:
future edits. |
| 03:07.12 |
CIA-52 |
BRL-CAD:
03brlcad * r44054 10/brlcad/trunk/src/libged/red.c: if the regex is
going to have the newline, make the separator have it
too |
| 03:30.12 |
CIA-52 |
BRL-CAD:
03brlcad * r44055 10/brlcad/trunk/src/libged/red.c: ouch.
write_comb() needs a rewrite. it's modifying data it should not be
modifying at this point in our processing. just asking for
trouble. |
| 03:42.08 |
CIA-52 |
BRL-CAD:
03brlcad * r44056 10/brlcad/trunk/NEWS: with r44022, richard fixed
two memory management issues introduced during a code audit that
reduced the size of an allocation after a conversion from bu_malloc
to bu_calloc as well as double-free on exit. |
| 03:47.24 |
CIA-52 |
BRL-CAD:
03brlcad * r44057 10/geomcore/trunk/src/GS/FileDataSource.cxx: if
one iterator needs it, don't they both? |
| 04:00.46 |
CIA-52 |
BRL-CAD:
03brlcad * r44058 10/geomcore/trunk/src/GS/ (25 files in 2 dirs):
attack of ws indent format consistency. remove useless header
metadata. |
| 05:26.37 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 05:41.45 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 06:16.51 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 06:18.19 |
*** join/#brlcad siddharth__
(~siddharth@117.211.88.150) |
| 06:33.05 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:00.27 |
*** join/#brlcad siddharth_
(~siddharth@117.211.88.150) |
| 07:07.53 |
*** join/#brlcad siddharth__
(~siddharth@117.211.88.150) |
| 08:51.39 |
*** join/#brlcad pawleeq
(~pavel@pc119.iabrno.cz) |
| 10:21.28 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 10:58.10 |
dloman |
Merin
all |
| 11:10.05 |
*** join/#brlcad siddharth__
(~siddharth@117.211.88.150) |
| 11:21.04 |
dloman |
brlcad: Is
there some 'good coding practice' that I am unaware of coming to
play at FileDataSource.cxx:53 ? Why do we need to incr the
iterator if its not going to be used again? |
| 11:28.10 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 11:34.37 |
CIA-52 |
BRL-CAD:
03davidloman * r44059 10/geomcore/trunk/ (include/Portal.h
src/libNet/Portal.cxx): Add convenience method for sending a
typeonly msg to client. |
| 11:38.14 |
CIA-52 |
BRL-CAD:
03davidloman * r44060 10/geomcore/trunk/ (include/DataManager.h
src/GS/DataManager.cxx): Stub in BRLCAD::Object <->
GeometryChunkMsg functions. Simplfy Msg handling by using new
Portal::sendTypeOnly() method. |
| 12:23.17 |
brlcad |
dloman: not
really, only if someone came to that block later and turned it into
a loop |
| 12:27.43 |
brlcad |
I presume
that function is incomplete in some fashion? |
| 12:27.43 |
CIA-52 |
BRL-CAD:
03brlcad * r44061 10/geomcore/trunk/src/GS/FileDataSource.cxx: not
a loop, no need to increment. odd pulling first 'top' object
though. |
| 12:27.58 |
*** join/#brlcad Elrohir
(~kvirc@p5B14A416.dip.t-dialin.net) |
| 12:33.11 |
dloman |
brlcad: just
the way the core interfaces are setup leads to the only real way to
arbitrarily get top objects is via an iterator and the only way to
get the iterator is to use the TopObjectIterator() |
| 12:33.39 |
dloman |
when i have
the time, i plan on expanding the
ConstDatabase/Database/MemoryDatabase functionality. |
| 12:34.40 |
dloman |
getObj()
assumes you only want 1 object, and that's because in our design,
many of the .g files in the repo are going to only have 1
object. |
| 12:37.10 |
dloman |
FFA question:
If i want to use memcpy to copy to a char*, but start at the 5th
char into the array, can i word it like: memcpy(dest+4,src,length)
? |
| 12:38.32 |
brlcad |
I saw getObj
as give me any object from a .g, not necessarily a top
object |
| 12:39.26 |
brlcad |
and yes re.
memcpy |
| 12:41.08 |
dloman |
the
coreInterface classes don't allow you to directly get an object
with out knowing its (string) name, and there is no way to get that
name unless you iterate, starting at the top. |
| 12:42.09 |
dloman |
tree walking
to build an array of Objects hasn't been implemented yet, but thats
ultimately what getObjs will do. |
| 12:42.17 |
brlcad |
sure, that's
the same with librt too |
| 12:42.20 |
dloman |
likely get to
that today. |
| 12:42.30 |
brlcad |
that getObj()
routine sounds like a routine to get a specific named
object |
| 12:43.40 |
dloman |
the fn
documentation will come soon, no worries. |
| 12:43.43 |
brlcad |
so if it has
the name, there should be no involvement of
TopObjectIterator() |
| 12:44.43 |
brlcad |
heh, so fix
the problem by changing the function definition? .. the name alone
implied that (which is a good thing) |
| 12:46.29 |
dloman |
dude, its a
name. can be changed at any time. small potatoes at this point,
especially when everything isn't solidified quite yet. |
| 12:47.47 |
brlcad |
of course,
that's expected |
| 12:47.53 |
brlcad |
just looking
for clarification |
| 12:48.31 |
brlcad |
trying to
work on the code too, and if that's not a function that gets an
object by name, then that obviously changes things |
| 12:49.42 |
brlcad |
if it is
supposed to get an object by name, which is what seemed the more
plausible (and useful) .. then the implementation didn't seem
right |
| 12:50.06 |
dloman |
getObj() gets
the single object at the repo 'path' |
| 12:50.21 |
dloman |
getObjs()
gets multiple object at the repo 'path' |
| 12:51.10 |
dloman |
after
implementing things now, it seems the use of getObj is nearly
nothing, since getObjs can perform the same funciton by returning a
list with one element. |
| 12:51.22 |
brlcad |
nods |
| 12:51.29 |
brlcad |
okay, that
makes more sense then |
| 12:51.34 |
dloman |
performance
and memory wise i am sure they are different. |
| 12:51.38 |
brlcad |
meh |
| 12:51.44 |
dloman |
but im just
going to leave them both for now |
| 12:52.15 |
brlcad |
seems error
prone to allow a getObj when there may be more than one object to
randomly be given "the first one" |
| 12:53.59 |
dloman |
exactly why
im thinking its going to go away soon, provided some profound
reason to keep it. |
| 12:54.58 |
brlcad |
now a general
getObj() that returns a specific object by name would be more
useful |
| 12:55.16 |
brlcad |
but that gets
into what you've named a path there and how that differs from a
geometry path |
| 12:55.51 |
brlcad |
something to
talk about later perhaps |
| 13:22.15 |
CIA-52 |
BRL-CAD:
03brlcad * r44062
10/brlcad/trunk/src/librt/db5_types.c: |
| 13:22.15 |
CIA-52 |
BRL-CAD: add
a new routine that will return a standard attribute name by an
index number, |
| 13:22.15 |
CIA-52 |
BRL-CAD: so
that we have a way to iterate over all the standard attribute
names. this |
| 13:22.15 |
CIA-52 |
BRL-CAD:
simplifies db5_is_standard_attribut() iteration and lets us reuse
the iteration |
| 13:22.15 |
CIA-52 |
BRL-CAD:
elsewhere. |
| 13:27.37 |
CIA-52 |
BRL-CAD:
03brlcad * r44063 10/brlcad/trunk/src/librt/db5_types.c: swap los
and air so that the index coincidentally matches the ATTR_*
returned from db5_standardize_attribute() |
| 13:31.49 |
dloman |
d_rossberg:
are you around? |
| 13:34.42 |
CIA-52 |
BRL-CAD:
03brlcad * r44064 10/brlcad/trunk/src/librt/db5_types.c: even
better, make the index-based lookup exactly match the ATTR_* index
value. convert to an enum for proper numeric indexing. |
| 13:38.18 |
CIA-52 |
BRL-CAD:
03brlcad * r44065 10/brlcad/trunk/src/librt/db5_types.c: document
the need for these needing to not have gaps in their value. only
specify the starting point to make is less error prone. add null
case so gcc thinks we're covering all our bases. |
| 13:50.36 |
CIA-52 |
BRL-CAD:
03brlcad * r44066 10/brlcad/trunk/src/librt/db5_types.c: simplify
db5_standardize_attribute() by unrolling the loops. we have to
perform all the comparisons anyways until we get a match, so just
list them. |
| 13:54.48 |
dloman |
d_rossberg:
I'm having an issue with a Database.Get() call. |
| 13:55.34 |
dloman |
whenever i
get an Object using .Get(), the object's internal db_i* and
diectory* are NULL. |
| 13:56.11 |
CIA-52 |
BRL-CAD:
03brlcad * r44067 10/brlcad/trunk/src/librt/db5_types.c: shorten to
attr |
| 13:58.37 |
dloman |
ConstDatabase::Get(char*)->ConstDatabase::get(char*
ObjectCallback)->ObjectCallbackIntern::operator()->Arb8::Clone()->Arb8::Arb8->Object::Object->Object::Copy() |
| 13:58.41 |
dloman |
thats the
stack trace |
| 13:59.20 |
dloman |
I don't ever
see the m_dbip, m_pDir, or m_ip get copied. |
| 13:59.24 |
dloman |
...is that by
design? |
| 14:01.18 |
brlcad |
starseeker:
can you help? what is db5_standardize_avs() supposed to do? I
don't understand the comment |
| 14:01.57 |
starseeker |
brlcad: one
sec... |
| 14:03.47 |
CIA-52 |
BRL-CAD:
03starseeker * r44068 10/brlcad/branches/cmake/ (6 files in 3
dirs): MFC r44067 |
| 14:04.17 |
starseeker |
hrm... yeah,
looks like brain backfired on that comment |
| 14:04.21 |
starseeker |
checks code... |
| 14:05.20 |
starseeker |
OK, I think
this was the thinking... |
| 14:05.30 |
brlcad |
see if that
says it |
| 14:05.34 |
CIA-52 |
BRL-CAD:
03brlcad * r44069 10/brlcad/trunk/src/librt/db5_types.c: update
comment for db5_standardize_avs(). is my understanding
correct? |
| 14:06.14 |
starseeker |
yeah, that's
pretty much it |
| 14:06.41 |
starseeker |
I think it
might remove the old attribute that it's replacing with the new
one, but will leave additional matches alone |
| 14:06.45 |
starseeker |
let me check
that though |
| 14:07.08 |
brlcad |
yeah, I was
thinking it should remove all the matches |
| 14:07.25 |
starseeker |
the problem
with that is if an existing comb has both color and rgb |
| 14:07.29 |
starseeker |
with
different values |
| 14:07.41 |
brlcad |
sure, but
what does that mean? |
| 14:08.06 |
starseeker |
who knows?
but picking one means destroying one of the color settings, if we
erase both of the old ones |
| 14:08.41 |
starseeker |
yesh, looks
like that one isn't doing any erasing |
| 14:08.47 |
starseeker |
so your
comment is right |
| 14:08.50 |
brlcad |
okay,that's
cool |
| 14:09.05 |
brlcad |
i'd think
we'd either wipe them all out with the new or leave them all intact
and add new |
| 14:09.30 |
brlcad |
we don't know
what that data is but technically "we own it" because it's in the
reserved namespace |
| 14:09.37 |
starseeker |
nods - that MIGHT be why you were seeing multiple color
settings on that havoc region... |
| 14:09.51 |
brlcad |
possibly |
| 14:10.12 |
brlcad |
though later
in red, you go through the whole update/apply thing that should
have consolidated |
| 14:10.17 |
brlcad |
maybe |
| 14:10.28 |
brlcad |
hello
hyarion |
| 14:10.57 |
hyarion |
hi |
| 14:11.52 |
d_rossberg |
dloman: see
the docu of Get() in ConstDatabase.h: this method returns a copy of
the object |
| 14:12.09 |
dloman |
the copy is
disconnected from any database then? |
| 14:12.15 |
dloman |
...by
design? |
| 14:12.18 |
d_rossberg |
this seams to
be a good idea because you close the database after each operation
;) |
| 14:13.02 |
dloman |
righto, that
part is sensible. |
| 14:13.26 |
dloman |
just want to
make sure I'm understanding your code correctly. |
| 14:14.48 |
d_rossberg |
the deeper
reason is the following: |
| 14:16.27 |
d_rossberg |
rt_db_get_internal() (as used in the
Get()) always gives you a copy of the database object on a
rt_db_internal structure |
| 14:17.39 |
d_rossberg |
therefore you
have to carefully choose the moment when to write back
rt_db_internal into the database |
| 14:17.49 |
starseeker |
brlcad: yeah,
it looks like what's happening is db5_update_std_attributes is
ensuring that all of the standard attributes correspond to the comb
structure values - in the process, it's creating any that aren't
already there (like color in the case of rt_r.pyl1) |
| 14:18.47 |
d_rossberg |
i'm doing it
usually when the callback returns (see the callback version of
Get()) |
| 14:19.21 |
d_rossberg |
i.e. the
non-const Get() in Database.h |
| 14:19.32 |
starseeker |
but since I
was trying to go with the "don't destroy information" policy, rgb
got left |
| 14:20.46 |
brlcad |
that's
great |
| 14:21.04 |
brlcad |
defaulting to
don't destroy is always right :) |
| 14:21.20 |
d_rossberg |
another
possibility is to take a copy of the Object explicitely (as you
did) and leave it to the user to write it back to the database with
Set() |
| 14:21.41 |
starseeker |
also, I don't
think db5_apply_std_attributes will remove excess extra
settings... |
| 14:21.48 |
starseeker |
so that part
of the comment may need updating |
| 14:21.53 |
brlcad |
k |
| 14:22.17 |
starseeker |
we can make a
function to do that, but I'd prefer it to be a separate call so the
decision to possibly destroy data is isolated |
| 14:22.17 |
brlcad |
i'm
simplifying standardize_avs() a bit now, given there's a function
that will return the name by type |
| 14:22.23 |
starseeker |
cool |
| 14:22.35 |
brlcad |
reduces
almost all of the cases to just add |
| 14:22.47 |
d_rossberg |
or for short:
Object is the C++ form of rt_db_internal which contains a copy of
an database element |
| 14:23.06 |
starseeker |
now remember why that took so long... lots of annoying little
questions to sort out... |
| 14:23.37 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.156.60) |
| 14:23.37 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:23.59 |
dloman |
d_rossberg:
awesome, thanks man. I figured out that in order to properly
extract a bu_external from an Object, i should use an
ObjectCallback |
| 14:24.34 |
starseeker |
brlcad:
probably the correct thing to do is if there is just one color
attribute (e.g. rgb) it should get renamed |
| 14:24.40 |
starseeker |
so that may
be a bug |
| 14:25.04 |
brlcad |
hm |
| 14:25.19 |
starseeker |
I thought I
had some "first hit for type T" logic that would rename, but maybe
I took it out as too complicated in the inital cut |
| 14:25.32 |
brlcad |
it's half in
there :) |
| 14:25.37 |
brlcad |
some of the
types don't use it |
| 14:25.50 |
starseeker |
ah,
crud |
| 14:26.02 |
d_rossberg |
dloman: btw:
Object has full attribute support including iteration |
| 14:26.44 |
starseeker |
we can get
fancier by checking the value of subsequent hits of the same type
against the stored standard type, and only keep them (and display
them) if they're different |
| 14:27.05 |
brlcad |
still, I see
this as an in-memory "upgrade my avs" routine .. so it can convert
any it finds, consolidate any that are the same value, and
otherwise rename the first to standard form |
| 14:27.06 |
starseeker |
that's
probably the best case - preserve and display conflicting data if
it actually conflicts, otherwise standardize |
| 14:27.22 |
starseeker |
er, yeah
:-) |
| 14:33.24 |
brlcad |
had a memory
leak in there bu_avs_add() already copies the value for
you |
| 14:33.49 |
starseeker |
ah |
| 14:34.02 |
CIA-52 |
BRL-CAD:
03starseeker * r44070 10/brlcad/trunk/include/raytrace.h: Update
db5_is_standard_attribute in raytrace.h |
| 14:39.13 |
CIA-52 |
BRL-CAD:
03starseeker * r44071 10/brlcad/trunk/src/libged/red.c: fix red.c
extern too |
| 14:40.29 |
d_rossberg |
dloman: ps:
this way you can copy an Object from one database to another: Get()
from the first one and Add() to the other one |
| 14:40.53 |
dloman |
excellent |
| 14:41.14 |
dloman |
I am actually
looking to properly create a bu_external, which requires a valid
db_i* and directory* |
| 14:41.59 |
brlcad |
dloman: only
that one routine required a db_i, there are other routines that
work with data in other stages of the i/o process |
| 14:42.13 |
brlcad |
might be
something else that can be used |
| 14:42.33 |
brlcad |
looks |
| 14:45.38 |
brlcad |
what data do
you have now? |
| 14:45.47 |
brlcad |
an
rt_db_internal *? |
| 14:47.08 |
dloman |
well, if hook
into ab Object before it gets .Clone()-ed, then i will have
everything (db_i, rt_db_internal*, resource* and
directory*) |
| 14:47.16 |
dloman |
otherwise, i
have none of those. |
| 14:47.46 |
brlcad |
none? if it
made a copy, you ahve at least the rt_db_internal I'd
think |
| 14:48.00 |
d_rossberg |
dloman: for
low level operations you should consider to use the C API directly,
the C++ interface is definitely not the place for such
tasks |
| 14:49.10 |
d_rossberg |
no, he has
nothing because the database will be closed after getting the
object |
| 14:49.30 |
brlcad |
d_rossberg:
we could still encapsulate serialization as something inherent to
an Object, a Serialize() routine that returns a bu_external for
example |
| 14:50.17 |
brlcad |
d_rossberg:
then how'd it 'get' the object? extracts values into private
member data from the db_intern? |
| 14:52.25 |
d_rossberg |
it has a
private char* for the name, bu_attribute_value_set for the
attributes and rt_~_internal for the element specific
stuff |
| 14:53.10 |
brlcad |
ah, so it
fully uncracks the rt_db_internal |
| 14:53.19 |
d_rossberg |
and
serialization isn't trivial, it depends on the protocol used and
purpose |
| 14:53.51 |
d_rossberg |
e.g. i would
prefer a serialization in xml |
| 14:54.10 |
brlcad |
heh |
| 14:54.36 |
d_rossberg |
or with other
words: this is something for the level above the core
interface |
| 14:55.34 |
brlcad |
and/or below
it |
| 14:56.24 |
brlcad |
i could still
see it providing some default serialization capability that it
could use for persistence and reconstruction |
| 14:56.26 |
d_rossberg |
for the
network my first idea would be to use something like
corba |
| 14:57.13 |
brlcad |
but that's so
much overhead ... |
| 14:57.45 |
brlcad |
and nobody
likes writing corba code :) |
| 14:58.00 |
d_rossberg |
this point is
on you :) |
| 14:58.01 |
brlcad |
except
businesses that are paid/forced to :) |
| 14:59.15 |
*** join/#brlcad Elrohir
(~kvirc@p5B14A416.dip.t-dialin.net) |
| 15:01.27 |
dloman |
who knew the
Dune soundtrack makes cood coding music..... |
| 15:02.18 |
d_rossberg |
however, the
"default serialization" should >mainly< (whatever this will
mean) be database independend because it is used in an abstraction
layer |
| 15:03.21 |
brlcad |
yeah, I'd
think you'd want it to be a black box serialization |
| 15:04.11 |
brlcad |
either to a
generic form (like xml, shudder!) or to an opaque type that you
aren't supposed to inspect beyond passing to a Deserialize()
call |
| 15:04.47 |
brlcad |
I was
thinking more the latter and just ganging up on the existing
serialization routines used for disk since they're compact and
really fast |
| 15:05.29 |
starseeker |
yeah... I
thought the external disk format was a serialization - is there
some situation where that's not appropriate? |
| 15:05.45 |
starseeker |
xml I can see
only as an archival ascii format (maybe)\ |
| 15:05.54 |
brlcad |
starseeker:
it's "not appropriate" if you don't want to deal with binary data
:) |
| 15:06.06 |
starseeker |
ah
heh |
| 15:06.20 |
brlcad |
or want to
pass it through some other parsing engine |
| 15:06.49 |
brlcad |
converting to
asc is technically a serialization too, just a not very interesting
one |
| 15:07.42 |
d_rossberg |
it is the
most interesting one: ican read it |
| 15:08.02 |
brlcad |
how about
json then? even easier to read ;) |
| 15:08.14 |
brlcad |
and less
verbose |
| 15:08.18 |
d_rossberg |
json
who? |
| 15:08.20 |
brlcad |
runs and hides |
| 15:08.40 |
dloman |
should I call
BU_INIT_EXTERNAL on a bu_external prior to passing the bu_external
into db_get_external(..) ? |
| 15:09.16 |
d_rossberg |
wasn't there
a windows ini-file format? |
| 15:09.53 |
brlcad |
dloman: not
necessary |
| 15:10.11 |
brlcad |
d_rossberg:
heh, now you're just talking crazy ;) |
| 15:10.50 |
brlcad |
that's about
as bad as a self-unarchiving shell script |
| 15:12.44 |
starseeker |
d_rossberg:
http://www.json.org/ |
| 15:13.33 |
starseeker |
http://oss.metaparadigm.com/json-c/
would probably be useful |
| 15:13.46 |
brlcad |
I think he
was being facetious |
| 15:13.52 |
starseeker |
ah |
| 15:19.27 |
starseeker |
brlcad: fwiw,
a comb with only one entry and a matrix on that entry DOES allow me
to save the change |
| 15:19.44 |
starseeker |
it's where
there are multiple entries in the comb tree with matricies that I
can confirm the failure |
| 15:19.52 |
brlcad |
okay |
| 15:23.12 |
dloman |
anyone
familiar with a Segfault dealing with _dl_fixup() in
/lib64/ls-linux-x86-64.so.2 ? |
| 15:29.12 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 15:29.26 |
brlcad |
er... ld is
trying to dynamically load something and it can't? |
| 15:29.39 |
brlcad |
shouldn't be
any dynamic loading that I know if |
| 15:30.05 |
dloman |
i hate this
crap :/ |
| 15:30.35 |
brlcad |
what'd you
change that got you into that state? |
| 15:31.03 |
brlcad |
just back up
to the previous commit, work forward in smaller steps |
| 15:31.13 |
dloman |
i literally
copy/pasted a class, changed the guts of one function. |
| 15:32.59 |
brlcad |
are you using
run-time type inference? |
| 15:33.06 |
brlcad |
in that
class |
| 15:34.30 |
dloman |
i don't think
i am |
| 15:34.57 |
dloman |
noob
question: is subclassing considered type inferencing? |
| 15:35.30 |
brlcad |
then it
"probably" was more than a simple copy/paste change, even if that's
all you may have intended .. |
| 15:35.57 |
brlcad |
in general
no, but subclassing a class that uses rtti might get you into
trouble |
| 15:35.58 |
dloman |
heh,
obviously something got messed up. :/ |
| 15:36.58 |
brlcad |
without
sitting at a debug console, "back it up" is probably the easiest
debug route to see where you went wrong |
| 15:37.33 |
dloman |
i've got it
isolated down to a function call, but it doesnt make sense atm.
still trying to figger it out. |
| 15:37.44 |
brlcad |
that error
sounds like the dynamic linker saying "I can't find a class I'm
told to use" |
| 15:39.45 |
dloman |
hrm, if I
comment out the call to db_get_external(), everything works
..... |
| 15:40.13 |
brlcad |
are you
linking librt? |
| 15:40.46 |
brlcad |
could be a
bonefide crash due to bad data or bug and the _dl_fixup is just a
red herring |
| 15:48.33 |
brlcad |
starseeker: I
think I see how the attibute got double-listed |
| 15:48.55 |
brlcad |
rewriting
db5_standarize_avs() is pretty tricky with all of the various
cases |
| 16:05.25 |
dloman |
so its not a
linker issue... i'm linking ALL of brlcad libraries. |
| 16:05.46 |
dloman |
but _dl_fixup
is throwing the segfault, according to gdb |
| 16:11.41 |
dloman |
brlcad: you
still around? |
| 16:14.35 |
brlcad |
yep |
| 16:15.00 |
brlcad |
where's it
segfaulting, what's the rest of the stack? |
| 16:15.04 |
dloman |
Pro tip:
Turns out that bu_malloc is handy for allocating memory for
pointers. |
| 16:15.09 |
dloman |
just
fyi |
| 16:15.14 |
dloman |
facepalms |
| 16:15.24 |
brlcad |
haha |
| 16:15.33 |
brlcad |
bu_calloc()
is even better |
| 16:15.43 |
dloman |
yeah, whats
the diffference? |
| 16:15.48 |
brlcad |
zeros the
memory |
| 16:16.10 |
dloman |
costs a bit
more cpu time? |
| 16:16.15 |
brlcad |
malloc will
allocate you a memory buffer, but there could be any random garbage
in that buffer |
| 16:16.28 |
brlcad |
insignificant |
| 16:16.49 |
dloman |
so there
really is no reason to ever use anything other than
calloc? |
| 16:16.53 |
brlcad |
the system
call itself is two orders more expensive, so might as well spend
one or two clock cycles and have fresh zero'd memory |
| 16:17.31 |
brlcad |
well, if the
very first thing I was going to do with the memory was clear it or
set it, then bu_malloc makes sense |
| 16:18.01 |
brlcad |
but talking
full-allocation set, which doesn't happen very often |
| 16:19.30 |
brlcad |
basically, if
you want to be a little more cautious and avoid some obscure bugs,
use bu_calloc() until you know better :) |
| 16:20.00 |
brlcad |
it's never
"wrong", it just might be unnecessary |
| 16:20.04 |
dloman |
bugs like me,
thus i like calloc |
| 16:20.31 |
brlcad |
it's like
initializing all your variables when you declare them |
| 16:20.38 |
dloman |
right
on |
| 16:20.39 |
brlcad |
I tend to
init to zero and/or NULL |
| 16:20.52 |
brlcad |
but if the
very next thing I'm going to do with them is set their value, it
was pointless |
| 16:21.19 |
brlcad |
if I don't
set their value until later down in the function, it might actually
save my butt some day to init them |
| 16:21.29 |
brlcad |
it might save
me down the road anyways if I just init them |
| 16:22.15 |
brlcad |
starseeker:
if you care to double-check my logic on this, I think I have
it |
| 16:24.12 |
CIA-52 |
BRL-CAD:
03davidloman * r44072 10/rt^3/trunk/ (4 files in 2 dirs): Added the
ability to get a bu_external* from a ConstDatabase and Object.
Needed for serialization |
| 16:25.42 |
CIA-52 |
BRL-CAD:
03brlcad * r44073 10/brlcad/trunk/ (include/raytrace.h
src/librt/db5_types.c): |
| 16:25.42 |
CIA-52 |
BRL-CAD:
document the db5_standard* functions, pulling comments from source
to header and |
| 16:25.42 |
CIA-52 |
BRL-CAD:
expanding with a note that they're new/private.
reimplement |
| 16:25.42 |
CIA-52 |
BRL-CAD:
db5_standardize_avs() using simple two-pass logic so standard
attributes take |
| 16:25.42 |
CIA-52 |
BRL-CAD:
precedence. use db5_standard_attribute() in conjunction
with |
| 16:25.42 |
CIA-52 |
BRL-CAD:
db5_standardize_attribute() in leu of tables so we don't have to
repeat any |
| 16:25.43 |
CIA-52 |
BRL-CAD:
values or even be aware of what is standard or not. |
| 16:25.47 |
brlcad |
that should
prevent the double-listing |
| 16:46.50 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.156.60) |
| 16:46.50 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:15.22 |
starseeker |
brlcad: looks
good |
| 17:25.02 |
CIA-52 |
BRL-CAD:
03davidloman * r44074 10/geomcore/trunk/ (7 files in 4 dirs): Clean
up a few bugs in ByteArray. Added ByteArray copy cstr. Converted
GenericMultibyteMsg and GeometryChunk to use ByteArray objects
(since they are thin wrappers around bu_vls) |
| 17:26.32 |
CIA-52 |
BRL-CAD:
03starseeker * r44075 10/brlcad/trunk/src/libged/red.c: Looks like
this might be the culprit - combtree_op_regex with blank seems to
work for matricies |
| 17:27.04 |
starseeker |
brlcad: does
that let you edit matricies? |
| 17:43.19 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44076 10/brlcad/trunk/src/libged/red.c: include
raytrace.h for prototype. remove extern func decl |
| 17:52.42 |
CIA-52 |
BRL-CAD:
03davidloman * r44077 10/geomcore/trunk/ (include/DataManager.h
src/GS/DataManager.cxx): put in
bu_external<->GeometryChunkMsg conversion
functions. |
| 18:06.54 |
CIA-52 |
BRL-CAD:
03davidloman * r44078 10/geomcore/trunk/include/GeometryChunkMsg.h:
Forgot a file in the ByteArray cleanup.... |
| 18:20.15 |
brlcad |
starseeker:
testing |
| 18:24.26 |
starseeker |
brlcad: I see
you listed red comb renaming as something to support for the next
release? |
| 18:25.10 |
brlcad |
with all this
attention needing to go towards red, might as well finish it while
it's all in context |
| 18:25.33 |
brlcad |
otherwise
it'll never get done unless there's another set of bugs |
| 18:25.36 |
starseeker |
so we should
make write_comb work on copies as well? |
| 18:26.17 |
brlcad |
yeah, I was
basically reviewing from top to bottom |
| 18:26.48 |
brlcad |
got to the
attr stuff, and a bit more to finish up in there |
| 18:27.40 |
brlcad |
sorting out
what this std avs api should look like now |
| 18:29.05 |
brlcad |
if you want
to hit up write_comb in the meantime, you're welcome to but might
be less conflict if you work either on recognizing the name change
or making sure the read-in is robust |
| 18:29.28 |
starseeker |
is working on the rename |
| 18:30.04 |
brlcad |
basically
just trying to get things to a no-hack "done" state without adding
any new functionality/features |
| 18:30.48 |
brlcad |
nice work on
the std avs stuff by the way -- the functions work pretty well
together |
| 18:30.57 |
brlcad |
just that one
missing so far, and maybe some name cleanup |
| 18:31.12 |
starseeker |
thanks
:-) |
| 18:32.07 |
CIA-52 |
BRL-CAD:
03brlcad * r44079 10/brlcad/trunk/include/raytrace.h: add the other
'new' attr funcs that are needed for the symbols to get published.
still a work-in-progress. |
| 18:32.49 |
CIA-52 |
BRL-CAD:
03brlcad * r44080 10/brlcad/trunk/include/raytrace.h: private funcs
till names get changed |
| 18:32.59 |
starseeker |
is there a
case-insenstivie version of the bu string comparison
macro? |
| 18:33.54 |
brlcad |
we use
something in a few other places, maybe strcasecmp |
| 18:35.48 |
brlcad |
yeah, we
surprisingly don't do a lot of string-insensitive
comparisons |
| 18:35.59 |
brlcad |
libfb
options |
| 18:39.08 |
brlcad |
might be
simple enough to add a BU_STRI_EQUAL and friends |
| 18:39.40 |
brlcad |
or
BU_STRCASE_EQUAL |
| 18:45.16 |
brlcad |
starseeker:
the other thing I wanted to change .. you have all that logic in
write_comb for pretty-printing, but standard printf has options
that do most of that built-in |
| 18:48.32 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 18:49.16 |
AbhijitKane |
brlcad: do
you have any info on the old material database /
website? |
| 18:52.12 |
brlcad |
AbhijitKane:
yes, I do |
| 18:52.13 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44081
10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: Flush output
buffer at end of msg write. Implement implement ping, info, fail,
ok, rualive and imalive. |
| 18:52.52 |
AbhijitKane |
brlcad: i've
started with a draft proposal, and was wondering what i could add
to it |
| 18:58.39 |
kunigami |
hi, which
string should be passed to bu_malloc and bu_free? |
| 18:59.17 |
``Erik |
anything that
explains what the memory is for, it's to help in
debugging |
| 19:00.34 |
brlcad |
AbhijitKane:
the existing dev interface is at mater.brlcad.org |
| 19:00.56 |
starseeker |
brlcad: ah,
figures |
| 19:01.16 |
AbhijitKane |
nods |
| 19:01.24 |
starseeker |
wades into the rename logic... |
| 19:01.31 |
kunigami |
ok. I'll pass
the name of the first pointer for which the memory is being
allocated |
| 19:01.36 |
starseeker |
let there be
build failures! |
| 19:02.04 |
brlcad |
kunigami:
just something short but descriptive "alloc foo", "free
foo" |
| 19:02.35 |
brlcad |
the
bu_calloc/bu_malloc string should pair up with the bu_free()
string |
| 19:03.15 |
brlcad |
not
necessarily the same string, but if you were reading a log file,
some reasonable pairing so you could check the pairings if you
needed to |
| 19:04.26 |
kunigami |
hmm what if I
allocated in bu_basename as bu_malloc(..., "foo"), then I tell in
the documentation that bu_free(..., "foo") should be
called? |
| 19:05.09 |
brlcad |
not
necessary |
| 19:05.39 |
brlcad |
maybe
"bu_basename alloc" |
| 19:08.40 |
kunigami |
then
bu_free(..., "bu_basename free")? |
| 19:10.39 |
brlcad |
well the free
happens in userland code, not library code so you don't really have
any control over that |
| 19:14.26 |
kunigami |
hmm,
understood. so I'll just do bu_free(var, "var free"). sounds
good? |
| 19:15.33 |
brlcad |
kunigami: but
where are you calling bu_free? |
| 19:15.57 |
AbhijitKane |
brlcad:
regarding the materials site, could there be google/openID
integration as well? |
| 19:15.57 |
AbhijitKane |
<PROTECTED> |
| 19:16.27 |
kunigami |
right before
the scope of the variable returned by bu_basename ends |
| 19:16.28 |
CIA-52 |
BRL-CAD:
03davidloman * r44082
10/geomcore/trunk/src/libNet/NetMsgRouter.cxx: Use the word
'routing' instead of 'forwarding' when talking about the routing of
NetMsgs. Confused some people, this is better. |
| 19:16.32 |
brlcad |
AbhijitKane:
the issue there is we presently have accounts in drupal and
mediawiki ... there was an effort to integrate them into one ldap
but that's incomplete |
| 19:17.35 |
brlcad |
adding in
google/openID adds more account auth but doesn't integrate with the
other two, so not much of a benefit integration-wise |
| 19:17.52 |
brlcad |
now if you
also update our drupal/MW installs to use google/openID, then
that'd be different |
| 19:18.07 |
brlcad |
could be a
little subtask |
| 19:18.59 |
AbhijitKane |
ok |
| 19:19.00 |
brlcad |
otherwise,
auth is a much lesser concern to getting
add/edit/inherit/view/delete working cleanly |
| 19:20.14 |
AbhijitKane |
yes, getting
the crud operations working properly will be the first
priority |
| 19:20.57 |
brlcad |
crud?
:) |
| 19:22.30 |
AbhijitKane |
create read
update delete. but i'm not sure whether i'm using it in the right
context, lol |
| 19:22.36 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2781
10/wiki/NetMsgTypes: add more info |
| 19:23.48 |
kunigami |
in
brlcad_path.c there's a line: return bu_basename(bu_progname); ---
where bu_progname is a global variable. how to proceed? |
| 19:24.27 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2782
10/wiki/GeometryReqMsg: New page: Message sent to the server to
request data. Single GSString with a URI/URN style encoding of the
geometry (path/to/file.g/top). (Should this be a multistring
message?) |
| 19:26.27 |
brlcad |
kunigami:
probably something similar to bu_argv0_full_path() where it has an
internal static buffer, get the basename, copy into buffer, free
the basename, return the buffer |
| 19:27.42 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2783
10/wiki/GeometryManifestMsg: New page: Sent after a geometry req is
recv'd, but before the chunks are sent. uint32 number of
objects/strings/chunks. List of GSStrings for returned objects.
ReUUID is the same as the GeometryR... |
| 19:30.24 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2784
10/wiki/GeometryChunkMsg: New page: Actual raw binary V5 .g
goodness. ReUUID is the same as the associated GeometryReqMsg's
UUID. There will be the same number of these as there were entries
in the GeometryManifest. NOT ... |
| 19:31.41 |
CIA-52 |
BRL-CAD:
03Erik 07http://brlcad.org * r2785
10/wiki/GeometryChunkMsg: mention length in stream |
| 19:33.24 |
kunigami |
brlcad: hmm
good idea |
| 19:33.35 |
CIA-52 |
BRL-CAD:
03starseeker * r44083 10/brlcad/trunk/src/libged/red.c: Add the
ability for changing name assignment in the red.c text file to
rename the comb being edited. |
| 19:33.41 |
starseeker |
brlcad: there
we go |
| 19:33.50 |
brlcad |
starseeker:
awesome |
| 19:34.22 |
brlcad |
btw, just
found (and hopefully fixed) a particularly egregious bu avs
iterator bug |
| 19:34.23 |
starseeker |
needs another
set of eyes, but it seems to work here |
| 19:34.39 |
starseeker |
in red or in
libbu? |
| 19:34.45 |
brlcad |
libbu |
| 19:34.50 |
starseeker |
ow |
| 19:34.58 |
brlcad |
the
BU_AVS_FOR() macro iterates from the end to the front, from
count-1 |
| 19:35.08 |
brlcad |
so if count
== 0 ... poof |
| 19:35.14 |
starseeker |
winces |
| 19:35.31 |
starseeker |
yeah, that's
not good... |
| 19:38.04 |
CIA-52 |
BRL-CAD:
03starseeker * r44084 10/brlcad/trunk/TODO: r_weiss fixed dem-g
crashes |
| 19:38.14 |
CIA-52 |
BRL-CAD:
03brlcad * r44085 10/brlcad/trunk/include/bu.h: |
| 19:38.14 |
CIA-52 |
BRL-CAD: bad
AVS, no donut for you. BU_AVS_FOR() macro iterator starts from the
end of |
| 19:38.14 |
CIA-52 |
BRL-CAD: the
avs to the beginning. however, if the avs is empty, this would
result in |
| 19:38.14 |
CIA-52 |
BRL-CAD:
indexing into a -1 index and potentially cause a segfault. make the
loop safe |
| 19:38.15 |
CIA-52 |
BRL-CAD: by
setting it to null if count is zero, so it should kick right out of
the loop. |
| 19:39.21 |
brlcad |
hm, that's
insufficient |
| 19:43.47 |
CIA-52 |
BRL-CAD:
03davidloman * r44086 10/geomcore/trunk/ (include/SvnDataSource.h
src/GS/SvnDataSource.cxx): Implement required functions for
SvnDataSource as spelled out by IDataSource |
| 19:50.56 |
CIA-52 |
BRL-CAD:
03davidloman * r44087 10/geomcore/trunk/ (3 files in 2 dirs):
Update data sources to pass back bu_externals instead of Objects.
This isn't optimal, nor do i think it will be permanent, but its
the best approach at the moment. |
| 19:52.40 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44088
10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: implement
geomreqmsg and geommanifestreq. stub geomchunkmsg. |
| 19:54.37 |
CIA-52 |
BRL-CAD:
03davidloman * r44089 10/geomcore/trunk/src/GS/DataManager.cxx:
Make DataManager handle bu_externals rather than
Objects |
| 19:56.46 |
CIA-52 |
BRL-CAD:
03brlcad * r44090 10/brlcad/trunk/include/bu.h: need to make sure
we don't enter the loop with that NULL pointer. halt if iterator or
target is NULL |
| 19:57.54 |
brlcad |
there, that
should allow looping over empty avs |
| 19:57.58 |
CIA-52 |
BRL-CAD:
03davidloman * r44091 10/geomcore/trunk/tests/GS/ (CMakeLists.txt
FileDataSourceTest.cxx): lots of cascading changes to
FileDataSourceTest |
| 20:01.37 |
CIA-52 |
BRL-CAD:
03brlcad * r44092 10/brlcad/trunk/include/bu.h: go a step further
and don't try to dereference the avs if we get handed a NULL
pointer. one more example of the lengths we go to for you. because
we care. |
| 20:04.34 |
dloman |
lol nice
one. |
| 20:04.51 |
dloman |
that's a
bumper sticker if i've ever seen one. |
| 20:06.29 |
*** join/#brlcad volock
(~chatzilla@174.46.225.138) |
| 20:07.39 |
CIA-52 |
BRL-CAD:
03brlcad * r44093 10/brlcad/trunk/include/bu.h: document
BU_AVS_FOR() macro with an example code snippet. |
| 20:10.59 |
CIA-52 |
BRL-CAD:
03brlcad * r44094 10/brlcad/trunk/include/bu.h:
tweakage |
| 20:11.52 |
kunigami |
in nirt/if.c
there's a external array, ValTab. There are at least two elements
of ValTab that store the output of bu_basename. should I use the
static buffer trick? |
| 20:13.37 |
CIA-52 |
BRL-CAD:
03brlcad * r44095 10/brlcad/trunk/src/librt/db5_types.c: use
db5_standard_attribute() instead of hard-coding the standard
attribute names in db5_apply_std_attributes(). also check our
inputs in db5_standardize_avs(). |
| 20:16.17 |
volock |
<PROTECTED> |
| 20:16.18 |
volock |
...though
I've also used BSP and Oct Trees. I'm trying to think out how an
API like is asked for should work. IE. What kind of data it'd be
expecting, etc for crafting my proposal |
| 20:16.49 |
brlcad |
kunigami: at
a glance, you can either wrap the output in bu_strdup() then free
the memory at the end (see 'need_to_free' for similar issue) ... or
you can reuse the existing regionPN buffer presuming ValTab is not
used after that function |
| 20:16.54 |
brlcad |
hello
volock |
| 20:17.44 |
volock |
hello brlcad.
You're Chris right? |
| 20:18.03 |
brlcad |
some people
call me that |
| 20:18.06 |
brlcad |
most call me
Sean :) |
| 20:19.09 |
volock |
Ah. I was
going from memory from reading the wiki you set up for us
prospective GSoC people. You guys definitely have a lot of
interesting coding to do, that looks like a lot of fun. Then again
as an Applied Math and CS double major, my view may be a little
skewed. |
| 20:20.58 |
brlcad |
thanks, most
of us tend to think it's a lot of fun too |
| 20:21.24 |
brlcad |
as for the
spatial partitioning project, the #1 difficulty there is going to
be careful integration |
| 20:22.26 |
brlcad |
that gets at
the very heart of our core library, which is highly optimized for
our current purposes, customers, raytracing, etc |
| 20:23.22 |
brlcad |
ideally,
you'd not only have pretty good familiarity with spatial
partitioning but also with our LIBRT library and how it does what
it does currently |
| 20:24.15 |
brlcad |
even
something as simple as abstracting out what it currently does
without affecting performance could be very tricky |
| 20:24.46 |
brlcad |
much harder
to implement a completely different modular partitioning scheme
that actually out-performs :) |
| 20:25.15 |
brlcad |
so that's not
mean to scare or entice you, it's just the matter-of-facts
surrounding that particular project |
| 20:26.39 |
volock |
Yeah. I have
experience with Spatial Partitioning both from a raytracer and
working for someone doing particle physics. Those were considerably
simpler than this would be obviously. Not only because your problem
contains performance constraints compared to what has probably been
highly optimized code over years, but in the variety of data you'd
want to easily send to the API |
| 20:32.07 |
brlcad |
the other
kicker is that our spatial partitioning has to be at least
partially aware of the construction hierarchy since we use
constructive solid geometry (CSG) where there may be void regions
or unknown overlap conditions |
| 20:32.15 |
brlcad |
we only
rarely deal with polygons so all you really have for binning things
together is a primitive's overall bounding box or bounding
sphere |
| 20:32.17 |
brlcad |
so, what
brought you to brl-cad's ideas list? |
| 20:32.21 |
brlcad |
or
not |
| 20:32.41 |
*** join/#brlcad volock
(~chatzilla@174.46.225.138) |
| 20:33.21 |
kunigami |
brlcad: is
there any guarantee that after the 'need_to_free' region the memory
allocated won't be used? |
| 20:33.45 |
brlcad |
didn't look
through the code that closely, good question :) |
| 20:36.06 |
kunigami |
well,
yesterday you said that if refactoring the code would take more
than 15 minutes I should tell you :P I think I spent at least an
hour on it :) |
| 20:38.06 |
*** join/#brlcad volock
(~chatzilla@174.46.225.215) |
| 20:38.29 |
volock |
Sorry my
internet connection decided to go out |
| 20:38.57 |
brlcad |
kunigami:
yes, fair enough -- it's a task for someone, that doesn't
necessarily need to be you right now |
| 20:39.25 |
brlcad |
if you're
selected, maybe you can finish the job on your own patch if someone
else hasn't by then :) |
| 20:41.05 |
kunigami |
hmm, ok.
that's the only file that is not that trivial to change. All other
ocurrences of bu_basename I've already changed. Should I re-submit
the patch with this new changes for registration? |
| 20:42.35 |
brlcad |
absolutely |
| 20:43.04 |
brlcad |
helps to give
them new name either on the file or the comment, so can tell which
is the latest |
| 20:56.32 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44096
10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: implement
chunking protocol. Add "getgeom" conviencience function |
| 20:58.50 |
kunigami |
brlcad: ok,
I'll append a version on it |
| 21:11.03 |
kunigami |
If I write
more than one proposal and both are accepted, will you take into
consideration the priority of my choices? |
| 21:13.50 |
brlcad |
both can't be
accepted -- we'd narrow it down to one or the other |
| 21:14.15 |
brlcad |
but that
said, your interest definitely matters too, so write down your
priority in the proposal too |
| 21:15.54 |
kunigami |
hmm
ok |
| 21:17.52 |
brlcad |
proposals
often do get changed throughout the course of the summer too, so
long as we're both in agreement on the goals and approach as things
change |
| 21:18.43 |
brlcad |
again, we
care more about integrating new developers than we do about getting
a particular chunk of code written |
| 21:22.21 |
CIA-52 |
BRL-CAD:
03starseeker * r44097 10/brlcad/branches/cmake/ (5 files in 4
dirs): MFC r44096 |
| 21:25.33 |
kunigami |
perfect! |
| 21:27.31 |
kunigami |
hmm, does
anyone know if melange allows editing the proposal? or if I want my
proposal to be reviewed I should write it in other place (google
docs for example) and send only the final revision to
melange? |
| 21:28.57 |
brlcad |
yes, you can
continue to edit up to the deadline |
| 21:29.09 |
brlcad |
we will write
questions and comments there too |
| 21:29.28 |
brlcad |
if you want
feedback beforehand, suggest wiki or google docs |
| 21:29.50 |
brlcad |
otherwise,
not much difference when/where the comments occur -- other than the
earlier the better |
| 21:30.01 |
brlcad |
gets really
hectic in the last few days |
| 21:39.48 |
*** join/#brlcad ``Erik (~erik@BRLCAD.ORG) |
| 21:39.51 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44098 10/geomcore/trunk/src/interfaces/cl/
(gsclient.asd gsclient.lisp gsnet.lisp): break GS net ops into
seperate package |
| 21:56.29 |
CIA-52 |
BRL-CAD:
03starseeker * r44099 10/geomcore/trunk/tests/svntest/
(CMakeLists.txt main.c): Get as far as deleting and adding files
via the commit editor - still don't have the ability to apply
diffs. |
| 22:01.28 |
CIA-52 |
BRL-CAD:
03brlcad * r44100 10/brlcad/trunk/src/librt/db5_types.c: check our
inputs for sanity on all the avs standard attribute
functions |
| 22:06.04 |
volock |
How many
people can BRL-CAD hire through GSoC? And how many typically apply
(out of curiosity)? |
| 22:17.26 |
brlcad |
volock: we
don't consider them as "hires", it's not just a summer
job |
| 22:17.47 |
brlcad |
if it's just
a summer job to you, then GSoC (with any org) might not be right
for you |
| 22:18.18 |
brlcad |
the intention
is to get you involved in open source development as a long-term
contributor |
| 22:20.12 |
brlcad |
otherwise, we
talk about it some at http://brlcad.org/wiki/Google_Summer_of_Code
and this year's slot count specifically at http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 22:25.16 |
CIA-52 |
BRL-CAD:
03starseeker * r44101 10/geomcore/trunk/tests/svntest/main.c: OK,
this creates a new file and gets contents into it. Next step will
be to change the contents of an existing file. |
| 22:41.25 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 23:01.09 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 23:01.09 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011
Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 23:14.33 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
| 23:25.13 |
CIA-52 |
BRL-CAD:
03starseeker * r44102 10/geomcore/trunk/tests/svntest/main.c: grr -
need to figure out how to handle svn_txdelta_run,
apparently... |
| 23:31.40 |
brlcad |
for anyone
that missed our logo limelite: http://imagepaste.nullnetwork.net/viewimage.php?id=1980 |
| 23:32.33 |
brlcad |
to be
repeated in a few hours :) |
| 23:33.28 |
CIA-52 |
BRL-CAD:
03starseeker * r44103 10/geomcore/trunk/tests/svntest/main.c: Hmm -
doesn't look like reading file contents from the repo was the issue
- maybe the md5 checksum is really necessary. |
| 01:10.50 |
*** join/#brlcad crazy_imp
(~mj@a89-182-194-151.net-htp.de) |
| 01:38.13 |
*** join/#brlcad AbhijitKane
(~Abhijit@111.93.5.194) |
| 03:20.51 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 03:26.31 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 03:57.24 |
dloman |
getting a
failure in libged/list.c |
| 03:57.36 |
dloman |
../../../brlcad-trunk/src/libged/list.c:
In function ?_ged_do_list?: |
| 03:57.36 |
dloman |
../../../brlcad-trunk/src/libged/list.c:146:
error: the address of ?avs? will always evaluate as
?true? |
| 03:57.49 |
dloman |
replace ?
with ' |
| 03:58.31 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 04:02.55 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 04:05.30 |
brlcad |
looking |
| 04:09.25 |
brlcad |
dloman: try
that |
| 04:09.37 |
CIA-52 |
BRL-CAD:
03brlcad * r44104 10/brlcad/trunk/include/bu.h: attempt to quell
warning about stack avs reference address always evaluating as
true. |
| 04:10.12 |
dloman |
kk |
| 04:12.01 |
dloman |
compile has
gotten farther than i did last time, so itink u got it. |
| 04:12.39 |
brlcad |
lil
ridiculous |
| 04:25.14 |
CIA-52 |
BRL-CAD:
03brlcad * r44105 10/brlcad/trunk/include/bu.h: add
parens |
| 04:37.54 |
sachinjain |
hey
brlcad |
| 04:38.28 |
sachinjain |
I am trying
to do one of the "quickies" to understand BRL-CAD |
| 04:40.10 |
sachinjain |
there is this
project "Fix 'analyze' command output formatting" |
| 04:40.33 |
sachinjain |
I have made
some changes in the file "src/libged/analyze.c" |
| 04:40.58 |
sachinjain |
bt when I am
compiling, I am not able to see those changes |
| 04:41.19 |
sachinjain |
I
think...there is problem with compiling part |
| 04:41.42 |
sachinjain |
can you tell
me what are all the files that I need to recompile |
| 04:41.43 |
sachinjain |
? |
| 04:43.01 |
sachinjain |
please help
me |
| 04:43.23 |
sachinjain |
I have
already run the "makefile" of "libged" directory |
| 04:47.56 |
dloman |
from the root
of the project, all you should have to do is type
'make' |
| 04:48.13 |
dloman |
and any
changes to source should recompile and link
autojmaticaly |
| 04:50.04 |
sachinjain |
bt that is
taking so much time |
| 04:50.33 |
dloman |
do yo uhave a
multi core computer? |
| 04:51.12 |
sachinjain |
core 2
duo |
| 04:51.19 |
dloman |
okay
then |
| 04:51.33 |
dloman |
try using the
command: 'make -j2' or 'make -j3' |
| 04:51.53 |
dloman |
that will
start 2 or 3 compiling jobs simultaneously. |
| 04:51.54 |
dloman |
things go a
lot faster that way |
| 04:51.59 |
sachinjain |
ok |
| 04:52.07 |
dloman |
many things
in brlcad rely on others being compiled. |
| 04:52.17 |
sachinjain |
hmmm.... |
| 04:52.22 |
dloman |
take the time
and do a full compile and things will work better. |
| 04:52.30 |
sachinjain |
I thought of
recompiling the whole thing earlier |
| 04:52.44 |
dloman |
have you
compiled the entire suite yet? |
| 04:52.48 |
sachinjain |
yup |
| 04:52.52 |
dloman |
kk |
| 04:52.54 |
dloman |
so
'make |
| 04:53.06 |
dloman |
from the root
of the checkout dir shouldn't take too long |
| 04:53.45 |
sachinjain |
gonna ask one
question.... |
| 04:53.54 |
sachinjain |
if I would do
this project.... |
| 04:54.12 |
sachinjain |
then...your
requirement of "making a patch" will be fulfilled |
| 04:54.24 |
sachinjain |
or do I need
to do something more? |
| 04:55.19 |
dloman |
I'll defer
that question to brlcad himself, he's the GSoC Admin for
us. |
| 04:55.34 |
sachinjain |
yeah...I am
asking to him only |
| 04:55.39 |
sachinjain |
no offence to
you dloman |
| 04:55.40 |
sachinjain |
:) |
| 04:55.44 |
dloman |
non
taken |
| 05:28.49 |
brlcad |
poor
sachin |
| 05:32.01 |
bhinesley |
lol |
| 05:36.13 |
CIA-52 |
BRL-CAD:
03davidloman * r44106 10/rt^3/trunk/ (5 files in 2
dirs): |
| 05:36.13 |
CIA-52 |
BRL-CAD: Stub
in MinimalDatabase and MinimalObject. After some thought, reading
and |
| 05:36.13 |
CIA-52 |
BRL-CAD:
notes, a cleaner/simpler way to interface GS and CoreInterface with
eachother is |
| 05:36.13 |
CIA-52 |
BRL-CAD:
needed. These two classes will form the bulk of this new
approach. |
| 06:18.24 |
brlcad |
calls it a night |
| 06:24.59 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 06:24.59 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:52.26 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 07:39.42 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 07:47.24 |
sachinjain |
hey
brlcad |
| 07:51.11 |
sachinjain |
brlcad : are
you there? |
| 08:05.55 |
sachinjain |
hey...is
there a way to decrease the compiling time? |
| 08:06.33 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 08:19.19 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 08:24.48 |
CIA-52 |
BRL-CAD:
03davidloman * r44107 10/rt^3/trunk/ (4 files in 2 dirs): Match up
cstr and dstr signatures with superclass. |
| 08:29.51 |
sachinjain |
hey...dloman |
| 08:29.58 |
sachinjain |
that
recompiling is taking so much time |
| 08:47.49 |
sachinjain |
dloman : I am
getting some error while recompiling |
| 10:33.02 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:49.34 |
dloman |
sachinjain:
.....and the error is? |
| 11:10.25 |
sachinjain |
"libtool:
link: `../../src/libwdb/libwdb.la' is not a valid libtool
archive |
| 11:10.25 |
sachinjain |
make: ***
[libged.la] Error 1" |
| 11:10.30 |
sachinjain |
this is the
error |
| 11:17.51 |
sachinjain |
dloman : are
you there? |
| 11:18.38 |
CIA-52 |
BRL-CAD:
03davidloman * r44108 10/rt^3/trunk/ (6 files in 4 dirs): Add tests
into build. Clean up remnants of old cmake system. Add libge
tests. |
| 11:21.47 |
dloman |
sachinjain:
did you do a clean prior to the rebuild? |
| 11:24.43 |
sachinjain |
no |
| 11:25.10 |
dloman |
try a 'make
clean' |
| 11:25.17 |
dloman |
then a 'make
-j3' |
| 11:25.24 |
dloman |
actually |
| 11:25.29 |
dloman |
'make
clean' |
| 11:25.32 |
dloman |
'svn
up' |
| 11:25.38 |
dloman |
then 'make
-j3' |
| 11:27.56 |
sachinjain |
why am I not
able to see those changes which I had made in a file? |
| 11:28.19 |
dloman |
what
file? |
| 11:28.38 |
sachinjain |
/src/libged/analyze.c |
| 11:30.22 |
sachinjain |
do I have to
recompile the whole thing.... |
| 11:30.51 |
sachinjain |
or can I run
just the "makefile" in /src/libged directory |
| 11:37.00 |
CIA-52 |
BRL-CAD:
03davidloman * r44109 10/rt^3/trunk/ (include/MinimalDatabase.h
src/libge/MinimalDatabase.cxx): Stub in desired functions for
MinimalDatabase |
| 11:38.18 |
dloman |
all you
should have to do is type 'make' form the top level directory for
any changes. |
| 11:38.26 |
``Erik |
you can do it
in just the libged directory, but you'll need to make sure the
dependancies for libged are built first... we usually do a big
"make" after configure, then just keep running make when we update
things. Make won't rebuild files it doesn't have to (my old mac
takes about 14 seconds over nfs) |
| 11:43.31 |
CIA-52 |
BRL-CAD:
03davidloman * r44110 10/rt^3/trunk/ (include/MinimalObject.h
src/libge/MinimalObject.cxx): Fill out MinimalObject fields and
associated Getters. |
| 11:46.59 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 11:49.56 |
CIA-52 |
BRL-CAD:
03davidloman * r44111 10/rt^3/trunk/include/MinimalObject.h:
Protect MinimalObject cstr, should not be public. |
| 11:54.56 |
CIA-52 |
BRL-CAD:
03davidloman * r44112 10/rt^3/trunk/tests/libge/ (CMakeLists.txt
GeometryEngineTest.cxx): Add libge to cmake link list. Flesh out GE
Test a bit more. Make fn for standard db generation for
testing. |
| 11:55.43 |
CIA-52 |
BRL-CAD:
03davidloman * r44113 10/rt^3/trunk/ (include/MinimalObject.h
src/libge/MinimalObject.cxx): Add a temporary debug fn for printing
MinimalObject's internal state. |
| 11:57.30 |
CIA-52 |
BRL-CAD:
03davidloman * r44114 10/rt^3/trunk/src/libge/MinimalDatabase.cxx:
Stub in NULL returns in all functions till implemented. |
| 12:12.24 |
brlcad |
sachinjain:
you can rebuild in just the subdir, but you may have to run make
depends first |
| 12:12.38 |
brlcad |
``Erik: all
sorts of tinyproxy errors |
| 12:22.20 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 12:25.32 |
sachinjain |
dloman : did
you get my messages? |
| 12:26.02 |
dloman |
nope. /msg
here or email or.... ? |
| 12:26.23 |
sachinjain |
I have made
some changes to the file "/src/libged/analyze.c" |
| 12:26.30 |
sachinjain |
and then
rebuild the whole thing |
| 12:26.38 |
sachinjain |
bt now...when
I am running "analyze" command through mged terminal... |
| 12:26.46 |
sachinjain |
I am not able
to see those changes |
| 12:27.04 |
starseeker |
sachinjain:
are you running from the build directory or the install
directory? |
| 12:27.08 |
starseeker |
e.g. did you
run make install? |
| 12:27.30 |
sachinjain |
from the root
directory? |
| 12:27.42 |
starseeker |
how are you
running mged? |
| 12:27.46 |
starseeker |
just typing
mged? |
| 12:27.59 |
sachinjain |
yeah |
| 12:28.14 |
starseeker |
type "which
mged" (no quotes) |
| 12:28.19 |
starseeker |
what does it
report? |
| 12:29.38 |
sachinjain |
/usr/brlcad/bin/mged |
| 12:30.04 |
starseeker |
that's why
your not seeing changes - when you type mged you're getting the
installed version |
| 12:30.12 |
sachinjain |
so? |
| 12:30.28 |
starseeker |
you either
have to run make install so your altered version is installed, or
specifically run the version in the build directory |
| 12:30.29 |
sachinjain |
what do I do
now? |
| 12:31.19 |
starseeker |
just typing
"make" does not put mged in /usr/brlcad/bin/mged |
| 12:31.41 |
sachinjain |
okie... |
| 12:31.44 |
sachinjain |
I got
you |
| 12:31.46 |
sachinjain |
let me try
now |
| 12:35.55 |
sachinjain |
starseeker :
thanks a lot....it worked |
| 12:55.28 |
``Erik |
brlcad:
errors? there was a bit of a fit getting it installed and
configured right (used to use crit for that... how's the user
migration, btw?) |
| 13:01.41 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:04.43 |
brlcad |
d_rossberg:
you raise a lot of good points, I'm responding to the them now --
some conceptual, some more short-term work-in-progress
mes |
| 13:15.48 |
sachinjain |
brlcad : I am
working on one of the quickies "Fix 'analyze' command output
formatting".... |
| 13:16.25 |
sachinjain |
will that
complete your requirement of "making a patch" |
| 13:16.27 |
sachinjain |
?? |
| 13:20.04 |
brlcad |
sachinjain:
it's not our requirement, it's you showing us how well you
code |
| 13:20.32 |
brlcad |
when you're
satisfied that you've shown your ability, submit it |
| 13:21.05 |
sachinjain |
okie |
| 13:32.20 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 13:33.26 |
d_rossberg |
brlcad: i've
a lot of ideas for if you plan to support a new API, e.g. a
NetDatabase which implements the client side and provides an
application the same interface as the other Databases in
coreInterface |
| 13:34.09 |
d_rossberg |
this makes it
easy to write client programs for stand-alone and network
applications |
| 14:07.31 |
dloman |
d_rossberg:
Didn't mean to cause you alarm. I'm simply trying to find a way to
leverage your coreInterface work for what we need the
GeometryService to do. Cleanup to follow shortly. |
| 14:34.29 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 14:39.56 |
CIA-52 |
BRL-CAD:
03davidloman * r44115 10/rt^3/trunk/ (8 files in 4
dirs): |
| 14:39.56 |
CIA-52 |
BRL-CAD: New
approach on getting bu_externals out of coreinterface. last idea
broke the |
| 14:39.56 |
CIA-52 |
BRL-CAD: API
and encapsulation. Using private methods this time around in
a |
| 14:39.56 |
CIA-52 |
BRL-CAD:
non-intrusive manner. CoreInterface should be returned to its
previous state. |
| 14:45.48 |
d_rossberg |
dloman: i
just got an idea on how to solve all your problems with the
coreInterface but the page margin is to small to write it down here
;) |
| 14:46.31 |
dloman |
the approach
I just committed involved extending MemoryDatabase with my own
class, outside of coreInterface |
| 14:46.52 |
d_rossberg |
that's why i
will write it in a reply to Sean's mail |
| 14:50.09 |
d_rossberg |
the core of
the idea was to get the memory out of the memory database, this
would be analogous to getten a file from the
FileDatabase |
| 14:50.34 |
dloman |
righto, i
just want the bytes |
| 14:51.27 |
d_rossberg |
sending this
data over a network and reloading it into a MemoryDatabase would
give you the database (or a single element in it) back |
| 14:52.36 |
dloman |
correct. The
only stipulation is that we are not enforcing the need to use a
MemoryDatabase object on the other end. client could be written in
another language. |
| 14:53.29 |
d_rossberg |
but then you
need a specific data format (not black box) |
| 14:54.20 |
dloman |
correct. We
have a protocol defined to transport the data across the
network. |
| 14:54.53 |
dloman |
in the case
of transporting the geometry, the protocol equates to a header +
geometrydata. |
| 14:55.12 |
d_rossberg |
it is not
about the protocol, it is the data the client must be able to
decipher |
| 14:56.01 |
dloman |
okay then.
Is there something incomplete about the data contained in a
bu_external? (something i missed?) |
| 14:57.10 |
d_rossberg |
you need
BRL-CAD core's C API to decipher bu_external |
| 14:57.39 |
dloman |
nods, that makes sense :) |
| 14:58.08 |
d_rossberg |
i.e. at least
a part of the client has to be written in C |
| 14:58.41 |
starseeker |
d_rossberg:
unless you want to use asc2g, I don't think we have anything
suitable that isn't bu_external for this kind of
thing... |
| 14:59.13 |
dloman |
I believe
there is some java code that can decipher an external, but for the
most part yes, use the brlcad libs or implement their own version
of them in the language of choice |
| 15:00.32 |
d_rossberg |
and then you
are not far away from reinventing the wheel (now in Java, not
C++) |
| 15:00.35 |
starseeker |
we could
update our database format definition document... |
| 15:01.01 |
starseeker |
then there's
a spec people can code deserializers to |
| 15:01.27 |
CIA-52 |
BRL-CAD:
03davidloman * r44116 10/rt^3/trunk/tests/CMakeLists.txt: Cmake
file for the libGE tests needed to include the BRLCAD include
dirs |
| 15:02.13 |
CIA-52 |
BRL-CAD:
03davidloman * r44117 10/rt^3/trunk/tests/libge/CMakeLists.txt:
Cmake file for the libGE tests needed to include the BRLCAD include
dirs (Missed a file) |
| 15:04.07 |
d_rossberg |
my approach
would be to have a high level interface to the database in C++ to
the programmers with the other languages |
| 15:04.40 |
starseeker |
then they
still need one or more of our libraries to decode it
though |
| 15:04.49 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 15:05.42 |
d_rossberg |
for a good
Java programmer it isn't easy to understand all the rt_~ and bu_~
but it is easy to wrap coreInterface with some Java
classes |
| 15:06.16 |
d_rossberg |
it is simply
straight forfard |
| 15:07.53 |
starseeker |
that might
make it simpler for people to wrap functionality in other
languages, but isn't that orthogonal to the question of how to do a
language agnostic wire protocol? |
| 15:08.24 |
CIA-52 |
BRL-CAD:
03davidloman * r44118 10/rt^3/trunk/ (include/MinimalObject.h
src/libge/MinimalObject.cxx): Drop filename as its redundant with
filePath. |
| 15:08.29 |
d_rossberg |
or look at my
.net example: it requires some typing to write the wrapper but not
much thinking |
| 15:09.36 |
d_rossberg |
i wouldn't
call bu_extern language agnostic, it is quit C |
| 15:10.17 |
d_rossberg |
on the other
side, simply reading the messages isn't very useful |
| 15:10.31 |
CIA-52 |
BRL-CAD:
03starseeker * r44119 10/geomcore/trunk/tests/svntest/main.c: grr.
Try a different approach to svn changes. |
| 15:10.47 |
dloman |
starseeker:
if the network stuff was in the CoreInterface and a 'bunch of other
languages' could then use it... in theory at least ;) |
| 15:10.55 |
d_rossberg |
you had to
reimplement all the knowledge about the elements and their
behavior |
| 15:11.45 |
d_rossberg |
and all this
to come out with something veri similar to
coreInterface |
| 15:12.13 |
starseeker |
that's true
for anyone wanting to do a client that doesn't use our libraries
though - are you saying bu_external is worse than some other
encoding for transporting that information? |
| 15:14.45 |
d_rossberg |
the problem
is that i have to go now ;} and the yort answer to your question
is: yes and no; i'll try to clarify it tomorrow |
| 15:15.10 |
dloman |
bah, i *hate*
cliff hangers |
| 15:15.15 |
dloman |
ba-doom
ching |
| 15:15.27 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 15:28.19 |
CIA-52 |
BRL-CAD:
03starseeker * r44120 10/geomcore/trunk/tests/svntest/main.c: Get
set up to test application of diffs - early results
promising |
| 15:37.39 |
*** part/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 15:43.22 |
CIA-52 |
BRL-CAD:
03davidloman * r44121 10/rt^3/trunk/ (include/MinimalObject.h
src/libge/MinimalObject.cxx): Fill out protected constructor
properly. This cstr is the one that the MinimalDatabase will use to
instantiate MinimalObjects |
| 15:48.42 |
CIA-52 |
BRL-CAD:
03davidloman * r44122 10/rt^3/trunk/ (include/MinimalDatabase.h
src/libge/MinimalDatabase.cxx): |
| 15:48.42 |
CIA-52 |
BRL-CAD:
Add/override Load() and Save() as well as make loading and non
loading |
| 15:48.42 |
CIA-52 |
BRL-CAD:
constructors. This must be done in order to preserve filename +
path in the |
| 15:48.42 |
CIA-52 |
BRL-CAD:
MinimalDatabase object. filename and path is required to have so
that |
| 15:48.42 |
CIA-52 |
BRL-CAD:
MinimalObjects generatedd by this MinimalDatabase have all they
required |
| 15:48.42 |
CIA-52 |
BRL-CAD:
information to be transmitted across a network |
| 16:16.23 |
CIA-52 |
BRL-CAD:
03davidloman * r44123 10/rt^3/trunk/ (TODO
src/libge/MinimalDatabase.cxx): Implement getAllTopObjects().
Inefficient, but quick. Time is of the essence. Added TODO item for
tracking purposes. |
| 16:42.37 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.21.195) |
| 16:42.37 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:11.09 |
CIA-52 |
BRL-CAD:
03davidloman * r44124 10/rt^3/trunk/ (3 files in 3 dirs):
Implemented getAllObjects(), getAllTopObjects,
getAllObjectsBelow(). Updated test to reflect. |
| 17:13.47 |
CIA-52 |
BRL-CAD:
03davidloman * r44125 10/rt^3/trunk/tests/CMakeLists.txt: Remove
some debug console printing that accidently made it in. |
| 17:33.07 |
CIA-52 |
BRL-CAD:
03starseeker * r44126 10/geomcore/trunk/tests/svntest/main.c: move
things around a bit so we can test whether changes to a .g are
actually applied. |
| 17:33.10 |
CIA-52 |
BRL-CAD:
03davidloman * r44127 10/geomcore/trunk/src/GS/ (CMakeLists.txt
GeometryProcessor.cxx GeometryProcessor.h): Drop GeometryProcessor.
We have the GeometryEngine for this. |
| 17:37.50 |
starseeker |
wooot! |
| 17:38.11 |
dloman |
starseeker
> svn ? |
| 17:40.52 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.138.254) |
| 17:40.58 |
starseeker |
kinda |
| 17:42.02 |
starseeker |
I still can't
get svn to do it's diff logic, but as long as individual objects
aren't crazy huge it doesn't matter too much - I'm just checking to
see whether the in-repository binary contents match the incoming
binary contents, and if they don't overwrite the old with the
new |
| 17:42.43 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 17:43.08 |
starseeker |
still need a
refinement in that each object diff is currently its own commit
(bad if you just changed 3000 objects) but the proof-of-concept is
there |
| 17:43.51 |
starseeker |
if you take
ktank, edit a couple objects and combs and save that as ktank2.g
(e.g. keep the original ktank.g too, just edit the
copy) |
| 17:44.32 |
starseeker |
you can do
./svnTest ktank.g ktank2.g |
| 17:44.40 |
starseeker |
it will 1.
check in all of ktank.g |
| 17:45.02 |
starseeker |
2. iterate
through ktank2.g comparing objects found there to those in the
repository |
| 17:45.19 |
starseeker |
3. apply any
modifications |
| 17:45.39 |
starseeker |
4.
re-assemble the repository into GS_staging/ktank.g |
| 17:46.45 |
starseeker |
still haven't
handled globals yet |
| 17:50.43 |
CIA-52 |
BRL-CAD:
03davidloman * r44128 10/rt^3/trunk/src/libge/CMakeLists.txt:
Change where some libge headers get installed to. brlcad/include
instead of brlcad/include/brlcad |
| 17:56.27 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.145.2) |
| 17:56.27 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:01.40 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 18:06.22 |
*** join/#brlcad dli
(~dli@dsl-173-248-203-45.acanac.net) |
| 18:09.23 |
CIA-52 |
BRL-CAD:
03davidloman * r44129 10/geomcore/trunk/ (8 files in 2 dirs): Add a
recursion flag to IDataSource::getObjs() and make the cascading
changes. |
| 18:12.16 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.129.35) |
| 18:12.26 |
CIA-52 |
BRL-CAD:
03davidloman * r44130 10/rt^3/trunk/ (include/MinimalObject.h
src/libge/MinimalObject.cxx): Implement helper method:
MinimalObject::getFullRepoPath(). This fn combines the path to the
.g file, the .g file name and the object's name. |
| 18:13.56 |
kunigami |
hi, one of my
proposals will be on the project "consolidate image processing".
the idea is rectoring the code so all individual tools on src/util
will be part of a library? if yes, should them be part of image.c
or libicv? |
| 18:14.21 |
CIA-52 |
BRL-CAD:
03davidloman * r44131
10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx:
Consolidate code by using helper function. |
| 18:18.45 |
kunigami |
*refactoring |
| 18:24.52 |
CIA-52 |
BRL-CAD:
03davidloman * r44132 10/rt^3/trunk/include/MinimalObject.h:
MinimalObject cstr need not be protected any longer.
GeometryService classes will need to instantiate
MinimalObjects. |
| 18:25.20 |
CIA-52 |
BRL-CAD:
0346.251.64.228 07http://brlcad.org
* r2787 10/wiki/User:391_buy_cialis: |
| 18:45.20 |
CIA-52 |
BRL-CAD:
03starseeker * r44133 10/geomcore/trunk/tests/svntest/main.c:
refactor logic that gets bu_external from svn file into its own
function. |
| 18:53.15 |
starseeker |
huh -
https://github.com/tpaviot/oce |
| 19:02.53 |
CIA-52 |
BRL-CAD:
03davidloman * r44134 10/geomcore/trunk/ (2 files in 2 dirs):
Rename chunk<->ext converters to chunk<->obj
converters. Updated implementation for new data types. |
| 19:20.17 |
CIA-52 |
BRL-CAD:
03davidloman * r44135 10/geomcore/trunk/CMake/FindLIBGE.cmake:
Forgot to update the libGE search logic. |
| 19:36.32 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44136
10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: Fix readuint64.
Return t instead of type for automagically handled packets. Handle
disconnect requests. Fix method mapping. |
| 19:39.58 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 19:54.13 |
CIA-52 |
BRL-CAD:
03davidloman * r44137
10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Worked
out a silly allocation bug in
GeometryChunkMsg::chunkToObj() |
| 19:56.41 |
CIA-52 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:46.251.64.228]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 20:07.59 |
CIA-52 |
BRL-CAD:
03erikgreenwald * r44138 10/geomcore/trunk/src/interfaces/cl/
(gsserver.asd gsserver.lisp): basic server |
| 20:11.04 |
CIA-52 |
BRL-CAD:
03davidloman * r44139 10/geomcore/trunk/tests/ (GS/CMakeLists.txt
libNet/CMakeLists.txt): Fix libs linked. |
| 20:13.35 |
CIA-52 |
BRL-CAD:
03davidloman * r44140 10/geomcore/trunk/ (include/FileDataSource.h
src/GS/FileDataSource.cxx): Start wiring up FileDataSource to
GeometryEngine |
| 20:16.19 |
CIA-52 |
BRL-CAD:
03davidloman * r44141 10/geomcore/trunk/src/GS/DataManager.cxx: Add
a list of strings to use to build a manifest. |
| 20:17.09 |
CIA-52 |
BRL-CAD:
03davidloman * r44142
10/geomcore/trunk/tests/GS/FileDataSourceTest.cxx: Update test with
all recent changes |
| 20:17.31 |
kunigami |
#2 question:
I suppose libicv stands for image conversion. I saw there's already
a rotation implementation there, so, it the objective provide all
sort of transformations such as filter, scaling,
threshold? |
| 20:18.30 |
kunigami |
#3 question:
will it contain conversion between different types of image (such
as bw and pix)? |
| 20:23.08 |
CIA-52 |
BRL-CAD:
0399.125.83.101 07http://brlcad.org
* r2793 10/wiki/User:Bhinesley: /* BRL-CAD Project Proposal */
Updated progress |
| 20:26.04 |
CIA-52 |
BRL-CAD:
0399.125.83.101 07http://brlcad.org
* r2794 10/wiki/User:Bhinesley: /* Who I am / Experience */
Reworded |
| 20:33.34 |
CIA-52 |
BRL-CAD:
03starseeker * r44143 10/geomcore/trunk/tests/svntest/main.c: No
clue if this is correct, but it compiles so checkpoint |
| 20:37.53 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 00:06.54 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 00:38.22 |
*** join/#brlcad Ralith_
(~ralith@S010600221561996a.vc.shawcable.net) |
| 00:38.43 |
*** join/#brlcad alex_jon1
(~alex_joni@81.196.65.201) |
| 00:39.38 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 01:11.52 |
*** join/#brlcad crazy_imp
(~mj@89.182.223.38) |
| 02:55.29 |
*** join/#brlcad vtts_
(~vytautas@diz.ktu.lt) |
| 02:55.51 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 03:01.45 |
*** join/#brlcad kanzure_
(~kanzure@bioinformatics.org) |
| 03:01.45 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 03:01.45 |
*** join/#brlcad alex_jon1
(~alex_joni@81.196.65.201) |
| 03:01.45 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
| 03:01.45 |
*** join/#brlcad poolio_
(~poolio@BZ.BZFLAG.BZ) |
| 03:04.51 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 03:44.43 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 03:44.43 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011
Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 04:04.54 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
| 04:06.15 |
*** join/#brlcad kanzure__
(~kanzure@bioinformatics.org) |
| 04:07.11 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 04:07.17 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
| 04:20.17 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 04:38.50 |
*** join/#brlcad kasuga5
(~kasuga5@wlnt-02-042.dsl.netins.net) |
| 05:43.33 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 07:00.00 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 07:25.28 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 07:25.57 |
*** join/#brlcad kasuga5
(~kasuga5@wlnt-02-042.dsl.netins.net) |
| 07:46.25 |
*** join/#brlcad kasuga5
(~kasuga5@wlnt-02-042.dsl.netins.net) |
| 08:23.38 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 08:23.38 |
*** join/#brlcad CIA-105
(~CIA@208.69.182.149) |
| 08:23.38 |
*** join/#brlcad dtidrow__
(~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) |
| 08:23.38 |
*** join/#brlcad Ralith_
(~ralith@S010600221561996a.vc.shawcable.net) |
| 08:23.39 |
*** join/#brlcad kasuga5
(~kasuga5@wlnt-02-042.dsl.netins.net) |
| 08:23.39 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 08:23.39 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
| 08:23.39 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 08:23.39 |
*** join/#brlcad kanzure__
(~kanzure@bioinformatics.org) |
| 08:23.39 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
| 08:23.39 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 08:23.39 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 08:23.39 |
*** join/#brlcad vtts
(~vytautas@diz.ktu.lt) |
| 08:23.39 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 08:23.39 |
*** join/#brlcad bhinesley
(~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) |
| 08:23.39 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 08:23.39 |
*** join/#brlcad WhiteCalf
(MK@whitecalf.net) |
| 08:23.39 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 08:23.39 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
| 08:23.39 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 08:23.39 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 08:23.39 |
*** join/#brlcad hyarion
(c05ben@peppar.cs.umu.se) |
| 08:23.39 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 08:23.39 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 08:23.39 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 08:23.39 |
*** mode/#brlcad [+o ChanServ] by
verne.freenode.net |
| 08:45.14 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 09:11.20 |
dloman |
reads GSOC proposals..... |
| 09:17.18 |
dloman |
Whoa, a Head
System Admin for a university doesn't know what IRC is? oh
dear..... |
| 09:35.05 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 09:37.36 |
dloman |
okay, now
that's done. |
| 09:37.39 |
dloman |
interesting
reads |
| 09:39.14 |
dloman |
needs about 10 more cores in my laptop :) |
| 09:44.00 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 09:44.41 |
*** join/#brlcad vtts
(~vytautas@diz.ktu.lt) |
| 09:45.06 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
| 10:46.35 |
kunigami |
hi, any
comments on my proposals? thanks :) |
| 10:47.46 |
CIA-105 |
BRL-CAD:
03davidloman * r44170
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java:
GSConnection need not extend Thread. Limits implementation and
restricts the end user's design. |
| 10:51.56 |
CIA-105 |
BRL-CAD:
03davidloman * r44171
10/geomcore/trunk/src/interfaces/java/test/org/brlcad/geometryservice/
(LoginTest.java SerialTest.java UUIDSerialResearch.java): Add in
some tests and research. These were created some time ago but were
never committed. |
| 10:53.34 |
CIA-105 |
BRL-CAD:
03davidloman * r44172
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java:
Update for starting of worker thread. |
| 11:06.46 |
dloman |
kunigami:
other than the lisencing issues starseeker mentioned, I'd offer the
idea of providing a detailed list of the standalone apps you are
consolodating. |
| 11:07.41 |
kunigami |
ok! could you
confirm that my proposal for 'shader enhancements' is visible for
you? |
| 11:08.23 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 11:08.33 |
dloman |
i can see it
yes. |
| 11:09.19 |
kunigami |
ok, thanks.
I'll edit my proposal ASAP |
| 11:10.34 |
dloman |
a detailed
list of apps provided in the begining gives you a better way to
gauge your progress and, overall, helps to more definitively
determine success or not. |
| 11:10.38 |
dloman |
just an
idea |
| 11:12.00 |
kunigami |
perfect, I
agree |
| 11:13.09 |
*** join/#brlcad kasuga5
(~kasuga5@wlnt-02-042.dsl.netins.net) |
| 11:37.36 |
*** join/#brlcad kasuga5_
(~kasuga5@wlnt-02-042.dsl.netins.net) |
| 11:40.16 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 11:43.36 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 11:56.21 |
*** part/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 11:57.56 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 12:17.08 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:33.25 |
CIA-105 |
BRL-CAD:
03brlcad * r44173
10/brlcad/trunk/src/libged/screengrab.c: |
| 12:33.25 |
CIA-105 |
BRL-CAD:
identify that this is a major encapsulation problem. this
introduced a new |
| 12:33.25 |
CIA-105 |
BRL-CAD:
dependency on libdm/libfb, which totally sucks and blows library
encapsulation. |
| 12:34.55 |
CIA-105 |
BRL-CAD:
03brlcad * r44174 10/brlcad/trunk/src/libged/Makefile.am: gah, as
expected, this introduced a new dependency. regression fail. maybe
need a test to prevent this from occurring on all the core
libraries (making calls to libraries that shouldn't be
linked. |
| 12:39.43 |
brlcad |
is really in disbelief ... seriously? there shouldn't have to
be training wheels to prevent this sort of crap
coding |
| 12:52.01 |
CIA-105 |
BRL-CAD:
03brlcad * r44175 10/brlcad/trunk/TODO: cliff added support for
name changes on red (needs NEWS). still need to indep test matrix
edit. more importantly, need to undo the mess added to
libged. |
| 12:59.28 |
``Erik |
O.o |
| 13:08.44 |
brlcad |
wonders how libged is even compiling without a libdm link, is
it all really header macros? |
| 13:10.01 |
brlcad |
begs for
further separation of include into subdirs, so you can't get away
with this so easily |
| 13:10.56 |
``Erik |
<-- has
always been a fan of keeping the headers with the source,
src/libbu/bu.h etc |
| 13:11.13 |
brlcad |
but then you
can't distinguish public from private |
| 13:11.53 |
brlcad |
at least
without making it stupid obvious like bu_private.h or
bu_don_t_use_me.h |
| 13:11.58 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 13:12.06 |
``Erik |
not without
having a convention in naming or looking at the .am, but *shrug*
hasn't bothered me |
| 13:12.31 |
brlcad |
then someone
just renames the file or worse, just includes it |
| 13:12.45 |
``Erik |
heh,
tieprivate.h librt_private.h ged_private.h :D |
| 13:13.02 |
brlcad |
exactly,
taking double measures to make it stupid obvious |
| 13:13.29 |
``Erik |
so what're
you thinking, include/bu/bu.h ? |
| 13:13.43 |
brlcad |
and how many
of those are STILL bing included where they shouldn't be ..
#include "../librt/librt_private.h" |
| 13:14.52 |
``Erik |
*ponder*
#ifndef BUILDING_LIBRT #error "Stopit." #endif |
| 13:15.17 |
brlcad |
yeah, exactly
that, then adding include/bu to the cppflags so "bu.h" still works,
maybe BU_CPPFLAGS |
| 13:15.51 |
brlcad |
might have to
do something that obtuse really |
| 13:16.37 |
brlcad |
seriously, I
totally expect better .. that sort of training wheels shouldn't be
needed |
| 13:17.55 |
brlcad |
there's only
one or two commiters that might not know better and they're not
even the ones doing this |
| 13:20.23 |
CIA-105 |
BRL-CAD:
03brlcad * r44176 10/brlcad/trunk/TODO: need to group together
library headers into public subdirs. will need to set up proper
cppflags as well similar to the LIBS flags. |
| 13:21.07 |
``Erik |
know anything
about, uh, .dot and graphviz? I wonder if we could use the DEPENDS
line to generate a map |
| 13:21.40 |
CIA-105 |
BRL-CAD:
03brlcad * r44177 10/brlcad/trunk/TODO: help cliff not go
bald. |
| 13:21.42 |
``Erik |
(assuming
that line is generally correct... it's manual, so it does get out
of sync on occasion) |
| 13:21.56 |
brlcad |
yes, I used
graphviz to visualize the CSG graph before .. pretty awesome for
small models |
| 13:22.17 |
brlcad |
had a g-dot
script I wrote up (didn't commit it) |
| 13:22.24 |
brlcad |
havoc was
insane |
| 13:23.00 |
brlcad |
a graphviz of
the libs would be interesting |
| 13:23.05 |
``Erik |
so when is
the cmake merge? I've been using his branch on fbsd mac and win32
without issue |
| 13:23.17 |
brlcad |
after
release |
| 13:23.38 |
brlcad |
which was
today, but now have to undo bob's junk and mabye move
screengrab |
| 13:27.54 |
CIA-105 |
BRL-CAD:
03brlcad * r44178 10/brlcad/trunk/TODO: if we do the subdir, then
there's risk of people going lazy and including via subdir. add a
regression to make sure it's clean code using CPPFLAGS. |
| 13:36.16 |
CIA-105 |
BRL-CAD:
03brlcad * r44179 10/brlcad/trunk/ (10 files in 2 dirs): (log
message trimmed) |
| 13:36.16 |
CIA-105 |
BRL-CAD: I
get it. It was an April Fool's Joke, right?? Revert to r44152 since
it makes |
| 13:36.16 |
CIA-105 |
BRL-CAD: all
sorts of calls to LIBDM macros and the dm struct, requires libdm
header. |
| 14:04.00 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 14:04.33 |
``Erik |
ahm, that
commit removed struct tclcad_obj, which is flipping out
libtclcad/tclcad_obj.c |
| 14:14.50 |
brlcad |
hrm,k |
| 14:15.35 |
brlcad |
ah, I
apparently wasn't up to date |
| 14:17.59 |
brlcad |
now to hunt
down a couple tires before I blow out my slicks |
| 14:18.18 |
``Erik |
heh, noticed
that :) I need to order a full set, myself :/ |
| 14:20.17 |
CIA-105 |
BRL-CAD:
03brlcad * r44180 10/brlcad/trunk/src/libdm/ (Makefile.am adc.c
axes.c grid.c labels.c rect.c scale.c): rest of revert to r44152.
helps to be fully up-to-date during merge. continuation of
r44179. |
| 14:27.52 |
CIA-105 |
BRL-CAD:
03bob1961 * r44181 10/brlcad/trunk/src/libged/ged.c: typo in
comment |
| 14:39.51 |
CIA-105 |
BRL-CAD:
03Erik 07http://brlcad.org * r2815
10/wiki/NetMsgTypes: add bot geometry request |
| 14:45.27 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44182 10/geomcore/trunk/ (3 files in 3 dirs):
add GeometryBoTReqMsg |
| 14:53.03 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44183 10/geomcore/trunk/src/interfaces/cl/
(gsclient.lisp gsnet.lisp gsserver.lisp): add
geombotreqmsg |
| 15:18.34 |
Ralith |
there's a CL
API? awesome |
| 15:19.17 |
``Erik |
it's just me
dorking around with the protocol, it's a keen test bed
:) |
| 15:24.15 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44184
10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: break the
connection loop out so it can be updated with a live session
going |
| 15:25.25 |
*** mode/#brlcad [+o brlcad] by ChanServ |
| 15:58.49 |
dloman |
feels like garbage. might have to take the rest of the day as
leave .... |
| 16:10.40 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 16:27.54 |
brlcad |
kunigami:
which of those two proposals is your main interest? |
| 16:31.13 |
kunigami |
brlcad: I
prefer shader enhancement! |
| 16:31.42 |
brlcad |
oh
really? |
| 16:31.51 |
brlcad |
wouldn't have
guessed that from the proposals :) |
| 16:32.06 |
brlcad |
you plan on
filling out the rest of the details you'd left out
then? |
| 16:32.38 |
kunigami |
:P I think I
mentioned somewhere on "shader enhancement" that this one would
have the greatest priority. let me check |
| 16:33.13 |
brlcad |
you may have,
hadn't gotten to reading it word-for-word yet |
| 16:34.09 |
kunigami |
hmm ok. And
yes, I'm planning to filling out the details. I just wanted to
submit the draft for possible reviews. I've been studying rt's code
this weekend and I already learned something to add on there
:) |
| 16:34.33 |
brlcad |
as they
currently stand written, at a glance, the image processing is much
more clearly composed with goals, scope, integration, plan of
attack, etc |
| 16:34.41 |
brlcad |
okay, good to
know |
| 16:36.26 |
kunigami |
oh yes, I had
a much clearer idea on what to do on image processing. I think I
had the necessary knowledge to write the proposal. For the shader
enhancement one, I have some research to do yet :) |
| 16:37.57 |
kunigami |
but anyway, I
think that the shader enhancement is more challenging. Since I'm
not sure if will be able to write a compelling proposal for this
one, I also did one for the image processing. |
| 16:40.07 |
brlcad |
it definitely
is more challenging :) |
| 16:40.47 |
brlcad |
so part of
the reason is so that we scope to the summer timeframe accordingly
so you can actually make progress and enjoy what you're working on
:) |
| 16:41.33 |
brlcad |
wouldn't want
you to get accepted to work on a hard task and then spend all
summer flailing about in liboptical not making any progress,
getting frustrated in a sea of code :) |
| 16:42.05 |
brlcad |
you won't
likely keep working on that code after the money stops, and that's
not something either of us benefits from :) |
| 16:47.53 |
brlcad |
bhinesley:
comments posted |
| 16:50.40 |
kunigami |
hmm my idea
was actually to keep working (there are a couple of other
rt-related projects that I got interested), but unfortunately I
don't know how will be my time after I finish my
masters. |
| 16:51.23 |
kunigami |
but let us
see what can I offer until the end of the week so you can better
judge if I'll be able to do that in a summer |
| 16:52.52 |
brlcad |
application
deadline is friday so we'll have the following two weeks to review
and elaborate |
| 16:55.03 |
kunigami |
cool! I din't
notice that during after deadline we could add further details to
the proposal! |
| 16:56.05 |
brlcad |
it's supposed
to be more to elaborate, but yes -- there is still some time to
elaborate but at that point it should be in response to our
questions |
| 16:56.49 |
brlcad |
I wouldn't
bank on it -- your proposal should be substantially "done" (i.e.
fully written) by Friday from your perspective |
| 16:57.18 |
brlcad |
no telling
what sort of restrictions the new google-melange interface may
impose after the deadline |
| 16:59.00 |
kunigami |
hmm
ok! |
| 17:03.53 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44185
10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: Enable
multi-threading. New 'stop' function. Hoist session loop. Use
specified dir for geometry instead of cwd. |
| 17:05.22 |
brlcad |
kunigami:
have you read the shaders presentation? |
| 17:05.30 |
brlcad |
it's on the
website somewhere |
| 17:15.42 |
brlcad |
kunigami: in
order to get a quick grasp on shaders for your proposal, I'd
recommend taking the following steps: |
| 17:15.59 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 17:16.04 |
brlcad |
1) download
http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf
and perform at least lessons 1 through 4 |
| 17:17.31 |
brlcad |
1a) through
lesson 7 to get to some basic (phong) shader options |
| 17:17.41 |
brlcad |
2) download
and read http://brlcad.org/w/images/2/2c/Optical_Shaders.pdf |
| 17:19.01 |
brlcad |
3) download
and read appendix B in http://brlcad.com/downloads/documentation/BRLCAD_VolumeIII.pdf |
| 17:22.29 |
brlcad |
that should
give a pretty good survey of what's presently available, should
help reading the code |
| 17:23.25 |
kunigami |
wow, thanks
for the links! I'll surely read them! I've already taken exactly
lessons 1 to 4 on /doc/lessons and learned how to use the basics of
mged and rt :) I'll read the other ASAP |
| 17:24.14 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2816
10/wiki/Shader_Enhancements: add documentation
references |
| 17:26.21 |
brlcad |
the shaders
are unfortunately some of our least documented portions of the code
(because being a content modeling and rendering system are
completely secondardy concerns) |
| 17:27.06 |
brlcad |
that said, we
have support for quite a lot .. some of more hacked and research
quality than other portions, but most all working for a specific
purpose at some point in time |
| 17:29.01 |
brlcad |
OSL has the
ability to replace our current shader string with a more formal and
descriptive shader parameterization, with the description living as
either as a new database object or keeping the string and passing
through to a new liboptical shader |
| 17:30.41 |
kunigami |
hmm
interesting |
| 17:31.36 |
brlcad |
shader
objects are the way to go :) |
| 17:31.49 |
brlcad |
how to deal
with them is the bigger question |
| 17:36.44 |
*** part/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 17:45.33 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 17:46.07 |
dli |
do we still
need openNURBS then? |
| 17:46.16 |
brlcad |
what? |
| 17:48.07 |
dli |
brlcad or you
mean shader is only for displaying, ray-tracing. |
| 17:48.37 |
brlcad |
shaders only
pertain to optics, displaying geometry via raytracing |
| 17:49.26 |
dli |
brlcad, I was
thinking to save all internal geometry as shaders and leave some
computation to GPU |
| 17:49.50 |
dli |
that sounds
too ambitious anyway |
| 17:50.28 |
brlcad |
I'm not sure
you're using the same terminology or there is a big
misunderstanding of some concept |
| 17:50.38 |
brlcad |
"I don't
think that means what you think it means" :) |
| 17:51.40 |
dli |
brlcad, don't
worry, I don't understand the 'shader' part anyway |
| 17:51.47 |
brlcad |
even if
you're thinking of a GPU shader, you still have to have a geometric
representation that goes with it |
| 17:52.07 |
brlcad |
shading
merely answers "how" to draw .. not what |
| 17:52.09 |
dloman |
dli: How many
fingers do you have on your right hand? |
| 17:52.23 |
brlcad |
six! |
| 17:52.36 |
dloman |
egads. |
| 17:52.42 |
dli |
101 |
| 17:53.43 |
brlcad |
dli: speaking
of 101, http://en.wikipedia.org/wiki/Shader
;) |
| 17:54.24 |
brlcad |
or even
better, http://en.wikipedia.org/wiki/Shading |
| 17:55.32 |
dli |
brlcad, I
thought shader also includes manipulating objects |
| 17:55.48 |
brlcad |
you have to
have objects to manipulate in the first place |
| 17:55.55 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2817
10/wiki/Shader_Enhancements: |
| 17:56.16 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44186 10/geomcore/trunk/src/interfaces/cl/
(gsclient.lisp gsnet.lisp gsserver.lisp): fix off by one weirdness
in chunk request |
| 17:56.21 |
brlcad |
and it
doesn't modify the object, it only modifies how it's
displayed |
| 17:57.55 |
dli |
brlcad,
thanks |
| 18:04.33 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44187
10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: remove packet
type display |
| 18:04.55 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44188 10/geomcore/trunk/src/interfaces/cl/
(gsclient.lisp gsnet.lisp): fix malformed expressions |
| 18:06.28 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 18:09.03 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 18:21.34 |
bhinesley |
brlcad: cool,
I responded |
| 18:21.50 |
brlcad |
bhinesley: do
you get e-mail notification? |
| 18:22.02 |
bhinesley |
brlcad: oops,
not to you. page must have cached... |
| 18:22.15 |
bhinesley |
no, how do I
enable that? I was looking everywhere... |
| 18:23.47 |
brlcad |
I just mean
if we post a comment, do they notify you |
| 18:23.49 |
brlcad |
might not be
a feature |
| 18:24.04 |
brlcad |
was in the
past, but it's a new interface this year |
| 18:24.04 |
bhinesley |
unfortunately, they don't |
| 18:24.10 |
brlcad |
k |
| 18:25.34 |
bhinesley |
it seems like
setting up a end-user editable plain text file with command aliases
might not be a bad idea |
| 18:25.57 |
bhinesley |
not for the
project, but in the future |
| 18:26.47 |
brlcad |
users can
(and do) do that now with their .mgedrc file |
| 18:27.07 |
bhinesley |
oh alright, I
had no idea (obviously) |
| 18:27.14 |
brlcad |
it would be
nice to formalize that into specific packages, though |
| 18:27.28 |
brlcad |
it's
basically akin to using the alias command and your .profile
now |
| 18:28.09 |
bhinesley |
ah |
| 18:28.15 |
brlcad |
more useful
would be command alias "packages" for things like "legacy mode
commands", "dwayne's extensions", etc |
| 18:28.36 |
starseeker |
thinks that's the way to go if we "clean up" our existing
commands - a "legacy.tcl" file or some such |
| 18:29.33 |
brlcad |
they should
register as plugins, though, and then get enabled via the options
gui |
| 18:30.13 |
brlcad |
so we can
ship multiple configurations that you can just checkbox on/off, or
they can toss in their own subdir into an install or homedir and
get listed too |
| 18:30.25 |
bhinesley |
that sounds
good |
| 18:30.32 |
bhinesley |
is it just
the alias token, or is there a way to change the default command
names? |
| 18:30.48 |
brlcad |
there's a way
to change the default names |
| 18:31.02 |
bhinesley |
okay, that's
what I was getting at |
| 18:31.08 |
brlcad |
so in theory
these packages could override everthing |
| 18:31.27 |
bhinesley |
sounds like a
good GSoC project ;) |
| 18:31.43 |
brlcad |
getting
libged cleaned up is more important right now :) |
| 18:31.48 |
bhinesley |
sure |
| 18:32.18 |
brlcad |
that
establishes the command baseline, one reusable across
applications |
| 18:32.48 |
bhinesley |
yeah, I see
that it makes sense to do that first |
| 18:33.53 |
brlcad |
that gets at
the command registration I was referring to in my comment, so
commands would register themselves with libged as an extension of
the library, describe their capability, implement functionality --
then each command would get mapped to one or more names for
scripting purposes, various GUI widgets, and into the help
system |
| 18:35.48 |
bhinesley |
that would be
ideal |
| 18:35.54 |
bhinesley |
highly
modular |
| 18:36.12 |
brlcad |
that's the
long-term goal |
| 18:36.27 |
brlcad |
so lots of
cleanup, LOTS of refactoring to get there |
| 18:37.54 |
bhinesley |
so the idea
is to keep things as contained as possible, for now |
| 18:38.05 |
bhinesley |
? |
| 18:38.22 |
brlcad |
what do you
mean? |
| 18:38.39 |
brlcad |
the idea is
to move towards that completely modular goal :) |
| 18:39.20 |
CIA-105 |
BRL-CAD:
03starseeker * r44189 10/brlcad/branches/cmake/ (19 files in 6
dirs): MFC r44188 |
| 18:39.25 |
brlcad |
getting the
command logic all in one place, making the two main apps (archer
and mged) call through to libged to get at that command -- ideally
without being aware of that command directly |
| 18:41.57 |
*** join/#brlcad Ralith
(~ralith@d142-058-173-143.wireless.sfu.ca) |
| 18:42.03 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 18:42.07 |
bhinesley |
I thought
that you were implying that these capabilities were not yet
possible |
| 18:42.54 |
bhinesley |
nevermind... |
| 18:47.55 |
CIA-105 |
BRL-CAD:
03starseeker * r44190
10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Update
libtclcad CMakeLists.txt file |
| 18:48.02 |
brlcad |
which is
where your gsoc proposal comes in .. |
| 18:48.58 |
brlcad |
you can
override commands and do things to them now, but there's no system
in place for managing them and the commands are listed all over the
place |
| 18:50.05 |
CIA-105 |
BRL-CAD:
03starseeker * r44191
10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Ah, right -
add tclcad_obj.c |
| 18:50.44 |
kunigami |
brlcad: I
commented on your question about my time during the summer. Could
you see what do you think? thanks |
| 18:59.24 |
bhinesley |
brlcad: at
this point, I would feel more comfortable starting with the command
migration. Perhaps after the GSoC I could take on the goal of
highly modular commands. |
| 19:01.45 |
brlcad |
kunigami:
sure, it'll be a while though |
| 19:02.08 |
brlcad |
bhinesley:
fair enough -- even working on command migration is moving towards
modular commands |
| 19:09.57 |
sachinjain |
brlcad : how
to upload a patch on sourceforge |
| 19:11.37 |
brlcad |
sachinjain: I
suggest searching the web, there are LOTS of tutorials on how to
create a patch using subversion, and how to upload to our patches
tracker should be outright obvious (search for it) |
| 19:16.21 |
CIA-105 |
BRL-CAD:
03bob1961 * r44192 10/brlcad/trunk/ (include/ged.h include/tclcad.h
src/libtclcad/tclcad_obj.c): Mods to get libtclcad compiling
again. |
| 19:27.20 |
bhinesley |
brlcad: okay,
comment posted now. I'm leaving for class. |
| 19:27.26 |
CIA-105 |
BRL-CAD:
03starseeker * r44193 10/brlcad/branches/cmake/ (include/ged.h
include/tclcad.h src/libtclcad/tclcad_obj.c): MFC
r44192 |
| 19:30.09 |
CIA-105 |
BRL-CAD:
03starseeker * r44194 10/geomcore/trunk/src/libgvm/gvm.h: Add a few
more possible gvm header entries. |
| 19:30.13 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 19:34.09 |
*** part/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 19:44.09 |
CIA-105 |
BRL-CAD:
03starseeker * r44195 10/geomcore/trunk/src/libgvm/gvm.h: will
probably want to populate lists from repositories to have an easy
format to send over the wire. |
| 19:49.52 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 20:08.33 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 20:25.25 |
starseeker |
wonders wy db_update_ident is used to update both title and
units - why not just one function for title and another for units?
or even just have _GLOBAL use normal bu_avs
pairs? |
| 20:33.50 |
starseeker |
or does
it... |
| 20:33.51 |
starseeker |
hmm |
| 20:36.55 |
brlcad |
_GLOBAL is
just an attribute object |
| 20:38.10 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44196 10/geomcore/trunk/src/interfaces/cl/
(brlcad.asd brlcad.lisp): start up a cffi wrapper for
librt |
| 20:38.27 |
brlcad |
db_update_ident() is historic behavior,
combining title and units together was that way in all previous db
versions iirc |
| 20:39.14 |
brlcad |
maybe even to
reduce two i/o operations to one, but only speculative |
| 20:39.47 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 20:39.48 |
brlcad |
separating
them would make sense now |
| 21:02.12 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 21:02.12 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
| 21:02.12 |
*** join/#brlcad CIA-105
(~CIA@208.69.182.149) |
| 21:02.12 |
*** join/#brlcad kanzure__
(~kanzure@bioinformatics.org) |
| 21:02.12 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
| 21:06.01 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44197
10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: Fix magic sizes
(this may be a bug in librt?). Fix up the rt-open func. |
| 22:46.38 |
CIA-105 |
BRL-CAD:
03bob1961 * r44198 10/brlcad/trunk/src/libged/title.c: Should be
using local2base instead of base2local here. |
| 23:45.37 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 00:30.13 |
starseeker |
Woot! |
| 00:30.20 |
starseeker |
now has 3 Neo1973 phones |
| 01:11.30 |
*** join/#brlcad crazy_imp
(~mj@a89-182-208-247.net-htp.de) |
| 02:03.50 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 02:27.04 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 02:46.18 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) |
| 03:22.50 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 03:58.55 |
brlcad |
starseeker:
haha |
| 04:49.44 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 04:50.07 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 05:57.41 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 06:04.45 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 06:39.26 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 06:39.26 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:10.42 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 09:00.22 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:03.59 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 10:29.15 |
dloman |
Mernin
all |
| 10:36.32 |
kunigami |
good
morning |
| 10:38.54 |
``Erik |
yargh |
| 10:49.23 |
dloman |
so hows the
lisp thing going =D |
| 10:58.01 |
``Erik |
awesome,
files are moving back and forth, etc |
| 10:58.54 |
``Erik |
the next
trick is tesselating geometry to send out on the fly, which is the
brlcad.lisp shtuff (which'll also do images, wireframes, parts of
files, etc) |
| 10:59.25 |
dloman |
are there svn
libs for lisp? |
| 10:59.57 |
``Erik |
probably, but
cffi is quick and easy to write, way nicer than jni |
| 11:00.55 |
dloman |
kewl |
| 11:02.15 |
``Erik |
librt is very
macro and struct heavy, so it's tricky to interface it :/ almost
temped to write getter/setter type funcs for some of the librt
stuff :D |
| 11:02.36 |
dloman |
...write it
in what language? |
| 11:02.56 |
``Erik |
C, in
raytrace.h |
| 11:03.12 |
dloman |
i'd say go
for it :) |
| 11:03.28 |
``Erik |
rt_set_ray(point_t origin, vect_t dir);
etc |
| 11:03.40 |
``Erik |
er, with an
application sturct somewhere in there |
| 11:12.56 |
CIA-105 |
BRL-CAD:
03davidloman * r44199 10/geomcore/trunk/ (2 files in 2 dirs): Add
in an optional replyMsg arg to the objToChunk converter |
| 11:22.39 |
CIA-105 |
BRL-CAD:
03davidloman * r44200 10/geomcore/trunk/src/GS/FileDataSource.cxx:
Oops, forgot to commit FileDataSource::getObjs() ! It's
implemented. |
| 11:23.31 |
CIA-105 |
BRL-CAD:
03davidloman * r44201 10/geomcore/trunk/src/GS/DataManager.cxx:
Cleanup/fixup DataManager::handleGeometryReqMsg. Now uses the
shiney, new, and improved FileDataSource. |
| 11:29.27 |
CIA-105 |
BRL-CAD:
03davidloman * r44202 10/geomcore/trunk/src/GS/GeometryService.cxx:
Make GeometryService objects route GEOMETRYMANIFEST NetMsg's to the
Datamanager |
| 11:41.25 |
CIA-105 |
BRL-CAD:
03davidloman * r44203 10/geomcore/trunk/ (3 files in 3 dirs): Stub
in GetCmd (client cmd) for getting geometry from
server. |
| 12:16.25 |
dloman |
``Erik: whats
with the GeometryBotReqMsg ? |
| 12:17.04 |
dloman |
look
identicle to GeometryReqMsg |
| 12:17.18 |
``Erik |
so far,
eventually it should tesselate the geometry into an inmem db and
send that |
| 12:17.41 |
``Erik |
to feed ogl,
isst, vsl, etc |
| 12:18.23 |
dloman |
why is a *Msg
doing any work other than serialization and deserialization?
tesselation is the job of the GE... isn't it? |
| 12:19.19 |
``Erik |
I d'no how ya
have things wired up, I was just mimicking what I saw :D I imagine
the msg would have to ask ge for a facetized version,
no? |
| 12:20.12 |
dloman |
perhaps, but
that's not the way the gs is architected. |
| 12:21.11 |
``Erik |
okie, it's
hard to read through all that inheritance, d'no where exactly it
should fit... I just figured I'd put SOMETHING there so you could
fix it up later :D |
| 12:21.14 |
dloman |
some function
being executed by some thread would 1) get the geometry from the
DataManager, 2) use the GE to tesselate it and 3) make a
GeometryManifest/Chunk to send the results to the
requestor. |
| 12:21.22 |
dloman |
kk |
| 12:21.40 |
dloman |
there isn't
that much inheritance :) Nothing compared to stuff like QT and
Boost. heh. |
| 12:21.47 |
dloman |
those make me
cry |
| 12:21.58 |
``Erik |
at least
they're documented :> |
| 12:22.16 |
dloman |
:P They're
also stable and released |
| 12:23.41 |
dloman |
..weren't
created by one person, weren't created by someone doing their first
soft dev project, etc, etc. |
| 12:23.46 |
dloman |
the list is
long. |
| 12:24.05 |
``Erik |
(and the only
machine I have with doxygen can't configure geomcore :/
) |
| 12:24.21 |
dloman |
cmake
fails? |
| 12:24.36 |
``Erik |
FindBRLCAD.cmake can't see the (system)
tcl |
| 12:25.14 |
dloman |
bummer |
| 12:25.15 |
starseeker |
``Erik: if
that's using our custom FindTCL there should be a way to expand the
search paths |
| 12:26.08 |
``Erik |
is that
pushed into rt^3, too? |
| 12:26.24 |
starseeker |
uh,
dunno |
| 12:26.44 |
starseeker |
I was waiting
until the ge/gs/gui reshuffle to go through all that |
| 12:29.56 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:10.36 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 13:34.36 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44204
10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: bind libgcv. do
RT_APPLICATION_INIT stuff. use &key to fill some of the
struct. |
| 13:35.05 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44205 10/geomcore/trunk/src/interfaces/cl/
(gsnet.lisp gsserver.lisp): clean up conditional stuff |
| 13:57.34 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 14:18.29 |
CIA-105 |
BRL-CAD:
03davidloman * r44206
10/geomcore/trunk/src/libNet/netMsg/GenericMultiByteMsg.cxx:
Removed some stray debugging lines. |
| 14:19.44 |
brlcad |
so my joking
rant was apparently taken much more to heart than was
intended |
| 14:20.16 |
brlcad |
if anyone in
here had a part in conveying how 'upset' I was, I really
wasn't |
| 14:21.34 |
brlcad |
the initial
crap coding comment was totally meant to be tongue-in-cheek
playful, the rest was simple matter-of-fact |
| 14:21.42 |
CIA-105 |
BRL-CAD:
03davidloman * r44207 10/geomcore/trunk/ (include/GetCmd.h
src/GS/cmds/GetCmd.cxx): Implement GetCmd for the test
client. |
| 14:22.13 |
brlcad |
particularly
with release preparations under way |
| 14:23.11 |
dloman |
Well, if you
want honesty, i was working remotely yesterday and only had IRC to
go by, but you came across as genuinely upset. Just how I read
it. |
| 14:23.32 |
dloman |
based on your
above comments I assume others read it incorrectly also
eh? |
| 14:23.38 |
brlcad |
apparently |
| 14:23.56 |
brlcad |
dislikes conflict, generally very
happy-go-lucky |
| 14:24.47 |
brlcad |
I was annoyed
by the timing, and that probably made some of my remarks more
cynical than usual |
| 14:24.55 |
CIA-105 |
BRL-CAD:
03davidloman * r44208
10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Typo
fix. |
| 14:25.48 |
dloman |
eh, it
happens. As adults we all (should) have thick enough skin to
weather someone's irritation, be it misinterpreted or
not. |
| 14:25.51 |
brlcad |
either way,
the internet sucks at conveying emotion and intent -- I should (and
do) know better and should have known better yesterday |
| 14:26.35 |
brlcad |
also don't
know if this played any part |
| 14:26.44 |
brlcad |
but for the
record |
| 14:26.46 |
brlcad |
reverts
should have NO NEGATIVE CONNOTATION |
| 14:27.17 |
brlcad |
particularly
for open source software projects, something I was taught long ago
that is different from closed development |
| 14:27.37 |
brlcad |
When there is
dispute or need, it's supposed to encourage communication without
any negative connotation. |
| 14:27.46 |
brlcad |
You have just
as much right to revert something I've done if a need
arises. |
| 14:27.53 |
brlcad |
If you
un-revert something I've reverted, then we both stop and discuss
since that implies there are conflicting needs. |
| 14:28.05 |
brlcad |
just an FYI
for everyone :) |
| 14:28.59 |
dloman |
did i miss a
revert war? |
| 14:29.05 |
brlcad |
nope |
| 14:29.25 |
brlcad |
but I did
revert something yesterday and don't know if that played any part
in people "interpreting" my upsetness |
| 14:29.49 |
dloman |
kk. I've
been trying to pay atention to the commit emails and thought I'd
missed yet another important bit of info |
| 14:30.29 |
dloman |
"SO i heard
brlcad was so mad that he punched three old ladies in the
face." |
| 14:30.40 |
brlcad |
it was four
dammit! |
| 14:30.43 |
dloman |
nice |
| 14:32.08 |
CIA-105 |
BRL-CAD:
03davidloman * r44209 10/geomcore/trunk/src/GS/GeometryService.cxx:
Make sure the DataManager point is initialized to something other
than 0x0 prior to attempting to use it. |
| 14:34.19 |
CIA-105 |
BRL-CAD:
03davidloman * r44210 10/geomcore/trunk/src/GS/DataManager.cxx: Add
some error logging so that DataManager won't handle a
GeometryReqMsg silently anymore. |
| 14:43.18 |
CIA-105 |
BRL-CAD:
03davidloman * r44211 10/geomcore/trunk/src/ (3 files in 2 dirs):
Make test client handle geometry data sent by server. |
| 14:45.48 |
dloman |
woot, back to
where i was before the qt rip out :) |
| 14:46.24 |
``Erik |
starts looking for something else to break
O:-) |
| 14:46.35 |
dloman |
lol |
| 14:46.45 |
dloman |
no need, i'm
already too good at breaking things. |
| 14:47.01 |
``Erik |
so ya found
the segfault? |
| 14:47.08 |
dloman |
oh, and take
that damned halo off your head. you're not fooling anyone
:P |
| 14:47.10 |
dloman |
yeah |
| 14:47.31 |
dloman |
keith was
right on with the pointer pointing at garbage |
| 14:59.52 |
CIA-105 |
BRL-CAD:
03Markhobley 07http://brlcad.org *
r2818 10/wiki/MGED_Commands: /* E */ |
| 15:11.55 |
CIA-105 |
BRL-CAD:
03davidloman * r44212
10/geomcore/trunk/src/libNet/NetMsgFactory.cxx: Make NetMsgFactory
log an error when an unknown MsgType is encountered. (Rather than
just returning NULL) |
| 15:16.00 |
CIA-105 |
BRL-CAD:
03davidloman * r44213 10/geomcore/trunk/src/GS/DataManager.cxx: Fix
DataManager's error reporting to the client. Was sending back error
codes as MsgTypes. Now sends MsgTypes as MsgTypes! |
| 15:20.04 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 15:20.36 |
``Erik |
now there's a
cab: http://www.youtube.com/watch?v=OiKFCzMxJik |
| 15:21.37 |
dloman |
nice |
| 15:23.50 |
dloman |
question: int
bu_file_readable(const char *path) |
| 15:24.05 |
dloman |
the int that
is returned.... is it 0 == readable ? |
| 15:39.30 |
``Erik |
nonzero is
readable, src/libbu/stat.c ... if(bu_file_readable(file)) { do
stuff to it; } else { bu_log("u y no has read?"); } |
| 15:41.13 |
dloman |
kk, that's
what I was thinkging, just got confused. |
| 15:41.14 |
dloman |
danke! |
| 15:53.49 |
CIA-105 |
BRL-CAD:
03davidloman * r44214 10/geomcore/trunk/include/FileDataSource.h:
Add in a util function that determines if the supplied path exists
and if it does, whether or not its a file or dir. |
| 15:54.18 |
CIA-105 |
BRL-CAD:
03davidloman * r44215 10/geomcore/trunk/src/GS/FileDataSource.cxx:
Woops, forgot a file on the last commit. |
| 16:03.00 |
CIA-105 |
BRL-CAD:
03davidloman * r44216 10/geomcore/trunk/src/GS/FileDataSource.cxx:
Make FileDataSource filter out all paths except paths ending in
files. |
| 16:12.01 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 16:12.37 |
CIA-105 |
BRL-CAD:
03davidloman * r44217 10/geomcore/trunk/src/GS/cmds/GetCmd.cxx:
Update the GetCmd::getHelp() method to display correct
help |
| 16:22.33 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
| 16:30.54 |
brlcad |
dloman: there
is no guarantee that <0 means files doesn't exist |
| 16:31.27 |
brlcad |
header
documents 0 (i.e., false) if doesn't exist, and >0 for exists ..
<0 is undefined |
| 16:31.43 |
dloman |
didn't see
that in the header :/ |
| 16:31.52 |
*** join/#brlcad hyarion_
(c05ben@peppar.cs.umu.se) |
| 16:32.05 |
dloman |
just saw one
sentence, so i read the code and asked to confirm. =D |
| 16:32.21 |
brlcad |
they're meant
to be simple if (bu_file_exists(file)) then do something else
don't |
| 16:32.23 |
*** join/#brlcad bhinesley_
(~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) |
| 16:32.51 |
brlcad |
complex
return values usually indicate API weaknesses |
| 16:32.58 |
brlcad |
so it's just
a simple boolean |
| 16:33.02 |
dloman |
kk |
| 16:34.07 |
*** join/#brlcad roberthl_
(~robert@v1.rhl.me.uk) |
| 16:35.49 |
*** join/#brlcad roberthl
(~robert@v1.rhl.me.uk) |
| 16:35.49 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 16:37.15 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 16:37.58 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
| 16:39.19 |
brlcad |
dloman: fwiw,
things like FileDataSource::existsFileOrDir() really belong up in
libbu (at least the implementation of it does) |
| 16:39.32 |
brlcad |
so we're
portably consistent and we get reuse |
| 16:39.40 |
dloman |
right
on. |
| 16:40.03 |
dloman |
i'm pushing
getting functionally complete and debugged to stable. Then I plan
on doing a ****ton of clean up =D |
| 16:40.15 |
brlcad |
if the API is
lacking, then it's just as much work to make things fit cleanly
into libbu as they do somewhere else |
| 16:41.47 |
*** join/#brlcad roberthl
(~robert@v1.rhl.me.uk) |
| 16:41.47 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 16:43.14 |
brlcad |
yeah, with
the current code, I think we just hadn't had a need yet to
distinguish dirs beyond bu_file_exists() and
bu_count_path() |
| 16:43.49 |
brlcad |
if that need
is there, then it's trivial to extend another call like
bu_dir_exists() or bu_is_directory() |
| 16:43.57 |
dloman |
well if the
esistsFileOrDir(char*) is usefull then i can push it down
there. |
| 16:44.14 |
brlcad |
there's a
whole class of posix file node matches like that |
| 16:44.38 |
brlcad |
I wouldn't
push it as it -- right now you only care if it's a file or a dir,
but there are other types |
| 16:44.41 |
brlcad |
could be a
link |
| 16:44.43 |
brlcad |
a
pipe |
| 16:44.44 |
brlcad |
a
socket |
| 16:45.04 |
brlcad |
existsFileOrDirOrSymbolicLinkOrPipeOr
... |
| 16:45.19 |
brlcad |
each having
useful purpose |
| 16:46.47 |
brlcad |
that's why
the current just followed the posix class ("man bash", jump down to
CONDITIONAL EXPRESSIONS to see a list) |
| 16:47.11 |
dloman |
kk |
| 16:48.52 |
brlcad |
you could get
a nearly identical result to your function with something like
bu_file_type() that returns an enum type for regular file, dir,
link, named pipe, etc |
| 16:49.39 |
dloman |
bu_file_type(), got it. |
| 16:49.51 |
brlcad |
that way
you're still only implementing support for the types you need now
but have the API in place that will extend to future node
types |
| 16:49.54 |
*** join/#brlcad ``Erik_
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 16:55.56 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44218 10/brlcad/trunk/src/conv/g-egg.c:
eliminate as many globals as possible. pack the rest in the global
struct. |
| 16:57.11 |
brlcad |
pretty
awesome:
http://www.youtube.com/watch?v=xFrMl_5T0Rc&feature=player_embedded |
| 16:59.04 |
brlcad |
open source
cars |
| 17:01.39 |
starseeker |
is that
anything like these guys? http://www.40fires.org/ |
| 17:02.09 |
starseeker |
or the
commerical side: http://www.riversimple.com/ |
| 17:05.16 |
starseeker |
huh -
http://www.onawi.org/ |
| 17:05.27 |
starseeker |
that could be
kinda cool |
| 17:05.40 |
dloman |
am i reading
g_transfer.c:server_geom() correctly? wdb_export_external()
doesn't write to disk there? |
| 17:05.58 |
dloman |
brlcad: Nice
video, that guys a good speaker :) |
| 17:13.23 |
brlcad |
dloman:
wdb_export_external() writes to the "database instance", whatever
that is |
| 17:13.34 |
brlcad |
in
g_transfer's case, it's an in-memory-only database |
| 17:13.49 |
dloman |
yeah,
figgered that out just now, heh. |
| 17:13.56 |
brlcad |
so it doesn't
write to disk, but only because it's in-mem |
| 17:14.29 |
dloman |
if i
instantiate a different type of db, then wdb_export_external to
that, then that will get me writing to disk......
correct? |
| 17:14.56 |
brlcad |
depends what
kind of dbip you make, but if it's a file-based dbip, then yes --
it'll write out to disk |
| 17:19.29 |
dloman |
db_open()
with a RT_WDB_TYPE_DB_DISK flag? |
| 17:27.47 |
brlcad |
sounds about
right |
| 17:27.56 |
dloman |
right
on |
| 17:28.14 |
CIA-105 |
BRL-CAD:
03starseeker * r44219 10/geomcore/trunk/src/ (6 files in 2 dirs):
Get some renaming done, get a couple files building. |
| 17:37.57 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44220 10/brlcad/trunk/ (configure.ac
src/Makefile.am src/java/): no implementation, abandoned 8 years
ago, unused, gone. |
| 17:39.00 |
dloman |
http://www.local-motors.com/checkup.php?c=6998 |
| 17:39.01 |
dloman |
awesome. |
| 17:41.53 |
``Erik |
http://ecoroamer.com/drupal/CAD-files
dwg for the thing |
| 17:42.13 |
dloman |
....do i
smell a new addition to the db library? |
| 17:42.44 |
``Erik |
dwg is all
engineering line drawings, no solid geometry, right? |
| 17:42.55 |
starseeker |
right |
| 17:43.10 |
starseeker |
good material
for modeling, but not a solid model itself |
| 17:44.24 |
starseeker |
license
statement is... less than clear |
| 17:44.39 |
starseeker |
someone
should suggest one of the creative commons licenses to
him |
| 17:44.53 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44221 10/brlcad/trunk/src/conv/g-egg.c: quell
warning that showed up on fbsd but not mac |
| 17:46.34 |
CIA-105 |
BRL-CAD:
03starseeker * r44222 10/geomcore/trunk/src/libgvm/ (gvm_svn.h
mem.c): Ah, right - we'll be using memory pools for the
internals. |
| 17:48.00 |
``Erik |
looks like
it's just a stretched f650 with a camper O.o |
| 17:49.00 |
starseeker |
probably |
| 17:49.12 |
dloman |
yeah *JUST* a
streched f650 |
| 17:50.10 |
``Erik |
they started
with a 2007 f650 with a c7 diesel engine, stretched it, slapped a
custom built camper on, run the camper on solar cells and heat
captured off the exhaust O.o |
| 17:52.34 |
CIA-105 |
BRL-CAD:
03starseeker * r44223 10/geomcore/trunk/src/libgvm/ (breakout.c
gvm.h): move header entrys around, remove breakout.c (deal with
that later) |
| 17:52.59 |
``Erik |
any news on
red testing for release? |
| 17:53.29 |
CIA-105 |
BRL-CAD:
03brlcad * r44224 10/brlcad/trunk/src/libged/wdb_obj.c: if
ged_title() is wrong, then this one is probably wrong too since
it's the daddy. make title not clobber units. |
| 18:00.13 |
starseeker |
we've also
got a report rtwizard isn't working... let me check... |
| 18:00.46 |
starseeker |
crud |
| 18:03.14 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.142.251) |
| 18:03.14 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:05.06 |
CIA-105 |
BRL-CAD:
03brlcad * r44225 10/brlcad/trunk/NEWS: |
| 18:05.06 |
CIA-105 |
BRL-CAD: bob
found/fixed a bug with the title command. presumably, this would
convert |
| 18:05.06 |
CIA-105 |
BRL-CAD: the
working units to mm if you tried to set the title via the units
command. |
| 18:09.50 |
CIA-105 |
BRL-CAD:
03brlcad * r44226 10/brlcad/trunk/TODO: libged encapsulation issue
reverted for release, schedule backlog task to restore with
libdm/libfb decoupling addressed. similar decouple needed for
screengrab command (though that command may just end up
migrating?). |
| 18:11.42 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 18:19.40 |
CIA-105 |
BRL-CAD:
03davidloman * r44227 10/geomcore/trunk/include/FileDataSource.h:
Add a //TODO about swapping out existsFileOrDir with
bu_file_type() |
| 18:31.40 |
CIA-105 |
BRL-CAD:
03davidloman * r44228 10/geomcore/trunk/src/GS/DataManager.cxx: Add
server side logging for geometry requests |
| 18:38.56 |
CIA-105 |
BRL-CAD:
03davidloman * r44229 10/geomcore/trunk/src/GS/FileDataSource.cxx:
Make note about the Logger failing after the call to
BRLCAD::MinimalDatabase cstr. |
| 18:42.00 |
CIA-105 |
BRL-CAD:
03davidloman * r44230 10/geomcore/trunk/src/GS/GSClient.cxx:
Display the name of the GeometryChunk as it comes in from the
server |
| 18:44.26 |
CIA-105 |
BRL-CAD:
03brlcad * r44231 10/brlcad/trunk/TODO: file node entity type
support to libbu |
| 19:21.22 |
CIA-105 |
BRL-CAD:
03brlcad * r44232 10/brlcad/trunk/TODO: red matrix edit
works! |
| 19:26.59 |
CIA-105 |
BRL-CAD:
03brlcad * r44233 10/brlcad/trunk/TODO: red is looking better,
doesn't seem to list rgb/color attributes multiple times any more,
but now seems to be wiping out the shader and region_id at least
when set to plastic and -1 respectively. |
| 19:42.57 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 20:38.54 |
*** join/#brlcad Wildstar
(42bd9f25@gateway/web/freenode/ip.66.189.159.37) |
| 20:39.05 |
Wildstar |
Hello |
| 20:39.35 |
Wildstar |
Is there a
PDP-11 source code for BRL-CAD? |
| 20:41.13 |
Wildstar |
BBL |
| 20:44.13 |
CIA-105 |
BRL-CAD:
03starseeker * r44234 10/geomcore/trunk/src/libgvm/ (CMakeLists.txt
mem.c objects.c): Add preliminary stab at repository_object
conversion routine. |
| 20:45.44 |
dli |
PDP-11 is
16bit, amazing request for brl-cad :( |
| 20:50.48 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44235 10/geomcore/trunk/src/interfaces/cl/
(gsclient.lisp gsnet.lisp gsserver.lisp): macros! |
| 00:04.10 |
*** join/#brlcad kunigami_
(~kunigami@187.106.4.220) |
| 00:09.05 |
kunigami_ |
hi, I've
updated my proposal on "shaders enhancements". commentaries are
most welcome! |
| 00:19.00 |
brlcad |
kunigami_:
hehe |
| 00:19.02 |
brlcad |
"write a
small tutorial on how to write a tutorial on how to implement
shaders" |
| 00:20.08 |
brlcad |
but ... I
what if I need a tutorial on writing small tutorial on how to write
a tutorial on how shaders are implemented? |
| 00:25.44 |
kunigami_ |
brlcad: oops
let me correct that :P |
| 00:26.23 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) |
| 00:33.31 |
brlcad |
kunigami_: so
a few other comments and clarifications |
| 00:34.37 |
brlcad |
it doesn't
necessarily have to go into your proposal now (though it will be
useful pre-coding work), but you'll have to tell me more about
their concept of closures |
| 00:35.27 |
brlcad |
as well as
whether OSL actually evaluates / calculates the optical properties
of a shader or whether it just describes a shader |
| 00:36.27 |
kunigami_ |
brlad: hmm,
ok! I think I'll spend some more time playing with OSL
tomorrow! |
| 00:37.30 |
brlcad |
a shader can
be a completely abstract concept, so it's hard for me to imagine
they actually implemented a system that takes a C-style text
description and turns it into an actual working implementation ..
but maybe, imageworks has a lot of resources |
| 00:38.20 |
brlcad |
returning a
parametric representation sounds more plausible, but then how that
interacts with a raytrace sounds very interesting |
| 00:39.15 |
brlcad |
kunigami_:
one thing you can look at, on the wiki is a tutorial on shooting a
ray with brl-cad -- that has no shader/optics, just returns a hit
point |
| 00:39.26 |
brlcad |
you could use
that with OSL as a proof-of-concept |
| 00:39.33 |
brlcad |
that might be
something work milestoning |
| 00:39.38 |
brlcad |
s/might/would/ |
| 00:39.45 |
brlcad |
since it
would show how the two interact |
| 00:41.00 |
kunigami_ |
hmm good
idea! |
| 01:01.58 |
brlcad |
starseeker: I
hope you meant sync TRUNK to stable and not stable to trunk...
;) |
| 01:08.43 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 01:11.53 |
*** join/#brlcad crazy_imp
(~mj@a89-182-6-68.net-htp.de) |
| 01:17.13 |
CIA-105 |
BRL-CAD:
03brlcad * r44245 10/brlcad/trunk/include/ (bu.h common.h): add
__BU_ATTR_ALWAYS_INLINE with a protection for gcc 3.4 and earlier
where the always_inline attribute wasn't yet fully implemented
(reportedly still works for some optimization options) |
| 01:19.27 |
CIA-105 |
BRL-CAD:
03brlcad * r44246
10/brlcad/trunk/src/librt/opennurbs_ext.h: |
| 01:19.27 |
CIA-105 |
BRL-CAD: use
the new __BU_ATTR_ALWAYS_INLINE define so that we get forced inline
behavior |
| 01:19.27 |
CIA-105 |
BRL-CAD: for
newer gcc or forced off if older. the 'inline' keyword may be
superfluous |
| 01:24.04 |
brlcad |
tick tock
gsoc applicants! |
| 01:24.11 |
brlcad |
two days
remaining |
| 02:00.52 |
*** join/#brlcad PrezWhiteCalf
(MK@whitecalf.net) |
| 02:03.48 |
*** join/#brlcad WhiteCalf
(MK@whitecalf.net) |
| 02:16.53 |
starseeker |
er,
yeah |
| 03:11.57 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 03:16.17 |
bhinesley |
brlcad: Part
of my new plan is to migrate oed (modified for stateless use),
which then opens the door for ill, sill, and consolidation of all
the rot commands. I wanted to try and get your opinion before
updating the proposal. |
| 03:25.17 |
bhinesley |
Also, I was
hoping to include the consolidation of the rcc-* commands, which
you mentioned was desirable. Can a naming convention be hashed out
during the coding phase, or is that something that the proposal
should address? |
| 03:53.25 |
brlcad |
bhinesley:
the proposal doesn't have to have everything addressed, just a
clear plan (even if the plan includes numerous research, design,
and coding work) |
| 03:54.54 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 04:05.45 |
bhinesley |
okay; I'm
submitting again. |
| 04:05.48 |
brlcad |
bhinesley:
the plan to migrate oed sounds great but that will be a somewhat
tricky on -- give yourself a good bit of time (a week or two) for
just that one command |
| 04:06.23 |
bhinesley |
that should
be just fine, I rear-loaded the milestones to give me a chance to
tackle the tougher issues |
| 04:07.00 |
brlcad |
setting up
some means to track your progress can be a milestone in
itself |
| 04:07.30 |
brlcad |
(e.g., the
spreadsheet idea) |
| 06:13.41 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:57.56 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 07:00.54 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 09:43.50 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
| 11:19.57 |
CIA-105 |
BRL-CAD:
03davidloman * r44247 10/geomcore/trunk/tests/ (20 files in 19
dirs): Split out tests into Functional and Unit dirs in prep for
some unit test addition. |
| 11:37.36 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.43.72) |
| 11:37.36 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:03.09 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 13:33.12 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:42.34 |
sachinjain |
brlcad : can
you tell me what are the two approaches that you told me earlier
for the project "vector output from raytracing" |
| 13:43.25 |
sachinjain |
and I have
also uploaded a patch on sourceforge as you told to do
so |
| 13:43.41 |
sachinjain |
told
me* |
| 13:48.01 |
CIA-105 |
BRL-CAD:
03starseeker * r44248 10/geomcore/trunk/tests/func/svntest/main.c:
Work from respository root for commit, rather than assuming a
particular model |
| 13:51.31 |
CIA-105 |
BRL-CAD:
03starseeker * r44249 10/geomcore/trunk/tests/func/CMakeLists.txt:
tweak build to get it working... |
| 13:53.43 |
sachinjain |
isn't there
any developer online? |
| 13:53.57 |
CIA-105 |
BRL-CAD:
03starseeker * r44250 10/geomcore/trunk/src/libgvm/objects.c: Will
need to specify 'root' here as well |
| 13:59.30 |
CIA-105 |
BRL-CAD:
03starseeker * r44251 10/geomcore/trunk/src/libgvm/objects.c:
Memory is in pool, but go ahead and dequeue list... |
| 14:16.26 |
d_rossberg |
sachinjain:
now, yes |
| 14:17.41 |
d_rossberg |
ups, he
quit |
| 14:18.24 |
starseeker |
he doesn't
really seem to grasp the nature of IRC |
| 14:27.59 |
``Erik |
or mebbe he
pays by time or data xfer |
| 14:28.32 |
``Erik |
(or has to
use a cybercafe or school lab for internet access) |
| 14:47.19 |
starseeker |
screen +
remote server |
| 15:04.26 |
``Erik |
gotta have
shell access on a remote server to do that :D |
| 15:05.22 |
brlcad |
they're at a
uni .. chances are super-high that they have or could get
access |
| 15:07.22 |
``Erik |
I d'no, where
I went, they started killing screens at night and then removed unix
servers for NT ones (12 rs6k aix boxes took over 300 nt4 machines
to meet needs), and he may've moved back home for the summer
*shrug* not everyone has our level of access, 'sall I'm
sayin' |
| 15:08.05 |
CIA-105 |
BRL-CAD:
03starseeker * r44252 10/geomcore/trunk/src/libgvm/ (CMakeLists.txt
models.c): Add logic for adding a new model |
| 15:08.21 |
``Erik |
might be
worth asking his connection details before stating that he doesn't
"get it" |
| 15:08.47 |
brlcad |
given the
previous discussions, I'd still bet on him just not getting it or
not being patient |
| 15:09.21 |
starseeker |
whatever his
connection details, IRC is what it is - if he can't communicate on
those terms that's OK, but then he should be using
email |
| 15:09.33 |
brlcad |
everything
you describe happened where I was at, but there was still a dozen
ways I could have run a screen session |
| 15:09.51 |
brlcad |
you only have
to find ONE .. which really isn't that hard |
| 15:10.35 |
brlcad |
starseeker:
great point, IRC isn't an excuse given we have a mailing
list |
| 15:16.21 |
*** join/#brlcad b0ef
(~b0ef@226.27.202.84.customer.cdi.no) |
| 15:32.19 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
| 15:43.19 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.145.3) |
| 15:43.19 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 15:47.11 |
CIA-105 |
BRL-CAD:
03starseeker * r44253 10/geomcore/trunk/src/libgvm/models.c: add
gvm_get_model implementation |
| 15:50.54 |
*** join/#brlcad dli
(~dli@dsl-173-248-203-45.acanac.net) |
| 16:06.20 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.135.83) |
| 16:22.38 |
CIA-105 |
BRL-CAD:
03brlcad * r44254 10/brlcad/trunk/src/libbu/: timetester
binary |
| 16:23.25 |
CIA-105 |
BRL-CAD:
03brlcad * r44255 10/brlcad/trunk/src/libpc/: ignore pc_test
binary |
| 16:24.15 |
CIA-105 |
BRL-CAD:
03brlcad * r44256 10/brlcad/trunk/src/libbn/: ignore bntester
binary |
| 16:26.56 |
CIA-105 |
BRL-CAD:
03r_weiss * r44257
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message
trimmed) |
| 16:26.56 |
CIA-105 |
BRL-CAD:
Added preprocessor commands to optionally disable nmg triangulation
functions |
| 16:26.56 |
CIA-105 |
BRL-CAD:
within nmg_tri.c that are not needed when new 'prototype' nmg
triangulation code |
| 16:47.39 |
CIA-105 |
BRL-CAD:
03starseeker * r44258 10/geomcore/trunk/src/libgvm/models.c:
restructure gvm_get_model to be simpler - don't really need
callback. Start working on gvm_get_objs - this will be tricky since
it's essentially a keep without the full database |
| 16:54.54 |
CIA-105 |
BRL-CAD:
03brlcad * r44259
10/brlcad/trunk/src/other/incrTcl/itcl/generic/itclInt.h: is the
common.h header necessary here? builds clean without |
| 16:59.38 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.154.206) |
| 16:59.38 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:04.16 |
brlcad |
``Erik: this
is the one:
http://www.tirerack.com/tires/tires.jsp?tireMake=Continental&tireModel=ExtremeContact+DWS |
| 17:05.57 |
brlcad |
http://www.e90post.com/forums/showthread.php?t=302424 |
| 17:10.03 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.139.40) |
| 17:10.03 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:13.11 |
*** join/#brlcad Elrohir
(~kvirc@p5B14AD98.dip.t-dialin.net) |
| 17:17.23 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.135.92) |
| 17:17.23 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:18.00 |
``Erik |
brlcad: these
were the kind I had
http://www.sears.com/shc/s/p_10153_12605_09543528000P?sid=IDx20070921x00003a&ci_src=14110944&ci_sku=09543528000P |
| 17:20.33 |
``Erik |
then I went
to
http://www.tirerack.com/tires/tires.jsp?tireMake=Michelin&tireModel=Pilot+Sport&partnum=54YR8SPORTG1&vehicleSearch=false&fromCompare1=yes
which were awesome |
| 17:20.57 |
``Erik |
last rears I
got, they ordered the wrong ones and I got
http://www.tirerack.com/tires/tires.jsp?tireMake=Michelin&tireModel=Pilot+Sport+A%2FS+Plus&partnum=54YR8PSAS&vehicleSearch=false&fromCompare1=yes |
| 17:22.52 |
brlcad |
yeah, this is
the review I was mentioning:
http://www.consumersearch.com/tires/continental-extremecontact-dws |
| 17:23.00 |
brlcad |
definitely
not the same tire :) |
| 17:24.45 |
``Erik |
yeh, all
season instead of summer... won't stick as well, but will last
longer and do better in rain |
| 17:25.26 |
brlcad |
yeah, the
michelin was what I was going to go with, though one step up, the
pilot super sport |
| 17:26.08 |
brlcad |
http://www.michelinman.com/tire-selector/category/ultra-high-performance-sport/pilot-super-sport/tire-details |
| 17:26.18 |
brlcad |
but too long
a wait, it's a new tire |
| 17:26.35 |
brlcad |
wasn't going
to be available until next week, wanted something now |
| 17:27.14 |
``Erik |
hm, longer
treadlife than the ones I used to have, interesting |
| 17:27.17 |
brlcad |
we'll see how
it goes, so far I'm loving them .. super comfortable and quiet
ride, and holding grip well enough to still make me
smile |
| 17:28.08 |
``Erik |
ponders the pilot sport cup |
| 17:33.37 |
CIA-105 |
BRL-CAD:
03r_weiss * r44260
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 17:33.37 |
CIA-105 |
BRL-CAD:
Added a prototype version of the function 'nmg_triangulate_fu' (nmg
triangulate |
| 17:33.37 |
CIA-105 |
BRL-CAD:
faceuse) to the file 'nmg_tri.c'. Added preprocessor commands to,
by default, |
| 18:14.36 |
CIA-105 |
BRL-CAD:
03r_weiss * r44261
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message
trimmed) |
| 18:14.36 |
CIA-105 |
BRL-CAD:
Added the functions 'nmg_plot_fu',
'nmg_triangulate_rm_holes', |
| 18:14.36 |
CIA-105 |
BRL-CAD:
'nmg_triangulate_rm_degen_loopuse', and 'nmg_dump_model' to the
file |
| 18:42.17 |
CIA-105 |
BRL-CAD:
03r_weiss * r44262
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message
trimmed) |
| 18:42.17 |
CIA-105 |
BRL-CAD:
Added a new prototype version of the function 'cut_unimonotone' to
the file |
| 18:42.17 |
CIA-105 |
BRL-CAD:
'nmg_tri.c'. This function supports the new prototype
function |
| 18:42.25 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 18:46.58 |
CIA-105 |
BRL-CAD:
03Markhobley 07http://brlcad.org *
r2819 10/wiki/MGED_Commands: /* E */ |
| 19:05.53 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.128.64) |
| 19:05.53 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:13.11 |
CIA-105 |
BRL-CAD:
03r_weiss * r44263
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message
trimmed) |
| 19:13.11 |
CIA-105 |
BRL-CAD:
Updated function 'pick_pt2d_for_cutjoin' within file 'nmg_tri.c'.
This update |
| 19:13.11 |
CIA-105 |
BRL-CAD:
supports the new prototype function 'nmg_triangulate_fu' (nmg
triangulate |
| 19:39.19 |
CIA-105 |
BRL-CAD:
03r_weiss * r44264
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message
trimmed) |
| 19:39.19 |
CIA-105 |
BRL-CAD:
Updated function 'is_convex' within file 'nmg_tri.c'. This update
supports the |
| 19:39.19 |
CIA-105 |
BRL-CAD: new
prototype function 'nmg_triangulate_fu' (nmg triangulate faceuse)
and is |
| 19:41.22 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
| 19:51.30 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:04.29 |
``Erik |
neat. incr
fails now :D |
| 20:05.19 |
starseeker |
oh, now that
I think about it I recall something similar when I tried a vanilla
build of incr |
| 20:13.54 |
CIA-105 |
BRL-CAD:
03r_weiss * r44265
10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: (log message
trimmed) |
| 20:13.54 |
CIA-105 |
BRL-CAD:
Updated function 'nmg_cut_loop' within file 'nmg_mod.c'. This
update supports |
| 20:13.54 |
CIA-105 |
BRL-CAD: the
new prototype function 'nmg_triangulate_fu' (nmg triangulate
faceuse) and is |
| 20:39.04 |
CIA-105 |
BRL-CAD:
03r_weiss * r44266
10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: |
| 20:39.04 |
CIA-105 |
BRL-CAD:
Updated function 'nmg_classify_lu_lu' within file 'nmg_class.c'.
This update |
| 20:39.04 |
CIA-105 |
BRL-CAD:
supports the new prototype function 'nmg_triangulate_fu' (nmg
triangulate |
| 21:05.49 |
CIA-105 |
BRL-CAD:
03r_weiss * r44267
10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: |
| 21:05.49 |
CIA-105 |
BRL-CAD:
Updated function 'nmg_2edgeuse_g_coincident' within file
'nmg_info.c'. This |
| 21:05.49 |
CIA-105 |
BRL-CAD:
update supports the new prototype function 'nmg_triangulate_fu'
(nmg triangulate |
| 21:15.03 |
``Erik |
src/brlcad/src/other/tcl/generic/tclInt.h:56:
error: conflicting types for 'ptrdiff_t' |
| 21:15.07 |
``Erik |
<PROTECTED> |
| 21:17.16 |
``Erik |
http://paste.lisp.org/display/121260
is the full one, I imagine that common.h was important |
| 21:23.44 |
CIA-105 |
BRL-CAD:
03r_weiss * r44268
10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: |
| 21:23.44 |
CIA-105 |
BRL-CAD:
Updated function 'nmg_lu_reorient' within file 'nmg_mod.c'. This
update supports |
| 21:23.44 |
CIA-105 |
BRL-CAD: the
new prototype function 'nmg_triangulate_fu' (nmg triangulate
faceuse) and is |
| 21:34.40 |
CIA-105 |
BRL-CAD:
03r_weiss * r44269
10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: |
| 21:34.40 |
CIA-105 |
BRL-CAD:
Updated function 'nmg_isect_eu_fu' within file 'nmg_inter.c'. This
update |
| 21:34.40 |
CIA-105 |
BRL-CAD:
supports the new prototype function 'nmg_triangulate_fu' (nmg
triangulate |
| 21:37.19 |
*** join/#brlcad dli (~dli@132.205.216.21) |
| 21:51.16 |
CIA-105 |
BRL-CAD:
03starseeker * r44270 10/geomcore/trunk/src/libgvm/models.c:
Untested, but add some logic to pull the comb's tree and add its
members (if they're something not already seen) to the
hash |
| 22:04.42 |
starseeker |
well, good
news and bad news about kermit |
| 22:04.59 |
starseeker |
bad news is
the project is shutting down, good news is they're planning to BSD
license it |
| 22:07.12 |
*** join/#brlcad Elrohir
(~kvirc@p5B14AD98.dip.t-dialin.net) |
| 22:33.42 |
starseeker |
wonders if their terminal emulation code could do what we
need on Windows... |
| 22:45.17 |
starseeker |
prods himself again to give this a try... http://www.projectpluto.com/win32a.htm |
| 22:54.06 |
CIA-105 |
BRL-CAD:
03starseeker * r44271 10/geomcore/trunk/src/libgvm/models.c: Once
we have the objects in question, stick 'em on the list. |
| 22:56.04 |
CIA-105 |
BRL-CAD:
03starseeker * r44272 10/geomcore/trunk/src/libgvm/models.c: Oh,
right - we had to get the bu_external already earlier, so no need
to get it again. |
| 23:51.39 |
CIA-105 |
BRL-CAD:
03starseeker * r44273 10/geomcore/trunk/src/libgvm/ (gvm.h
models.c): Clear out comment, add gvm_export_list to
header. |
| 23:53.27 |
CIA-105 |
BRL-CAD:
03starseeker * r44274 10/geomcore/trunk/src/libgvm/models.c: Go
with NULL to avoid confusion here, assuming that's
viable |
| 00:29.23 |
*** join/#brlcad bhinesley
(~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) |
| 01:11.40 |
*** join/#brlcad crazy_imp
(~mj@a89-182-208-255.net-htp.de) |
| 03:26.39 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 03:33.43 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca) |
| 04:36.10 |
*** join/#brlcad stevegt`
(~stevegt@cislunar.TerraLuna.Org) |
| 07:31.23 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.5.31) |
| 07:31.23 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:49.21 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 09:09.48 |
*** join/#brlcad mafm
(~mafm@132.Red-81-35-69.dynamicIP.rima-tde.net) |
| 09:25.05 |
CIA-105 |
BRL-CAD:
03jordisayol * r44293 10/brlcad/trunk/sh/ (make_deb.sh
make_rpm.sh): Properly handle errors during GNU/Linux packages
building. |
| 13:09.49 |
dloman |
yawns |
| 13:10.03 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 13:22.32 |
brlcad |
resists the yawn |
| 13:23.00 |
brlcad |
totally
bummed though |
| 13:23.03 |
brlcad |
no
furlough |
| 13:23.33 |
dloman |
had two big brown eyes staring at me starting at 0100.
Youngest wouldn't sleep! |
| 13:23.59 |
dloman |
heh, speak
for your self. I still have a paying job because of 'no furlough'
;) |
| 13:37.38 |
``Erik |
vacation
woulda been nice O.o |
| 13:37.57 |
dloman |
still a
chance for it :) |
| 13:37.59 |
``Erik |
brlcad:
migration? accounts? |
| 13:54.32 |
dloman |
brlcad: was
looking at VLB over the weekend and saw that a bu_vlb_write() call
could potentially trigger a bu_realloc(). In order to know this
ahead of time, the caller would need to know both the vlb's
'nextByte' and 'capacity'. bu_vlb_buflen serves to get the
'nextByte' but there's nothing for capacity. I was thinking about
adding a bu_vlb_capacity() and/or bu_vlb_remaining() functions.
Comments/concerns/tips ? |
| 13:58.40 |
``Erik |
the struct is
public and the math is trivial O.o |
| 14:00.00 |
``Erik |
iirc, vlb's
default to 4k 'chunks', so that's a straight up page mapping, quick
and cheap on linux (not on fbsd/mac) |
| 14:01.20 |
brlcad |
dloman:
sounds good to me |
| 14:01.36 |
brlcad |
should make
the function name mirror the vls api, though |
| 14:01.46 |
dloman |
nods |
| 14:04.51 |
brlcad |
very curious
that you'd need to know the size, though -- the mechanism by which
the bytes are stored is supposed t be a black box |
| 14:05.14 |
brlcad |
could be a
bu_list of individual bytes, for example, or some c++ construct or
a static buffer |
| 14:05.33 |
dloman |
was looking
at vlb_write and saw that there is a possiblity of a
realloc |
| 14:05.55 |
dloman |
and without
knowing capacity a head of time, you'll never know if that realloc
will happen or not. |
| 14:06.01 |
brlcad |
so? |
| 14:06.07 |
brlcad |
anything that
adds bytes is going to be a potential realloc |
| 14:06.18 |
brlcad |
part of the
black box |
| 14:06.36 |
dloman |
would
exposing the capacity break the black box mindset? |
| 14:06.54 |
brlcad |
pretty
much |
| 14:07.04 |
dloman |
okie |
| 14:07.15 |
brlcad |
still, what
does the realloc matter? |
| 14:07.17 |
``Erik |
I think it's
more "why do you care?" O.o reallocs aren't terribly slow on
occasion |
| 14:07.27 |
``Erik |
premature
optimization? O.o |
| 14:08.14 |
dloman |
just trying
to think ahead ;) |
| 14:08.37 |
brlcad |
or "a little
knowledge is dangerous" |
| 14:09.05 |
brlcad |
std::string
foo = "hello"; foo += "world"; may or may not cause a realloc
too |
| 14:09.16 |
brlcad |
you don't
know, shouldn't care -- vlb is the same |
| 14:09.23 |
dloman |
okie |
| 14:10.28 |
``Erik |
(no forward
motion on the server? I'm out today, thought maybe I could start a
system update and get some stuff installed) |
| 14:10.59 |
dloman |
is bug fixing and generally de-stupifying
things. |
| 14:12.44 |
brlcad |
``Erik:
noted, i'll create your account |
| 14:13.01 |
brlcad |
context
switch thrashing a bit at the moment |
| 14:19.49 |
brlcad |
``Erik:
gmail |
| 14:20.45 |
brlcad |
was leaving
those default passwords until accounts got migrated |
| 14:22.27 |
brlcad |
so the
coverity scan is really frelling awesome |
| 14:33.41 |
CIA-105 |
BRL-CAD:
03starseeker * r44294 10/geomcore/trunk/src/libgvm/ (files.c
objects.c): Hrm. Something strange - simply calling
gvm_obj_in_model was enough to cause a crash - reorganizing the
initializations in gvm_object_in_model was enough to make things
work. |
| 15:03.58 |
brlcad |
if anyone is
interested in actually working on fixing coverity bugs, let me know
with an e-mail address to provide so I can get an account created
(let me know via e-mail or PM) |
| 15:05.00 |
brlcad |
please don't
bother if you're just interested or want to peek at results, rather
not waste david's time |
| 15:05.09 |
brlcad |
or mine for
that matter |
| 15:05.33 |
brlcad |
here's what
some of the results look like, though: |
| 15:06.17 |
brlcad |
http://brlcad.org/tmp/cov1.png
<-- detected potential null dereference |
| 15:06.31 |
brlcad |
http://brlcad.org/tmp/cov2.png
<-- security issues |
| 15:07.20 |
brlcad |
http://brlcad.org/tmp/cov3.png
<-- more elaborate (and awesome) detection of potentially
uninitialized data being used |
| 15:07.44 |
dloman |
neato. |
| 15:07.47 |
dloman |
that a pay
service? |
| 15:07.54 |
brlcad |
just a sample
of the 2k or so issues reported |
| 15:08.12 |
brlcad |
it's paid
for, but not something we're paying for |
| 15:08.52 |
brlcad |
DHS funded an
initiative a few years ago to evaluate (and improve) security of
open source software |
| 15:09.03 |
dloman |
=D |
| 15:09.04 |
dloman |
nice |
| 15:09.40 |
dloman |
so its "free"
=D |
| 15:10.47 |
brlcad |
I applied and
we were one of the first to get added to the scan ladder (when
there were only a couple dozen being scanned), but our scan (of an
old version) got stuck on a build failure in src/other |
| 15:11.05 |
brlcad |
wasn't fully
resolved until the past friday |
| 15:11.55 |
dli |
brlcad, I can
have a look on the coverity bugs, not sure how hard it is to fix
them, without collateral damage at least |
| 15:12.28 |
dli |
brlcad, do
you have some examples for me to digest |
| 15:12.39 |
brlcad |
dli: just
screenshotted three :) |
| 15:13.36 |
dli |
brlcad, too
bad. :( no text report? |
| 15:14.04 |
brlcad |
dli: what do
you mean? |
| 15:14.41 |
brlcad |
there's a
full-blown website around the report generated, pretty sure there
are export options too -- but the website lets you manage the
issues so you know which ones are fixed and which are
not |
| 15:15.10 |
brlcad |
dli: can you
not view images at the moment or something? |
| 15:15.39 |
dli |
brlcad, of
course, I can view images |
| 15:16.26 |
brlcad |
then what's
the "too bad"? |
| 15:17.34 |
dli |
brlcad, I
expected a list with file locations, line numbers, and explanation
of findings, etc. |
| 15:20.17 |
dli |
http://scan.coverity.com/all-projects.html |
| 15:20.26 |
dli |
not
found |
| 15:21.28 |
brlcad |
dli: it has
that list of files, explanations and a lot more |
| 15:21.36 |
brlcad |
the
screenshots show three specific bugs |
| 15:22.37 |
brlcad |
I can dump
out the various reports (there are many, all configurable) as csv,
but that's not really effective for fixing them
collaboratively |
| 15:22.49 |
dli |
brlcad,
found, 178,135 lines, that will take ages to fix :( |
| 15:23.10 |
brlcad |
dli: that's
the stalled scan |
| 15:23.18 |
brlcad |
that webpage
hasn't been updated in years |
| 15:23.39 |
brlcad |
it found
690,667 lines |
| 15:23.41 |
dli |
brlcad, so, I
have to sign in to get updated |
| 15:24.00 |
brlcad |
that's lines
of code analyzed, not # issues |
| 15:24.15 |
brlcad |
it found 1892
issues, 700 of which are like cov2.png |
| 15:24.24 |
CIA-105 |
BRL-CAD:
03starseeker * r44295 10/geomcore/trunk/ (4 files in 2 dirs): Ah,
there we go - got changes committed to the repository. Approaching
full parity with the old svnTest example. |
| 15:25.05 |
dli |
brlcad, a
link for cov2.png? |
| 15:25.26 |
brlcad |
points up |
| 15:26.45 |
brlcad |
those where
the screenshots I mentioned |
| 15:27.50 |
dli |
brlcad, to
fix like sscanf(), we use atof(), etc., right? |
| 15:33.13 |
brlcad |
dli: it
depends, strtol/strtod with manual string parsing or regexp parsing
are generally more robust to sanitizing input |
| 15:33.55 |
starseeker |
brlcad: in
that case, should we pre-package some regex logic for the common
parsing cases? |
| 15:33.56 |
brlcad |
preferred
over the ato*() family of functions because they don't report
error |
| 15:35.41 |
dli |
brlcad, but
the idea is to replace all sscanf(), rather than trying to keep
sscanf() safe by limiting buffer size, etc |
| 15:35.44 |
brlcad |
starseeker:
bu routines that get values from strings would be useful (however
the underlying mechanism does it) |
| 15:36.41 |
brlcad |
dli: to best
solve the problem, yes |
| 15:36.56 |
brlcad |
the quickest
solution is to just add precision specifiers like the comment
states |
| 15:37.33 |
brlcad |
depending on
how many there are, that could be a first step or could be skipped
in leu of an API solution |
| 15:39.47 |
dli |
brlcad, I
think I can help fixing the issues here |
| 15:40.12 |
brlcad |
e-mail me a
username and an e-mail to give the coverity guys |
| 15:41.18 |
dli |
brlcad, using
the sean address in topic? |
| 15:43.15 |
dli |
brlcad,
sent |
| 15:45.37 |
brlcad |
thx |
| 15:47.50 |
dli |
brlcad, I
will ask about ideas before actually fixing anything, my biggest
fear is still the collateral damages :) |
| 15:48.19 |
brlcad |
okay, no
worries |
| 15:49.25 |
brlcad |
i'll mostly
be concerned with people actually using the coverity website when
bugs are fixed so we don't get people wasting time looking into
issues that have already been solved |
| 15:49.35 |
brlcad |
so using the
various status markers they provide |
| 15:49.41 |
brlcad |
inspected,
uninspected, fixed, etc |
| 15:51.31 |
dli |
brlcad,
right, with so many lines to check, need an way to
assign/partition |
| 15:54.07 |
CIA-105 |
BRL-CAD:
03starseeker * r44296 10/geomcore/trunk/src/libgvm/gvm.h: Nevermind
these functions - handled in a couple for loops. Add them later if
needed. |
| 15:54.07 |
brlcad |
nods |
| 15:54.41 |
brlcad |
some are
downright trivial to fix, some are downright tricky
logic |
| 16:09.00 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 16:26.24 |
CIA-105 |
BRL-CAD:
03starseeker * r44297 10/geomcore/trunk/src/libgvm/ (files.c gvm.h
objects.c): Clear out a few more functions of dubious utility,
assing some names to the commit actions. |
| 16:37.35 |
CIA-105 |
BRL-CAD:
03starseeker * r44298
10/geomcore/trunk/tests/func/gvmtest/main.c: |
| 16:37.35 |
CIA-105 |
BRL-CAD: Add
a test to create an empty repo. May need to add one additional
parameter to |
| 16:37.35 |
CIA-105 |
BRL-CAD: all
these functions - the ability to pass a local subpool (presumably
as a void |
| 16:47.56 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2821
10/wiki/Main_Page: add a section on code cleanup |
| 16:55.19 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2822
10/wiki/Code_Cleanup: stub in initial page, link to
HACKING |
| 17:01.01 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2823
10/wiki/Code_Cleanup: coverity section |
| 17:05.19 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded
"[[Image:CoverityExample1.png]]": Example Coverity scan issue
showing a potential (albeit unlikely) NULL dereference |
| 17:25.24 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded
"[[Image:CoverityExample2.png]]": Coverity analysis showing secure
coding practice suggestions |
| 17:27.48 |
CIA-105 |
BRL-CAD:
03starseeker * r44299 10/geomcore/trunk/src/libgvm/objects.c: Er,
oops - need a textdelta if we're going to add
content... |
| 17:27.49 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded
"[[Image:CoverityExample3.png]]": Coverity analysis showing an
elaborate detection of a variable being used that was potentially
uninitialized |
| 17:28.47 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2827
10/wiki/Code_Cleanup: link in the images and site |
| 17:29.55 |
CIA-105 |
BRL-CAD:
03starseeker * r44300 10/geomcore/trunk/src/libgvm/objects.c: Use
the gvm_info_clear_objects function |
| 17:31.18 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2828
10/wiki/Code_Cleanup: add a section on code reduction and using
simian |
| 17:31.19 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2829
10/wiki/Code_Cleanup: swap the order so lays out better |
| 17:33.14 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2830
10/wiki/Code_Cleanup: add an example of the output |
| 17:35.46 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2831
10/wiki/Code_Cleanup: break the long line |
| 17:46.46 |
CIA-105 |
BRL-CAD:
03Sean 07http://brlcad.org * r2832
10/wiki/Code_Cleanup: add one more section on strict compilation,
yay TOC |
| 17:50.47 |
CIA-105 |
BRL-CAD:
03davidloman * r44301 10/geomcore/trunk/CMake/FindCppUnit.cmake:
Check in a quick n dirty cmake find module for finding
CppUnit |
| 17:53.48 |
CIA-105 |
BRL-CAD:
03davidloman * r44302 10/geomcore/trunk/ (4 files in 4 dirs): Setup
cmake to find CppUnit if the UnitTests are enabled. Split out
subdirectory addition for Functional and Unit test dirs. Stub in
unit test dir CMakeList.txt |
| 18:06.05 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca) |
| 18:10.32 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.144.22) |
| 18:10.32 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:04.39 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca) |
| 19:14.17 |
*** join/#brlcad mafm
(~mafm@132.Red-81-35-69.dynamicIP.rima-tde.net) |
| 19:27.46 |
starseeker |
hah -
Manassas, Virginia |
| 19:43.47 |
CIA-105 |
BRL-CAD:
03davidloman * r44303 10/geomcore/trunk/tests/unit/ (4 files in 2
dirs): Wire in CppUnit to cmake build. Added a sample cmake unit
test that will eventually be ByteBuffer's Unit Test. |
| 19:47.33 |
CIA-105 |
BRL-CAD:
03davidloman * r44304 10/geomcore/trunk/ (3 files in 2 dirs):
Implement ByteBuffer. Combines the functionality of ByteArray and
DataStream, since those were mostly redundant. ByteBuffer is backed
by a bu_vlb and, at this point, is completely untested. |
| 19:57.19 |
CIA-105 |
BRL-CAD:
03starseeker * r44305 10/geomcore/trunk/src/libgvm/TODO: Add a TODO
for libgvm |
| 20:16.54 |
``Erik |
hrm? |
| 20:26.21 |
starseeker |
``Erik:
Tcl/Tk conference this year is in Virginia |
| 20:30.30 |
``Erik |
ah,
roger |
| 20:40.14 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.144.22) |
| 20:40.14 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:41.17 |
brlcad |
perfect
nearby location for a presentation or three |
| 20:44.34 |
brlcad |
``Erik: login
worked? |
| 21:03.31 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 21:05.53 |
brlcad |
starseeker:
did you make red delete or keep the original if the user edits the
object name? |
| 21:06.28 |
starseeker |
uh... I
thoght I made it delete the original, but not sure |
| 21:06.48 |
brlcad |
okay |
| 21:07.18 |
brlcad |
i was
thinking about the usability implications of both and
intent |
| 21:09.01 |
brlcad |
given cases
where both might be expected, I'm thinking it'll be safer to err on
keeping the original |
| 21:09.32 |
starseeker |
make it a cp,
instead of a mv? |
| 21:09.43 |
brlcad |
basically |
| 21:09.50 |
starseeker |
that kind of
violates the paradigm of "changing this object" we're using with
red |
| 21:10.03 |
starseeker |
the fact we
use a temp copy is an implementation detail, after all |
| 21:11.00 |
brlcad |
the tradeoff
is make those expecting copies having to cp first vs. those
expecting rename having to rm after |
| 21:12.19 |
brlcad |
that's only
if you expect red to "change this object" ... I can just as easily
see someone pulling up the text editor, and expecting the name
change to mean "give me a copy using that object's
values" |
| 21:12.55 |
brlcad |
more than
likely with some value(s) changed |
| 21:13.12 |
starseeker |
as opposed to
every other parameter in the text editor changing the original
object? dunno, seems a bit inconsistent (not to say someone
wouldn't expect it...) |
| 21:13.16 |
brlcad |
basically
boils down to cp+ed vs ed+rm |
| 21:14.05 |
brlcad |
i'm not sure
someone wouldn't expect it frankly |
| 21:14.10 |
brlcad |
there are
good use cases for both |
| 21:14.41 |
brlcad |
and every
other param wouldn't change the original, it applies to that
copy |
| 21:15.18 |
brlcad |
you wouldn't
edit the original AND make a copy .. that'd just be
wrong |
| 21:15.39 |
CIA-105 |
BRL-CAD:
03starseeker * r44306 10/geomcore/trunk/ (3 files in 2 dirs):
Grrrrr. Can't get recursive assembly to function. Am I hitting some
issue with pool memory size or something? |
| 21:15.55 |
starseeker |
oh, I agree -
I just was thinking in the paradigm of "if you red an object,
you're working on that one object. Period" |
| 21:16.06 |
brlcad |
it's the
intent of changing the object name, did they mean rename or did
they mean make me a new one based on the original |
| 21:17.22 |
brlcad |
the other
consideration is that even if they are thinking that way, that it
should rename the original .. the only surprise is that the
original object is still there and they have to manually delete
it |
| 21:18.13 |
brlcad |
if they're
thinking the other way, that it should make a copy .. then much to
their surprise, the original is deleted (along with the destruction
of any original values they maybe still wanted) |
| 21:19.26 |
starseeker |
could make
two commands - red and rcp |
| 21:19.27 |
brlcad |
that alone is
pretty strong case for not deleting, maybe adding a flag to red to
force one behavior |
| 21:20.09 |
starseeker |
yeah, I
suppose until we have undo support not deleting is
safer |
| 21:23.15 |
brlcad |
of course,
copy or move behavior will have to check if that object name
already exists, and similarly abort (unless there's a force
flag) |
| 21:24.21 |
brlcad |
ah, and I see
you already have code for that, excellent |
| 21:27.05 |
brlcad |
hm, what's a
similar command that has cp/mv options |
| 21:36.25 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
| 21:42.42 |
CIA-105 |
BRL-CAD:
03starseeker * r44307 10/geomcore/trunk/src/libgvm/ (files.c
models.c): OK, that worked. Wasn't cleaning up after myself. See if
I can put the content assignment back. |
| 21:45.18 |
CIA-105 |
BRL-CAD:
03starseeker * r44308 10/geomcore/trunk/src/libgvm/ (files.c
models.c): Yep, that was it - just needed to clear the
list. |
| 22:24.29 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 22:40.06 |
brlcad |
hello
KimK |
| 22:40.39 |
KimK |
Hi brlcad,
how's it going? |
| 22:40.47 |
brlcad |
pretty
great! |
| 22:41.00 |
KimK |
Ha,
excellent |
| 22:44.21 |
KimK |
You might be
interested to know that I have now managed to install BRL-CAD on
several machines, one defeated me, I'll look into that one again on
a return visit there. Unfortunately, I'm no smarter on operating
BRL-CAD yet, but I have stumbled across some tutorials, I hope to
have time to work on those. |
| 22:48.16 |
brlcad |
KimK:
outstanding |
| 22:48.30 |
brlcad |
yeah, the
tutorials on the main website (under Documentation) is really the
place to begin |
| 22:48.49 |
brlcad |
several of
the documents listed there are very helpful for learning the
basics |
| 22:55.40 |
KimK |
I have been
trying to get the Ubuntu menu to start BRL-CAD. The LibreOffice-dev
group has a similar problem, they start scripts to start the
locally-built development versions. A developer friend gave me a
little bash trick to put in the Ubuntu menu command to start them,
example: bash -c 'cd /home/username/libo/install/program;
./swriter' But I haven't been able to apply it in the expected
ways to start mged, I don't know what's up with that |
| 22:55.40 |
KimK |
. |
| 22:56.00 |
KimK |
Bah, flooded
by one, need a character counter, lol! |
| 22:57.56 |
brlcad |
KimK: hm.. in
more recent versions jordi sayol has menu and icons working for
fedora and debian |
| 22:58.23 |
brlcad |
might check
out the .deb to see how he did it |
| 22:58.41 |
brlcad |
(it's not in
apt, it's up on the website) |
| 23:00.15 |
KimK |
More recent
as in your development version? OK, no problem, I only installed
from the 7.18 tarball. Do you guys have a git repo yet? |
| 23:00.32 |
brlcad |
7.18.2 |
| 23:00.43 |
KimK |
OK,
7.18.2 |
| 23:00.51 |
brlcad |
no plans to
move from svn to git any time soon |
| 23:01.46 |
KimK |
Oh, you're on
svn? Maybe I can use "git svn". (Git is really nice.) |
| 23:01.58 |
brlcad |
quite
familiar with git |
| 23:03.01 |
KimK |
Excellent,
maybe git will be an option someday and you can advocate for
it? |
| 23:04.57 |
brlcad |
if a revision
control system needs advocating, then it's not mature enough yet
for our use |
| 23:06.01 |
brlcad |
didn't
advocate for cvs when switched from rcs, didn't advocate for svn
when switched from svn ... the benefits were clear and downsides
non-existent |
| 23:06.22 |
brlcad |
git doesn't
have that case yet, several downsides |
| 23:06.44 |
brlcad |
maybe
someday, but then maybe svn will have those features by then too or
maybe some other system will have stepped up |
| 23:08.00 |
KimK |
What do you
see as the downsides of git? Is svn in the group of one-repo cvs's,
is that the issue? |
| 23:08.31 |
brlcad |
don't
understand the second question |
| 23:09.29 |
KimK |
well, some
are bothered by the idea that there's no "official central repo" in
git (except by agreement or convention). |
| 23:09.53 |
KimK |
Any repo is
equal to any other repo. |
| 23:09.58 |
brlcad |
that could be
seen as a downside (or a benefit), depending on the
community |
| 23:11.57 |
brlcad |
there are
social impacts that are pretty extensively discussed, potential for
community fragmentation, potentially increase in antisocial
behavior (comparitively, since collaboration isn't
forced) |
| 23:12.14 |
brlcad |
practical
downside is the windows support, but that's improving |
| 23:13.12 |
brlcad |
the fact that
it's a relatively new version control system, not nearly as
extensively tested due to age alone |
| 23:14.21 |
KimK |
The EMC2
group hasn't had fragmentation problems that I have observed. They
do have an agreed central repo. I would put decentralization in the
benefit category, especially when there are internet connectivity
issues, as might be expected more frequently now. (Earthquakes,
tsunamis, sunspots, disasters, emp, what-have-you.) |
| 23:14.40 |
brlcad |
size of repo
clone compared to checkout requires increased disk (particularly
for large histories) |
| 23:15.09 |
brlcad |
that's a bit
ridiculous imho :) |
| 23:15.21 |
KimK |
Ease of
anyone browsing full history might be helpful? |
| 23:15.24 |
brlcad |
"might be
expected more frequently now" .. no more or less than before unless
people are just ignorant of the planet :) |
| 23:16.16 |
brlcad |
I think I can
count on one hand how many times I've been offline and needing to
commit over the past five years |
| 23:16.40 |
brlcad |
that would be
a benefit, but it's minor (and it's also something that svn is
working to implement too) |
| 23:16.52 |
brlcad |
in the end, I
think the systems will become so hybridized that it just won't
matter |
| 23:17.47 |
brlcad |
in which
case, a central repo that can be distributed would win over a
distributed repo pretending to be central |
| 23:18.01 |
brlcad |
but that's
many many years out, of course |
| 23:18.52 |
KimK |
Well, git
does have an impressive array of projects, even if you discount the
Linux kernel one. (Admittedly some bias there, lol.) |
| 23:19.05 |
brlcad |
the point
about switching, though, was that up until now, it's been very
clear and strong benefits with NO downsides ... that's simply not
the case quite yet |
| 23:19.12 |
brlcad |
popularity
means nothing |
| 23:19.56 |
brlcad |
git tends to
be the most vocal but by far not the most popular yet, last
estimate I saw had it at maybe 20% (across industry) |
| 23:20.16 |
brlcad |
course stats
can be fudged to show just about anything :) |
| 23:20.49 |
KimK |
Well, not
completely nothing, it means that some groups saw an advantage to
switching (to whatever). |
| 23:21.12 |
brlcad |
the fact that
the benefits and downsides have to be weighed means it's closer to
a wash .. which would simply be busy work right now |
| 23:21.19 |
brlcad |
not solving
any specific problem we're having |
| 23:21.36 |
KimK |
Yes, well,
you guys do have your hands full. |
| 23:21.54 |
KimK |
Hope it's
going well, generally? |
| 23:22.01 |
brlcad |
it solves a
big problem when the dev team scales beyond a communication
point |
| 23:22.05 |
brlcad |
git, that
is |
| 23:22.40 |
brlcad |
that point is
around 50-100 active developers, if I recall correctly |
| 23:23.41 |
KimK |
Due to its
history, are most brlcad developers in the US? I think that makes a
difference too. |
| 23:23.42 |
brlcad |
I did the
math a couple years ago, but it's basically the point at which NxM
communication points slow down development where having a
distributed infrastructure lets you have islands of
communication |
| 23:24.33 |
KimK |
Not in the
US, but in the same time zone, makes chatting difficult, or at
least delays email. |
| 23:24.34 |
brlcad |
i don't think
that makes any difference -- same issue with other communities I
work with that are predominantly non-US |
| 23:25.24 |
brlcad |
if you have
active devs, then the method and time of communication plays only a
minor part .. they're reading logs, mailing lists,
whatever |
| 23:25.28 |
brlcad |
impact is
minimal |
| 23:25.53 |
brlcad |
it's the
point at which there is too much activity, too many devs to have
centralized communication |
| 23:26.08 |
brlcad |
that's the
50-100 dev metric |
| 23:26.19 |
brlcad |
that's why it
was dead-obvious for linux |
| 23:26.27 |
brlcad |
hundreds of
active devs |
| 23:27.40 |
KimK |
OK. Well,
hopefully brlcad will continue to grow and you'll have more
developers too. |
| 23:27.55 |
brlcad |
yeah, that's
a problem I'd LIKE to have ;) |
| 23:28.42 |
KimK |
Haha, you'll
get there. |
| 23:37.55 |
brlcad |
starseeker:
on further inspection, red will also *create* a new combination
(from nothing) .. so that seems even more pertinent that the
editing intent is "write an object I've named with these values"
and the in-editor object name might simply be them changing their
mind on that name |
| 00:47.47 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-70-176.try.wideopenwest.com) |
| 01:12.23 |
*** join/#brlcad crazy_imp
(~mj@a89-183-84-47.net-htp.de) |
| 03:08.37 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) |
| 03:32.26 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) |
| 03:33.21 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.154.227) |
| 03:33.21 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 04:14.05 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.154.227) |
| 04:14.14 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 04:44.42 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 05:14.51 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:26.36 |
brlcad |
outstanding,
already an rtwizard failure reported |
| 07:10.21 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 07:21.29 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 07:57.58 |
*** part/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 08:09.33 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 08:18.57 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 10:04.11 |
dloman |
Mernin |
| 10:11.32 |
*** join/#brlcad mafm_
(~mafm@233.Red-83-54-181.dynamicIP.rima-tde.net) |
| 12:01.12 |
d_rossberg |
er,
src/libged/search.c tries to access a non-existent "local" member
of struct db_full_path_list |
| 12:33.14 |
CIA-105 |
BRL-CAD:
03davidloman * r44337 10/geomcore/trunk/tests/unit/test_runner.cxx:
Update test_runner.cxx with header and footer. Make console
printing a tad prettier. |
| 12:37.26 |
CIA-105 |
BRL-CAD:
03davidloman * r44338 10/geomcore/trunk/CMakeLists.txt: Add in
check to root CMakeLists.txt that tests if CppUnit has been found
or not. If not, configuration of the unit tests will not occur and
a message will be printed to the console instead of a cmake
failure. |
| 12:38.07 |
starseeker |
d_rossberg:
whoops - maybe I didn't check in the header change |
| 12:38.09 |
starseeker |
let me
check |
| 12:40.02 |
CIA-105 |
BRL-CAD:
03starseeker * r44339 10/brlcad/trunk/include/raytrace.h: whoops -
helps to check in the headers too |
| 12:42.47 |
CIA-105 |
BRL-CAD:
03starseeker * r44340 10/brlcad/branches/cmake/ (. include/bu.h
src/libbu/vls.c src/libged/search.c): MFC r44339 |
| 12:43.12 |
CIA-105 |
BRL-CAD:
03davidloman * r44341 10/geomcore/trunk/include/ByteBuffer.h:
getMark() should be public, not protected. |
| 13:08.53 |
CIA-105 |
BRL-CAD:
03starseeker * r44342 10/brlcad/trunk/src/libged/search.c: Hmm -
that only worked on the Mac. Go the safe route and put basename
into a tmp string. |
| 13:09.54 |
CIA-105 |
BRL-CAD:
03starseeker * r44343 10/brlcad/branches/cmake/src/libged/search.c:
MFC r44342 |
| 13:25.41 |
``Erik |
iirc,
basename fills a chunk of static memory and is not necessarily
thread safe |
| 13:27.15 |
``Erik |
wait, no, it
returns a pointer into the memory passed to it, n/m |
| 13:33.46 |
dloman |
fwiw it looks
like gcj hasn't been touched in about 2 years :/ |
| 13:35.41 |
``Erik |
huh, yeh,
sept 22, 2009 |
| 13:36.12 |
``Erik |
last commit
was 113 minutes ago |
| 13:36.28 |
``Erik |
http://gcc.gnu.org/viewcvs/trunk/ |
| 13:36.36 |
dloman |
to the gcc
trunk yeah |
| 13:36.41 |
dloman |
but gcj is a
subset |
| 13:36.52 |
``Erik |
libjava is 28
hours |
| 13:37.03 |
dloman |
yeah, but
someone touched the makefile junk |
| 13:37.06 |
dloman |
thats
it. |
| 13:38.33 |
``Erik |
hm, poking
around, it looks like it's maintenance mode |
| 13:38.55 |
``Erik |
handful of
commits in the last year, some new test stuff, but otherwise
"done" |
| 13:39.05 |
dloman |
yeah, i
looked also. according th the 'status page' there are some big
holes in functionality |
| 13:39.13 |
dloman |
like NIO
isn't implemented :/ |
| 13:39.29 |
``Erik |
nio, even?
hm, last I looked, the gui stuff was the gaping hole :/ |
| 13:39.57 |
dloman |
for the most
part, it is the gui |
| 13:39.58 |
CIA-105 |
BRL-CAD:
03brlcad * r44344 10/brlcad/trunk/TODO: already a request from a
user to test out the BoT TIE integration, via rtg3 or covart, so
add a LIBRT_BOT_MINTIE environment variable as a means to enable it
pervasively. |
| 13:40.12 |
dloman |
but i saw
that .nio.* was also just an interface, no
implementation. |
| 13:40.14 |
dloman |
so that
sucks. |
| 13:40.32 |
``Erik |
brlcad: as a
getenv(), not just the -c cmd? |
| 13:42.10 |
brlcad |
yeah |
| 13:42.48 |
``Erik |
where did the
request come from? I don't see it in email or trackers |
| 13:42.58 |
brlcad |
like
LIBRT_V4FLIP, src/librt/librt.3 |
| 13:43.30 |
brlcad |
it was a
direct e-mail |
| 13:44.46 |
CIA-105 |
BRL-CAD:
03davidloman * r44345 10/geomcore/trunk/ (include/ByteBuffer.h
src/utility/ByteBuffer.cxx): Convert some size_t's to int32_t since
size_t does not necessarily mean unsigned int. |
| 13:45.06 |
brlcad |
bu_basename()
has a patch pending that will require the caller to
bu_free() |
| 13:45.18 |
brlcad |
to match
behavior with bu_dirname() |
| 13:45.38 |
brlcad |
(they don't
match dirname()/basename() but it let them be
thread-safe) |
| 13:45.48 |
brlcad |
at least
re-entrant |
| 13:47.20 |
CIA-105 |
BRL-CAD:
03davidloman * r44346 10/geomcore/trunk/tests/unit/ (3 files in 2
dirs): Implement a few unit tests to get the feel for
CPPUnit. |
| 13:47.50 |
brlcad |
dloman: heh,
int32_t definitely doesn't mean unsigned int either :) |
| 13:47.58 |
brlcad |
uint32_t
would though |
| 13:47.58 |
dloman |
righto |
| 13:48.21 |
dloman |
that's what i
mean :) commit entry was poorly worded. |
| 13:49.32 |
brlcad |
size_t should
be used when the value is meant to represent a "size" (i.e.
unsigned 0->whatever) |
| 13:50.44 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44347 10/brlcad/trunk/src/librt/dir.c: if the
LIBRT_BOT_MINTIE environment variable is set, try to update the
corrosponding global (direct email request to brlcad@ |
| 13:50.46 |
brlcad |
why would a
bytebuffer be specific about using 32-bit return values? smells
wrong |
| 13:51.23 |
dloman |
need
something that can return a -1 |
| 13:51.26 |
brlcad |
at a glance,
getMark() sounds more like an off_t |
| 13:51.53 |
brlcad |
if it's still
a size, ssize_t |
| 13:52.07 |
brlcad |
if it's a
range offset, off_t |
| 13:52.21 |
dloman |
ssize_t ==
signed size_t ? |
| 13:52.28 |
brlcad |
yep |
| 13:52.40 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44348 10/brlcad/trunk/src/libged/search.c: hoise
declarations before body, C90 does not allow mixing. |
| 13:52.54 |
dloman |
its a
position.... so does that make it an range offset? |
| 13:53.48 |
``Erik |
brlcad: in
rt_dirbuild(), I'm assuming that is adequate for <third
party>'s needs? |
| 13:54.08 |
brlcad |
having
functions return values do double-duty with error values and values
mixed fell out of stylistic favor a while ago, but is still fairly
common -- ssize_t was added for that purpose to describe some of
the legacy I/O calls (e.g., man 2 write) |
| 13:54.55 |
brlcad |
``Erik: could
just pull the getenv() during prep, avoid setting the global
altogether |
| 13:55.42 |
dloman |
getMark()
simply returns the 'marker' that the user set in the ByteBuffer.
if its not set, getMark() returns -1 |
| 13:55.45 |
brlcad |
if
(rt_bot_mintie > val || LIBRT_BOT_MINTIE > val || ...) tie
prep |
| 13:56.17 |
brlcad |
dloman: would
a marker of -32 work? |
| 13:56.54 |
dloman |
work as in
'is a marker of -32 valid' ? in that case, no |
| 13:57.29 |
brlcad |
then probably
not an off_t |
| 13:57.39 |
dloman |
kk |
| 13:57.40 |
brlcad |
ssize_t |
| 13:57.49 |
dloman |
gets it now. duh, lol |
| 13:58.13 |
``Erik |
wanted to
avoid a slew of getenv() calls |
| 13:58.44 |
brlcad |
aren't they
basically free? |
| 13:59.09 |
``Erik |
um, any sane
shell would save them in a trie, but it'll be a few
syscalls |
| 13:59.15 |
brlcad |
already
loaded into mem, just scans the array with string
compares |
| 14:01.06 |
brlcad |
yeah, there's
an environ[] global that is set up during binary init |
| 14:01.16 |
brlcad |
shouldnt' be
syscalls |
| 14:01.54 |
brlcad |
http://pubs.opengroup.org/onlinepubs/009695399/functions/getenv.html
says a few things about performance, nothing too insightful other
than it "should" be fast |
| 14:03.12 |
``Erik |
other than
cognitive locality, is there any benefit to placing it in the
primitive prep? |
| 14:03.37 |
brlcad |
also have the
downside for long-running apps that might run some traces, stay
running with the db still open, set the var, then run some
more |
| 14:03.45 |
``Erik |
it's already
a global due to how rt -c works |
| 14:04.29 |
brlcad |
db_open()
isn't a bad choice, it can probably work |
| 14:05.04 |
brlcad |
I'd just
think you'd want it closer to the actual decision point (until it's
observed / measured that performance is a problem) |
| 14:05.08 |
brlcad |
premature and
all that :) |
| 14:05.42 |
``Erik |
hm, I went
with rt_dirbuild() because it seemed like the closest decision
point... a converter will call db_open() without needing to prep
*shrug* |
| 14:06.01 |
brlcad |
oop, I meant
dirbuild |
| 14:07.34 |
``Erik |
*shrug* if
you want to make a todo to discuss it, that's cool. if we move it
and it impacts my isst stuff, I'll bitch/moan/complain/etc
:D |
| 14:08.37 |
``Erik |
I'm not above
saying "if you want it, change your rtg3/covart stuff" (this is the
ohio office?) |
| 14:09.55 |
``Erik |
if they test
it, it'll break and I'll have to fix it :/ I'm running into cmake
issues with gtk+2, so I can't give it the testing I'd like to just
yet |
| 14:11.03 |
brlcad |
if it moved
and impacted, it'd get moved back right away .. that'd be the
"observed" problem :) |
| 14:11.42 |
dloman |
okay, most
systems have htons and htonl, but is there any 'standard' support
for 64 bit ints? |
| 14:11.46 |
brlcad |
the user's
desire to test it isn't our concern until you give it the "thumbs
up, seems to be working fine for me, I'm done" stamp of
approval |
| 14:11.57 |
brlcad |
that's why
the release notes said it was preliminary |
| 14:12.24 |
brlcad |
the flag is
more "oh yeah, that'd be a great way to toggle it on/off for
everyone, even after it's all done and working" |
| 14:12.56 |
brlcad |
dloman: in
libbu there is |
| 14:13.07 |
brlcad |
otherwise
no |
| 14:13.07 |
dloman |
kk, am
checking there atm, thanks. |
| 14:13.49 |
brlcad |
dloman:
nothing so fancy, #include "bu.h" and just call ntohll() or
htonll() |
| 14:15.03 |
dloman |
brlcad: would
you recommend using the fns for floats and doubles as
well? |
| 14:15.29 |
brlcad |
what are you
doing? |
| 14:15.44 |
dloman |
cleaning up
the network serializer stuff |
| 14:15.53 |
brlcad |
libbu
implements htonf() htond() ntohf() ntohd() |
| 14:19.06 |
CIA-105 |
BRL-CAD:
03starseeker * r44349 10/brlcad/branches/cmake/ (TODO
src/libged/search.c src/librt/dir.c): MFC r44348 |
| 14:27.18 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
| 14:35.43 |
*** join/#brlcad willdye
(~willdye@198.183.6.23) |
| 14:39.31 |
CIA-105 |
BRL-CAD:
03davidloman * r44350 10/geomcore/trunk/ (include/ByteBuffer.h
src/utility/ByteBuffer.cxx): use of int32_t for ByteBuffer::mar was
wrong. use ssize_t instead. Also, implemented put16Bit() and
get16Bit() |
| 14:41.17 |
CIA-105 |
BRL-CAD:
03davidloman * r44351 10/geomcore/trunk/src/utility/ByteBuffer.cxx:
No need to increment 'position' since bu_vlb_write already does
this. |
| 14:44.30 |
``Erik |
hm, 'ceylon'
O.o |
| 14:46.58 |
dloman |
? |
| 14:49.56 |
``Erik |
http://blog.talawah.net/2011/04/gavin-king-unviels-red-hats-top-secret.html |
| 14:51.00 |
dloman |
that a play
on Cylon? |
| 14:51.24 |
CIA-105 |
BRL-CAD:
03d_rossberg * r44352 10/rt^3/trunk/include/ (MinimalDatabase.h
brlcad/ConstDatabase.h brlcad/Object.h): |
| 14:51.25 |
CIA-105 |
BRL-CAD:
cleaned up to revision 44007 |
| 14:51.25 |
CIA-105 |
BRL-CAD: -
removed unused includes from ConstDatabase.h (moved them to
MinimalDatabase.h, maybe they are important there) |
| 14:51.56 |
``Erik |
redhat has a
plan. |
| 14:53.03 |
starseeker |
how do they
plan to get all the existing java code over to Ceylon
though? |
| 14:53.39 |
starseeker |
we can't even
get IE6 to die - I doubt anything will prompt businesses to rewrite
key Java code |
| 14:54.36 |
``Erik |
it's
"enterprisy" and on the jvm, groovy was too 'hippy'
*shrug* |
| 14:54.57 |
starseeker |
is the jvm
fully open source? |
| 14:55.23 |
``Erik |
last I heard,
the only turd left was in the sound code? |
| 14:55.34 |
starseeker |
hmm' |
| 14:56.19 |
``Erik |
well, the
only technical turd... the new ownership is a big steaming pile...
O:-) |
| 14:57.03 |
starseeker |
interesting:
http://vmkit.llvm.org/ |
| 14:57.37 |
``Erik |
you saw that
apple has thrown in with the llvm crowd after gcc went
gplv3? |
| 14:57.56 |
starseeker |
yep |
| 14:58.38 |
starseeker |
could be a
very good thing |
| 14:59.31 |
starseeker |
only problem
I know of at the momemt is that clang isn't quite there performance
wise compared to gcc |
| 14:59.42 |
``Erik |
mebbe,
hopefully apple still has some top tier talent, even though they
just had another 'great exodus' |
| 14:59.51 |
starseeker |
did
they? |
| 15:00.02 |
starseeker |
hadn't heard |
| 15:00.03 |
``Erik |
well, mebbe
5ish years ago |
| 15:00.10 |
starseeker |
oh, the BSD
guys? |
| 15:00.15 |
``Erik |
hubbard,
perlstein, etc |
| 15:00.16 |
``Erik |
yeah |
| 15:01.19 |
starseeker |
well, so far
it looks like they're doing a decent job |
| 15:01.52 |
starseeker |
a robust
compiler toolkit with most of industry behind it and a BSD license
strikes me as a Good Thing - everybody benefits |
| 15:02.42 |
starseeker |
seeing as
there's not much of a commerical compiler market outside of
specialized applications, it's in the interests of most companies
to make a common substrate as good as possible |
| 15:03.14 |
``Erik |
icc is
proprietary, right? |
| 15:03.27 |
starseeker |
and Apple's
gcc fork is going to stray further and further from gcc proper, so
it'll just get more and more annoying |
| 15:03.30 |
starseeker |
I believe
so |
| 15:04.02 |
``Erik |
of anyone who
would benefit, intel would be the obvious choice... they're
starting to smell like 80's ibm :/ |
| 15:05.26 |
starseeker |
they must get
enough licenses to make it worthwhile |
| 15:05.52 |
starseeker |
I suppose for
companies shipping binaries, the cost is no big deal and they want
the speedup |
| 15:06.52 |
starseeker |
dunno though
- modern PCs seem fast enough that the difference would only be
user visible in select cases |
| 15:33.46 |
CIA-105 |
BRL-CAD:
03starseeker * r44353 10/brlcad/trunk/src/libged/search.c: Unlike
find, we won't insist on a path if we're given options - if we have
options but no path, assume '.' |
| 15:34.48 |
CIA-105 |
BRL-CAD:
03starseeker * r44354 10/brlcad/branches/cmake/src/libged/search.c:
MFC r44353 |
| 16:13.19 |
CIA-105 |
BRL-CAD:
03starseeker * r44355
10/brlcad/trunk/doc/docbook/system/mann/en/search.xml: Update
search documentation |
| 16:13.58 |
CIA-105 |
BRL-CAD:
03starseeker * r44356
10/brlcad/branches/cmake/doc/docbook/system/mann/en/search.xml: MFC
r44355 |
| 16:26.05 |
starseeker |
brlcad: hrm.
I can't get the red tests to work - they're trying to fire off
emacs for some reason |
| 16:33.38 |
starseeker |
oh, I have to
set EDITOR to cat |
| 16:48.05 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:13.39 |
``Erik |
hm, I saw
that on fbsd, but mac worked ok |
| 17:14.38 |
``Erik |
wonders if anything is still going on with googles 'go'
O.o |
| 17:32.33 |
dloman |
http://i.imgur.com/y7Hm9.jpg |
| 17:55.37 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 18:07.10 |
CIA-105 |
BRL-CAD:
03r_weiss * r44357 10/brlcad/trunk/src/libbn/plane.c: (log message
trimmed) |
| 18:07.11 |
CIA-105 |
BRL-CAD:
Corrected a bug in function 'bn_isect_lseg3_lseg3_new' in file
'plane.c' within |
| 18:07.11 |
CIA-105 |
BRL-CAD: the
libbn library. This is a prototype version of the
function |
| 19:06.09 |
starseeker |
brlcad: aha -
ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/bmake/files/realpath.c |
| 19:08.48 |
CIA-105 |
BRL-CAD:
03starseeker * r44358
10/brlcad/branches/cmake/regress/CMakeLists.txt: Add CMake code to
run the red regression, but don't add it to the general regress
target for now since a) red doesn't pass and b) something funny is
happening with the EDITOR being called |
| 19:13.09 |
CIA-105 |
BRL-CAD:
03starseeker * r44359 10/brlcad/trunk/ (include/bu.h
src/libbu/vls.c src/libged/search.c): OK, no halfway measures.
Going to need a full-on path resolution function. |
| 19:21.43 |
CIA-105 |
BRL-CAD:
03davidloman * r44360 10/geomcore/trunk/tests/unit/utility/
(ByteBufferUTest.cxx ByteBufferUTest.h): Complete implementation of
the ByteBufferUTest class. |
| 19:23.23 |
CIA-105 |
BRL-CAD:
03davidloman * r44361 10/geomcore/trunk/ (include/ByteBuffer.h
src/utility/ByteBuffer.cxx): Unit test immediately reveled some
bugs with ByteBuffer's behavior. Fixt. |
| 19:33.45 |
*** join/#brlcad Raz_Lobo
(~razer@178.139.103.130) |
| 19:38.35 |
Raz_Lobo |
hi all, I
have a problem during deb package built of Brlcad-7.18.4 on PowerPC
architecture. |
| 19:38.41 |
Raz_Lobo |
Copy from
console: |
| 19:38.59 |
Raz_Lobo |
gcc
-DHAVE_CONFIG_H -I. -I. -I../../include
-I../../src/other/tcl/generic -I../../src/oBS
-I../../src/other/libz -pedantic -W -Wall -Wundef -Wfloat-equal
-Wshadow -Winline -Wnc -W -Wall -Wundef -Wfloat-equal -Wshadow
-Winline -Wno-long-long -c bntester.c |
| 19:38.59 |
Raz_Lobo |
cc1: warnings
being treated as errors |
| 19:38.59 |
Raz_Lobo |
bntester.c:
In function ‘main’: |
| 19:38.59 |
Raz_Lobo |
bntester.c:190:5: error: comparison is
always true due to limited range of data type |
| 19:38.59 |
Raz_Lobo |
make[3]: ***
[bntester.o] Error 1 |
| 19:39.06 |
Raz_Lobo |
Someone can
help me? |
| 19:39.38 |
starseeker |
Raz_Lobo: Try
adding --disable-strict to the configure flags |
| 19:40.27 |
Raz_Lobo |
ok, thanks so
much, so fast. ^_^ |
| 19:40.28 |
Raz_Lobo |
I
try. |
| 20:21.16 |
brlcad |
starseeker:
hmm.. you shouldn't have needed to set editor to cat |
| 20:23.52 |
starseeker |
``Erik was
seeing issues with that too |
| 20:25.34 |
brlcad |
also,
ftp://ftp.irisa.fr/pub/OpenBSD/src/lib/libc/stdlib/realpath.c |
| 20:26.01 |
*** join/#brlcad dli
(~dli@dsl-173-248-203-45.acanac.net) |
| 20:26.20 |
brlcad |
the more I
think about it, the more I lean towards that deserving to be a
librt function, not libbu |
| 20:27.07 |
brlcad |
since the
minimal case right now isn't arbitrary path reduction, it's
geometry path reduction |
| 20:27.29 |
brlcad |
also sets the
stage for later if "symbolic link" objects get added |
| 20:27.52 |
starseeker |
arrgh
:-P |
| 20:28.02 |
starseeker |
is 4/5 of the way to a bu_normalize |
| 20:28.14 |
brlcad |
hehe, you
still need every bit of that for the rt func |
| 20:28.55 |
starseeker |
let me get
this going first, then we can move it |
| 20:29.01 |
brlcad |
yeah keep on
then, not a big deal |
| 20:31.11 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:39.25 |
CIA-105 |
BRL-CAD:
03starseeker * r44362 10/brlcad/trunk/ (include/bu.h
src/libbu/brlcad_path.c src/libged/search.c): Try again, this time
with a realpath based path normalization |
| 20:44.48 |
CIA-105 |
BRL-CAD:
03starseeker * r44363 10/brlcad/branches/cmake/ (5 files in 4
dirs): MFC r44362 |
| 20:56.57 |
CIA-105 |
BRL-CAD:
03starseeker * r44364 10/brlcad/trunk/ (4 files in 2 dirs): Move
db_path.c to db_fullpath.c |
| 21:06.00 |
CIA-105 |
BRL-CAD:
03starseeker * r44365 10/brlcad/trunk/ (7 files in 4 dirs): Take a
stab at making bu_normalize into db_normalize |
| 21:15.51 |
CIA-105 |
BRL-CAD:
03starseeker * r44366 10/brlcad/trunk/src/librt/db_path.c: Opps,
headers are a good thing. |
| 21:18.19 |
CIA-105 |
BRL-CAD:
03starseeker * r44367 10/brlcad/branches/cmake/ (9 files in 4
dirs): MFC r44366 |
| 21:27.20 |
CIA-105 |
BRL-CAD:
03starseeker * r44368 10/brlcad/trunk/src/libged/search.c: remove
debug line |
| 21:58.39 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-70-176.try.wideopenwest.com) |
| 22:45.31 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 02:28.10 |
brlcad |
hello
evander |
| 02:30.43 |
``Erik |
so the merge
is complete? |
| 02:42.01 |
evander |
I'm having
trouble getting brl-cad to compile, it's just one line causing
trouble, anyone willing to help |
| 02:42.05 |
evander |
? |
| 02:49.42 |
brlcad |
``Erik: doing
a final pass review now |
| 02:50.12 |
brlcad |
haven't done
a compilation check yet, both old and new builds may be busted but
the changes are reviewed and merged |
| 02:50.17 |
brlcad |
evander:
what's the failure? |
| 02:51.39 |
evander |
make says
that 'abi' and 'aci' 'may be uninitialized in this
function' |
| 02:54.42 |
evander |
this is for
the proc_box function in src/librt/patch/patch-g.c line 1936:
'vect_t ab, ac, ad, abi, aci, adi' |
| 02:55.37 |
evander |
sorry,
src/conv/patch/patch-g.c |
| 03:10.12 |
``Erik |
evander:
there's a flag to disable strict flags when you run configure, try
that? |
| 03:14.10 |
evander |
I'll
try |
| 03:21.38 |
CIA-105 |
BRL-CAD:
03brlcad * r44466 10/brlcad/trunk/src/conv/patch/patch-g.c: quell
strict compilation warning reported by evander via irc. compiler
wasn't smart enough to figure out that use prior to init isn't
possible (valid is false). |
| 03:33.41 |
CIA-105 |
BRL-CAD:
03brlcad * r44467 10/brlcad/trunk/misc/archlinux/brlcad.install:
remove the rcs id var to minimize branch diff. add /bin/sh header
for source scanners since it looks like proper syntax. |
| 03:37.54 |
CIA-105 |
BRL-CAD:
03brlcad * r44468
10/brlcad/trunk/src/other/togl/CMake/CheckFunctions.cmake: this
just very well may be the last sync needed to merge cmake branch to
trunk. |
| 03:40.20 |
brlcad |
verified, the
diff looks clean |
| 03:40.33 |
brlcad |
now to
check/fix the build :) |
| 03:41.09 |
brlcad |
fair game for
anyone to hack on now |
| 03:51.57 |
``Erik |
I'll do my
usual spread tomorrow and either fix or report all the failures O.o
I doubt there'll be many if the merge is solid, been
fixing/reporting for the cmake branch for a while :) |
| 04:17.17 |
brlcad |
should be
possible to have both working without too much effort at least
while install testing proceeds -- that was just a pure source merge
review so the branch can be closed out |
| 04:19.52 |
CIA-105 |
BRL-CAD:
03brlcad * r44469 10/brlcad/trunk/src/conv/patch/patch-g.c: oops,
double semi |
| 04:31.31 |
brlcad |
hmm.. the
lights regression is failing |
| 04:31.46 |
brlcad |
pretty sure
it worked for release, but not 100% |
| 04:34.18 |
CIA-105 |
BRL-CAD:
03brlcad * r44470 10/brlcad/trunk/TODO: light regression is
failing, need to investigate and fix. don't know when it
broke. |
| 04:39.04 |
CIA-105 |
BRL-CAD:
03brlcad * r44471 10/brlcad/trunk/TODO: |
| 04:39.04 |
CIA-105 |
BRL-CAD: aha,
found the cause. the lights test calls 'put' and sets attributes
directly |
| 04:39.05 |
CIA-105 |
BRL-CAD:
including several old attribute names such as rgb and .. oshader.
this makes |
| 04:51.34 |
CIA-105 |
BRL-CAD:
03brlcad * r44472 10/brlcad/trunk/src/librt/CMakeLists.txt:
deterministic behavior still applies, ignore individual
'extra_dist' files. |
| 05:55.06 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:02.29 |
*** join/#brlcad crazy_imp
(~mj@a89-182-193-94.net-htp.de) |
| 08:07.31 |
*** join/#brlcad crazy_im1
(~mj@a89-182-199-125.net-htp.de) |
| 08:45.35 |
*** join/#brlcad mafm
(~mafm@213.Red-83-40-126.dynamicIP.rima-tde.net) |
| 10:29.08 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 11:28.43 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 11:39.39 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 13:14.36 |
brlcad |
interesting..
old build passed distcheck :) |
| 13:26.00 |
starseeker |
blinks - but it shouldn't, should it? |
| 13:29.06 |
``Erik |
should the
old stuff get all the CMakeLists.txt and misc/CMake/ stuff added as
EXTRA_DIST ? |
| 13:29.42 |
brlcad |
that's why it
passing distcheck was interesting :) |
| 13:29.56 |
brlcad |
but
otherwise, yeah |
| 13:30.18 |
starseeker |
winces - that's a lot of work unless we're going to maintain
both for a while |
| 13:30.21 |
``Erik |
distcheck
won't complain if unknown "turds" don't get put in the
tarball |
| 13:30.32 |
brlcad |
only minimal
attention I'd think -- wont' live for long |
| 13:30.55 |
brlcad |
``Erik:
except I have logic in there that checks if anything is
missing |
| 13:31.09 |
brlcad |
it compares
the svn list with the dist |
| 13:31.34 |
starseeker |
took some
doing to duplicate that behavior with CMake |
| 13:31.36 |
brlcad |
starseeker:
o.O not really .. 10 min tops |
| 13:32.10 |
starseeker |
brlcad:
updating all the Makefile.am extradists for all the directories
where something was added? |
| 13:32.11 |
brlcad |
tedious,
sure, but not a lot of actual time |
| 13:32.28 |
starseeker |
what do we
gain? |
| 13:32.52 |
brlcad |
if we have to
push a source release with it |
| 13:33.11 |
brlcad |
it's not your
10min, no worries :) |
| 13:33.18 |
starseeker |
true
:-) |
| 13:33.41 |
brlcad |
I didn't plan
on adding them unless distcheck failed |
| 13:33.53 |
brlcad |
and it didn't
fail, so .. interesting :) |
| 13:34.03 |
starseeker |
cmake build
is currently failing due to the Itcl_Init issue, bty |
| 13:42.49 |
brlcad |
hm, mine is
actually failing in librt here |
| 13:42.55 |
brlcad |
strictness
fail on bot.c |
| 13:43.02 |
brlcad |
signage
warnings |
| 13:48.03 |
starseeker |
er, yeah -
itcl is with strict off |
| 13:48.21 |
starseeker |
(lots of
formatting blather too) |
| 13:56.13 |
brlcad |
so that's
going to require a little digging -- Itcl_init definitely shouldn't
be failing (nor should package require) |
| 13:56.18 |
brlcad |
i'll hop of
the debugger later today |
| 13:56.23 |
brlcad |
s/of/on/ |
| 14:00.10 |
``Erik |
the signed
issues came from a commit indianlarry did, I'll ask him about it
when he gets back in the office |
| 14:01.55 |
brlcad |
autotools
strict is actually off in librt, was turned off during release
preparations due to a problem in the nmg export code |
| 14:02.04 |
brlcad |
so even if
bot succeeds, nmg is going to issue a warning |
| 14:02.41 |
brlcad |
we need to
either exempt librt like autotools does, or fix the warnings
(ideal) |
| 14:05.23 |
``Erik |
yeah, I'd
like to ask him sooner than later while it's still semi-fresh,
mebbe leave a comment in the src if it bears holding off
reverting |
| 14:06.08 |
``Erik |
log says
something about a bug report, d'no which one, so'z
*shrug* |
| 14:36.42 |
starseeker |
brlcad: I
know why Itcl_init isn't working - it's because I didn't include
all the directories needed for the itcl.h/itk.h headers |
| 14:37.29 |
starseeker |
was trying to
use package require to avoid that whole "using private headers"
mess |
| 15:33.31 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.20.210) |
| 15:33.31 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:57.14 |
``Erik |
mmmm, pröst
*pats belleh* |
| 16:58.04 |
``Erik |
brlcad: those
g_bot_include signed issues are direct fallout from size_t, the
'index' and nhits stuff use -1 as a special value in some cases, a
mixed of == and <0 |
| 16:59.58 |
starseeker |
brlcad: there
are a couple of cases where I call out whole directories to ignore
in the CMakeLists.txt files - in particular, the Tcl/Tk man pages
are generated by scripts. I suppose would could actually list all
those out and update that list every time Tcl/Tk changes something,
but that's quite a pain as opposed to just snarfing the list of
generated files after generating them |
| 17:06.19 |
CIA-105 |
BRL-CAD:
03starseeker * r44473
10/brlcad/trunk/doc/docbook/system/mann/en/CMakeLists.txt: Remove
early experiment with file-checking code |
| 17:21.18 |
CIA-105 |
BRL-CAD:
03starseeker * r44474 10/brlcad/trunk/src/ (bwish/CMakeLists.txt
mged/CMakeLists.txt): Until we get it sorted out, add in the logic
needed for btclsh/bwish and mged to find the itcl.h and itk.h
headers. |
| 17:21.46 |
starseeker |
ok, that gets
me going with a non-strict build on Mac |
| 17:24.28 |
starseeker |
reflects that eventually we'll probably want to update the
svn ignore properties in trunk |
| 17:24.37 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44475
10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: use
temporary signed variables to quell the signed/unsigned warning.
Add a TODO: requesting review down the road. |
| 17:34.00 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44476
10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: bu_glong ->
ntohl (only tested on v5) |
| 17:35.35 |
``Erik |
librt should
be safe for strict again |
| 17:42.51 |
CIA-105 |
BRL-CAD:
03starseeker * r44477 10/brlcad/trunk/
(misc/CMake/BRLCAD_Util.cmake src/librt/CMakeLists.txt): Add the
ability to specify a NOSTRICT compile when adding a
library. |
| 18:11.53 |
*** join/#brlcad merzo
(~merzo@222-14-94-178.pool.ukrtel.net) |
| 18:14.05 |
brlcad |
``Erik: yeah,
I remember that patch -- most of the -1 should have been properly
cast through size_t, so if anything was missed, it might have been
a <0 check that needed to be changed to ==
(size_t)-1 |
| 18:14.28 |
brlcad |
warrants
getting the test case that provoked the bug |
| 18:16.11 |
brlcad |
starseeker:
that sounds fine for src/other dirs -- I think the issue is more
with our own directories |
| 18:16.41 |
starseeker |
brlcad: k.
For ours it'll probably be a few cases like the xxx dir |
| 18:17.50 |
brlcad |
a minor
referential integrity cost so we can say we're fully managed (with
lists of all intentional files, whether source code or
not) |
| 18:18.09 |
brlcad |
not a major
issue in the least, just completeness |
| 18:18.22 |
brlcad |
really
impressed how cleanly the merge went |
| 18:19.49 |
brlcad |
``Erik:
unless I typo'd .. the "obvious" conversion to ntohl() resulted in
a hard crashing raytracing bug |
| 18:20.13 |
starseeker |
'course, I
doubt the windows build works right now |
| 18:20.32 |
starseeker |
but it
shouldn't be far off |
| 18:20.39 |
brlcad |
sure, some
wrinkles to iron out, but in all .. looking great |
| 18:20.44 |
starseeker |
is impressed you managed to save all the
history |
| 18:20.46 |
brlcad |
old build
works, new build works |
| 18:21.29 |
starseeker |
(all my early
CMake suckage preserved for posterity...) |
| 18:21.30 |
brlcad |
now a
confirmation that release tarballs produced are identical and same
with binary installs, and the old can go bye bye soon |
| 18:21.47 |
starseeker |
not quite yet
- install docs will need more work |
| 18:22.02 |
brlcad |
minor, that's
an afternoon at best |
| 18:22.29 |
starseeker |
and possibly
some expansion of the options in the fake configure script - also
not a huge deal, unless we want to automate its
generation |
| 18:22.54 |
brlcad |
it'll take
more time to write up an article on the conversion overview and
impact |
| 18:23.50 |
starseeker |
for the
source files, it's make package_source - make package for the
binaries, IIRC |
| 18:24.21 |
brlcad |
no worries,
I'll assume it's all documented in INSTALL.cmake |
| 18:24.25 |
brlcad |
otherwise,
I'll chase you down :) |
| 18:24.32 |
starseeker |
quickly checks... |
| 18:24.34 |
starseeker |
erm... |
| 18:24.53 |
brlcad |
er, perhaps
HACKING.cmake |
| 18:25.23 |
starseeker |
which doesn't
exist yet |
| 18:25.25 |
starseeker |
gets busy |
| 18:29.39 |
starseeker |
eventually
we'll probably want to tie the new deb/rpm settings into the CPack
stuff |
| 18:37.41 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.20.210) |
| 18:37.41 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:46.11 |
``Erik |
brlcad: I
raytraced a big nmg heavy model successfully (took 2 regex passes
and hand reviewing the changes to verify, there was a cfl grade
difference in some cases) |
| 18:46.38 |
``Erik |
for bots, the
test case was dark side |
| 18:47.36 |
brlcad |
``Erik: okay
cool |
| 18:47.50 |
brlcad |
i'm not above
having entered a typo or fat-fingered some expression |
| 18:48.14 |
brlcad |
probably diff
what I did with your patch to see where this lamb went
astray |
| 18:59.07 |
CIA-105 |
BRL-CAD:
03starseeker * r44478 10/brlcad/trunk/src/other/CMakeLists.txt: Add
a few dirs to the ignore list |
| 19:08.13 |
kanzure |
did jdoliner
ever finish his implementation of boole? http://brlcad.org/wiki/User:Jdoliner |
| 19:10.27 |
kanzure |
ah..
brlcad/trunk/src/proc-db/surfaceintersect.cpp |
| 19:12.15 |
kanzure |
yeah i'm not
sure if he committed all of his code or not |
| 19:13.07 |
kanzure |
hmm the
latest was 2009-08-13 |
| 19:13.14 |
kanzure |
ok. that
sounds about right |
| 19:14.25 |
brlcad |
kanzure: he
didn't implement or integrate boole itself, but he was trying to
implement what boole does in our system |
| 19:15.18 |
brlcad |
he started
building up the individual pieces needed to get surface-surface
intersection calculations going, and got something going, but it
wasn't a complete effort |
| 19:15.48 |
kanzure |
looks like he
did good work sticking with the opennurbs primitives |
| 19:15.54 |
brlcad |
src/proc-db/surfaceintersect.cpp is the
latest state of the code |
| 19:15.58 |
brlcad |
yeah, pretty
good |
| 19:16.46 |
kanzure |
on the wiki
he mentions SurfaceSurfaceIntersect but all i see is
BrepBrepIntersect; i figure it's the one? |
| 19:16.59 |
kanzure |
oh
"SurfaceSurfaceIntersect has been renamed to FaceFaceIntersect
same" ok |
| 19:17.21 |
brlcad |
a brep is one
or more surfaces |
| 19:17.54 |
kanzure |
i forget how
opennurbs handles multiple faces on an object |
| 19:18.13 |
kanzure |
i know that
it's accessed as an array (like my_nurb.m_F[x] for the xth
face) |
| 19:18.21 |
kanzure |
but usually
there's some information about adjacency of faces .. er,
somewhere |
| 19:18.42 |
brlcad |
see
src/proc-db/brep*.cpp |
| 19:18.51 |
kanzure |
since you can
call myobject.get_edges() where each edge separates two faces,
etc. |
| 19:18.54 |
kanzure |
ok |
| 19:18.55 |
brlcad |
several
examples |
| 19:19.42 |
kanzure |
it's the
trimming curve that is the edge around a given face
right? |
| 19:20.45 |
brlcad |
yes |
| 19:21.40 |
kanzure |
why do you
say it wasn't a complete effort? |
| 19:21.51 |
kanzure |
oh duh,
intersection isn't enough to actually perform the set
operators |
| 19:22.14 |
*** join/#brlcad KimK
(~Kim__@wlnt-02-246.dsl.netins.net) |
| 19:22.20 |
brlcad |
and I don't
think his implementation will handle ALL cases of surface surface
intersections |
| 19:22.29 |
brlcad |
lots of edge
cases to consider |
| 19:24.00 |
CIA-105 |
BRL-CAD:
03starseeker * r44479 10/brlcad/trunk/doc/README.MacOSX: Document
the issue CMake has with parallel builds and OSX open file
limits |
| 19:25.00 |
kanzure |
yeah and then
you have to merge the intersection curves |
| 19:25.07 |
CIA-105 |
BRL-CAD:
03starseeker * r44480 10/brlcad/trunk/HACKING.cmake: Add a cmake
version of HACKING |
| 19:26.16 |
kanzure |
then use the
merged brep to partition the original two solids, classify each
partitioned component as either inside/outside and based on that
classification add it to the object (depending on whether this is a
union or difference) |
| 19:28.33 |
brlcad |
example,
consider two simple triangles. they can intersect as a point (pt),
a line (ln), or a face (fc), so you have pt-pt for two coinciding
vertices, pt-ln for a vertex on edge, and pt-fc for a vertex in the
face; ln-ln for coinciding edges (with three overlap sub-cases),
ln-fa (similarly with three sub-cases), and fa-fa for
non-tangential planar intersections (with at least three
sub-cases) |
| 19:29.15 |
brlcad |
that's twelve
cases, and I'd be surprised if he ended up with support for more
than a few of them |
| 19:30.16 |
brlcad |
two random
intersecting polygons is going to be a fc-fc intersect producing a
ln result |
| 19:31.06 |
kanzure |
i don't know
what to do in the case of a vertex on a face- presumably that
vertex is infintismal anyway so.. |
| 19:31.29 |
brlcad |
right, so you
decide whether to ignore or stitch |
| 19:31.48 |
brlcad |
one of them
will be wrong :) |
| 19:32.03 |
brlcad |
but you don't
know which |
| 19:33.24 |
brlcad |
you could
attempt to say "okay, no points on faces" .. but even regular
triangle that share an edge have this property (two pairs of
coinciding vertices and a coinciding edge) |
| 19:33.59 |
kanzure |
btw the guys
who wrote BOOLE released their code in the public
domain |
| 19:34.36 |
kanzure |
(in
c) |
| 19:34.49 |
brlcad |
basically,
it's needing to preserve a concept of "inside", "outside", ... and
"on" |
| 19:35.15 |
brlcad |
boole is not
PD, unless they changed it recently |
| 19:35.25 |
brlcad |
it's
NC |
| 19:36.04 |
brlcad |
http://gamma.cs.unc.edu/CSG/BOOLE-DOCS/copyright |
| 19:36.32 |
kanzure |
blah |
| 19:36.55 |
kanzure |
sorry for the
false alarm |
| 19:37.13 |
brlcad |
I know the
guys that worked on boole (and later esolid) |
| 19:37.25 |
brlcad |
that was
collaborative research back in the day |
| 19:37.29 |
kanzure |
in one of
their papers they claim it is public domain, but i see the license
clearly claims differently |
| 19:37.41 |
brlcad |
they actually
gave us permission to use their code many years ago via e-mail, but
no longer have access to that e-mail without serious archive
searching |
| 19:37.57 |
kanzure |
yeah the same
paper references muuss which made me wonder if brlcad implemented
this (which, the answer is no, but the 2009 gsoc student worked on
it, neat) |
| 19:38.32 |
brlcad |
they were
contracted by BRL to work on the problem back in the mid-90's, but
unfortunately there was licensing disputes |
| 19:38.40 |
kanzure |
lamesauce |
| 19:38.56 |
brlcad |
maybe late
80's .. old history now |
| 19:39.27 |
kanzure |
i trust boole
over, say, opencascade, for their intersection algorithm.. since at
least this one is documented |
| 19:39.31 |
brlcad |
the goal was
primarily nurbs raytracing and I think our current implementation
easily beats it hands down |
| 19:39.48 |
kanzure |
i'm honestly
surprised how there is no simple, well-written, well-documented,
open source brep-brep intersection software |
| 19:40.06 |
kanzure |
this isn't
*that* hard |
| 19:40.32 |
brlcad |
a lot of the
surface surface intersection calculations were needed to get
accurate ray-tracing, so you might be able to repurpose some of the
ray-tracing code into a more general surface-surface intersection
function |
| 19:40.55 |
kanzure |
i was
thinking of implementing boole but i see there's a good start
here |
| 19:40.58 |
brlcad |
it's hard to
do robustly :) |
| 19:41.16 |
kanzure |
i think
robustness can be sacrificed at first for a working system, and
then robustness can be designed in for a 2.0 |
| 19:41.35 |
kanzure |
once we have
someone, anyone, who is working on open source code that has
successfully implemented any of this :) |
| 19:42.00 |
brlcad |
that's just
it, it's not really working if it's not robust -- the best you can
do is limit yourself to robustness across simple
geometry |
| 19:42.08 |
brlcad |
like two
spheres or two boxes |
| 19:42.22 |
kanzure |
do you mean
practically robust or the academic version of "robust by proof"?
;) |
| 19:42.27 |
kanzure |
er, robust by
theorem |
| 19:42.28 |
brlcad |
even robustly
answering whether that pairing intersect or not ..
tricky |
| 19:42.36 |
brlcad |
practically
robust |
| 19:42.50 |
brlcad |
if you want
provably, you need different numerics |
| 19:42.57 |
brlcad |
CGAL-style |
| 19:43.04 |
brlcad |
slow fixed
arithmetic |
| 19:43.57 |
brlcad |
if you want
to pick up the torch working in src/proc-db or elsewhere related to
this, lemme know and I'll set you up |
| 19:44.14 |
kanzure |
what do you
mean set me up? |
| 19:44.47 |
brlcad |
with commit
access, so you can work on test code in src/proc-db for
example |
| 19:45.51 |
brlcad |
if you want
to do your own thing out of repo, that's cool too, but it is nice
to see the commits to see rationale behind development
directions |
| 19:45.54 |
kanzure |
i don't have
anything to commit at the moment but i'll ping you |
| 19:46.02 |
kanzure |
that's
true.. |
| 19:46.26 |
brlcad |
whatever
works |
| 19:46.45 |
kanzure |
so you're ok
with incomplete/dysfunctional code commits? |
| 19:47.00 |
brlcad |
in
src/proc-db yes |
| 19:47.07 |
brlcad |
in src/lib*
no |
| 19:47.20 |
brlcad |
unless it's
#ifdef's out of course |
| 19:47.45 |
brlcad |
just
shouldn't affect production use until it's reasonably well
tested |
| 19:48.05 |
brlcad |
otherwise,
visibility and communication ftw |
| 19:50.35 |
kanzure |
okay. |
| 19:50.48 |
kanzure |
sure, i'll
take some svn commit access goodness |
| 19:52.05 |
brlcad |
done |
| 19:52.07 |
brlcad |
you've been
around here long enough to know how we operate, not exactly a loose
canon |
| 19:52.20 |
brlcad |
just don't
break stuff :) |
| 19:52.28 |
brlcad |
read HACKING
for the rest |
| 19:52.39 |
brlcad |
and/or
ask |
| 20:03.15 |
kanzure |
okie
dokie |
| 20:05.53 |
*** join/#brlcad mafm
(~mafm@48.Red-83-63-197.staticIP.rima-tde.net) |
| 20:14.35 |
kanzure |
brlcad: did
you add my sourceforge account? |
| 20:22.26 |
brlcad |
yep |
| 20:22.26 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44481
10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: use defvar
instead of defparameter (to avoid clobbering a live recompile
conflict). Use global variable notation instead of
constant. |
| 20:22.32 |
brlcad |
try a test
commit |
| 20:25.06 |
kanzure |
i'd rather
not muddy up commit history |
| 20:26.04 |
brlcad |
heh |
| 20:26.30 |
brlcad |
it's a huge
history, not really going to be noticed :) |
| 20:26.53 |
CIA-105 |
BRL-CAD:
03erikgreenwald * r44482 10/geomcore/trunk/src/libgvm/repo.c:
return 0 on success (instead of stack trash since there was no
explicit return on success) |
| 20:27.09 |
brlcad |
https://sourceforge.net/mailarchive/forum.php?forum_name=brlcad-commits
<-- per month commit stats |
| 20:28.21 |
brlcad |
wow, we hit a
new record in january .. 914, nifty! |
| 20:42.02 |
``Erik |
ah,
svn_repos_open doesn't open the file, each operation opens and
closes the file described by the repo struct... brutal |
| 20:49.05 |
bhinesley |
while (1)
{touch . ; svn commit -M "testing"} |
| 20:49.13 |
bhinesley |
this month
promises to be even better ;) |
| 20:49.43 |
brlcad |
heh, nice
try |
| 20:50.12 |
brlcad |
that wouldn't
commit a change, and you'll get invalid option on the -M
;) |
| 20:51.22 |
``Erik |
can't think of a shell that'd eat that |
| 20:51.53 |
brlcad |
while `true`
; do echo "==$RANDOM==" >> file ; svn commit -m "+1" file ;
cat file | sed 's/==.*==//g' > file ; done |
| 20:52.06 |
*** join/#brlcad merzo
(~merzo@7-32-94-178.pool.ukrtel.net) |
| 20:52.17 |
bhinesley |
you guys are
too much |
| 20:54.58 |
*** join/#brlcad mafm
(~mafm@48.Red-83-63-197.staticIP.rima-tde.net) |
| 20:54.59 |
starseeker |
never give
brlcad a shell script challenge |
| 21:00.36 |
``Erik |
it's just
another language *shrug* a repl based one, even |
| 21:01.30 |
kanzure |
brlcad: now
that i look at it, BrepBrepIntersect doesn't actually use its
(brep) "out" variable |
| 21:02.08 |
kanzure |
err,
(ON_Brep) type |
| 21:02.55 |
brlcad |
kanzure: yep,
I vaguely recall having to mark that as UNUSED during a strictness
pass |
| 21:03.02 |
kanzure |
ah. |
| 21:03.04 |
kanzure |
fooey |
| 21:03.09 |
brlcad |
fix it
;) |
| 21:03.15 |
brlcad |
or
rewrite |
| 21:03.26 |
kanzure |
if it wasn't
using opennurbs, i'd immediately rewrite it on my own |
| 21:03.43 |
kanzure |
but.. since
he did at least go to the trouble of making this slightly
maintainable.. |
| 21:03.55 |
brlcad |
opennurbs is
actually a pretty nice api to work with |
| 21:04.16 |
kanzure |
sure |
| 21:04.22 |
brlcad |
most of the
annoying aspects have been things that were intentionally
removed |
| 21:04.30 |
kanzure |
yes |
| 21:04.36 |
kanzure |
ON_GL...
grr |
| 21:04.48 |
``Erik |
nice, the
acknowledgements section in the scsh manual... awesome |
| 21:05.19 |
brlcad |
do they thank
the flying spagetti monster? |
| 21:05.49 |
``Erik |
http://www.scsh.net/docu/html/man.html |
| 21:07.21 |
brlcad |
haha |
| 21:18.06 |
brlcad |
hm, sanity
check: unsigned char cp; cp + 4 == &cp[4] ? |
| 21:22.11 |
``Erik |
yup |
| 21:23.51 |
brlcad |
then the only
diff between our conversions is you wrapped the cast in
parens |
| 21:24.31 |
brlcad |
I'm thinking
the bug was actually an unrelated change made to rt_nmg_reindex()
in the same commit |
| 21:24.49 |
brlcad |
upgraded
return type from int to long including two index vars |
| 21:26.40 |
brlcad |
the parens
shouldn't matter because arrow has higher precedence than the cast,
so it's already grouped |
| 21:27.01 |
brlcad |
otherwise we
match line for line |
| 21:27.08 |
brlcad |
gotta be
rt_nmg_reindex() .. hrm |
| 21:29.29 |
brlcad |
either way,
nice fix ``Erik .. librt can be restrictified |
| 21:34.45 |
*** join/#brlcad bhinesley
(~bhinesley@99.104.168.20) |
| 21:42.23 |
CIA-105 |
BRL-CAD:
03starseeker * r44483 10/brlcad/trunk/src/librt/CMakeLists.txt:
Erik restored the strict building. |
| 22:05.34 |
starseeker |
ah, that's
why - the default implementation of opennurbs_memory.c is a
straight-up malloc/calloc/etc. wrapper |
| 22:11.49 |
brlcad |
starseeker:
another approach for the itcl/package problem -- take it to the
natural limit, shouldn't be calling either from C-land |
| 22:11.51 |
CIA-105 |
BRL-CAD:
03brlcad * r44484 10/brlcad/trunk/src/librt/Makefile.am: ditto for
now |
| 22:12.08 |
brlcad |
make the
scripts package require what they need |
| 22:12.15 |
starseeker |
true... |
| 22:25.19 |
starseeker |
er... this is
not good. Probably the best way to set this up would be to use the
apr memory pools, since we need variable sizes |
| 22:25.23 |
starseeker |
ick |
| 22:25.54 |
starseeker |
or custom
roll our own |
| 22:32.38 |
``Erik |
variable
sizes? that doesn't tend to work well with pools, that's a full
allocator |
| 22:34.22 |
``Erik |
yeah, I've
gotten in the habit of using parens whenever casting a referenced
pieces just to verify it's all correct and obvious |
| 22:34.36 |
``Erik |
piece |
| 22:34.54 |
starseeker |
``Erik: it
seems the technical term is "region based memory
management" |
| 22:36.23 |
starseeker |
that's what
the Apache Portable Runtime pools really are |
| 22:36.26 |
``Erik |
if you have a
finite set of sizes, you can do sets of pools... a 'buddy'
allocator is pretty easy and quick, used to be the norm... system
alloc usually uses slabs these days |
| 22:37.04 |
``Erik |
'region
based' might mean slabs, just implemented outside of the kernel to
avoid syscalls, maybe? *shrug* |
| 22:37.04 |
starseeker |
unfortunately, if we're going to put
something behind the opennurbs on* functions (which we want to for
improved performance) their API accepts arbitrary sizes |
| 22:37.48 |
starseeker |
the only
thing that comes readily to mind is a hash table of pointers to
pools, hashed by data type size |
| 22:39.09 |
starseeker |
basically,
assume finite sizes in practice (if not in theory) and create
whatever pools are needed - one per requested size |
| 22:39.12 |
``Erik |
that'd be one
wasteful way to do it... buddy system slicer on subpage chunks,
mebbe with an occasional gc/compactor might be another |
| 22:39.36 |
starseeker |
looks up buddy allocator |
| 22:39.47 |
``Erik |
(buddy system
basically means a binary tree of memory, pick the best fit,
dividing if needed) |
| 22:40.10 |
``Erik |
and here we
go, screaming to greenspuns tenth :D |
| 22:40.47 |
starseeker |
the quickest
and most practical thing to do would be to stick APR behind
opennurbs and see what kind of performance we get |
| 22:41.05 |
starseeker |
but that
would tie our raytracing directly to the APR libraries as a
dependency |
| 22:41.54 |
``Erik |
isn't keen on that |
| 22:42.05 |
starseeker |
isn't either |
| 22:42.50 |
``Erik |
do we know
the typical size range that opennurbs wants? |
| 22:44.02 |
starseeker |
not
really |
| 22:44.20 |
``Erik |
as an
experiment, we (and I mean you) could write a trivial allocator
that does a big block alloc, sets a 'usual max' size and subdivides
the memory into those sizes, so if it's 256 bytes, just return a
256 byte zone when 40 bytes is requested |
| 22:44.24 |
``Erik |
wasteful, but
easy |
| 22:44.28 |
starseeker |
my concern is
if it's using onmalloc and friends to allocate storage for NURBS,
the size range is going to be all over the map |
| 22:46.45 |
``Erik |
could do a
'pass-through' allocator to instrument and record a history of
allocs (or see if valgrind, efence, etc can be tortured into doing
that) and compare with and without that for a test
model? |
| 22:47.27 |
starseeker |
nods - or we might just do a data collection experiment -
record all sizes requested and see how big the distribution really
is |
| 22:47.38 |
starseeker |
I might be
over-estimating the problem |
| 22:48.00 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177871947.dsl.bell.ca) |
| 22:48.06 |
``Erik |
yeh, I'd
imagine you are :) profile before optimizing, right? |
| 22:49.54 |
``Erik |
it'd be
convenient if an automated tool could do that for you, instead of
hand instrumenting the code |
| 22:50.41 |
bhinesley |
make well1.s
rcc |
| 22:50.45 |
bhinesley |
oops
sorry |
| 22:51.23 |
brlcad |
if you're
messing with anything more complex than a simple bundling
allocation pool (if even that), then you're probably doing
something wrong |
| 22:51.59 |
brlcad |
who is doing
the allocate? when? |
| 22:52.13 |
starseeker |
opennurbs -
anytime onmalloc and friends are called |
| 22:52.19 |
brlcad |
which is
when? |
| 22:52.30 |
``Erik |
I think part
of the evaluator for a shot hits one |
| 22:52.46 |
starseeker |
depends on
whether you're overriding the C++ new or not - if you are,
everytime anything is allocated in opennurbs |
| 22:52.52 |
brlcad |
evaluator
that's called during prep, yes? |
| 22:53.35 |
brlcad |
find it hard
to believe that malloc is being called during the trace ..
performance would be very bad |
| 22:53.39 |
starseeker |
I believe so
- I'd have to check if it's being called during the
raytrace |
| 22:53.57 |
brlcad |
not just a
little bad .. super bad, like almost nmg bad |
| 22:54.15 |
brlcad |
from I've
seen interactive, that's just not possible |
| 22:54.17 |
starseeker |
brlcad: there
is a new being called, I remember that from the Shark profiles, but
it hit some geometries worse than others |
| 22:54.26 |
brlcad |
so if it's
all prep, then you can pretty much control when you
allocate |
| 22:54.33 |
``Erik |
I was under
the impression that shoot had one... and prep definitely needs sped
up |
| 22:55.00 |
brlcad |
mm.. I'd
focus on eliminating that single one during shot before even
thinking about prep |
| 22:55.27 |
``Erik |
if you're not
freeing until the end, you can alloc a bit chunk and walk it
linearly, if you request more than what's left, make a new one, ad
the old one to a crap list and move on |
| 22:55.42 |
``Erik |
big
chunk |
| 22:55.47 |
brlcad |
nods |
| 22:56.19 |
brlcad |
that can even
be done during prep |
| 22:56.29 |
brlcad |
at least for
the initial chunk |
| 23:00.12 |
*** part/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177871947.dsl.bell.ca) |
| 23:00.48 |
CIA-105 |
BRL-CAD:
03starseeker * r44485 10/brlcad/trunk/src/librt/uvpoints.cpp: Add
some timing and defaults. |
| 23:10.18 |
starseeker |
ah, looks
like apr is using a more straightforward approach than I
thought |
| 23:10.44 |
starseeker |
or
wait... |
| 23:11.18 |
starseeker |
OK, well,
either way something custom is needed - time to figure out how to
set that up |
| 23:13.11 |
``Erik |
the key is to
limit the problem domain, if you try to be as generic as the libc
stuff, you're trying to outsmart some incredibly smart guys
O.o |
| 23:13.35 |
starseeker |
nods - I know, special allocation for special
purposes |
| 23:17.53 |
starseeker |
huh, nifty:
http://books.google.com/books?id=ukXrNh2g6fQC&pg=PA128&lpg=PA128&dq=APR+memory+pool+Boost&source=bl&ots=CF5TfwORRZ&sig=a6lt3dYZoPXYEaGRYIAb6mS3asU&hl=en&ei=J6uwTYvuBIeUtweqotDzCw&sa=X&oi=book_result&ct=result&resnum=3&ved=0CCYQ6AEwAg#v=onepage&q=APR%20memory%20pool%20Boost&f=false |
| 23:48.45 |
brlcad |
starseeker:
do you have a profile? |
| 23:49.20 |
starseeker |
no, Shark is
busted on my machine at the moment :-( |
| 23:49.21 |
brlcad |
I know we
constantly say "allocations are bad" .. but they are totally
trumped by algorithmic complexity analysis |
| 23:49.28 |
starseeker |
working off
of memory from last year |
| 23:49.53 |
starseeker |
I suppose
it's time to upgrade and get everything fixed |
| 23:50.34 |
brlcad |
e.g., it may
be spending most of it's time calling malloc, but if it's because
of some O(N^3) algorithm then it may be calling malloc 10-1000
times more than it actually needs to |
| 23:51.32 |
starseeker |
nods |
| 23:52.30 |
brlcad |
case in point
was my nmg fix a few months bad .. nmg is relatively slow due to
allocations, but was being really stupid reallocating over and over
unnecessarily (by two orders of magnitude) .. cut a 5-day run down
to half hour, all without changing the way allocations occur even
though that's where most of the time was spent |
| 23:52.46 |
brlcad |
changed why
it was allocating in the first place |
| 23:53.28 |
brlcad |
shark is
awesome, but gprof can give insight too |
| 23:53.42 |
brlcad |
if you copied
configure, it's the -pg profile option |
| 23:55.02 |
starseeker |
in cmake it's
BRLCAD-ENABLE_PROFILING |
| 23:55.07 |
starseeker |
tests... |
| 23:58.58 |
starseeker |
I'm not
actually messing with BRL-CAD's raytracing yet - I'm trying to get
a feel for how my test uvpoints.cpp file is behaving |
| 00:01.27 |
brlcad |
gprof excels
at function-level analysis |
| 00:01.42 |
starseeker |
growl... for
whatever reason, that's not working on the mac either |
| 00:01.50 |
starseeker |
either in
isolation or as part of the build |
| 00:01.58 |
starseeker |
to
linux... |
| 00:02.35 |
brlcad |
TODO: fix
profiling option :) |
| 00:03.05 |
brlcad |
(presuming
you're using gprof right) |
| 00:03.28 |
starseeker |
yep, but I'm
assuming it's my mac's fault until proven otherwise |
| 00:04.26 |
brlcad |
unlikely,
it's not like shark |
| 00:04.55 |
brlcad |
it's not cpu
metrics, it injects code around all your functions |
| 00:05.14 |
brlcad |
so if gcc
works, it should work |
| 00:05.26 |
starseeker |
gprof works
on inux |
| 00:05.29 |
starseeker |
linux
even |
| 00:07.03 |
brlcad |
ok, whatever
works |
| 00:09.25 |
starseeker |
must...
fix... mac... |
| 00:10.47 |
starseeker |
yeah, ok - my
uvpoints.cpp file is wasting most of its time with
strings |
| 00:10.53 |
starseeker |
no
wonder |
| 00:19.57 |
brlcad |
(fwiw, "using
std namespace" is evil) |
| 00:20.10 |
brlcad |
er, using
namespace std; |
| 00:20.22 |
starseeker |
I know -
it's just a test program, not intended for production in its
current form |
| 00:20.31 |
brlcad |
ah,
interesting |
| 00:20.52 |
starseeker |
scratchpad
for experimenting with uv coordinates, memory pools, etc. without
the complexity of the SurfaceTree |
| 00:20.55 |
brlcad |
perhaps a
less on references, pointers, and std:: data types :) |
| 00:21.06 |
brlcad |
damn, can't
type tonight |
| 00:21.15 |
brlcad |
lesson |
| 00:21.18 |
starseeker |
winces - yeah, I'm quite sure I'm using it all
wrong |
| 00:21.29 |
brlcad |
you're
passing std::string in and out of functions |
| 00:21.41 |
brlcad |
that makes a
copy of the string every function call |
| 00:21.47 |
brlcad |
and every
return |
| 00:22.00 |
brlcad |
malloc-style |
| 00:22.29 |
brlcad |
you want to
either pass around std::string*'s or std::string&'s depending
on the use |
| 00:22.53 |
brlcad |
depends who
creates the string and how it's used |
| 00:23.37 |
brlcad |
safest is to
pass a pointer, but best is usually a ref .. but then you have to
be more careful on how it's accessed and stored |
| 00:24.57 |
starseeker |
nods - any good tutorials? |
| 00:25.08 |
brlcad |
e.g.
UVKey::UVKey() is fine taking a std::string newkey (so it'll make a
copy on construction), but UVKey::getKey() should return a
std::string& |
| 00:31.52 |
CIA-105 |
BRL-CAD:
03starseeker * r44486 10/brlcad/trunk/src/librt/uvpoints.cpp: Try
returning a reference |
| 00:31.55 |
starseeker |
brlcad: like
that? |
| 00:32.34 |
brlcad |
yeah, that's
better |
| 00:33.17 |
brlcad |
one thing to
remember, that change now changes the contract for UVKey -- it's no
longer just a string, it's UVKey's string |
| 00:33.37 |
starseeker |
nods - that was the idea originally,
actually |
| 00:33.43 |
brlcad |
so if you
delete UVKey, any references to a std::string from getKey() would
be dangling references (invalid) |
| 00:33.47 |
starseeker |
yow, string
comparison is brutal |
| 00:35.26 |
brlcad |
yeah, that
was my next question .. what's up with string keys?? |
| 00:35.33 |
brlcad |
numeric
ftw |
| 00:35.41 |
starseeker |
they're UV
coordinates |
| 00:36.40 |
brlcad |
so? |
| 00:36.50 |
starseeker |
I don't
recall the original motivator - I think it was to make it easier to
mash together two pairs into one unique descriptive
string |
| 00:36.52 |
brlcad |
yeah,
AppendKeys() .. nfg |
| 00:37.25 |
brlcad |
ints_to_key
looks like some sort of string-based hash |
| 00:37.51 |
brlcad |
just store
them into a u,v array, O(1) lookups |
| 00:38.01 |
starseeker |
ah, right -
0100 and 0001 don't convert to different integers |
| 00:38.34 |
starseeker |
and those
strings are the keys for a minimal perfect hash |
| 00:39.01 |
brlcad |
perfectly
inefficient maybe :) |
| 00:39.07 |
starseeker |
probably I
should stash them as numbers and only build the strings when I need
to |
| 00:39.57 |
starseeker |
the original
effort there was to find unique identifiers for all the UV points
that might get evaluated into 3-space during a subdivision of depth
N |
| 00:40.15 |
brlcad |
either way,
even as a perfect hash, shouldn't have a sprintf() call in there
for generating a hash (heck, shouldn't need to manually hash
yourself anyways) |
| 00:40.17 |
starseeker |
because there
are a lot of shared points, I wanted a good way to avoid duplicate
evaluations |
| 00:41.13 |
brlcad |
the std::
container hashing is pretty frickin good |
| 00:41.40 |
starseeker |
the simplest
way to avoid duplicates was to have a way for any subdivision, at
any depth up until the maximum depth, be able to look up a given UV
coordinate to see if it had been evaluated |
| 00:42.32 |
brlcad |
you probably
want a std::map |
| 00:43.09 |
brlcad |
heck, maybe
even a simple std::map<u, std::map<v, value>
> |
| 00:43.23 |
starseeker |
how fast are
those lookups? |
| 00:43.33 |
brlcad |
guaranteed to
be at least logN iirc |
| 00:43.57 |
starseeker |
in theory, if
I understand correctly, a minimal perfect hash is O(1) |
| 00:44.50 |
starseeker |
and as a tree
deepens, we can build up a LOT of points and do a LOT of
lookups |
| 00:46.06 |
starseeker |
so a minimal
perfect hash of a unique string descriptor of the UV coordinates,
which is possible because we know the candidate sites that might be
evaluated in advance, allows us to generate such a hash up
front |
| 00:46.38 |
brlcad |
if it's O(1)
lookup and O(insane) to generate the hash, you've kinda missed the
boat |
| 00:46.56 |
brlcad |
that's still
just the minimum guarantee |
| 00:47.02 |
starseeker |
except the
hash only has to be generated at compile time |
| 00:47.13 |
brlcad |
you mean
prep? |
| 00:47.18 |
starseeker |
no,
compile |
| 00:47.22 |
starseeker |
source code
compile |
| 00:47.38 |
brlcad |
er, there's
no such thing going on in your code there now |
| 00:47.43 |
starseeker |
right |
| 00:47.56 |
starseeker |
because it
was early days when I had to shift to other stuff |
| 00:48.14 |
starseeker |
but it DOES
generate the keys.txt file, which contains the full list of unique
keys |
| 00:48.31 |
brlcad |
if there is a
limited set of hash sites, why not just direct index into a set
then? |
| 00:49.25 |
starseeker |
all I know
when I'm subdividing is the UV coordinates of the point I'm at - I
have to map that to some index value |
| 00:49.37 |
brlcad |
i'd still try
the std::map first -- dead simple implementation, easy to maintain,
and really good performance behavior guarantees |
| 00:50.42 |
brlcad |
so the idea
sounds fine, but it shouldn't be based on or involve
strings |
| 00:51.47 |
starseeker |
uh... the
string is key for hashing - apparently hashing numbers usually
doesn't work out well |
| 00:52.11 |
starseeker |
my problem is
I'm storing the info as a string, which is wrong |
| 00:52.12 |
brlcad |
http://www.sgi.com/tech/stl/hash_set.html |
| 00:52.42 |
brlcad |
again,
configurable key type, even configurable hash function |
| 00:53.26 |
brlcad |
a hash set of
hash maps perhaps for u,v to value mapping |
| 00:53.29 |
brlcad |
http://www.sgi.com/tech/stl/hash_map.html |
| 00:53.43 |
brlcad |
or hash_map
of hash_maps |
| 00:59.07 |
brlcad |
the tradeoff
with a std::map<> is that std::hash_map<> will be
faster (O(1) on average O(N) worst case even with perfect hashing,
have to account for collisions) but it's not in any particular
order if you need to iterate or search |
| 00:59.48 |
brlcad |
so find
*this* UV is fast.. finding your closest neighbor will be
relatively expensive |
| 01:00.25 |
starseeker |
nods - so far there hasn't been a need for nearest UV
neighbor (famous last words...) |
| 01:00.56 |
starseeker |
brlcad: let
me see if I can take strings out of what I'm doing now, at least up
until keys.txt is generated |
| 01:01.04 |
starseeker |
that works in
the right direction regardless |
| 01:01.52 |
starseeker |
once I'm
doing that right, we can tangle with the various hashing/mapping
options |
| 01:08.04 |
starseeker |
the minimal
perfect hash appeals to me because with this situation we don't
NEED to have any collisions, but I suppose I could be full of...
err... converted dog food too |
| 01:14.28 |
*** join/#brlcad KimK
(~Kim__@wlnt-02-246.dsl.netins.net) |
| 02:31.04 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1128565712.dsl.bell.ca) |
| 03:22.05 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 04:29.39 |
starseeker |
brlcad wins -
will investigate stl map tomorrow, then look into hash_map if
that's not enough |
| 04:29.55 |
starseeker |
braces for another C++ learning curve |
| 05:06.15 |
brlcad |
it's
important enough to warrant a simple performance
comparison |
| 06:14.42 |
brlcad |
starseeker:
here's a code snippet I just whipped up for you to play
with |
| 06:15.35 |
brlcad |
shows how to
use map, hash map, and shows the comparative performance of
each |
| 06:41.24 |
brlcad |
http://brlcad.org/tmp/hasher.cxx |
| 06:42.42 |
brlcad |
just for
kicks, I stubbed in some code sort of showing worst case and best
case perfect hashing .. though the devil is truly in the details
for all of them since a simple datatype change or iteration change
can completely skew the comparison |
| 06:44.12 |
brlcad |
only played
two use-case scenarios, setting and reading .. not iterating over
all, nearest neighbor, deletions, etc |
| 06:45.30 |
brlcad |
also using
the non-bounds-checked [] operator instead of insert(), find(), and
other functions |
| 06:46.55 |
brlcad |
I'd suggest
looking at a real worst case trace, see how many
insertions/lookups/deletions and what the tree looks like --
shallowest, average, deepest |
| 06:47.10 |
brlcad |
then mapping
that into a test program simulating the same behavior |
| 06:50.51 |
brlcad |
should
hopefully be a little more clear how/why I think map or
unordered_map will probably be more than "good enough" given how
much simpler they are to run with .. and if not, looking into
exactly why |
| 07:33.21 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.22.183) |
| 07:33.21 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:10.31 |
*** join/#brlcad crazy_imp
(~mj@a89-182-215-216.net-htp.de) |
| 08:28.56 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 08:30.38 |
*** join/#brlcad b0ef
(~b0ef@226.27.202.84.customer.cdi.no) |
| 09:38.38 |
*** join/#brlcad KimK
(~Kim__@wlnt-02-246.dsl.netins.net) |
| 11:35.09 |
``Erik |
*readreadread* obsessing over a perfect
hash may be self defeating... also; O() is just one of the bits to
consider, there are 5 categories of asymptotic notation. qsort is a
poor performer on O(), but awesome in real life (omega is tight, k
is low, etc) |
| 11:40.48 |
``Erik |
hm, no system
hash funcs in your demo, brlcad? md5? sha1? :) |
| 12:45.34 |
starseeker |
brlcad:
thanks for the demo - that will be a big help |
| 12:48.28 |
starseeker |
hmm... u+v
won't work, isn't unique 0 + 1 = 1 + 0... probably need something
like u * (some power of 10) + v |
| 12:48.52 |
starseeker |
that's a
detail though |
| 12:49.20 |
starseeker |
rummages around for some energy and gets
moving |
| 13:13.00 |
``Erik |
collisions
may be acceptable... ergo; quadratic (http://en.wikipedia.org/wiki/Quadratic_probing)
or chained (each hash bin is a linked list) |
| 13:17.15 |
*** join/#brlcad KimK
(~Kim__@wlnt-02-246.dsl.netins.net) |
| 13:33.11 |
brlcad |
starseeker:
it'll "work" .. it's just a really really bad hash :) |
| 13:33.15 |
brlcad |
lots of
collisions |
| 13:33.31 |
brlcad |
more showing
the full range of impact it can have |
| 13:34.06 |
brlcad |
with the
right hash, you approach the best case instant update time of an
array but worst case can be an order worse than a simple
map |
| 13:34.54 |
brlcad |
all the more
motivation to just stick with the algo that makes most
sense |
| 13:36.35 |
brlcad |
the data is a
simple mapping of uv keys to a 3dpoint, so the immediate thought
that comes to mind is std::map<std::pair<int, int>,
vect_t> |
| 13:37.56 |
brlcad |
(do not use
ON_3dpoint .. it's got lots of junk, you can set the vect_t direct
on read: vect_t v = VINIT_ZERO; ON_3dpoint p = v; ON_3dpoint *pp =
new ON_3dpoint(v); |
| 13:38.25 |
brlcad |
they added
operator support for getting the value from a double* |
| 13:46.10 |
brlcad |
good exercise
for the reader to attempt adding std::map<std::pair<int,
int>, vect_t> and using proper std::map::iterator instead of
using the [] operator .. you'll get a lot of insight |
| 13:57.11 |
brlcad |
then switch
it to [] and compare :) |
| 14:31.14 |
*** join/#brlcad dli (~dli@67.55.46.44) |
| 14:46.25 |
starseeker |
brlcad: the
map is good if we need things like nearest-neighbor? |
| 14:48.17 |
starseeker |
wonders if triangulation might just want that information,
even if we don't need it for raytracing |
| 15:25.06 |
``Erik |
r-tree is the
shizzle for nearest neighbor |
| 15:25.12 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.18.42) |
| 15:25.12 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 15:25.41 |
``Erik |
but data
repacking should never take more than nlgn |
| 15:25.59 |
``Erik |
poor cats,
still reeling from the bathing this morning |
| 15:43.01 |
starseeker |
``Erik: this
should appeal to your bit-level side - can I take a floating point
value and map it to an int simply? |
| 15:43.38 |
starseeker |
std::map is
slow with floats, but for storage the important thing is to have an
easy, unique identifer |
| 15:44.15 |
starseeker |
if the UV
floating point coordinates can be mapped to integers... |
| 15:45.30 |
starseeker |
I hadn't
properly considered what wanting to split first on the knot points
implies - it pretty much trashes my subdivision gridding coordinate
scheme |
| 15:46.34 |
starseeker |
might be able
to get away with just being aware of which leaves contain knots,
but more general solution of being able to pick any given UV point,
subdivide using it, and using the std::map or something like it all
the while sounds nice |
| 15:53.03 |
*** part/#brlcad willdye
(~willdye@198.183.6.23) |
| 16:27.29 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 17:35.13 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.18.42) |
| 17:35.13 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:47.37 |
starseeker |
hmm...
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm |
| 18:45.43 |
kanzure |
did
commercial CAD packages ever take more than a few seconds to do a
boolean operation on two solids? |
| 19:08.49 |
starseeker |
kanzure: I
doubt it... |
| 19:12.44 |
kanzure |
hrm. weird.
i'm reading some papers from the 90s where these programmers are
cheering because they can merge a few meshes "IN ALMOST EIGHT
SECONDS!!" |
| 19:13.03 |
kanzure |
on some sort
of sgi onyx machine (200 mhz.. etc.) |
| 19:17.49 |
bhinesley |
I'm off to
the beach for the weekend. Have a good weekend,
everyone. |
| 19:25.24 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 19:36.48 |
kanzure |
wow "CATIA
uses polyhedral approximations for intersection and boundary
computations" |
| 19:38.36 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 19:44.36 |
kanzure |
"We then use
the trapezoidation of the trimming polygon (using Seidel's
algorithm) to perform logarithmic time point location
queries. |
| 19:44.39 |
kanzure |
"However, the
accuracy of this result depends on the magnitude of errors
introduced by approximating the high degree trimming curve through
the boundary of the Gaudl invariants." |
| 19:44.43 |
kanzure |
ok i give up
on this paper |
| 19:45.42 |
starseeker |
kanzure:
which paper? |
| 19:45.53 |
kanzure |
one of
krishnan's |
| 19:46.14 |
kanzure |
i'll use his
other one where he uses matrix math for constructing the
intersection curve |
| 20:39.27 |
starseeker |
brlcad: looks
like the pair iteration is slightly slower, I'm assuming due to the
make_pair overhead: http://brlcad.org/~starseeker/map_test.cxx |
| 20:43.37 |
starseeker |
I can't get
the iterator to work thus far |
| 20:56.05 |
starseeker |
ah, there we
go - I THINK that works... anyway, if I do full assignment instead
of using drand48 the count returned seems to match up |
| 21:00.53 |
starseeker |
hmm,
interesting - iterator is faster if I replace drand48 with i in the
insertion loops |
| 21:01.03 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 22:26.36 |
``Erik |
hm, you could
always do floor() or ceiling()... could also grab a bit mask (
((uint320t)f) >> 16) ) |
| 22:26.52 |
``Erik |
s/0/_/ |
| 22:27.51 |
starseeker |
``Erik:
actually, even the worst case floating point performance may not be
a showstopper - plus, it looks like to get performance benefit the
data type in question needs to be small anyway |
| 22:29.22 |
starseeker |
suspects, based on conversations concerning STL libraries,
that they probably are doing whatever the sanest thing is for
floats under the hood |
| 22:30.25 |
``Erik |
the guys who
did stl are pretty good... don't try to outsmart them, the key is
to not use their stuff wrong... |
| 22:31.06 |
starseeker |
nods |
| 22:31.24 |
``Erik |
at the
moment, we assume a full fpu... I'm sure BRL-CAD on my arm7 would
suck arse |
| 22:31.40 |
starseeker |
heh |
| 22:32.02 |
``Erik |
http://brlcad.org/~erik/20110422/
they are not happy :) |
| 22:32.31 |
starseeker |
hehe |
| 23:04.18 |
brlcad |
starseeker:
excellent that you got the pair working along with
iterators |
| 23:04.28 |
brlcad |
that was more
the point than actual performance |
| 23:05.07 |
brlcad |
make_pair()
is probably injecting a tiny overhead, you'd probably just call the
pair<> constructor directly where you can set values by const
reference instead of by value |
| 23:06.18 |
brlcad |
the other
thing you should try is printing the pair values through the
iterator |
| 23:06.43 |
brlcad |
instead of
just incrementing counter, try to use the iterator |
| 23:22.45 |
``Erik |
if I groked
correctly, iterator classes are insanely efficient once invoked...
a machine optimizable deref, iirc |
| 23:23.31 |
``Erik |
same level of
machine nerdiness as a ^= b ^= a ^= b |
| 00:57.20 |
starseeker |
``Erik: my
take would be to focus on getting a working shader - integration
into the build logic can come later |
| 00:57.35 |
starseeker |
for the
moment, we could even assume an installed osl |
| 00:58.27 |
starseeker |
I'd probably
have to cmakeify at least one or two deps - to the best of my
knowledge tbb doesn't currently use CMake, for example |
| 01:05.49 |
starseeker |
idly wonders if imageio could sub for freeimage in
ogre... |
| 01:05.54 |
starseeker |
openimageio
rather |
| 03:47.58 |
``Erik |
starseeker:
the src/liboptical/sh_osl.c thing is what I meant, integrate it
into our raytracing package. Not spend a lot of time writing
shaders for it before... src/other with checks for system are after
some basic integration |
| 07:03.25 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:23.03 |
*** join/#brlcad Stattrav_
(~Stattrav@111.93.134.142) |
| 10:52.48 |
*** join/#brlcad kunigami_
(~kunigami@187.106.4.220) |
| 12:55.19 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 13:42.19 |
*** join/#brlcad kunigami_
(~kunigami@187.106.4.220) |
| 14:14.02 |
dloman_ |
bangs head against keyboard..... doesn't wanna write a custom
treewalker :( |
| 14:16.04 |
``Erik |
why would you
need to? we have too many already? |
| 14:17.03 |
``Erik |
cinematics
are dandy and all, but after half a dozen times, zomfg, give me a
button to skip it, seriously |
| 14:17.26 |
dloman_ |
trying to
make a tree walker that does two things: 1) keeps track of full
path and 2) creates the appropriate bu_ext |
| 14:17.32 |
dloman_ |
i get 1
easy |
| 14:17.40 |
dloman_ |
but 2 keeps
eluding me. |
| 14:18.16 |
dloman_ |
every
different tree walker i've tried fails on 'badmagic' cause somehow,
the directory* gets 'misaligned' with the db_i* |
| 14:18.24 |
``Erik |
ooh, all the
tree walkers are thinking prepped geometry, not disk... you MIGHT
be able to create a memory image and do a wdb export into it, then
have a magic bu_external |
| 14:18.30 |
``Erik |
I think that
might be what, um |
| 14:18.55 |
``Erik |
bad magic
probably means you're trying to use a bu_external as a .g file,
which is not valid |
| 14:19.30 |
``Erik |
g_transfer.c
dude |
| 14:19.36 |
dloman_ |
hrm, dunno
how. just calling bu_get_external() and feeding it a dbip and
directory |
| 14:19.38 |
``Erik |
your answers
are there :D |
| 14:19.49 |
dloman_ |
kk, i've been
all over search.c, keep.c paths.c |
| 14:19.53 |
dloman_ |
thanks, i'll
check it. |
| 14:20.17 |
``Erik |
src/gtools/g_transfer.c, brlcad mentioned
it a while ago |
| 14:20.42 |
dloman_ |
okay, that's
half the info i already know. |
| 14:20.55 |
dloman_ |
i can make
valid bu_externals by simply looping thru the file. |
| 14:21.07 |
dloman_ |
and i can get
a good set of full paths by tree walking. |
| 14:21.32 |
dloman_ |
now, i need
to combine the two so I can do both in one pass over the
file. |
| 14:21.37 |
dloman_ |
..... that
even possible? |
| 14:21.42 |
``Erik |
a bu_external
maps immediately to a single line of a .asc file |
| 14:21.58 |
dloman_ |
righto. |
| 14:22.00 |
``Erik |
maybe the
g2asc program will help you more |
| 14:22.02 |
dloman_ |
well, here's
a question |
| 14:22.07 |
``Erik |
since it has
to do that by definition |
| 14:22.26 |
dloman_ |
is there a
way to take a db object name and get its full path? |
| 14:23.29 |
``Erik |
I'm
questioning myself on the notion of what full path means in the
BRL-CAD filesystem... I'm kinda thinking that there is no such
thing as a path, it's imaginary :D or, rather, reconstituted based
on relationships |
| 14:23.48 |
``Erik |
the whole
"flat namespace" has always bugged me a bit |
| 14:24.26 |
``Erik |
using
notation to denote a tree when everything sits at the same level
and stacks metadata to denote associations... *shudder* |
| 14:24.38 |
dloman_ |
hrm. time to
ponder and test code more. |
| 14:24.42 |
``Erik |
denote note
note denote note stop. morse dork. :D |
| 14:25.01 |
dloman_ |
backs away slowly. |
| 14:25.15 |
``Erik |
I'm off
today, man, cut me some slack |
| 14:25.33 |
dloman_ |
=D |
| 14:25.38 |
``Erik |
I'm just
saying that viewing it as a real 'path' may be problematic, it
might not actually exist that way |
| 14:26.00 |
``Erik |
it's more
like a strange ORM in reality |
| 14:26.02 |
dloman_ |
that's why
i'd like to be able to 'walk' the tree and verify the
path. |
| 14:26.33 |
dloman_ |
aka, a user
specifies they want a list of all child objects of
/some/path/to/an/obj.r |
| 14:26.54 |
dloman_ |
where the
actual .g file is named 'to' |
| 14:26.57 |
``Erik |
yeah, and
that's why I'm bugged, it has to be hand assembled from the entire
soup |
| 14:27.11 |
``Erik |
mebbe we'll
do real pathing in v6 |
| 14:27.53 |
``Erik |
you'd have to
stop at 'to' and pull everything in it to construct the tree, the
tree does not explicitely exist in the .g |
| 14:28.02 |
``Erik |
it's
assembled from name relationships at load time |
| 14:28.03 |
dloman_ |
exactly |
| 14:29.39 |
``Erik |
gonna go swap
laundry, the things you should probably be looking at are g2asc,
libged tops, maybe pulling a loaded 'internal' tree and doing
exports on each bit |
| 14:30.21 |
dloman_ |
thinking
about giving up and chalking it to 'premature
optimization' |
| 14:30.27 |
dloman_ |
and just
doing in two passes |
| 14:30.36 |
dloman_ |
slower, yeah,
but hellova lot less frustrating |
| 14:30.43 |
``Erik |
good luck O.o
:D *think* butler might be able to help, brlcad might, but he's
otherwise occupied... |
| 14:30.55 |
dloman_ |
doody
duty |
| 14:30.57 |
``Erik |
for the muves
guys, performance is not a concern |
| 14:30.58 |
dloman_ |
*snicker* |
| 14:31.07 |
dloman_ |
don't really
care about them |
| 14:31.10 |
``Erik |
dropped off
their package on saturday, btw |
| 14:31.26 |
dloman_ |
im thinking
of mged 2 or 3 performance. |
| 14:31.36 |
``Erik |
they're the
ones driving funding and deadlines... yeah, we want better, but if
under teh gun, just gotta shut them up, right? |
| 14:31.46 |
dloman_ |
yuppers. |
| 14:31.58 |
``Erik |
soo mebbe you
should KISS |
| 14:32.31 |
``Erik |
who knows,
maybe the simple slow approach is adequate |
| 14:32.43 |
dloman_ |
yeah, i was
just thinking that same thing. |
| 14:32.44 |
dloman_ |
heh |
| 14:35.12 |
``Erik |
(yeah, you
kinda already said it, I was agreeing) |
| 14:35.34 |
dloman_ |
i was
focusing on the 'stupid' part, lol |
| 14:35.42 |
dloman_ |
my head hurts
cause of this stuff. |
| 14:35.46 |
dloman_ |
i sooooooo
can't read C |
| 14:35.47 |
``Erik |
"keep it
stupid, simple?" |
| 14:36.15 |
``Erik |
heh,
different paradigm than you're used to |
| 14:36.27 |
dloman_ |
that's Yodas
version? |
| 14:36.52 |
``Erik |
I thought I
was a really good programmer when I went back to college, bitched
like crazy when I had to learn new languages and design
paradigms... |
| 14:37.15 |
``Erik |
I think every
new language and definitely every new paradigm has made me a much
better programmer in all the languages I can use |
| 14:37.58 |
dloman_ |
hehehe, just
reading thru www.ihas1337code.com makes me realize just how much i
missed by not going to college for CS. |
| 14:38.23 |
``Erik |
it twists
your mind and makes you look at things differently... and then
enlightenment :) |
| 14:40.12 |
``Erik |
the, uh,
monthly 'scrum', one of the points ed wanted to talk about was the
future of GS and having you rotate to other stuff, drag you out of
isolation and expose you to other stuff |
| 14:40.30 |
dloman_ |
that'd be
nice |
| 14:40.48 |
``Erik |
are you in
the office? I know ed is in, he answered his phone a bit
confused |
| 14:41.01 |
dloman_ |
yeah, im
here. |
| 14:41.36 |
``Erik |
well, there
ya go :D walk over and mention it, I'd be willing to go on
speakerphone since I poked the tiger |
| 14:42.12 |
dloman_ |
well, there's
the issue of me being pissed that i can't make this thing work the
way i want it to, as easily as it should be to
implement. |
| 14:42.29 |
dloman_ |
im stubborn
like that, an i really want this to be done. |
| 14:43.37 |
``Erik |
dude, it's a
whole bucketload of very specialized knowledge, the smart thing is
to say "hey, this is hard" and get help... |
| 14:43.51 |
dloman_ |
that's why i
have you :P |
| 14:44.02 |
``Erik |
I mean,
what'd you say if a coner tried to restart a reactor and refused to
stop and say they didn't know what was going on? |
| 14:44.23 |
``Erik |
getwhutahmean,verne? |
| 14:44.36 |
dloman_ |
to be fair,
things have gotten a whole lot better since i stopped trying to
hammer rocks into swords :) |
| 14:45.00 |
dloman_ |
well, in that
case, i'd laugh, then leave the boat. power to him :) |
| 14:45.04 |
dloman_ |
but i know
what you mean. |
| 14:45.15 |
``Erik |
notes that he is not on the boat at the moment O:-)
*duck* |
| 14:46.16 |
``Erik |
sorry,
couldn't resist that one.. Cliff Ed and I talked a bit about the
needs, state, possibilities, etc of GS and ed felt that you and
brlcad needed some insight, but it was time to stop and see what
was what |
| 14:46.36 |
dloman_ |
right
on |
| 14:47.00 |
dloman_ |
i'd like to
get it to a point where i can say: Here, its working. Barely, but
its working to reqs. |
| 14:47.16 |
``Erik |
I think cliff
and i did a big info dump that he grokked, but a little more data
was needed for a good decision |
| 14:47.38 |
``Erik |
it might be
that the lithp version is close enough to their requirements that
we can say "good 'nuff till next fy" |
| 14:48.06 |
dloman_ |
that's my
fallback, so thanks for that :) |
| 14:48.24 |
``Erik |
is cliff in?
be social, man, our downfall is lack of communication |
| 14:48.42 |
dloman_ |
oh, we've
talked a lot the last few weeks :) |
| 14:48.59 |
dloman_ |
ive tripled
my understanding of the brlcad libs in a short time. |
| 14:49.26 |
dloman_ |
add in the
fact that i am finally confident enough to say "No, using that lib
is stupid" |
| 14:49.27 |
``Erik |
talking and
communication are not necessarily parallel, and ed feels in the
dark a lot of the time |
| 14:50.22 |
``Erik |
he's a good
guy to talk to, I'd strongly recommend heading over, sitting down
and chattering a bit |
| 14:50.36 |
dloman_ |
will
do |
| 14:50.59 |
``Erik |
and like I
said, I'm off today, but if you feel the need to call up and throw
me on speakerphone *shrug* I'm here |
| 14:52.45 |
dloman_ |
will do,
thanks. |
| 15:03.46 |
kunigami_ |
does the blue
ball seem to be using a phong shader? http://imageshack.us/photo/my-images/101/phong3.png/ |
| 15:07.41 |
kunigami_ |
in this other
image is used the microfacet-beckmann shader, http://imageshack.us/photo/my-images/40/imager03.png/
but the specular highlighting is blue instead of white |
| 15:08.02 |
``Erik |
kunigami_:
yes, phone, but not radiosity or photon mapping, which the rest of
the scene seems to be using... the granulatiry makes it look like a
combination, almost |
| 15:08.06 |
``Erik |
phong,
even |
| 15:09.41 |
``Erik |
looks like
the difference is a specular saturation issue, and the latter kinda
looks wrong on reflection issues |
| 15:15.35 |
kunigami_ |
but shouldn't
the phong shader ball look like a snooker ball? |
| 15:15.52 |
``Erik |
on pure
phong, it'll be very smooth with maybe banding |
| 15:16.32 |
``Erik |
if it's a
photon map or radiosity type thing before, then the normal will be
randomly permutated and you'll get the grainyness |
| 15:17.46 |
``Erik |
it could also
be that a material property is effecting the normal |
| 15:23.46 |
kunigami_ |
hmm ok!
thanks |
| 15:24.53 |
``Erik |
either way,
I'd imagine it's a minor issued compared to the
src/liboptical/sh_osl.c work... *shrug* just my opinion, you may
want to email Daniel Rossberg about it to see his thoughts
:) |
| 15:25.08 |
``Erik |
he's the one
listed as your mentor, right? |
| 15:29.22 |
kunigami_ |
yup, it's
him. ok, I'll send an email to him. |
| 15:30.01 |
kunigami_ |
I think I
already completed what I was expected to do on the bounding time
(according to my final proposal) |
| 15:30.35 |
kunigami_ |
thus, I was
trying to do make more complex things before
proceeding. |
| 15:31.14 |
kunigami_ |
anyway, my
next task was to understand brlcad shading system |
| 15:37.24 |
``Erik |
if it helps,
sh_toon.c is something I just recently started, it's a very trivial
example |
| 15:37.59 |
kanzure |
beep
boop |
| 15:38.16 |
kanzure |
i'm still
working on my rewrite of esolid |
| 15:38.23 |
kanzure |
it's a lot of
code |
| 15:38.28 |
kanzure |
there are no
unit tests |
| 15:38.46 |
kanzure |
and there's
maybe another 5k lines to write before it might be
working |
| 15:38.47 |
kanzure |
what should i
do? |
| 15:43.54 |
``Erik |
esolid? I'm
not aware of that, can you quickly summarize? |
| 15:48.48 |
``Erik |
sorry, gotta
run, I'll be on later |
| 15:49.19 |
kanzure |
nurbs-based
boolean operations |
| 15:49.35 |
kanzure |
(well,
trimmed bezier patches) |
| 16:20.53 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:09.15 |
CIA-117 |
BRL-CAD:
03davidloman * r44621 10/geomcore/trunk/ (7 files in 2 dirs): Clean
up the IDataSource interface a tad. |
| 17:17.48 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 17:25.11 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.43) |
| 17:25.11 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:46.32 |
CIA-117 |
BRL-CAD:
03davidloman * r44622 10/geomcore/trunk/src/GS/FileDataSource.cxx:
Start work on getListing() |
| 18:00.01 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:10.30 |
starseeker |
ah, bugger -
http://dev.crypt.co.za/coffee/wiki?name=Project+Status |
| 18:10.35 |
starseeker |
how'd I miss
THAT? |
| 18:21.00 |
starseeker |
kanzure: did
you get a license OK from the original devs? |
| 18:34.59 |
starseeker |
hmm...
apparently tcl/tk switched to fossil?? |
| 18:42.39 |
starseeker |
ah, right -
after that CVS business on SF |
| 18:49.55 |
kanzure |
starseeker:
no didn't get a response from him |
| 18:53.40 |
kanzure |
why would i
be rewriting if i had a permissive license to use the original
code? |
| 19:41.56 |
CIA-117 |
BRL-CAD:
03starseeker * r44623 10/brlcad/trunk/src/other/togl/
(CMakeLists.txt src/CMakeLists.txt): Use LIB_DIR variable for
install, so Windows gets things where it expects them. |
| 19:42.10 |
starseeker |
kanzure: oh,
you're re-writing from SCRATCH? |
| 19:42.17 |
starseeker |
thought you were re-factoring |
| 19:42.52 |
kanzure |
heh |
| 19:43.00 |
kanzure |
yeah... i'm
doing something dumb |
| 19:43.07 |
kanzure |
it's taking
me forever and i can't really judge my progress along the
way |
| 19:43.27 |
kanzure |
i mean, i
sort of am able to - like i have two boxes that are generated and
i'm somewhere in the middle of the intersection code |
| 19:43.39 |
kanzure |
but i don't
really know if all of my implementation works the same or
not |
| 19:46.42 |
starseeker |
kanzure: if
esolid had test cases, you should at least be able to feed those to
your code to see if the results are the same |
| 19:46.54 |
kanzure |
it has no
test cases |
| 19:46.59 |
starseeker |
winces |
| 19:47.10 |
starseeker |
are you
building off of the opennurbs libraries? |
| 19:47.10 |
kanzure |
it's roughly
20,000 lines of code |
| 19:47.11 |
kanzure |
with no
tests |
| 19:47.38 |
kanzure |
no i'm just
doing a vanilla implementation/port first using esolid's code
base |
| 19:47.45 |
kanzure |
and then i'll
rip out all of the custom crap |
| 19:47.55 |
kanzure |
and replace
it with opennurbs/opengl/scipy/numpy/clapack |
| 19:48.17 |
starseeker |
um... be
careful about that - if you're building off of esolid's code base
that might be seen as a "derivative work" |
| 19:48.33 |
kanzure |
yes i've
examined the legal implications thoroughly |
| 19:48.38 |
kanzure |
don't
worry |
| 19:48.45 |
starseeker |
nods. |
| 19:49.26 |
starseeker |
might be
worth trying to call him if email didn't work - once in a while a
phone call will get through where email won't |
| 19:49.43 |
kanzure |
sure |
| 19:49.52 |
kanzure |
but honestly,
if it doesn't have unit tests, it's not worth that much |
| 19:49.57 |
kanzure |
someone will
have to do what i'm doing eventually anyway |
| 19:50.05 |
starseeker |
true |
| 19:51.42 |
starseeker |
q |
| 19:51.45 |
starseeker |
whoops |
| 20:06.14 |
kanzure |
so now i
don't know what to do |
| 20:06.25 |
kanzure |
http://diyhpl.us/cgit/lolcad/plain/esolid/esolid.py |
| 20:07.52 |
kanzure |
write unit
tests for the original code base, then re-write them for my
own? |
| 20:08.10 |
kanzure |
keep trucking
and weep at the end as i slowly/painfully try to figure out why
results are different? |
| 20:08.40 |
starseeker |
kanzure: how
different would unit tests be between your code and the
original? |
| 20:08.51 |
kanzure |
well it's
just 2x the amount of code |
| 20:09.07 |
kanzure |
but other
than that the initial upfront figuring out "wtf" is a one-time
cost |
| 20:09.53 |
starseeker |
kanzure:
might be worth verifying the original behavior |
| 20:11.19 |
kanzure |
true.. i
should really do it |
| 20:11.28 |
kanzure |
HOW do these
people write this code without testing? |
| 20:12.21 |
starseeker |
may have
figured the tests were too messy to release |
| 20:15.40 |
CIA-117 |
BRL-CAD:
03starseeker * r44624
10/brlcad/trunk/src/other/togl/CMakeLists.txt: whoops,
typo. |
| 21:20.47 |
*** join/#brlcad crazy_imp
(~mj@a89-183-22-49.net-htp.de) |
| 21:43.33 |
*** join/#brlcad Ralith
(~ralith@d142-058-174-188.wireless.sfu.ca) |
| 22:47.46 |
*** join/#brlcad Ralith
(~ralith@d142-058-174-188.wireless.sfu.ca) |
| 00:23.56 |
*** join/#brlcad crazy_imp
(~mj@a89-182-143-78.net-htp.de) |
| 02:34.35 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 03:35.57 |
*** join/#brlcad merzo
(~merzo@1-45-132-95.pool.ukrtel.net) |
| 04:22.07 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 06:52.54 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 07:06.05 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.103.233) |
| 07:06.05 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:23.35 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 07:25.32 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 07:25.33 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:42.35 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1128565552.dsl.bell.ca) |
| 08:53.14 |
*** join/#brlcad mafm
(~mafm@62.Red-81-34-125.dynamicIP.rima-tde.net) |
| 09:37.01 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 11:04.20 |
*** join/#brlcad mafm
(~mafm@62.Red-81-34-125.dynamicIP.rima-tde.net) |
| 11:16.16 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 11:50.50 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.103.233) |
| 11:50.51 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:53.03 |
dloman |
so ``Erik, i
did some data szie calcs in my head yesterday..... might have a
memory issue :) |
| 12:53.08 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:54.04 |
dloman |
1.6x10^6 pix
x 1.6x10^6 pix image is about 2.56 x 10^12 pixels... and at 1 byte
per pixel... yeah, thats a bit large :) |
| 13:10.56 |
``Erik |
1552000000000000000000 square
meters. |
| 13:12.35 |
dloman |
m or km
? |
| 13:12.48 |
dloman |
i though we
were saying 1 pix == 1 km |
| 13:13.08 |
``Erik |
meters |
| 13:13.16 |
``Erik |
um, at 1km
res, 1.5 petabytes |
| 13:14.08 |
``Erik |
even when ya
think you grok the scale of that puppy, it's still
ungrokkable |
| 13:18.55 |
``Erik |
hm, 606x^2
widths of area |
| 13:19.59 |
``Erik |
1284.5 km
pixels will produce 1g of surface 8b elevetion data |
| 13:20.18 |
``Erik |
or wait, no,
my math is wrong |
| 13:20.51 |
``Erik |
1245.6 km
edges will produce 1g |
| 13:22.20 |
``Erik |
sooooo, the
US would be ~6 pixels at that resolution |
| 13:22.44 |
dloman |
lol |
| 13:22.53 |
dloman |
question,
since i know nothing of the process: |
| 13:23.27 |
dloman |
when brlcad
'preps' geometry... is that a good place to put in a LoD Proc Gen
function(s) ? |
| 13:24.01 |
``Erik |
no, LoD
requires some understanding of the viewpoints location, and prep
doesn't know anything about that |
| 13:24.17 |
``Erik |
we cannot do
LoD with the raytracing data as it stands |
| 13:24.33 |
dloman |
hrm, so does
the geometry have *any* idea where the viewport is at
anytime? |
| 13:24.59 |
``Erik |
the geometry
does not, the app is responsible for setting ray start
points |
| 13:25.57 |
``Erik |
hm |
| 13:26.12 |
``Erik |
mebbe a
fractal procedural displacement shader might work |
| 13:26.35 |
starseeker |
one of the
things we need to do longer term is have the primitives provide the
ability to take a view/geometry size and return an appropriate
wireframe |
| 13:26.58 |
dloman |
so whats the
order of operations then? |
| 13:27.23 |
dloman |
call 'rt',
prep geometry, then start firing rays? |
| 13:27.30 |
``Erik |
yup |
| 13:27.45 |
``Erik |
all prep is
completed before the first ray is shot |
| 13:27.56 |
starseeker |
has been tempted to start that level of re-org once or twice,
but it's deeply invasive and probably a fair bit of
work |
| 13:28.01 |
dloman |
aka, if the
geometry is prepped *after* the call is made to rt, then the
viewport data should be 'somewhere' that a function could get
at. |
| 13:29.15 |
``Erik |
starseeker:
I'm setting up a git repo using the svn bridge on my desk fbsd box,
um, /usr/tmp/brlcad.git I think? if you want to clone it for
playground activities |
| 13:29.21 |
dloman |
course, this
is 'logic' speaking and that may need not apply :) |
| 13:30.18 |
``Erik |
sets is schedule to involve; finding pants. getting coffee.
cleaning house on his day off here O.o wee. |
| 13:30.40 |
dloman |
oh you taking
a 4 day then? |
| 13:30.46 |
``Erik |
yup |
| 13:30.56 |
``Erik |
CN
today |
| 13:32.26 |
dloman |
starseeker:
you taking a 4 day weekend also? |
| 13:39.06 |
starseeker |
no, i'll be
in |
| 13:52.14 |
dloman |
Well that's a
great way to kick off the weekend. my bank called. Accounts been
comprimized :/ |
| 13:56.45 |
``Erik |
ow, an actual
compromise? not a false positive? |
| 13:57.29 |
dloman |
they shut
down all my cards :) I have all my money. So whether it was a true
compirmise or not, i really don't care :/ |
| 13:57.51 |
dloman |
However, now
i have to jump thru a ton of hoops to get my accounts back
up |
| 13:58.03 |
dloman |
kinda annoyed
atm :) |
| 14:03.13 |
``Erik |
better'n
bein' empty handed, ah surpose |
| 14:03.21 |
dloman |
true
that |
| 14:03.33 |
``Erik |
cranks up poplamoose while cleaning O.o |
| 14:03.37 |
dloman |
pretty much
why im not beating down the door of the base Bank of
America |
| 14:03.40 |
``Erik |
pomplamoose,
even |
| 14:04.19 |
``Erik |
(if'n ya
don't know them, check them out on the youtubez, 'beat it' 'put a
ring on it' 'nature boy'... awesome covers) |
| 14:05.49 |
dloman |
oh god, they
did a christmas commercial this last year...... |
| 14:06.16 |
dloman |
they annoyed
the hell out of me, lol |
| 14:07.06 |
``Erik |
the hyundai
one, yeah.. but they really don't suck, that was just a corporate
obnoxiousness |
| 14:07.10 |
dloman |
seems it was
the editing on the commercial, these arent that bad :) |
| 14:07.27 |
``Erik |
their version
of nature boy is effin' awesome |
| 14:07.32 |
dloman |
heh, is that
a moog? |
| 14:37.21 |
CIA-61 |
BRL-CAD:
03davidloman * r44701 10/geomcore/trunk/ (include/BrlcadDb.h
src/GS/BrlcadDb.cxx): Verbage change from 'path' to 'gPath' for
clarity. |
| 14:45.58 |
CIA-61 |
BRL-CAD:
03davidloman * r44702 10/geomcore/trunk/src/GS/BrlcadDb.cxx: Was
mistakenly using StringUtils::getLastStepOfPath() as a .g file path
validation check. Fixt. Now correctly using
BrlcadDb::_isValidPath() call. |
| 14:49.56 |
CIA-61 |
BRL-CAD:
03davidloman * r44703 10/geomcore/trunk/include/BrlcadDb.h: "//TODO
Move these to a more common place?" added in reference to common
return values dealing with errors for BrlcadDb function
calls. |
| 15:47.12 |
CIA-61 |
BRL-CAD:
03davidloman * r44704 10/geomcore/trunk/include/BrlcadDb.h: Add
some notes about ByteBuffer::wrap() failure handling. |
| 15:49.18 |
CIA-61 |
BRL-CAD:
03davidloman * r44705 10/geomcore/trunk/ (include/ExtObject.h
src/GS/ExtObject.cxx): Add in a serialize method to ExtObject that
creates a ByteBuffer and passed back a pointer to it. This allows
the ByteBuffer to be exactly the size required. |
| 18:12.09 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.25.117) |
| 18:12.09 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:17.52 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.25.117) |
| 19:17.52 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:32.19 |
CIA-61 |
BRL-CAD:
03r_weiss * r44706
10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 20:32.19 |
CIA-61 |
BRL-CAD:
Corrected logic in functions 'nmg_booltree_evaluate' and
'nmg_boolean' within |
| 20:32.19 |
CIA-61 |
BRL-CAD: file
'nmg_bool.c'. This fix stops the error 'nmg_boolean() result
of |
| 20:32.19 |
CIA-61 |
BRL-CAD:
nmg_booltree_evaluate() isn't tp' which occurs occasionally when
performing nmg |
| 20:32.19 |
CIA-61 |
BRL-CAD:
boolean operations such as when using the mged 'facetize' command.
This change |
| 20:32.19 |
CIA-61 |
BRL-CAD: also
allows boolean operations to return a null result without
failing. |
| 20:44.04 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.25.117) |
| 20:44.04 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 21:17.17 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
| 21:18.06 |
starseeker |
dloman: ouch,
sorry to hear that about your accounts! |
| 21:18.23 |
starseeker |
``Erik: just
curious, do you know anything about Lua (scripting
language?) |
| 21:26.33 |
``Erik |
unfortunately |
| 21:26.47 |
``Erik |
it's an ugly
language, but it's simple and very embedable |
| 21:27.38 |
``Erik |
you can use
luac to generate luab files, compiled things... um, I heard lua 5
was supposed to fix a lot of stuff, I mostly dealt with lua 4 a
llllong time ago, doing a platformer video game |
| 21:34.05 |
starseeker |
hmm... how's
it compare to Tcl? |
| 21:34.21 |
starseeker |
notes 5 has been out for quite a while... |
| 21:35.50 |
``Erik |
my info is
outdated, at the time... tcl was worse to integrate and slower, but
tcl felt "lisper" |
| 21:36.09 |
``Erik |
lua reminded
me of basic |
| 21:36.15 |
starseeker |
winces |
| 21:36.41 |
starseeker |
darn... the
"easier to integrate" bit really appeals... |
| 21:36.53 |
``Erik |
it's a tiny
language, easy to integrate... compile yourself up a version and
experiment |
| 21:37.18 |
starseeker |
was looking over the Tcl build logic again and having bad
things happen to his blood pressure... |
| 21:37.56 |
starseeker |
has evil thought... stick a Tcl parser on top of Lua
:-P |
| 21:38.05 |
``Erik |
tcl is stuck
in the 80's, lua is designed for src/other/ type stuff... but the
language panders to javascript/java/c++/perl
programmers |
| 21:39.52 |
starseeker |
hmm... wonder
if I can re-create the "mged command prompt" type
environment |
| 21:39.54 |
``Erik |
give it a
shot, it's an easy one to learn... *shrug* all I can give is my
opinion, and opinions are like a**holes :) |
| 21:40.11 |
starseeker |
wouldn't have
Tcl under the hood though, so I suppose it's a guaranteed fail for
acceptance |
| 21:41.02 |
``Erik |
my vote is
for removing tcl from teh core and providing a more abstracted
interface so we can use python, ruby, cl, scheme, lua, ... perl...
whatever anyone wants |
| 21:41.48 |
``Erik |
C is lingua
franca, so that should be our exposed interface |
| 21:42.30 |
starseeker |
would looove to find a way to get Tcl/Tk out of src/other
altogether |
| 21:43.38 |
``Erik |
that'd be
interesting, I'm more concerned with doing "make librt" with no tcl
having to be involved |
| 21:44.09 |
starseeker |
heh, CMake
perspective talking for me I guess - making sure Tcl/Tk builds
integrated and everywhere is like hauling around a 50 pound
anchor |
| 21:44.56 |
``Erik |
you're the
one who decided to start not liking automake and push the cmake
migration... you did it to yourself :D |
| 21:45.28 |
``Erik |
so release
today is not happening? |
| 21:46.19 |
``Erik |
http://www.youtube.com/watch?v=LNpwBpZUrzk
<-- all sorts of awesome |
| 21:46.49 |
starseeker |
``Erik: well,
having autotools and Windows builds separate is another and worse
sort of boat anchor |
| 21:47.12 |
``Erik |
yes, windows
is a definite ... issue |
| 21:47.17 |
starseeker |
``Erik:
unfortunately, probably not today |
| 21:47.46 |
starseeker |
that little
change of Bob's got rtwizard up, but means we need another round of
testing |
| 21:47.52 |
``Erik |
if you can
get a build on thor, awesome... if not, well, it's a .0 and we
expect pain in the transfer |
| 21:48.09 |
starseeker |
plus I
suppose I should really figure out why rtedge isn't displaying in
the rtwizard framebuffer... |
| 21:48.41 |
starseeker |
oh, and I
didn't START not liking autotools - I NEVER liked it
:-P |
| 21:48.47 |
``Erik |
part of me
wants to say "just throw it out" and take out lumps, and .2 will be
a big cleanup release |
| 21:48.56 |
``Erik |
s/out/our/ |
| 21:49.08 |
starseeker |
``Erik:
<shrug> we can do that |
| 21:49.28 |
starseeker |
``Erik: you
can do the release too you know - I don't have some "magic
key" |
| 21:49.45 |
``Erik |
I'm taking
the day off, I'm not allowed to do work :D |
| 21:49.50 |
starseeker |
heh -
cop-out |
| 21:50.17 |
``Erik |
indeed. I'll
go back to scrubbing toilets and floors now. :/ |
| 21:51.04 |
``Erik |
(almost
tagged yesterday, btw... seriously, fuggit, it'll suck and we'll
get "it don't work", but ...) |
| 21:51.28 |
starseeker |
yeah, I
know |
| 21:51.33 |
starseeker |
updates... |
| 21:53.27 |
``Erik |
7.20.2 will
see the fixing of the osX ogl bug, the 32b tie bug, ... but 7.20.0
will not. |
| 21:53.54 |
starseeker |
``Erik: if
we're going to do it - anything we should toss in the deprecation
list now? |
| 21:54.03 |
starseeker |
(i.e. we want
to get rid of this ASAP?) |
| 21:54.04 |
``Erik |
and the
7.20.0 winderz binary will be huge for the community, I think...
99% instead of 25% of the tools |
| 21:54.36 |
``Erik |
um, mro and
the libtie change is all I can think of |
| 21:55.12 |
starseeker |
heh - mro is
kinda "whoops, it's gone now" instead of "deprecated, will go away
eventually" |
| 21:55.12 |
``Erik |
maybe a
statement about the altered attribute handling? |
| 21:56.07 |
``Erik |
"deprecated
7.20.0, deleted 7.20.0. Sucks to be you." |
| 21:56.37 |
``Erik |
it's a minor
bump, we're allowed to be a bit mean |
| 21:57.36 |
starseeker |
yeah, I guess
we'll go with condition c |
| 21:57.46 |
``Erik |
btw, I
started a cmake migration of the project who would lament the mro
removal... it's making me nervous |
| 21:58.55 |
``Erik |
can trunk
succeed at a distcheck? I tried to keep my modifications synced
between cmake and automake, but ... |
| 21:59.33 |
``Erik |
if automake
can do a distcheck, benchmark and regress, I say tag and
go |
| 21:59.39 |
starseeker |
nods |
| 21:59.47 |
starseeker |
I'm trying an
automake distcheck now |
| 22:00.40 |
``Erik |
seriously,
crank http://www.youtube.com/watch?v=LNpwBpZUrzk
up, get the sub going, tell bob it's for his own good |
| 22:00.57 |
starseeker |
heh |
| 22:01.04 |
starseeker |
he's not in,
actually |
| 22:01.16 |
``Erik |
PLAY
IT |
| 22:02.28 |
starseeker |
is |
| 22:02.52 |
``Erik |
since you're
doing the gruntwork of releasing today, and it's a monster change,
um, I will do a fbsd port cook on tuesday, and thinking this will
be a very short run release |
| 22:03.10 |
``Erik |
we might
target 7.20.2 for, uh, 2 weeks from now? |
| 22:03.23 |
starseeker |
nods |
| 22:03.40 |
starseeker |
um...
PomplamooseMusic |
| 22:03.43 |
starseeker |
? |
| 22:03.45 |
``Erik |
yes |
| 22:04.11 |
``Erik |
pomplamoose
is a duo band out of nyc, their cover of nat king coles nature boy
is ... awesome |
| 22:04.33 |
starseeker |
they seem to
bet getting a lot of attention |
| 22:04.36 |
starseeker |
do you know
them? |
| 22:04.39 |
``Erik |
I've been a
fan of the for a few years, last winter they had a contract deal
with hyundai on a commercial |
| 22:05.15 |
starseeker |
cool |
| 22:05.45 |
``Erik |
I like to
pretend that I find awesome bands before they become popular, I'm
very "scene" like that |
| 22:06.02 |
starseeker |
nods - it does happen, once in a while |
| 22:06.35 |
``Erik |
I think
there're 4 that I've told people about that have gone on to
commercials or some kinda recognition when I pointed to them as
subs |
| 22:07.02 |
``Erik |
goldfrapp, 2
weeks after I messaged every I knew about them, they showed up in a
commercial |
| 22:07.10 |
CIA-61 |
BRL-CAD:
03starseeker * r44707 10/brlcad/trunk/doc/deprecation.txt: Abrupt,
but close to minimal and what appears to be the least painful way
forward - mro is going, all hail
bu_attribute_value_set. |
| 22:07.20 |
starseeker |
awesome |
| 22:07.26 |
``Erik |
(they
probably shot the commercial before I heard them, but
*shrug*) |
| 22:07.48 |
starseeker |
awaits the thunderbolt from brlcad... |
| 22:08.37 |
``Erik |
the boy has a
mini-me. the thunderbolt is 3 months out at the soonest |
| 22:09.12 |
``Erik |
and this is
explicitely permitted in the rules set down |
| 22:09.35 |
starseeker |
hehe |
| 22:09.57 |
starseeker |
well, for
loose definitions of minimal |
| 22:10.01 |
starseeker |
close
though |
| 22:10.08 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 22:10.16 |
starseeker |
and I still
think it's the least painful approach |
| 22:10.37 |
``Erik |
the, uh,
favor you volunteered for, I started on it, it's gonna be rough...
they have a very intertwined dep chain with lots of #include
action |
| 22:12.02 |
``Erik |
#include
<Ap.h> instead of #include |
| 22:12.09 |
``Erik |
#include
"Ap/Ap.h" |
| 22:12.19 |
starseeker |
winces |
| 22:12.21 |
``Erik |
so a lot of
-I action |
| 22:12.36 |
starseeker |
I suppose
untangling it isn't an option |
| 22:12.39 |
``Erik |
or C
changes... |
| 22:13.17 |
``Erik |
if you can
convince geoff... |
| 22:13.26 |
starseeker |
uh...
yeah |
| 22:13.42 |
starseeker |
-I it
is |
| 22:13.51 |
starseeker |
initially at
least |
| 22:14.02 |
``Erik |
frankly, I
started my 'acst' branch to superseed both teams |
| 22:14.23 |
``Erik |
unfortunately, we lack a dietz |
| 22:14.43 |
``Erik |
"nothing
succeeds like success", my gut feeling is that success will be
punished |
| 22:15.17 |
starseeker |
well, all we
can do is try |
| 22:17.00 |
CIA-61 |
BRL-CAD:
03starseeker * r44708 10/brlcad/trunk/ (README include/conf/MINOR
include/conf/PATCH): Here we got - bump the version
numbers. |
| 22:19.03 |
CIA-61 |
BRL-CAD:
03starseeker * r44709 10/brlcad/trunk/ChangeLog: Update
ChangeLog |
| 22:21.02 |
``Erik |
w00t |
| 22:29.35 |
CIA-61 |
BRL-CAD:
03starseeker * r44710 10/brlcad/branches/STABLE/ (427 files in 165
dirs): Merge trunk r44709 to STABLE |
| 22:30.11 |
*** join/#brlcad Yoshi477
(~jan@d72-39-60-53.home1.cgocable.net) |
| 22:34.11 |
starseeker |
notes he somehow missed that the byacc maintainer also
maintains a version of flex |
| 22:35.23 |
starseeker |
hmm... |
| 22:59.31 |
starseeker |
hmm, cool
http://tdb.samba.org/ |
| 23:00.34 |
CIA-61 |
BRL-CAD:
03starseeker * r44711 10/brlcad/tags/rel-7-20-0/: Tag
7.20.0 |
| 23:00.53 |
starseeker |
``Erik: there
ya go |
| 23:01.36 |
starseeker |
ahhh, crud -
forgot to update the date of release |
| 23:02.16 |
CIA-61 |
BRL-CAD:
03starseeker * r44712 10/brlcad/trunk/NEWS: Ah, nuts - forgot to
fix the date. |
| 23:05.06 |
CIA-61 |
BRL-CAD:
03starseeker * r44713 10/brlcad/trunk/ (NEWS README
include/conf/PATCH): Bump numbers. |
| 23:05.24 |
starseeker |
needs to get outta here... |
| 00:01.09 |
brlcad |
yeah, once
you start making a little progress, your commits (and your commit
messages) will be just as important if not more important than
progress updates .. good stuff |
| 00:01.58 |
bhinesley |
nods |
| 00:02.03 |
bhinesley |
there will be
a lot going through today |
| 00:10.31 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.142.216) |
| 00:10.31 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 00:26.32 |
*** join/#brlcad crazy_imp
(~mj@a89-182-166-16.net-htp.de) |
| 01:09.43 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.142.216) |
| 01:09.43 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 01:24.13 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 01:41.07 |
CIA-61 |
BRL-CAD:
03bhinesley * r44769 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): (log message trimmed) |
| 01:41.07 |
CIA-61 |
BRL-CAD: This
was an incremental step towards: 1) adding the man command to
archer 2) |
| 01:41.07 |
CIA-61 |
BRL-CAD:
creating a megawidget for the manual page browser, to eliminate
code duplication |
| 01:41.07 |
CIA-61 |
BRL-CAD:
among Archer and MGED. Progress already made on the actual
megawidget will be |
| 01:41.07 |
CIA-61 |
BRL-CAD:
added in a bit. |
| 01:41.07 |
CIA-61 |
BRL-CAD: -Man
command now works in Archer |
| 01:41.08 |
CIA-61 |
BRL-CAD:
-Changed the method of adding commands to the Manual Page Browser
ToC from "insert end" to using -listvariable as recommended here:
http://www.tkdocs.com/tutorial/morewidgets.html |
| 02:44.55 |
CIA-61 |
BRL-CAD:
03bhinesley * r44770
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Removed
doarcherMan, and set Help->Man Pages to call the man command
directly |
| 03:22.01 |
brlcad |
woot |
| 03:31.18 |
bhinesley |
:-P |
| 03:31.36 |
CIA-61 |
BRL-CAD:
03brlcad * r44771 10/brlcad/trunk/NEWS: brandon added the 'man'
command to archer. |
| 03:33.03 |
bhinesley |
ah |
| 03:33.19 |
bhinesley |
shall I make
an effort to keep that updated? |
| 03:33.28 |
starseeker |
it's usually
easier |
| 03:33.39 |
starseeker |
add
user-visible stuff |
| 03:34.00 |
bhinesley |
ok |
| 03:34.52 |
starseeker |
brlcad: what
plans did you have for the architecture of libgcv? I've been
reading up on the issue indianla1ry ran into with trying to turn
the step-g factory mechanism into a library - the whole "compiler
removing static" thing |
| 03:35.12 |
starseeker |
there appears
to be No Good Solution if you stick to straight C++ |
| 03:35.44 |
starseeker |
not compiler,
linker stripping out static rather |
| 03:35.46 |
CIA-61 |
BRL-CAD:
03brlcad * r44772 10/brlcad/trunk/NEWS: |
| 03:35.47 |
CIA-61 |
BRL-CAD:
brandon also improved the manual page browser gui behavior with
improved |
| 03:35.47 |
CIA-61 |
BRL-CAD:
performance (using listbox variable binding instead of adding items
manually) |
| 03:35.47 |
CIA-61 |
BRL-CAD: and
adding a ListboxSelect event binding so keys, clicking, and
dragging work. |
| 03:36.15 |
brlcad |
bhinesley:
yeah, any time you make a change that is *user* visible, it
warrants a one-line entry in the NEWS file |
| 03:37.10 |
brlcad |
the file has
a specific format (described at the bottom) and the commit message
per line is important |
| 03:38.01 |
starseeker |
is getting desperate enough to consider embedding scheme or
lisp to escape the limits of C++/C... |
| 03:38.02 |
brlcad |
the svn log
is automatically parsed with a script that pulls each commit
message for each feature line which we use to review features, so
try to only commit one line at a time and make your commit message
as descriptive as needed |
| 03:38.39 |
brlcad |
starseeker:
not sure what you're referring to |
| 03:39.01 |
brlcad |
step-g's
factory mechanism isn't a very good way to do things.. |
| 03:39.18 |
starseeker |
erm. what's
the better way? |
| 03:39.45 |
brlcad |
first, what's
the goal? :) |
| 03:39.45 |
starseeker |
was under the impression the factory design was the recommend
approach to that sort of problem... |
| 03:39.50 |
brlcad |
factory
sure |
| 03:39.57 |
brlcad |
there's lots
of ways to make factory |
| 03:40.06 |
bhinesley |
brlcad: I'm
not sure I follow... you're saying keep commit messages
brief? |
| 03:40.32 |
starseeker |
architect the
library in such a way that you can write one file per format, add
it to the library without changing anything else, and have the
conversion routines be able to find it when some program using the
library asks for it |
| 03:40.50 |
brlcad |
bhinesley: no
no, the messages can/should be any details not encoded in the
70-char news line, like why or bug report numbers or who reported a
bug or who requested the feature, ets |
| 03:41.09 |
bhinesley |
oh
okay |
| 03:41.13 |
brlcad |
starseeker:
one file per format is probably not feasible |
| 03:41.15 |
bhinesley |
that's what I
figured |
| 03:41.25 |
starseeker |
growl |
| 03:41.39 |
brlcad |
i mean,
there'd be just one set of function hooks per format |
| 03:41.49 |
brlcad |
ala
src/librt/primitives |
| 03:41.55 |
brlcad |
but it's a
set of funcs that you'd need |
| 03:42.08 |
brlcad |
probably not
just read and write |
| 03:42.26 |
brlcad |
but even
those two, rather different requirements |
| 03:44.30 |
brlcad |
starseeker:
as for the rest (add it to the library without changing anything
else, and have the conversion routines be able to find) .. that's
pretty easy |
| 03:44.48 |
brlcad |
even a simple
freshman textbook factory implementation will do that |
| 03:45.02 |
brlcad |
or dynamic
loaded library snippets |
| 03:45.42 |
starseeker |
what's the
problem with step-g's implementation then? |
| 03:45.55 |
starseeker |
I was under
the impression indianla1ry designed it fairly carefully |
| 03:46.58 |
brlcad |
it's using
the sdai (app interface) from the step class libraries |
| 03:47.28 |
starseeker |
I'm not sure
that's the reason it wouldn't work as a lib though... |
| 03:47.29 |
brlcad |
it
static-initializes variables, then searches at runtime for those
classes |
| 03:47.48 |
starseeker |
right - most
of the C++ Factory discussions I can find do something like
that |
| 03:47.55 |
brlcad |
the problem
was there was some compiler (erroneously) optimizing away those
static classes so they didn't exist iirc |
| 03:48.08 |
brlcad |
not the way
sdai did it |
| 03:48.14 |
brlcad |
it was a nit
pick detail |
| 03:48.15 |
starseeker |
shakes his head - that's not a compiler error, according to
everything that I can find |
| 03:48.25 |
brlcad |
the overall
approach they intended was 'okay' |
| 03:49.12 |
brlcad |
it relied on
static variable initialization ordering, which isn't
guaranteed |
| 03:49.33 |
starseeker |
http://programmerjoe.com/2007/03/18/the-abstract-factory-pattern-in-c/ |
| 03:49.51 |
starseeker |
that article
mentions the linker stripping out "unreferenced" static
variables |
| 03:50.01 |
brlcad |
they needed
to require an init point other than main() (like loading a library
or an explicit init() method) |
| 03:51.01 |
brlcad |
right off the
bad, that write-up isn't entirely accurate |
| 03:51.22 |
brlcad |
lack of an
ability to instantiate an object at runtime given the name of a
class .. you can, it's just complicated |
| 03:52.29 |
starseeker |
it must be, I
can't find anything so far telling me how to do it |
| 03:52.57 |
brlcad |
he states the
problem: "you won't be referencing these classes and objects
directly, so you have to force the linker to include them by adding
references" |
| 03:53.32 |
brlcad |
it's all in
how you build up the factory, and there are lots of ways to go
about it |
| 03:53.47 |
brlcad |
sdai's method
was a little sucky, but a simple reference fixes the optimization
problem |
| 03:54.02 |
brlcad |
actual code
example I wrote a few years ago:
https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/include/Factory.h |
| 03:55.02 |
brlcad |
that's the
abstract factory, here showing a real factory:
https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/bzfs/SpawnPolicyFactory.h |
| 03:55.34 |
brlcad |
and then the
'simple fix' that lets the linker know that you don't want it to
optimize away:
https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/bzfs/SpawnPolicyFactory.cpp |
| 03:55.45 |
brlcad |
(see the
_init() function) |
| 03:56.32 |
starseeker |
yes |
| 03:56.41 |
brlcad |
if I wanted
to avoid the explicit list of types (which isn't all that bad
really, factory lists don't really tend to change that
frequently) |
| 03:57.01 |
brlcad |
I'd just have
made loadable library modules, and load / register them all in
_init() |
| 03:57.32 |
brlcad |
think
dlopen() style |
| 03:58.02 |
starseeker |
um...
wouldn't that get rather messy if you started to have hundereds of
types floating around? |
| 03:58.39 |
brlcad |
not really,
it's still just an entity list |
| 03:58.43 |
starseeker |
also, is that
portable? (loadable library modules) |
| 03:58.56 |
brlcad |
pretty much,
but I'd start with an explicit list |
| 03:59.51 |
starseeker |
so is that
_init call in a library or an executable? |
| 04:00.04 |
``Erik |
might be
worth seeing how OS's deal with, say, network cards... I think that
might be somewhat analogous. FBSD has a set of common functions and
some macro fu to 'register' |
| 04:00.18 |
brlcad |
starseeker:
an exectuable in that case, but it could go into a lib
too |
| 04:01.53 |
brlcad |
the libgcv
api should get written down first before getting mired in
implementation detail like this, issues that might screw up the api
if done poorly |
| 04:02.00 |
``Erik |
my concern is
that different formats hold different kinds of data, so your
intermediate format is either a massive superset or a minimal
subset :/ |
| 04:02.47 |
brlcad |
.g or .step
are both fairly massive supersets |
| 04:02.55 |
brlcad |
or at least
have arbitrary storage capability |
| 04:03.23 |
starseeker |
massive
superset doesn't worry me - a pivot format in a conversion library
of this nature will be conceptually broad of necessity |
| 04:03.33 |
brlcad |
in-mem .g ftw
imnsho ;) |
| 04:03.47 |
starseeker |
we we need is
a technically sound way to manage that complexity and extend it
cleanly |
| 04:03.51 |
brlcad |
that's how
most of the code is already written anyways, least
effort |
| 04:04.19 |
brlcad |
best
performing too, of known options |
| 04:04.55 |
starseeker |
if we focus
on just what .g supports, yeah that's the simple route. But it
means the conversion library will remain special purpose, because
there are a LOT of things we don't support now in the .g
format |
| 04:04.58 |
brlcad |
but the api
shouldn't care -- it's more "import from X" .. then "export as
Y" |
| 04:05.14 |
brlcad |
using in-mem
.g or whatever else is just the in-between implementation
detail |
| 04:05.25 |
starseeker |
sure, but the
devil's in the details |
| 04:05.54 |
brlcad |
nothing says
we have to only focus on what .g supports |
| 04:06.11 |
brlcad |
just need a
mechanism for storing and recovering |
| 04:06.16 |
starseeker |
uh... if
we're using .g as the in-mem pivot format... |
| 04:06.17 |
brlcad |
which .g
has |
| 04:06.27 |
brlcad |
example |
| 04:06.57 |
``Erik |
bones,
keyframes, animation stuff, programmable definition (povray),
... |
| 04:07.17 |
``Erik |
v5 has
deficiencies |
| 04:07.30 |
brlcad |
I can store
opengl-style pixel shader information into a .g file along with
textures and texture mapping data ... even though brl-cad can't use
it |
| 04:08.05 |
brlcad |
just need to
know that's what was stored so when an exporter wants the data, it
can pull it |
| 04:08.41 |
starseeker |
but if you
need to convert that to format FOO pixel shader information for
three other export formats, where does that logic live? |
| 04:09.02 |
``Erik |
you can shove
lightwave objects and scenes in an attribute, but without knowledge
of the magic black box, conversion is impossible |
| 04:09.05 |
starseeker |
I doubt we
want each exporter to implement all of its own conversion logic for
that sort of thing |
| 04:09.12 |
starseeker |
there will be
lots of overlap |
| 04:09.50 |
brlcad |
starseeker:
how's that different than asking "if you need to convert that
sphere to format FOO, where does that logic live?" |
| 04:10.01 |
brlcad |
it lives in
format FOO's converter |
| 04:11.22 |
brlcad |
the only
thing an underlying format is going to give you is structure, not
necessarily easier access or reduction of export logic |
| 04:11.36 |
brlcad |
*memory*
structure |
| 04:12.25 |
brlcad |
so .g doesn't
have a memory structure for pixel shaders, boo hoo .. don't care
really .. libgcv defines a structure and shoves it in, knows the
structure, so it can pull it out |
| 04:13.11 |
brlcad |
this isn't
unique to .g in the least .. there's not a single format that
doesn't have this issue and would need a similar 'fix' |
| 04:14.22 |
brlcad |
step would be
the closest to being a format that has in-memory structure for
almost everything, but it's still NOT everything and you pay for
the complexity |
| 04:14.47 |
brlcad |
can see
either working, though, easily enough (step or .g) |
| 04:14.54 |
starseeker |
's instinct is that the complexity might be worth paying
for... |
| 04:15.36 |
brlcad |
write a
complet g-step and say that again :) |
| 04:16.23 |
starseeker |
fair enough -
but that gets back to trying to understand how to Do It Right - and
explicit lists get long fast when we're talking about
STEP |
| 04:16.34 |
``Erik |
d'no,
starseeker... it's not our job to be a zomfg utility conversion
toolkit... we do better than most already, but that's a hell of a
calling |
| 04:16.48 |
brlcad |
it's not?
:) |
| 04:16.53 |
starseeker |
``Erik: I'm
not saying we need to be that overnight, but I'd like to architect
so that we can grow into that |
| 04:17.04 |
brlcad |
we do better
than everyone at this point (open source) |
| 04:17.37 |
starseeker |
thinks the best way to get other interests on board is to
position ourselves to do it better than ANYONE, closed or
open |
| 04:17.50 |
brlcad |
my thoughts
were to leverage existing code as much as possible, because it
really is a huge task once you involve more than a couple
formats |
| 04:18.38 |
``Erik |
some
commercial packages do a very impressive job of importing and
exporting, but they have tons of resources to throw at satisfying
their customers |
| 04:19.06 |
brlcad |
take the
converters main() as they stand now, rewrite them so that stl-g's
main is something like stl2g() but the g is opened as an in-mem db
and a context is preserved |
| 04:19.12 |
starseeker |
sure. That's
why it's so important we be able to grow incrementally, being clean
from the start and gradually expanding our abilities |
| 04:19.36 |
brlcad |
repeat for
all formats, and you have a slew of conversion funcs from files to
in-mem .g with very very minimal code change |
| 04:19.40 |
CIA-61 |
BRL-CAD:
03bhinesley * r44773 10/brlcad/trunk/src/tclscripts/
(archer/Archer.tcl man_browser.tcl pkgIndex.tcl): Added the
ManBrowser mega-widget (nonfunctional). This will eliminate code
duplication of the Manual Page Browsers among Archer and
MGED. |
| 04:20.07 |
``Erik |
many conv/
files can be simplified by migrating them to the existing libgcv
tesselation functions |
| 04:20.08 |
brlcad |
register all
of those funtions into a table in libgcv and bingo, universal
converter |
| 04:20.13 |
starseeker |
brlcad: My
understanding was that we were going to have a lot of code changes
anyway as we reduced the duplication of logic during the libgcv
conversion |
| 04:20.19 |
``Erik |
triangles are
a good lcd |
| 04:20.21 |
brlcad |
``Erik: yeah
they can.... |
| 04:20.26 |
brlcad |
but it's a
royal pita |
| 04:20.32 |
brlcad |
i've tried a
couple times |
| 04:20.52 |
``Erik |
I've made an
attempt, as well :) |
| 04:20.53 |
brlcad |
almost all of
them have slight tweaks, write out different data at random points
in the output, etc |
| 04:21.48 |
``Erik |
I threw in a
generalized tesselation function into the new stuff I'm doing
that'll return a full tree of BoTs, it might be the change we need
to migrate |
| 04:22.24 |
brlcad |
starseeker:
ideally, but not necessarily .. reducing the code duplication there
is not nearly as trivial as what I described |
| 04:22.58 |
brlcad |
``Erik: I saw
.. by trying to tessellate from scratch with a different algo...
good luck with that ;) |
| 04:23.22 |
brlcad |
even if it
works reliably, that's still 100k lines of code to
refactor |
| 04:23.31 |
``Erik |
have a
working java example, surprisingly small |
| 04:23.32 |
brlcad |
even if it
reduces 10-fold, that's weeks of work |
| 04:23.38 |
``Erik |
nmg is just
plain horrible |
| 04:23.57 |
brlcad |
because it
guarantees topology |
| 04:24.13 |
brlcad |
what's the
approach you're using do for that? |
| 04:24.27 |
``Erik |
there's a
trick in the latest approach that kinda surprises me, slicing all
intersecting triangles before catagorizing |
| 04:25.16 |
``Erik |
the original
'86 paper has a whole chain of refinements, UnNBoolean seems to be
the latest real example. I think the NMG stuff was originally based
on that old '86 paper, then prematurely abstracted and
implemented... poorly. |
| 04:25.31 |
brlcad |
there's only
three or four methods I'm aware of that preserve
topology |
| 04:26.10 |
``Erik |
at the heart,
this is still the same approach that nmg was supposed to
be |
| 04:26.54 |
``Erik |
lee admitted
that he didn't know what he was doing and screwed it up, daytona
noted that too much information was thrown away at the beginning of
the pass, ... *shrug* we'll see |
| 04:27.00 |
``Erik |
and I think
my cat just farted at me |
| 04:27.28 |
brlcad |
nmg is the
radial-edge method, there's winged-edge, half-edge, quad-edge,
doubly linked faces, .. |
| 04:28.37 |
``Erik |
most of those
assume arbitrary polygons, i'm sticking to pure
triangles |
| 04:29.06 |
brlcad |
I'm not
defending nmg as much as saying it's hard to do it while still
guaranteeing topology, preserving the manifold property |
| 04:29.36 |
``Erik |
http://unbboolean.sourceforge.net/ |
| 04:30.07 |
``Erik |
s/N/B/ |
| 04:31.08 |
louipc |
huh replace N
with B? |
| 04:31.33 |
``Erik |
yeh, louis, I
said unnboolean, shoulda been unbboolean :) |
| 04:31.38 |
brlcad |
``Erik: fwiw,
the polyhedral paper they reference came *before*
radial-edge |
| 04:31.56 |
``Erik |
erm, the
portugeuse 2008 paper? |
| 04:32.06 |
louipc |
ah
cool |
| 04:32.34 |
louipc |
new
competitions? |
| 04:32.46 |
brlcad |
by a couple
years |
| 04:32.54 |
brlcad |
he states it:
Constructive Solid Geometry for Polyhedral Objects, by D. H.
Laidlaw, W. B. Trumbore, and J. F. Hughes |
| 04:33.19 |
``Erik |
there's a
chain of papers that go from 86 to 08 |
| 04:33.35 |
brlcad |
the
portuguese paper he wrote :) |
| 04:33.38 |
CIA-61 |
BRL-CAD:
0399.144.90.118 07http://brlcad.org
* r2908 10/wiki/User:Bhinesley: /* Log */ Yesterday, today, and
plan for tomorrow. |
| 04:34.21 |
brlcad |
I have
trumbore's paper around here somewhere |
| 04:34.35 |
brlcad |
it's decent,
simple |
| 04:35.08 |
``Erik |
*grouse* pine
frequently crashes on brlcad.org, and mutt won't even run. need to
migrate |
| 04:35.12 |
brlcad |
definitely
wouldn't declare the approach better (or worse) |
| 04:35.59 |
louipc |
what
os? |
| 04:36.00 |
brlcad |
iirc, the
method also attempts to preserve manifold, but fails for some
n-manifold cases that radial solved |
| 04:36.41 |
brlcad |
radial solved
the problem, but with complexity .. the failure in nmg isn't the
method but the implementation |
| 04:38.54 |
``Erik |
there seems
to be a lot of success with the KISS deviation from what nmg tried,
shouldn't take too long to implement and would bump up a couple 9's
on success rate for real geometry |
| 04:40.01 |
``Erik |
I'll read up
on radial edge, but the task as stated is pretty low
investment |
| 04:40.48 |
brlcad |
done again
from scratch, I'd probably be looking at winged edge or
radial |
| 04:40.58 |
brlcad |
the bigger
issue for CAD is the manifold property |
| 04:41.48 |
brlcad |
if something
has three holes, it should preserve those three holes through
conversion, not some other number .. or catastrophic for analysis,
turn into a non-manifold |
| 04:42.19 |
brlcad |
the latter is
the biggest problem and the hardest to guarantee without
structure |
| 04:44.41 |
``Erik |
I'd love to
just use nurbs as the intermediary and focus effort now, but
several people want visual tesselations to shove in ogl, that's
what I'm working towards... not serious interrogation, just quick
visualization |
| 04:45.24 |
brlcad |
except the
very next thing they'll want is to dump that to something other
than opengl and shoot rays at it, pretending it means
something |
| 04:45.29 |
brlcad |
you know it
as well as I |
| 04:47.32 |
``Erik |
unfortunately, they'll try... so we call
BoT's an approximation and push 'em towards nurbs |
| 04:48.08 |
``Erik |
time for
sleep, catch ya'll later :) |
| 04:48.16 |
brlcad |
hey, it's
your seconds ticking by |
| 04:48.21 |
brlcad |
I just think
it's a waste of time |
| 04:49.34 |
brlcad |
and I'll
annongly keep saying it .. we should be focusing on robust solid
modeling and geometry managemenet |
| 04:50.06 |
brlcad |
anything else
is outside our domain, a distraction, wasted divergent resources
and wasted effort |
| 04:50.59 |
``Erik |
dude, I
agree... I tried to pitch putting my funded time to nurbs... but
was told I had to have improved tesselation by the end of the fy,
it's on my objectives, need something for accomplishments in late
sept... :/ process is screwing product yet again |
| 04:51.51 |
louipc |
I'd say UI is
the most important at this point :P |
| 04:51.55 |
brlcad |
so give them
g-egg ;) |
| 04:52.07 |
brlcad |
louipc: it is
to the community at large |
| 04:52.31 |
``Erik |
they were
trying to put me on tweaking marching cubes, which is simply wrong
for our kind of geometry, so I think I managed a small victory in
changing that direction |
| 04:52.37 |
brlcad |
but not to
the elephant contributor that pays to get what they think is most
important :) |
| 04:52.53 |
louipc |
hehe |
| 04:53.07 |
louipc |
name the
price ;) |
| 04:53.54 |
``Erik |
after all the
overhead (equipment, facilities, mgmt, support staff), I think it's
in the neighborhood of 240000usd/year |
| 04:54.01 |
brlcad |
louipc:
nominally, http://www.ohloh.net/p/brlcad/estimated_cost |
| 04:54.58 |
brlcad |
heh, that's
probably missing a digit |
| 04:55.22 |
louipc |
waow |
| 04:55.59 |
brlcad |
or did you
mean per year per person |
| 04:56.13 |
``Erik |
disturbingly,
I'm pretty sure that the failbomb upstairs has already cost more
than all of BRL-CAD |
| 04:56.17 |
``Erik |
I meant per
person per year |
| 04:57.28 |
``Erik |
so yeh,
sleep. hasta la pasta |
| 04:57.43 |
louipc |
nite |
| 04:57.50 |
brlcad |
still thinks the easiest path forward is unit testing libbn
then libnmg, evaluating robust up the call
hierarchy |
| 04:57.56 |
brlcad |
cheers |
| 05:02.36 |
CIA-61 |
BRL-CAD:
03brlcad * r44774 10/brlcad/trunk/NEWS: cliff and erik developed a
tcl/tk version of isst made available through the cmake build for
64-bit platforms. recommit for docs. |
| 05:02.59 |
brlcad |
starseeker:
did you see the bug report about the bindings? |
| 05:03.25 |
brlcad |
said both
mouse buttons now zoom out, probably related to "zoom out
keybinding fixed on Linux/*BSD" made prior to release |
| 05:05.26 |
CIA-61 |
BRL-CAD:
03brlcad * r44775 10/brlcad/trunk/NEWS: |
| 05:05.26 |
CIA-61 |
BRL-CAD:
cliff fixed the zoom-out mouse binding on linux/bsd that probably
stopped |
| 05:05.26 |
CIA-61 |
BRL-CAD:
working after I made a fix for Mac bindings. problem may need
revisiting, |
| 05:05.26 |
CIA-61 |
BRL-CAD:
though, becuase there's already a report that both left/right mouse
now zoom out |
| 05:05.26 |
CIA-61 |
BRL-CAD: for
some platform. |
| 05:08.45 |
CIA-61 |
BRL-CAD:
03brlcad * r44776 10/brlcad/trunk/BUGS: both mouse buttons zoom in
now on some common platform |
| 05:10.25 |
CIA-61 |
BRL-CAD:
03brlcad * r44777 10/brlcad/trunk/NEWS: cliff improved the mged
'search' command so you can specify multiple paths now and it will
report them appropriately. recommit for docs. |
| 05:13.46 |
CIA-61 |
BRL-CAD:
03brlcad * r44778 10/brlcad/trunk/NEWS: richard reportedly fixed a
segment splitting bug that would affect all tessellation and
polygonal conversions. recommit for docs. |
| 05:15.14 |
CIA-61 |
BRL-CAD:
03brlcad * r44779 10/brlcad/trunk/NEWS: richard fixed a crash that
was occuring during facetization/conversion of large models. bad
book keeping? recommit for docs. |
| 05:18.03 |
CIA-61 |
BRL-CAD:
03brlcad * r44780 10/brlcad/trunk/NEWS: bob fixed a bug introduced
in asc2g where the new standard attribute logic was causing the
color tables and other attribute data to not get converted
properly. recommit for docs. |
| 05:20.41 |
brlcad |
starseeker:
"improve path resolution logic for search paths" means
what? |
| 05:22.01 |
CIA-61 |
BRL-CAD:
03brlcad * r44781 10/brlcad/trunk/NEWS: remove items that weren't
user-visible. annotate is not yet 'published', attribute
standardization is all under the hood, libtie was already announced
in 7.18.4 |
| 05:23.18 |
CIA-61 |
BRL-CAD:
03brlcad * r44782 10/brlcad/trunk/NEWS: cliff added a -q quiet
lookup option tot he ls command so that the lookup failure message
can be suppressed (particularly important for
scripting) |
| 05:28.00 |
CIA-61 |
BRL-CAD:
03brlcad * r44783 10/brlcad/trunk/NEWS: multiple names separated by
commas for parsing, using past tense |
| 05:33.05 |
CIA-61 |
BRL-CAD:
03brlcad * r44784 10/brlcad/trunk/NEWS: |
| 05:33.05 |
CIA-61 |
BRL-CAD:
cliff and I addressed numerous stability and robustness issues in
the red |
| 05:33.05 |
CIA-61 |
BRL-CAD:
command. now should handle standard attributes more consistently,
be robust to |
| 05:33.05 |
CIA-61 |
BRL-CAD:
bogus user input, be robust to empty/null input, and correctly
preserve values |
| 05:33.06 |
CIA-61 |
BRL-CAD:
creating a copy if the name is changed. |
| 05:40.01 |
CIA-61 |
BRL-CAD:
03brlcad * r44785 10/brlcad/trunk/NEWS: (log message
trimmed) |
| 05:40.02 |
CIA-61 |
BRL-CAD:
previously undocumented keith's modification because the change
wasn't expected |
| 05:40.02 |
CIA-61 |
BRL-CAD: to
be user-visible, but it turns out it was (for pixel accurate
grazing |
| 05:40.02 |
CIA-61 |
BRL-CAD:
selection), so credit us both for changing the spatial partition
traversal |
| 05:40.02 |
CIA-61 |
BRL-CAD:
ordering. keith originally fixed a traversal 'bug' where it was
walking cut |
| 05:40.02 |
CIA-61 |
BRL-CAD:
planes something like XYXYXYXYX (missing Z). he changed it to
traverse |
| 05:40.03 |
CIA-61 |
BRL-CAD:
YZXYZXYZX, but that caused a different cell to get selected first
and |
| 05:44.07 |
CIA-61 |
BRL-CAD:
03brlcad * r44786 10/brlcad/trunk/NEWS: |
| 05:44.07 |
CIA-61 |
BRL-CAD: I
added a LIBRT_BOT_MINTIE environment variable override that lets
the user |
| 05:44.07 |
CIA-61 |
BRL-CAD:
specify at what level libtie is used to evaluate a bot. lets you
override |
| 05:44.07 |
CIA-61 |
BRL-CAD:
during database loads affecting subsequent raytrace calls (better
suited to |
| 05:44.07 |
CIA-61 |
BRL-CAD:
repeat single-ray shots ala muves). |
| 05:46.00 |
CIA-61 |
BRL-CAD:
03brlcad * r44787 10/brlcad/trunk/NEWS: cliff changed the search
output order to list shallow items prior to deeply nested
items. |
| 05:48.20 |
CIA-61 |
BRL-CAD:
03brlcad * r44788 10/brlcad/trunk/NEWS: cliff extended search's
power by adding support for '.' relative path search results where
object lists are returned instead of full paths |
| 05:52.34 |
CIA-61 |
BRL-CAD:
03brlcad * r44789 10/brlcad/trunk/NEWS: |
| 05:52.35 |
CIA-61 |
BRL-CAD: I
added a -f flag to the red command to force overwriting any
existing |
| 05:52.35 |
CIA-61 |
BRL-CAD:
combinations. if you run red, change the object name while editing,
yet that |
| 05:52.35 |
CIA-61 |
BRL-CAD: new
name already exists, it will abort. with the -f flag, it will
overwrite. |
| 05:56.21 |
CIA-61 |
BRL-CAD:
03brlcad * r44790 10/brlcad/trunk/NEWS: technically, many of our
items are verbless clauses as the action verb is implied (usually
'added'). |
| 05:58.43 |
CIA-61 |
BRL-CAD:
03brlcad * r44791 10/brlcad/trunk/src/tclscripts/ (CMakeLists.txt
Makefile.am): add the new man_browser.tcl file to the
dist |
| 06:15.46 |
CIA-61 |
BRL-CAD:
03brlcad * r44792 10/brlcad/trunk/NEWS: reword the intro
description with details about the new cmake build and additional
reasoning for the migration. |
| 07:30.11 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.24.91) |
| 07:30.11 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:08.49 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 08:08.49 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 is posted! (20110412) |
| 08:22.01 |
*** join/#brlcad milamber
(~devlin@d118-75-70-176.try.wideopenwest.com) |
| 09:17.57 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 09:17.57 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 11:37.38 |
starseeker |
brlcad: the
search path thing is the whole "make sense out of .././.././" type
paths |
| 11:38.13 |
starseeker |
there's
another new zoom bug? I thought the only zoom bug was the one
introduced by the mac keybinding change |
| 11:54.07 |
starseeker |
that report
was 7.18.4 - I think thats the mac thing |
| 11:54.28 |
starseeker |
will check later |
| 12:03.50 |
CIA-61 |
BRL-CAD:
03davidloman * r44793 10/geomcore/trunk/: Add /Debug to svn:ignore
(Build byproduct) |
| 12:06.30 |
CIA-61 |
BRL-CAD:
03davidloman * r44794 10/geomcore/trunk/src/interfaces/java/: Add
/bin to svn:ignore (Build byproduct) |
| 12:45.19 |
kunigami_ |
hi, do I
already have an SVN account for commit? If so, which is my
password? |
| 12:49.49 |
``Erik |
it's your
sourceforge account |
| 12:50.15 |
``Erik |
you should
have uploaded ssh keys |
| 12:51.28 |
kunigami_ |
hmm how do I
do that? |
| 12:53.36 |
``Erik |
log into the
web page at sourceforge, click account at the top right, click
services, click edit ssh keys |
| 12:54.29 |
``Erik |
https://sourceforge.net/apps/trac/sourceforge/wiki/Subversion
is the help page for all of that |
| 12:55.02 |
``Erik |
(might be
able to do https with your sf password, but I think ssh is the
recommended route) |
| 12:59.28 |
kunigami_ |
thank you! I
seems that there may be a delay when updating the ssh-keys. I still
don't have acess, so I'll wait a bit |
| 13:03.39 |
brlcad |
starseeker: I
must have missed that the report was for 7.18.4 |
| 13:03.55 |
brlcad |
that would be
more promising, I'll follow up |
| 13:04.23 |
brlcad |
kunigami_:
your sf.net username/password should work just fine too |
| 13:05.17 |
kunigami_ |
I'm getting
the following error: |
| 13:05.20 |
kunigami_ |
svn: Commit
blocked by pre-commit hook (exit code 1) with output: |
| 13:06.01 |
kunigami_ |
<PROTECTED> |
| 13:06.32 |
kunigami_ |
brlcad/trunk/include/osl-renderer.h :
svn:mime-type is not set |
| 13:07.09 |
``Erik |
you have to
do a propset, it should tell you exactly what to do in the error
msg |
| 13:07.39 |
kunigami_ |
oops. you're
right. sorry for that |
| 13:08.57 |
``Erik |
http://brlcad.org/wiki/Cvs2svn
has an example autoprop file to avoid that in the
future |
| 13:13.26 |
CIA-61 |
BRL-CAD:
03Paydayway 07http://brlcad.org *
r2909
10/wiki/Forex_Trading-_How_To_Understand_FOREX_Market_Sentiment:
New page: Investors can trade almost any currency in the world.
Investors, as individuals, countries, and corporations, may trade
in the forex if they have enough financial capital to get started
an... |
| 13:13.55 |
CIA-61 |
BRL-CAD:
03kunigami * r44795 10/brlcad/trunk/ (6 files in 2 dirs): This is
my first commit. It adds a ols shader as well as a osl-renderer
which by now just sets a color |
| 13:14.12 |
``Erik |
w00t,
grats |
| 13:14.27 |
kunigami_ |
yay!
cool! |
| 13:25.39 |
brlcad |
woohoo |
| 13:27.10 |
CIA-61 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/protect: protected "[[Forex Trading- How To
Understand FOREX Market Sentiment]]":
[edit=sysop:move=sysop] |
| 13:27.22 |
CIA-61 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: |
| 13:27.22 |
CIA-61 |
BRL-CAD:
deleted "[[Forex Trading- How To Understand FOREX Market
Sentiment]]": content |
| 13:27.22 |
CIA-61 |
BRL-CAD: was:
'Investors can trade almost any currency in the world. Investors,
as |
| 13:27.22 |
CIA-61 |
BRL-CAD:
individuals, countries, and corporations, may trade in the forex if
they have |
| 13:27.22 |
CIA-61 |
BRL-CAD:
enou...' (and the only contributor was |
| 13:27.22 |
CIA-61 |
BRL-CAD:
'[[Special:Contributions/Paydayway|Paydayway]]') |
| 13:27.45 |
CIA-61 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Paydayway]] with an
expiry time of infinite (account creation disabled, e-mail
blocked): Spamming links to external sites |
| 13:47.39 |
``Erik |
brlcad: is sf
backend 1.5 now? |
| 13:48.04 |
brlcad |
kunigami_:
http://brlcad.org/wiki/Mime-types |
| 13:48.27 |
brlcad |
``Erik: I
haven't migrated it, so unless they did for us, probably
not |
| 13:48.39 |
brlcad |
could be
something to work on today |
| 13:49.03 |
CIA-61 |
BRL-CAD:
03kunigami * r44796 10/brlcad/trunk/ (4 files in 2 dirs): Changed
.c to .cpp and now I'm exporting the osl-renderer functions so that
C code can call them |
| 13:54.25 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44797 10/brlcad/trunk/TODO: Remove the
LIBRT_BOT_MINTIE task. Bump bottie crash and repo backend to next
release. |
| 14:21.43 |
brlcad |
woot, another
logo submission |
| 14:35.45 |
CIA-61 |
BRL-CAD:
03brlcad * r44798 10/brlcad/trunk/NEWS: |
| 14:35.45 |
CIA-61 |
BRL-CAD: in
retrospect, my addition of the LIBRT_BOT_MINTIE variable was during
prep, |
| 14:35.45 |
CIA-61 |
BRL-CAD:
which erik replaced with override during database load, so credit
him on the |
| 14:35.45 |
CIA-61 |
BRL-CAD:
change that toggles tie BoT raytrace optimization on/off as an
environment |
| 14:35.45 |
CIA-61 |
BRL-CAD:
variable override. |
| 16:03.55 |
CIA-61 |
BRL-CAD:
03tbrowder2 * r44799 10/brlcad/trunk/NEWS: correct
spelling |
| 17:02.52 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.154.39) |
| 17:02.52 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:21.43 |
kunigami_ |
a question
regarding the macro BRLCAD_ADDLIB(libname srcs libs) |
| 17:22.25 |
kunigami_ |
when I pass
libs as "abc.dylib;def.dylib" is does not call
target_link_libraries |
| 17:23.07 |
kunigami_ |
but when I
pass libs as "abc.dylib def.dylib", that is, replacing ";" for " "
, it does call target_link_libraries |
| 17:23.55 |
kunigami_ |
that's
strange because there's a replacement: STRING(REGEX REPLACE " " ";"
libslist1 "${libs}") right on the beginning of the
macro |
| 17:33.02 |
CIA-61 |
BRL-CAD:
03tbrowder2 * r44800 10/brlcad/trunk/doc/README.Linux: correct
relative path typo for 32-bit configuration |
| 18:33.38 |
brlcad |
that wasn't a
question :) |
| 18:36.27 |
kunigami_ |
hehe, let me
complete :) Is that true or am I missing something? |
| 18:39.48 |
brlcad |
'yes' |
| 18:40.08 |
brlcad |
those aren't
mutually exclusive options ;) |
| 18:40.17 |
brlcad |
that said,
sounds like a starseeker question |
| 18:52.00 |
CIA-61 |
BRL-CAD:
03kunigami * r44801 10/brlcad/trunk/ (5 files in 2 dirs): Moved
osl-renderer.h from /include to /src/liboptical. there's no need to
such headers to be public |
| 18:55.11 |
brlcad |
~kunigami++ |
| 18:55.20 |
brlcad |
was going to
comment on that yesterday |
| 18:56.11 |
brlcad |
you should
also change the #include to be a relative path reference so it's
"private" status is clear (e.g., #include
"./osl-renderer.h") |
| 18:56.33 |
kunigami_ |
ok! |
| 18:56.57 |
brlcad |
kunigami_:
have you been able to make a (brl-cad) shader do anything
yet? |
| 18:58.15 |
kunigami_ |
I made the
polka dot shader: http://kuniga.files.wordpress.com/2021/05/goblet1.png
it's very ugly, but I think I got the idea |
| 19:30.12 |
starseeker |
``Erik: were
you refering to the kernel module loading process? (kldload and
friends?) |
| 20:10.56 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 20:10.56 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 is posted! (20110412) |
| 20:11.32 |
``Erik |
gets some popcorn |
| 20:13.04 |
starseeker |
brlcad: I
guess it comes down to what we consider immediate needs to
be |
| 20:13.15 |
brlcad |
if dynamic
loading becomes desirable, that can be added *very easily* using
any number of methods |
| 20:13.47 |
brlcad |
so what is
the immediate need? what is dynamic loading fixing? |
| 20:13.54 |
brlcad |
(again,
forget step-g for a minute) |
| 20:14.40 |
starseeker |
for me the
immediate question is "can we design an API/library that can expand
to handle arbitrary geometry files" |
| 20:15.47 |
starseeker |
step-g aside,
it's quite clear there are an awesome number of object times we
*potentially* will want/need to convert |
| 20:15.50 |
brlcad |
case in point
.. you can design an *API* to handle arbitrary geometry files with
or without dynamic |
| 20:16.07 |
starseeker |
s/times/types |
| 20:16.46 |
starseeker |
if the api
design can be considered fully independent of the implementation,
we can start with the api - I wasn't sure that was a practical
reality |
| 20:16.48 |
brlcad |
right, and if
it's going to be "arbitrary", you don't even really know what all
the types are |
| 20:17.24 |
starseeker |
right. which
is why flexible and general mechanisms for expanding what types the
library can handle are so important |
| 20:17.38 |
brlcad |
right |
| 20:17.40 |
brlcad |
but mind you,
the API is agnostic to the implementation |
| 20:18.10 |
brlcad |
the library
*architecture* is not necessarily agnostic, as that's basically the
implementation detail nuts and bolts |
| 20:18.34 |
brlcad |
but if you
don't have the API nailed down yet, you don't really have a grasp
on requirements to be designing architecture anyways |
| 20:18.51 |
brlcad |
whereas you
can easily come up with an architecture that might mess up your
API |
| 20:19.08 |
brlcad |
horse ->
cart ;) |
| 20:20.09 |
starseeker |
was worried that the issue with Factory classes and C++
(which is by no means unique to step-g) meant that a good mechanism
for generality might be problematic |
| 20:20.43 |
starseeker |
hence my
interest in learning enough about the approaches to implementing
that generality to be sure it wasn't a complete and total blind
alley |
| 20:21.13 |
brlcad |
sure, but
that's where a lil knowledge is leading to fear .. there are
hundreds of other proof-positive implementations of factories and
c++ that do this just fine |
| 20:21.33 |
brlcad |
and of
dynamic loading and of scripted loading and of network loading ....
etc |
| 20:23.00 |
starseeker |
brlcad: the
existence of the Apache mod system I guess I can accept as proof
that it can be done |
| 20:23.12 |
brlcad |
if you really
want to make it type AWARE and type extensible, that will
definitely affect the API |
| 20:23.31 |
brlcad |
just about
every single commercial game loads data modularly ;) |
| 20:23.43 |
starseeker |
uh... don't
we want it to be type aware? |
| 20:23.44 |
brlcad |
heck, even
liboptical does it .. we just don't have any |
| 20:24.15 |
brlcad |
I haven't
thought about an API too much yet (which is really what's needed
first), but my inclination would be no |
| 20:24.26 |
starseeker |
O.o |
| 20:24.31 |
brlcad |
there are too
many entity types, and there will always be some entity type you
don't recognize |
| 20:24.44 |
brlcad |
basically
akin to keeping it as a typeless system |
| 20:24.57 |
starseeker |
so we handle
the ones we do recognize, and gracefully fail on the ones we
don't |
| 20:25.02 |
brlcad |
interactors
know what they can interact with (and they are types in
themselves) |
| 20:25.29 |
brlcad |
each geometry
format module can handle the ones they recognize |
| 20:25.50 |
brlcad |
we have some
abstract way for registering annotated "data" |
| 20:27.00 |
starseeker |
I guess what
I need to do is lay out my notion of an API |
| 20:27.06 |
starseeker |
maybe that'll
clarify it for me |
| 20:27.08 |
brlcad |
yeah |
| 20:27.54 |
brlcad |
try to write
the public header, or a main() that shows how the API might be used
in simple terms |
| 20:28.18 |
starseeker |
at this point
I don't agree that it should be typeless, so I guess I need to run
head-first into why it should be |
| 20:28.26 |
brlcad |
there you
answer questions like, do you allow iterating over individual
objects |
| 20:28.28 |
starseeker |
nods - will do |
| 20:28.40 |
brlcad |
how to deal
with hierarchy information |
| 20:28.45 |
brlcad |
what to do
with metadata, etc |
| 20:29.00 |
brlcad |
"typeless" is
being used very loosely here |
| 20:29.45 |
brlcad |
typeless in
the language sense .. if it were C, there wouldn't be a sphere
struct; if c++, there would not be a sphere class .. that's what I
mean by typeless |
| 20:30.17 |
starseeker |
yeah... I'm
not seeing that, but let me play with the API thing for a day or
two and I'll see |
| 20:30.18 |
brlcad |
there'd be
some bundle data saying "I'm a sphere and I have these parameters
and these values" |
| 20:31.36 |
brlcad |
it's the
difference between librt reading objects off disk and knowing "this
is a sphere entity with some data" and having an actual
rt_ell_internal object with sphere data in it |
| 20:32.05 |
brlcad |
the latter is
going to be a veritable hell for a conversion library, and I'd
argue probably unnecessary |
| 20:32.42 |
starseeker |
well, let me
crunch on it |
| 20:32.48 |
brlcad |
it'd just
make the library way more complex when you can perform the same
work, turn that sph into a set of polygons and write out stl
*without* an rt_ell_internal in memory |
| 20:33.00 |
starseeker |
how? |
| 20:33.26 |
brlcad |
just like how
librt does it now |
| 20:34.04 |
starseeker |
uh... don't
the tessellation routines need to know the details of the
sphere? |
| 20:34.51 |
brlcad |
yep |
| 20:35.01 |
brlcad |
they don't
necessarily need an rt_ell_internal though |
| 20:36.11 |
brlcad |
data-driven
object-oriented design |
| 20:36.31 |
brlcad |
I think one
of my game programming gems has a relevant article, I'll see if I
can dig it up |
| 20:37.33 |
starseeker |
nods - that might be helpful |
| 20:37.47 |
starseeker |
I'll try and
cook up an API |
| 20:40.35 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44805 10/brlcad/trunk/ (6 files in 4 dirs):
add/use dlfcn wrapper |
| 20:43.57 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44806 10/brlcad/trunk/src/liboptical/material.c:
remove the HAVE_DLOPEN stuff, since that's handle in bu
now |
| 20:45.36 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44807 10/brlcad/trunk/src/liboptical/sh_stack.c:
more HAVE_DLOPEN removal |
| 20:48.10 |
brlcad |
starseeker:
if you haven't yet, I'd suggest looking briefly into both
liboptical and librt, how they deal with extensible
types |
| 20:49.02 |
brlcad |
not what I'd
suggest going with for gcv, but they are about as simple as it
gets, scalable to hundreds of entities, and should be understood
(how their types relate to the *API*) |
| 20:59.36 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44808 10/brlcad/trunk/src/libbu/dlfcn.c: take a
whack at porting these functions to windows |
| 21:07.32 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44809 10/brlcad/trunk/include/bu.h: add dlfcn.h
for RTLD_* |
| 21:26.21 |
starseeker |
hah, cool:
http://deviceguru.com/worlds-first-open-source-flashlight/ |
| 21:27.40 |
kunigami_ |
I'm getting
compilation error for material.c -- ‘RTLD_NOW’
undeclared. |
| 21:28.08 |
kunigami_ |
I'll check
later, but that could have been introduced by r44806 |
| 21:28.18 |
kunigami_ |
I'm off by
today |
| 21:28.23 |
``Erik |
which
os? |
| 21:28.28 |
kunigami_ |
mac
os |
| 21:28.53 |
``Erik |
that'd be the
one fixed in 44809 :) |
| 21:29.54 |
kunigami_ |
oops sorry. I
did update from src/ dir |
| 21:31.19 |
*** join/#brlcad kunigami_
(~kunigami@loco-gw.ic.unicamp.br) |
| 21:52.11 |
*** join/#brlcad crazy_imp
(~mj@a89-182-166-16.net-htp.de) |
| 21:52.46 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44810 10/brlcad/trunk/src/ (10 files in 5 dirs):
Apple includes stdbool.h in dlfcn.h, so change our various typedefs
of bool to their actual type. |
| 22:47.11 |
*** join/#brlcad DarkCalf
(DC@173.231.40.98) |
| 23:01.17 |
``Erik |
aw man, I
can't compete in the logo contest? shucks |
| 23:12.13 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44811 10/brlcad/trunk/AUTHORS: Keith and Richard
probably qualify as developers instead of contributors at this
point. |
| 23:30.52 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 00:26.19 |
*** join/#brlcad crazy_imp
(~mj@a89-182-241-223.net-htp.de) |
| 00:48.16 |
louipc |
do I count as
a dev? could I compete in the contest? hehe |
| 01:06.32 |
CIA-61 |
BRL-CAD:
03bhinesley * r44812
10/brlcad/trunk/src/tclscripts/man_browser.tcl: |
| 01:06.32 |
CIA-61 |
BRL-CAD:
Changed ManBrowser mega-widget to inherit from iwidgits::dialog. It
now creates |
| 01:06.32 |
CIA-61 |
BRL-CAD: the
window properly, activates, loads the table of contents
and |
| 01:06.32 |
CIA-61 |
BRL-CAD:
Introduction.html. Selection binding of the ToC is not working yet.
Still some |
| 01:06.33 |
CIA-61 |
BRL-CAD:
cleanup to do. |
| 02:11.29 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 02:11.39 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
| 02:35.49 |
brlcad |
``Erik: no
complaints for those two as they're "close enough" but they were
still under the measure I've used for others in the list,
fwiw |
| 02:39.26 |
brlcad |
not a hard
steadfast rule of course since it's easily fudged, but a couple
hundred "significant" commits on the core code for several months
sustained is the general rule of thumb |
| 02:40.31 |
brlcad |
course, with
those two in particular, if they were committing properly, they
probably would have hit that metric by now |
| 03:55.25 |
``Erik |
both are lean
on frequency, but indianlarry has provided significant value, and
the other needs help to grow beyond old waterfall |
| 03:55.50 |
brlcad |
certainly |
| 03:56.27 |
``Erik |
if you wanna
tweak, go for it, I just felt like those two deemed
shift |
| 03:56.40 |
brlcad |
nah, like I
said.. they're close enough to the metric I was using |
| 03:57.27 |
brlcad |
value isn't
the metric, though .. a big honkin' awesome 100k patch that makes
mged totally awesome would not make one a dev ;) |
| 03:57.36 |
``Erik |
aight, then
shove your passive aggresiveness :D |
| 03:57.39 |
brlcad |
more
sustained value .. which he has cetainly demonstrated |
| 03:57.53 |
brlcad |
isn't being passive aggressive |
| 03:58.35 |
``Erik |
both need to
be more frequent in commits, and I will continue to harangue
them |
| 03:58.45 |
brlcad |
more cautious
that we start adding borderline folks, shifting the gray area lower
and lower instead of waiting until it's a "well duh they're a
dev" |
| 03:58.53 |
brlcad |
yay |
| 03:59.26 |
``Erik |
so how's
tesa? missing the idea of sleep yet? ;) |
| 03:59.27 |
brlcad |
hey even the
latter did pretty well with that I noticed.. have a dozen or so
major commits to review in my queue |
| 04:00.02 |
brlcad |
I haven't
gotten this much sleep since .. high school |
| 04:00.47 |
``Erik |
might wanna
reconsider that answer, cuz I'll loan jill a kuhknifh to stab you
with ;> *duck* |
| 04:02.01 |
brlcad |
definitely
more interruptions, but nothing so drastic .. lots of drama queens
and kings making a big deal out of nothing :) |
| 04:02.25 |
``Erik |
aaaanyhow, as
youv'e stated, a commit is a statement that can be
argued |
| 04:02.50 |
brlcad |
yeah, it's
all good |
| 04:02.56 |
``Erik |
half
surprised you haven't chimed in on my dlfcn.c tweak |
| 04:03.12 |
brlcad |
bigger issue
is there are a few names on there now that probably don't belong
but got grandfathered in |
| 04:03.26 |
brlcad |
at least with
that same metric, but then different times too |
| 04:03.38 |
brlcad |
dlfcn looked
cool, what of it? |
| 04:05.14 |
``Erik |
given your
discussion with starseeker about dynamically loaded stuff at the
time, I imagined... constertation. It's viable given the liboptical
and librender dependancies, ... just imagined a bit of fireworks
:) |
| 04:05.15 |
brlcad |
kinda lame
failure case (i.e., print "boo hoo") but simple enough to be
portable and useful |
| 04:05.45 |
brlcad |
I don't rant
on everything you know :) |
| 04:05.48 |
brlcad |
sometimes
it's all good |
| 04:06.15 |
brlcad |
so you can't
unload a lib on windows? |
| 04:06.35 |
brlcad |
early osx
10.0 had that same fail |
| 04:06.37 |
``Erik |
usually...
figured this might stir ya up... no, could not find an unload on
winderz |
| 04:07.20 |
brlcad |
it was a
perfect refactor case to boot |
| 04:07.23 |
``Erik |
msdn's "see
also" had no unload stuff |
| 04:07.33 |
brlcad |
non-portable
code in two places, refactored to one and made portable |
| 04:07.51 |
``Erik |
more than
2 |
| 04:07.59 |
brlcad |
three? |
| 04:08.05 |
brlcad |
liboptical,
render, and ? |
| 04:08.07 |
``Erik |
4, I
think |
| 04:08.14 |
``Erik |
optical,
render, fb, fbed |
| 04:08.31 |
brlcad |
ah, wasn't
aware of the latter to (and didn't notice in the
commit) |
| 04:08.36 |
brlcad |
*two* |
| 04:08.46 |
brlcad |
that's really
stupid for fbed |
| 04:09.09 |
brlcad |
wtf is fbed
dynamically loading? |
| 04:09.21 |
``Erik |
grep
it. |
| 04:10.24 |
``Erik |
or svn
diff... you know what to do. |
| 04:11.00 |
brlcad |
I don't care
that much |
| 04:11.40 |
brlcad |
I had a mail
queue over 1000 to work through, if I spent that much time per
issue, it'd take months |
| 04:13.19 |
brlcad |
so curiousity
got me, see that it's linking -ldl, but no dl*() function being
called .. just bool issue in your commit |
| 04:14.14 |
brlcad |
er, I take it
back, not linking -ldl |
| 04:19.50 |
brlcad |
meh, doesn't
look like it's dynamically loading to me, but no matter |
| 04:40.34 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 04:40.35 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 is posted! (20110412) |
| 05:33.38 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 05:33.39 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 is posted! (20110412) |
| 07:05.43 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.241.15) |
| 07:05.43 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:23.26 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.241.15) |
| 07:23.26 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:49.11 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 09:50.08 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.241.15) |
| 09:50.08 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:12.02 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 11:32.10 |
``Erik |
brlcad:
liboptical and adrt/librender do dynamic loading, but the inclusion
of dlfcn.h pulled in stdbool on osX, which caused fbed, fb, and a
few others to flip out where we had our own bool defined, so the
change cascaded. I'm half thinking of removing dlfcn.h from bu.h,
defining our own RTLD_* variables and making a translation table in
bu_dlopen(). :/ |
| 11:40.40 |
``Erik |
vmath.h is a
link dep? I thought it was purely macro and typedef O.o |
| 11:44.54 |
``Erik |
yeh, I see no
function or global in vmath, it shouldn't be a lib dep |
| 11:46.24 |
``Erik |
ah, bunk
commit message, it's just more digits on the arse end of
M_PI |
| 11:58.07 |
dloman |
woot!!!
Powers back on :) |
| 12:58.01 |
CIA-61 |
BRL-CAD:
03brlcad * r44817 10/brlcad/trunk/src/libged/combmem.c: HINIT_ZERO
instead of VSETALLN() for simplicity |
| 13:03.11 |
CIA-61 |
BRL-CAD:
03brlcad * r44818 10/brlcad/trunk/doc/deprecation.txt: annotate the
recently obsolete items with their entity. time to consider the
vmath length constants obsolete too. |
| 13:04.22 |
CIA-61 |
BRL-CAD:
03brlcad * r44819 10/brlcad/trunk/include/vmath.h: remove
ELEMENTS_PER_PT, HVECT_LEN, and HPT_LEN in favor of their more
consistent replacements that were added deprecating these in
7.12 |
| 13:05.32 |
CIA-61 |
BRL-CAD:
03brlcad * r44820 10/brlcad/trunk/Makefile.am: one of the last
times the trailing slash issue will make an
appearance.. |
| 13:39.02 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44821 10/brlcad/trunk/TODO: multiple
configuration cmake builds seem to be ok, so strike it. Add the OSX
GL/X segfault to things to fix. |
| 13:40.20 |
CIA-61 |
BRL-CAD:
03brlcad * r44822 10/brlcad/trunk/ (14 files in 6 dirs): remove
template comments and unused doxygen file blocks |
| 13:40.24 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44823 10/brlcad/trunk/NEWS: note that cmake
files will now be included in dist. |
| 13:41.06 |
brlcad |
``Erik: yeah,
i knew about the bools in fbed and elsewhere |
| 13:41.29 |
brlcad |
they were on
my hit list to eliminate next time stomping through those
files |
| 13:42.35 |
brlcad |
when I said
non-portable code in two places, I meant non-portable dynamic
loading in two places, refactored to one |
| 13:42.42 |
brlcad |
that was the
awesome goodness |
| 13:49.53 |
``Erik |
aight, I
don't have a test case to see if my bu_dl* winderz stuff works, do
you? |
| 17:08.34 |
dloman |
Community
'paintball episode' : http://www.youtube.com/watch?v=ivLmfGK6pj4 |
| 17:08.54 |
dloman |
Community
'D&D Episode' : http://www.youtube.com/watch?v=cVanRXdlfLA |
| 17:25.30 |
``Erik |
ringworld
anim: http://www.youtube.com/watch?v=sR2296df-bc |
| 17:48.22 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.241.15) |
| 17:48.22 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:45.17 |
CIA-61 |
BRL-CAD:
03bhinesley * r44824
10/brlcad/trunk/src/tclscripts/man_browser.tcl: Fixed ManBrowser
mouse binding. The dialog itself is back to business as usual. Now,
to fix internal ToC selection (ex: set archerMan [ManBrowser
.archerMan]; archerMan configure -selection )... |
| 18:46.01 |
bhinesley |
bah... didn't
escape \$cmdName |
| 18:51.40 |
CIA-61 |
BRL-CAD:
03kunigami * r44825 10/brlcad/trunk/src/liboptical/
(osl-renderer.cpp osl-renderer.h sh_osl.c): Added support for OSL
closure color query. It's crashing though. Maybe due to a memory
leak |
| 19:10.47 |
CIA-61 |
BRL-CAD:
03bhinesley * r44826
10/brlcad/trunk/src/tclscripts/man_browser.tcl: ManBrowser internal
ToC selection is working, although a bit differently than
originally planned: [ select ls]. |
| 19:11.03 |
bhinesley |
smacks head |
| 19:11.51 |
bhinesley |
forgot to
escape again |
| 19:20.26 |
brlcad |
``Erik: I do,
but don't have a windows box to test it on ;) |
| 20:21.02 |
*** join/#brlcad mafm
(~mafm@19.Red-83-40-127.dynamicIP.rima-tde.net) |
| 20:51.39 |
CIA-61 |
BRL-CAD:
03kunigami * r44827 10/brlcad/trunk/misc/CMake/FindOSL.cmake: Just
realized that I did not added OSL finder for cmake |
| 21:03.11 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r44828 10/brlcad/trunk/misc/Makefile.am: add
FindOSL.cmake to the dist list |
| 21:21.38 |
brlcad |
kunigami_:
vmath macros ftw |
| 21:21.59 |
brlcad |
you used them
in at least one place, but there looked like other places you can
put them to use to reduce code |
| 21:23.37 |
kunigami_ |
brlcad: ok. I
was thinking to refactor the code after making it work |
| 21:26.01 |
CIA-61 |
BRL-CAD:
03kunigami * r44829 10/brlcad/trunk/misc/CMake/ (FindOIIO.cmake
FindOSL.cmake FindOpenEXR.cmake FindTBB.cmake): added three more
cmake finders. Also edited Makefile.am this time |
| 21:26.39 |
CIA-61 |
BRL-CAD:
03kunigami * r44830 10/brlcad/trunk/misc/Makefile.am: ... Also
edited Makefile.am this time |
| 21:28.42 |
CIA-61 |
BRL-CAD:
03kunigami * r44831 10/brlcad/trunk/misc/CMake/util_macros.cmake:
This was borrowed from OSL build system. TODO: merge it with BRLCAD
util |
| 21:33.38 |
brlcad |
nods |
| 21:40.18 |
CIA-61 |
BRL-CAD:
03brlcad * r44832 10/brlcad/trunk/src/liboptical/ (osl-renderer.cpp
osl-renderer.h): untested (don't have osl/oiio/boost installed),
but should work just fine to use VMOVE for Vec3's too if [] is
defined. |
| 21:41.06 |
brlcad |
that should
work, lemme know if it barks |
| 21:42.31 |
brlcad |
few other
code completeness issues, file formatting should match existing
style and structure |
| 21:43.35 |
brlcad |
if you run
sh/template.sh on all new files, it'll add the proper header and
footer to those files |
| 21:44.08 |
brlcad |
afterwards,
you should similarly be able to run sh/indent.sh and sh/ws.sh to
clean up the style |
| 21:45.45 |
brlcad |
you'll find
me harping a lot about maintaining consistent style all the time
... codebases this size require it ;) |
| 21:48.15 |
brlcad |
also, looks
like render_svc file(s) are missing |
| 21:49.55 |
CIA-61 |
BRL-CAD:
03brlcad * r44833
10/brlcad/trunk/src/liboptical/Makefile.am: |
| 21:49.56 |
CIA-61 |
BRL-CAD: any
new files have to get added to both CMakeLists.txt and Makefile.am
for the |
| 21:49.56 |
CIA-61 |
BRL-CAD: time
being while the build system is in transition. at a minimum, list
files in |
| 21:49.56 |
CIA-61 |
BRL-CAD:
EXTRA_DIST in the Makefile.am and proper logic in the cmake
build. |
| 21:51.21 |
CIA-61 |
BRL-CAD:
03brlcad * r44834 10/brlcad/trunk/src/liboptical/CMakeLists.txt:
render_svc.cpp apparently wasn't added, remove from compile
rules |
| 21:51.55 |
brlcad |
bhinesley:
question from one of the archer devs about closedb -- what happens
after the db is closed? is another temp db created? |
| 21:52.34 |
brlcad |
it's of his
opinion that it should put archer back into a state like when it
was first started with an empty unsaved db |
| 21:52.48 |
bhinesley |
that's what
happens |
| 21:52.53 |
bhinesley |
I haven't
commited that patch yet, though |
| 21:52.56 |
brlcad |
cool |
| 21:53.06 |
brlcad |
he was just
asking about it today |
| 21:53.21 |
brlcad |
hadn't looked
at the patch yet |
| 21:54.14 |
bhinesley |
I'm planning
on re-reviewing them all and committing sometime this week, if
that's alright |
| 21:57.28 |
brlcad |
sounds
perfect |
| 22:01.15 |
brlcad |
kunigami: is
there some technical reason that -Wno-error -no-pedantic were set
on the the osl render files? |
| 22:27.30 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.155.178) |
| 22:27.30 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 22:29.15 |
CIA-61 |
BRL-CAD:
03bhinesley * r44835 10/brlcad/trunk/src/tclscripts/
(archer/Archer.tcl man_browser.tcl): (log message
trimmed) |
| 22:29.15 |
CIA-61 |
BRL-CAD:
ManBrowser is now ready to be used by Archer and MGED |
| 22:29.15 |
CIA-61 |
BRL-CAD:
Added -disabledPages and -enabledPages to give more control over
which commands are displayed. |
| 22:29.15 |
CIA-61 |
BRL-CAD:
Configured constructor to call configbody's with blank args if user
didn't configure public variables, in order to trigger
defaults. |
| 22:29.16 |
CIA-61 |
BRL-CAD:
Removed \"get\" method, as it doesn't appear to be necessary the
way things are done now. |
| 22:29.16 |
CIA-61 |
BRL-CAD:
Renamed cmd/commands etc. variable name components to page/pages,
since they're not necessarily commands (ex:
Introduction.html). |
| 22:29.17 |
CIA-61 |
BRL-CAD:
Changed regex uses to \[file\] commands. |
| 22:32.37 |
bhinesley |
There is an
-enabledPages option for ManBrowser, which I'd like to populate
with a list of commands that are actually available in Archer. Is
there a preferred method of getting such a list? |
| 22:33.05 |
bhinesley |
actually,
while we're at it, I'd like to do the same thing for
MGED |
| 22:38.19 |
brlcad |
the best way
to do that consistently / maintainably is via libged |
| 22:39.07 |
brlcad |
there are
ways to get the lists via tcl for both, but it's two different ways
and would rather suck from an architecture standpoint |
| 22:39.33 |
brlcad |
libged needs
a way to keep a registry of all commands available |
| 22:40.31 |
brlcad |
have each
command register themselves, so when you query, you get the
list |
| 22:40.49 |
brlcad |
would also
let you build up built-in commands like 'help' that need access to
all commands |
| 22:41.43 |
bhinesley |
hmm |
| 22:43.13 |
bhinesley |
I'll look
into this |
| 22:44.01 |
bhinesley |
I was kinda
hoping you were going to say "Yes! Here's a variable with the exact
list you need!" |
| 22:44.08 |
bhinesley |
:-P |
| 22:46.18 |
brlcad |
haha |
| 22:47.14 |
brlcad |
it's one of
the design goals for libged anyways, so might as well work on it
now where it's needed |
| 22:47.52 |
brlcad |
it's also
critical for one of the most powerful features on our to-do list,
search -exec |
| 22:48.02 |
brlcad |
major
win |
| 22:48.44 |
bhinesley |
Sounds great.
I'm basically set for my first milestone, so I definitely have the
time. |
| 22:50.04 |
brlcad |
if you're
making progress on core dev issues like that one, then you're
golden :) |
| 22:50.53 |
brlcad |
even if you
spent all summer "getting it perfect" and the milestones went out
the window ;) |
| 22:51.19 |
bhinesley |
good to
know |
| 22:51.36 |
brlcad |
more
important that you're having fun and maintainable progress is being
made |
| 22:52.44 |
brlcad |
I can work on
stubbing out a basic plugin framework this week if that's next on
your plate unless you have some ideas on an approach as
well |
| 22:54.26 |
bhinesley |
it is, and I
don't |
| 22:56.16 |
brlcad |
the design
constraints are pretty simple, want to move towards libged being an
event-driven modular plugin system, so you'd define a command
(e.g., kill) that performs some action (e.g., validates and records
delete events); that command is registered with the library (e.g.,
adds a callback struct to a command array) |
| 22:59.10 |
brlcad |
the library
can then call into any registered command, or iterate over all
registered commands and get information (e.g., call a
ged_short_help() callback for the 'help' command) and so
on |
| 23:00.58 |
bhinesley |
much easier
to keep track of |
| 23:03.43 |
bhinesley |
"search
-exec", like unix "find -exec" I take it |
| 23:03.55 |
bhinesley |
to run
operations on the results |
| 23:05.53 |
CIA-61 |
BRL-CAD:
03brlcad * r44836 10/brlcad/trunk/include/nmg.h: fill in the
remaining available debug bits |
| 23:05.54 |
brlcad |
exactly |
| 23:06.53 |
CIA-61 |
BRL-CAD:
03Quattvendypol 07http://compilefarm.org * r2911
10/wiki/Main_Page: |
| 23:06.54 |
brlcad |
that will
likely be one of the single most powerful geometry processing
options to get added |
| 23:07.44 |
CIA-61 |
BRL-CAD:
03Sean 07http://brlcad.org * r2912
10/wiki/Main_Page: Reverted edits by
[[Special:Contributions/Quattvendypol|Quattvendypol]] ([[User
talk:Quattvendypol|Talk]]); changed back to last version by
[[User:Erik|Erik]] |
| 23:07.51 |
CIA-61 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Quattvendypol]] with an
expiry time of infinite (account creation disabled): Inserting
nonsense/gibberish into pages |
| 23:08.30 |
CIA-61 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/protect: protected "[[Main Page]]":
[edit=sysop:move=sysop] |
| 23:08.53 |
CIA-61 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/protect: changed protection level for "[[Main
Page]]": [edit=autoconfirmed:move=autoconfirmed] |
| 23:09.22 |
CIA-61 |
BRL-CAD:
03Sean 07http://brlcad.org * r2915
10/wiki/Main_Page: |
| 23:13.30 |
CIA-61 |
BRL-CAD:
03brlcad * r44837 10/brlcad/trunk/include/nmg.h: NMG_DANGLING isn't
used, but doesn't need to be commented out |
| 23:15.08 |
*** join/#brlcad mafm_
(~mafm@19.Red-83-40-127.dynamicIP.rima-tde.net) |
| 23:15.23 |
CIA-61 |
BRL-CAD:
03bhinesley * r44838
10/brlcad/trunk/src/tclscripts/man_browser.tcl: Added getBrowser
proc to make ManBrowser do the footwork |
| 23:16.50 |
CIA-61 |
BRL-CAD:
03brlcad * r44839 10/brlcad/trunk/src/burst/plot.c: would be nice
to be able to toggle the plotting |
| 23:18.11 |
CIA-61 |
BRL-CAD:
03bhinesley * r44840 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Removed buildarcherMan function and
replaced it with the instantiation of a ManBrowser mega-widget.
Removed ::man command logic that is now performed by
ManBrowser. |
| 23:21.54 |
CIA-61 |
BRL-CAD:
03brlcad * r44841 10/brlcad/trunk/include/nmg.h: er, conflicts with
raytrace.h -- prefix with NMG_ which they should probably all do
anyways |
| 23:22.55 |
CIA-61 |
BRL-CAD:
03brlcad * r44842 10/brlcad/trunk/src/conv/asc/asc2g.c: dead code
elimination. not likely support for these (old bspline geometry)
will be implemented any time soon, so remove the unused code
instead of exiting. |
| 23:34.43 |
CIA-61 |
BRL-CAD:
03brlcad * r44843 10/brlcad/trunk/ (5 files in 2 dirs): remove
cat-fb because it incurred a maintenance cost. phototypesetting
went out of style 20 years ago, obsolete hardware. |
| 23:36.34 |
CIA-61 |
BRL-CAD:
03brlcad * r44844 10/brlcad/trunk/misc/win32-msvc8/ (Makefile.am
cat2fb/): remove the msvc8 build files too |
| 23:36.49 |
brlcad |
would anyone
object if I remove the msvc build files? |
| 23:40.40 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 23:52.08 |
starseeker |
wouldn't :-P |
| 00:04.42 |
CIA-61 |
BRL-CAD:
03bhinesley * r44845
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Don't need to
keep the window name around, since ManBrowser has
getBrowser |
| 00:14.22 |
*** join/#brlcad archivist_emc
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 00:22.30 |
CIA-61 |
BRL-CAD:
03bhinesley * r44846 10/brlcad/trunk/src/tclscripts/mged/man.tcl:
Removed existing MGED man dialog code, inswitching to the
ManBrowser mega-widget. Now MGED/Archer Manual page dialogs are
identical, but ToC may vary depending on configuration. |
| 00:24.50 |
CIA-61 |
BRL-CAD:
03bhinesley * r44847 10/brlcad/trunk/NEWS: The manual page browser
behavior improvements applied to Archer are now found in MGED as
well, since they both use the same ManBrowser
mega-widget. |
| 00:26.33 |
*** join/#brlcad crazy_imp
(~mj@a89-182-190-201.net-htp.de) |
| 00:32.50 |
CIA-61 |
BRL-CAD:
03bhinesley * r44848 10/brlcad/trunk/NEWS: removed period from
sentence fragment |
| 00:56.33 |
CIA-61 |
BRL-CAD:
0399.144.90.118 07http://brlcad.org
* r2916 10/wiki/User:Bhinesley: /* Log */ Yesterday,
today |
| 01:22.10 |
starseeker |
bhinesley: I
can't run archer from build dir: |
| 01:22.21 |
starseeker |
<PROTECTED> |
| 01:22.21 |
starseeker |
can't find
package ManBrowser 1.0 |
| 01:22.21 |
starseeker |
ERROR: Unable
to load Archer |
| 02:27.30 |
*** join/#brlcad archivist_emc
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 03:00.51 |
bhinesley |
starseeker:works for me |
| 03:01.00 |
bhinesley |
anyone else
confirm this? |
| 03:01.22 |
starseeker |
bhinesley:
are you doing an out of source directory build? |
| 03:01.28 |
bhinesley |
yeah |
| 03:02.10 |
bhinesley |
you mean
running archer from the bin directory under the svn
trunk? |
| 03:02.44 |
starseeker |
yeah,
uninstalled |
| 03:03.14 |
starseeker |
not from
source dir, but from the build bin dir without anything in the
final install location |
| 03:03.18 |
bhinesley |
I've noticed
that it will use the tclscripts that are in your install directory,
rather than those in your source directory |
| 03:03.45 |
bhinesley |
but that was
true far before I made any changes |
| 03:03.52 |
starseeker |
yeah, that's
not really avoidable |
| 03:04.16 |
starseeker |
let me try
flushing out my install dir... |
| 03:04.20 |
starseeker |
rebuilds |
| 03:12.16 |
bhinesley |
I'm a bit
confused though... how would it work uninstalled, since the
tclscripts wouldn't be in the install location |
| 03:15.39 |
CIA-61 |
BRL-CAD:
03starseeker * r44849
10/brlcad/trunk/src/tclscripts/CMakeLists.txt: Add man_browser.tcl
to CMakeLists.txt |
| 03:16.08 |
starseeker |
bhinesley:
the CMake build logic goes to some trouble to re-create
(functionally, at least) the installed layout in the build
dir |
| 03:16.42 |
starseeker |
including
build and install versions of configuration files, if need
be |
| 03:17.57 |
starseeker |
that's what
all the extra foo in the BRLCAD_ADDDATA macro is about |
| 03:18.56 |
bhinesley |
okay... but
you just removed man_browser.tcl from the list of tclscripts and
added a second menu_override.tcl |
| 03:19.05 |
bhinesley |
starseeker:
what does that achieve? |
| 03:19.21 |
starseeker |
no - I added
man_browser.tcl and re-aligned menu_override.tcl |
| 03:19.36 |
starseeker |
man_browser.tcl wasn't in that list
previously |
| 03:19.47 |
bhinesley |
oops, forgot
to update |
| 03:20.05 |
bhinesley |
well
menu_override is in there twice |
| 03:20.34 |
starseeker |
ah,
whoops |
| 03:21.00 |
CIA-61 |
BRL-CAD:
03starseeker * r44850
10/brlcad/trunk/src/tclscripts/CMakeLists.txt: only need
menu_override.tcl once |
| 03:21.14 |
starseeker |
there we
go |
| 03:21.33 |
bhinesley |
does it work
as expected now? |
| 03:21.36 |
starseeker |
yep |
| 03:21.40 |
starseeker |
nice
:-) |
| 03:21.47 |
bhinesley |
cool |
| 03:21.53 |
bhinesley |
you live you
learn |
| 03:22.25 |
starseeker |
no problem -
that's something of a custom feature of our build system, not a
"normal" CMake setup |
| 03:22.31 |
starseeker |
easy
fix |
| 03:23.08 |
starseeker |
really needs to properly document this thing in a
writeup... |
| 03:23.24 |
starseeker |
right after
all my other problems go away (sigh) |
| 03:23.28 |
bhinesley |
haha |
| 03:23.54 |
bhinesley |
so if I add a
file, as far as building goes, is that the only place I need to add
it? |
| 03:24.06 |
starseeker |
for a
tclscript? yeah. |
| 03:24.19 |
bhinesley |
yes, that's
all I meant |
| 03:24.22 |
starseeker |
or in the
CMakeLists.txt file in the appropriate subdirectory |
| 03:24.36 |
bhinesley |
nods |
| 03:25.05 |
bhinesley |
what time is
it for you? |
| 03:25.07 |
starseeker |
technically
we should probably add 'em to the Makefile.am lists, at least until
we finally remove the old logic |
| 03:25.15 |
starseeker |
closing in on
11pm |
| 03:25.55 |
starseeker |
I lied -
closing in on 11:30pm |
| 03:26.01 |
bhinesley |
ah okay... I
wasn't sure if you were a night owl or an early riser
:) |
| 03:26.21 |
starseeker |
night owl by
inclination - occasional early riser by necessity |
| 03:26.45 |
bhinesley |
yeah, me
too |
| 03:27.48 |
bhinesley |
but not
tonight ;-) see you later |
| 03:29.05 |
starseeker |
later |
| 03:38.51 |
CIA-61 |
BRL-CAD:
03brlcad * r44851 10/brlcad/trunk/src/mged/points/main.c: let both
of them work together, wrap in COMPILE_STANDALONE instead of
ambiguous if 0 |
| 03:39.46 |
CIA-61 |
BRL-CAD:
03brlcad * r44852 10/brlcad/trunk/src/mged/points/process.c: key
off PRINT_DEBUG instead of 0 |
| 03:52.20 |
brlcad |
bhinesley:
er, and (for the time being) also add new files into the
Makefile.am .. parallel build systems until deprecation process is
completed |
| 03:53.33 |
brlcad |
(which you
did, I believe) |
| 03:56.44 |
CIA-61 |
BRL-CAD:
03brlcad * r44853 10/brlcad/trunk/src/mged/points/process.c: quell
warning, PRINT_ARRAY, not PRINT_DEBUG |
| 04:03.11 |
CIA-61 |
BRL-CAD:
03brlcad * r44854 10/brlcad/trunk/NEWS: |
| 04:03.11 |
CIA-61 |
BRL-CAD: the
commit message must be reiterated when lines are edited so that
our |
| 04:03.11 |
CIA-61 |
BRL-CAD:
auto-processing of this file will pick up the right (last) comment
in reports. |
| 04:03.11 |
CIA-61 |
BRL-CAD: erik
and I added a handful of new cmake build files that were missing
from the |
| 04:03.12 |
CIA-61 |
BRL-CAD:
source dist. |
| 04:07.56 |
brlcad |
bhinesley:
NICE |
| 04:08.03 |
brlcad |
the browser
looks fantastic |
| 04:08.24 |
brlcad |
like the
bindings |
| 04:17.16 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 04:19.36 |
brlcad |
starseeker:
am I correct recalling that the cmake build does not produce a
unified brlcad lib (brlcad.dll, libbrlcad.so, etc) |
| 04:19.59 |
brlcad |
because
everything would need to compile multiple times |
| 04:49.23 |
CIA-61 |
BRL-CAD:
03brlcad * r44855 10/brlcad/trunk/ (91 files in 34
dirs): |
| 04:49.24 |
CIA-61 |
BRL-CAD: A
Big Code Deadness Elimination Fest, G. Huzzah... Remove code that
is #if 0'd |
| 04:49.24 |
CIA-61 |
BRL-CAD: out
unless there's a comment or some other strong evidence that the
code really |
| 04:49.24 |
CIA-61 |
BRL-CAD:
needs to hang around because it's useful, is part of a recent work
in progress |
| 04:49.24 |
CIA-61 |
BRL-CAD:
(still should document why it's if 0'd), or is code that is
clearly |
| 04:49.24 |
CIA-61 |
BRL-CAD:
demonstrating some useful purpose (beyond "this 'might' be useful
some day"). |
| 04:49.25 |
CIA-61 |
BRL-CAD:
Reduction of 2680 lines. |
| 05:05.40 |
CIA-61 |
BRL-CAD:
03brlcad * r44856 10/brlcad/trunk/doc/deprecation.txt: changes to
the spm interface in libbn (to include bn prefix) are minimally
impacting changes) |
| 05:08.44 |
CIA-61 |
BRL-CAD:
03brlcad * r44857 10/brlcad/trunk/doc/deprecation.txt: two more spm
macro types getting updated |
| 05:36.03 |
CIA-61 |
BRL-CAD:
03brlcad * r44858 10/brlcad/trunk/ (8 files in 6 dirs): |
| 05:36.03 |
CIA-61 |
BRL-CAD: spm
functions, types, and macro symbols get the bn prefix added. this
makes the |
| 05:36.03 |
CIA-61 |
BRL-CAD: bn
api more self-consistent and easier to identify origination.
fortunately, |
| 05:36.03 |
CIA-61 |
BRL-CAD:
minimally impacting too, so just update symbol names
accordingly. |
| 06:21.57 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 06:45.50 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.241.15) |
| 06:45.50 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:30.33 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.241.15) |
| 07:30.33 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:26.51 |
*** join/#brlcad mafm_
(~mafm@155.Red-83-40-127.dynamicIP.rima-tde.net) |
| 08:54.51 |
CIA-61 |
BRL-CAD:
03d_rossberg * r44859 10/brlcad/trunk/src/libbu/dlfcn.c: made it
compile with MSVC |
| 10:05.23 |
starseeker |
brlcad:
correct |
| 10:44.35 |
kunigami |
brlcad: they
were there because I wanted to remove warning flags that were
causing compilation errors due to osl headers. I'm now turning them
off through cmake parameters. I'll remove them. |
| 11:09.23 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 11:09.36 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 11:30.13 |
CIA-61 |
BRL-CAD:
03kunigami * r44860 10/brlcad/trunk/misc/CMake/FindOSL.cmake:
Changed FindOSL so that it searches osl libraries from the OSLHOME
environment variable (the path was hard-coded before) |
| 11:33.44 |
CIA-61 |
BRL-CAD:
03kunigami * r44861 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt
osl-renderer.cpp): removed unused cpp flags |
| 11:34.35 |
CIA-61 |
BRL-CAD:
03davidloman * r44862
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java:
Added some documentation and a try/catch to catch the thrown
exceptions. |
| 11:47.26 |
brlcad |
kunigami: so
warnings are disabled or enabled? we should default to fully
enabled and accommodate quelling the warnings if at all
possible |
| 11:47.47 |
brlcad |
strict
compilation is the golden standard |
| 11:48.49 |
brlcad |
with a couple
auto-generated code (lex/yacc) exceptions where we can't fix them,
the entire source code has been made compliant for improved
portability, maintainability, security, consistency,
etc |
| 11:49.40 |
brlcad |
also, doesn't
that memset() defeat the VMOVE's that immediately preceede
it? |
| 12:03.48 |
CIA-61 |
BRL-CAD:
03davidloman * r44863
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NetMsgChangeTracker.java:
Implement a simple change tracker class with pooling. |
| 12:05.07 |
CIA-61 |
BRL-CAD:
03davidloman * r44864
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferUtils.java:
Move ByteBuffer resize functions into ByteBufferUtils |
| 12:08.28 |
CIA-61 |
BRL-CAD:
03davidloman * r44865
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/utils/:
Add a utils package |
| 12:13.11 |
CIA-61 |
BRL-CAD:
03kunigami * r44866 10/brlcad/trunk/src/liboptical/ (render_svc.cpp
render_svc.h): missing files for osl-renderer to
compile |
| 12:30.28 |
kunigami |
brlcad: I
can't compile OSL code if I do not use
-DBRLCAD-ENABLE_COMPILER_WARNINGS=OFF and
-DBRLCAD-ENABLE_STRICT=OFF |
| 12:30.41 |
kunigami |
I mean
link |
| 12:31.52 |
CIA-61 |
BRL-CAD:
03brlcad * r44867 10/brlcad/trunk/src/librt/ (librt_private.h
primitives/ell/ell.c primitives/epa/epa.c): consolidate and move
rt_ell_ang() from epa.c to ell.c since it's used by ehy, epa, and
hyp. Add to librt_private.h since it's private reuse
API. |
| 12:31.56 |
CIA-61 |
BRL-CAD:
03kunigami * r44868 10/brlcad/trunk/misc/CMake/FindOSL.cmake:
Modified FindOSL so that it can find the libraries on linux
too |
| 12:34.23 |
CIA-61 |
BRL-CAD:
03brlcad * r44869 10/brlcad/trunk/src/librt/primitives/ (ehy/ehy.c
hyp/hyp.c): no longer need the forward decls for rt_ell_ang() since
it's in librt_private.h |
| 12:34.43 |
kunigami |
brlcad:
thanks for spotting that! I'll fix it |
| 12:35.07 |
brlcad |
kunigami:
sure, but what are the warnings |
| 12:35.16 |
brlcad |
it *should*
stop the build |
| 12:35.34 |
brlcad |
until the
source code issues get fixed or accommodated |
| 12:35.43 |
brlcad |
that's part
of the strictness |
| 12:36.09 |
brlcad |
so the
question isn't whether it works or not, it's what's the
warning? |
| 12:36.50 |
kunigami |
ok. I'll run
it again to get these warnings |
| 12:36.57 |
brlcad |
if that can
be dealt with (in any fashion) without disabling warnings, then we
should if only so that we can compile OUR code with strict
reporting |
| 12:37.32 |
brlcad |
i.e., the
code in if_osl.c and osl_renderer.cpp should be strict
compliant |
| 12:37.57 |
brlcad |
it's possible
that the warnings can't be squashed, but we should try |
| 12:39.56 |
brlcad |
also, if
you're going to readd new files, make sure you update Makefile.am
and CMakeLists.txt so the build isn't broken in the interim
:) |
| 12:40.25 |
brlcad |
trying not to
call out too much at once, hopefully not overwhelming -- one bit at
a time... :) |
| 12:42.33 |
kunigami |
I always
forget to update Makefile.am! On cmake files I'm trying to maintain
them inside ENABLE_OSL code, so that normal builds will keep
compiling |
| 12:43.08 |
CIA-61 |
BRL-CAD:
03brlcad * r44870 10/brlcad/trunk/src/librt/ (5 files in 5 dirs):
rename rt_ell_ang() to ell_angle(). it's not public librt API, so
it shouldn't have the rt_ prefix. ell_ prefix is appropriate living
in ell.c and given what it does. |
| 12:43.58 |
brlcad |
yeah, I saw
that |
| 12:44.14 |
brlcad |
for
Makefile.am, you can keep it simple |
| 12:44.50 |
brlcad |
since they
have all those extra deps and build logic needed, your stuff can
just get added to EXTRA_DIST so it's at least in the source
tarball |
| 12:45.18 |
kunigami |
ok! |
| 12:45.22 |
brlcad |
would be a
waste of time to add duplicate build logic to both now that the
autotools one is deprecated |
| 12:46.24 |
kunigami |
wouldn't be
better to add those files to Makefile.am only after they are
functional? |
| 12:49.07 |
brlcad |
nope |
| 12:49.35 |
brlcad |
it will
actually halt our ability to make a release |
| 12:50.28 |
brlcad |
there's a
validation check to make sure any file available on checkout is in
a source tarball |
| 12:50.52 |
kunigami |
ok |
| 12:50.53 |
brlcad |
so all files
have to get listed at least as EXTRA_DIST |
| 12:51.08 |
brlcad |
it won't
attempt to compile them as EXTRA_DIST, just adds them to the source
tarball |
| 12:51.38 |
brlcad |
that was a
source tarball can still be prepared with autotools, but you'd have
to compile with cmake to get the osl shader |
| 12:51.54 |
brlcad |
which is all
good, cmake will be prime within 3 months |
| 12:52.12 |
kunigami |
perfect |
| 12:55.29 |
CIA-61 |
BRL-CAD:
03kunigami * r44871 10/brlcad/trunk/src/liboptical/ (Makefile.am
osl-renderer.cpp): including added files on EXTRA-DIST |
| 12:55.30 |
``Erik |
*readreadread* yeh, I was thinking
EXTRA_DIST |
| 12:55.41 |
``Erik |
hopefully,
cmake will be primary in 3 weeks. |
| 12:58.14 |
kunigami |
the file in
src/other/iwidgets/pkgIndex.tcl seems to be written on building and
is versioned |
| 12:59.52 |
kunigami |
oh I'm
confused. I'm able to compile even with strict flags on >.<
I'll check if it was not a cache issue |
| 13:01.31 |
``Erik |
brlcad: the
compile fails he was getting were with the fruity osl headers, it's
legit |
| 13:02.05 |
``Erik |
(or, the ones
he reported a few days back were osl headers, ... I'll shut up and
let it unfold here :) ) |
| 13:02.19 |
kunigami |
haha
:) |
| 13:04.08 |
``Erik |
starseeker:
I'm getting bad memory assertions on winderz from btclsh... I'm not
in today, but if you want to borrow my winderz pooter to look into
it, be my guest. it's stopping the ampi stuff from doing it's
thing. (and I have the spare key, had it on the dash of my truck
when I turned around and went home this morning. if I don't see you
tomorrow, I'll either leave it on my desk or stop by your place
over the weekend) |
| 13:04.35 |
starseeker |
cool,
thanks |
| 13:05.33 |
starseeker |
growl...
Windows Strikes Again... |
| 13:05.39 |
``Erik |
(and one of
these days, I'll take ya guys to dinner as a danke) |
| 13:05.58 |
starseeker |
``Erik: no
worries - I owe Bob at least a steak... |
| 13:06.37 |
starseeker |
kunigami: you
might try mentioning OSL header issues to the OSL devs |
| 13:07.03 |
``Erik |
yeah, I
should probably give bob a bottle of 1800 or something for the
tree |
| 13:07.23 |
``Erik |
get him
spoiled on 'good' stuff :> |
| 13:07.32 |
starseeker |
heh |
| 13:07.46 |
kunigami |
starseeker:
ok |
| 13:07.50 |
``Erik |
mebbe cabo
wabo |
| 13:08.28 |
brlcad |
I don't doubt
they were legit, it's whether they can be squashed on our end or
not, like we do for other headers that have issues |
| 13:09.43 |
kunigami |
ouch I just
ran cmake inside brlcad source directory and made a mess. Any
easier way to cleanup that instead of a clean checking
out? |
| 13:09.46 |
``Erik |
I still need
to look up details on the tnt/jama ... thing. external headers can
be a bear :) |
| 13:10.15 |
``Erik |
rm -rf
CMakeCache.txt CMakeFiles ; find . -name Makefile -or -name
CMakeFiles | xargs rm -rf |
| 13:10.23 |
brlcad |
kunigami: if
you ever want to verify the autotools build in addition to the
cmake build, this should do it: sh autogen.sh &&
./configure --enable-all --enable-warnings --without-ogl &&
make distcheck |
| 13:10.26 |
``Erik |
I think
that'll clobber it well |
| 13:10.55 |
brlcad |
tnt/jama we
can fix :) |
| 13:11.28 |
brlcad |
they're
warnings were trivial, but easy edits |
| 13:11.41 |
``Erik |
"best
practice" is to build out of srcdir... mkdir -p build/auto
build/cmake ; (cd build/cmake && cmake ../.. &&
make) ; sh autogen.sh && (cd build/auto &&
../../configure && make) |
| 13:12.12 |
brlcad |
though in-dir
should work too .. just gets messy |
| 13:13.15 |
``Erik |
if ya make a
mess using out of dir, rm -rf is an easy cleanup :) indir is the
trivial case, so of course it should work |
| 13:13.46 |
kunigami |
I always use
a build directory with cmake ../brlcad but if I'm on blcar
directory, ../brlcad goes to the source directory. Maybe I should
change brlcad-build level :) |
| 13:17.00 |
``Erik |
brlcad: what
do you think of a toplevel "models" repo? is MoRe a flop? I think
I've been volunteered for a small construction project and want to
crank a model for verification and materials list... (toddler
sandbox) |
| 13:31.19 |
*** join/#brlcad kunigami_
(~kunigami@loco-gw.ic.unicamp.br) |
| 13:31.56 |
kunigami_ |
Here's the
error when compiling with strict: http://pastebin.mozilla.org/1246222 |
| 13:32.37 |
kunigami_ |
note that
most of the errors come from two files I copied from OSL. There's
one at oslclosure that is from the library itself |
| 14:19.17 |
brlcad |
likes to use .build dirs, old gen.sh
legacy |
| 14:19.58 |
brlcad |
more
consistent for NFS mounted filesystems too where you have multiple
binary builds simultaneously |
| 14:22.58 |
brlcad |
kunigami: all
except the one in oslclosure.h are fixable since they're in our
source tree |
| 14:23.09 |
brlcad |
and since
it's just an extraneous ';', it's worth an edit on oslclosure.h too
so strict can remain enabled |
| 14:24.37 |
brlcad |
worth a patch
to the osl dev, since it's probably just something
overlooked |
| 14:37.20 |
CIA-61 |
BRL-CAD:
03d_rossberg * r44872 10/brlcad/trunk/src/ (libbn/CMakeLists.txt
libbu/CMakeLists.txt): removed a flag that is set in the
BRLCAD_ADDLIB macro anyway |
| 14:41.55 |
CIA-61 |
BRL-CAD:
03d_rossberg * r44873
10/brlcad/trunk/src/other/libz/CMakeLists.txt: now there will be
build a static zlib library too if the BUILD_STATIC_LIBS flag is
set |
| 14:45.40 |
kunigami |
brlcad:
ok! |
| 14:50.00 |
``Erik |
huh, jra
called |
| 15:46.08 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.136.249) |
| 15:46.08 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 15:53.50 |
dloman |
jra? Where
is he now... Florida? |
| 16:15.57 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.143.183) |
| 16:15.57 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:23.48 |
CIA-61 |
BRL-CAD:
03kunigami * r44874 10/brlcad/trunk/src/liboptical/CMakeLists.txt:
Modified CMakeLists. Libraries paths are not hard-coded
anymore |
| 17:18.34 |
``Erik |
he's still
local, he has grandkids in the area |
| 17:18.52 |
``Erik |
he noted your
abdication, dlo |
| 18:24.21 |
*** join/#brlcad mafm_
(~mafm@155.Red-83-40-127.dynamicIP.rima-tde.net) |
| 18:34.00 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 21:43.25 |
dloman |
brlcad: was
in your neighborhood today and saw this: http://i56.tinypic.com/2e0iog0.png
and figured I'd let you know that a cop might stop you since the
car seat isn't facing backwards. Just a heads up. |
| 21:44.41 |
dloman |
=D |
| 21:57.35 |
CIA-61 |
BRL-CAD:
03bhinesley * r44875
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: ManBrowser window
naming collision is no longer a factor; renamed window. |
| 23:26.14 |
*** join/#brlcad mafm
(~mafm@155.Red-83-40-127.dynamicIP.rima-tde.net) |
| 00:26.47 |
*** join/#brlcad crazy_imp
(~mj@a89-182-155-87.net-htp.de) |
| 01:27.36 |
bhinesley |
I'm getting a
compile error with cmake: http://pastebin.mozilla.org/1246735 |
| 01:27.46 |
bhinesley |
glu.h doesn't
exist |
| 01:40.13 |
bhinesley |
I disabled
GL, and was able to compile. |
| 02:08.05 |
bhinesley |
disregard...
I cleaned the build directory and it's working with GL enabled now,
too. |
| 02:17.02 |
CIA-61 |
BRL-CAD:
03bhinesley * r44876 10/brlcad/trunk/src/proc-db/sketch.c: Applied
patch 3247828, submitted by myself. Fixed sketch usage statment so
that it isn't always printed, and clarified the output when an
argument is mistakenly provided |
| 02:40.11 |
brlcad |
dloman:
hehe |
| 02:40.16 |
brlcad |
where'd that
pic come from? |
| 02:43.49 |
CIA-61 |
BRL-CAD:
03bhinesley * r44877
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: |
| 02:43.49 |
CIA-61 |
BRL-CAD:
Applied patch 3309910, submitted by myself. It makes Archer's
opendb command |
| 02:43.49 |
CIA-61 |
BRL-CAD:
behave like more mged when no arguments are supplied. It prints the
database |
| 02:43.49 |
CIA-61 |
BRL-CAD: name
if it is in memory only, or it prints the path to and name of the
database |
| 02:43.49 |
CIA-61 |
BRL-CAD: if
it is saved on disk. |
| 02:50.03 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 02:50.09 |
CIA-61 |
BRL-CAD:
03bhinesley * r44878
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Applied patch
3309107, submitted by myself. It adds a closedb command to Archer,
which simply loads an empty database in memory, like when Archer is
first started. |
| 02:57.57 |
CIA-61 |
BRL-CAD:
03bhinesley * r44879
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Applied patch
3267991, submitted by myself. The commands 'q' and 'exit' are
already available in Archer; this adds the 'quit'
synonym. |
| 02:59.20 |
CIA-61 |
BRL-CAD:
03brlcad * r44880 10/brlcad/trunk/NEWS: bhinesley made Archer's
opendb command behave like mged when no arguments are supplied. It
prints the name if the database is in memory only, or it prints the
absolute path if the database is saved on disk. |
| 03:00.28 |
CIA-61 |
BRL-CAD:
03brlcad * r44881 10/brlcad/trunk/BUGS: opening a database with the
same name as a command (in archer) reportedly (by bhinesley)
doesn't work |
| 03:01.33 |
CIA-61 |
BRL-CAD:
03brlcad * r44882 10/brlcad/trunk/NEWS: bhinesley added the missing
closedb command to archer as well, calls Load '' which closes the
current database and opens an empty one like when archer first
starts up. |
| 03:17.46 |
CIA-61 |
BRL-CAD:
0399.144.90.118 07http://brlcad.org
* r2917 10/wiki/User:Bhinesley: /* Log */ today, and plan
tomorrow |
| 03:33.51 |
*** part/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 06:52.01 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.241.15) |
| 06:52.01 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:17.03 |
*** join/#brlcad mafm
(~mafm@183.Red-81-32-97.dynamicIP.rima-tde.net) |
| 09:29.44 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 09:29.44 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:00.55 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 15:00.55 |
*** join/#brlcad mafm
(~mafm@183.Red-81-32-97.dynamicIP.rima-tde.net) |
| 15:25.00 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.247.68) |
| 15:25.00 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:09.35 |
brlcad |
mm, some nice
features coming in the subversion 1.7 update |
| 16:23.32 |
CIA-61 |
BRL-CAD:
03brlcad * r44883 10/brlcad/trunk/ (42 files in 25 dirs): convert
about 180 calls to NEAR_ZERO() to NEAR_EQUAL() where the intent
seems (via the a - b = 0 trick) to be comparing for equality.
improves readability. |
| 16:24.07 |
starseeker |
brlcad: are
they close to releasing 1.7? |
| 16:28.02 |
CIA-61 |
BRL-CAD:
03brlcad * r44884 10/brlcad/trunk/doc/deprecation.txt: BU_EXTERN
and BU_ARGS are pre-c89 accommodations, no longer needed and
minimally impacting to remove them |
| 16:42.18 |
CIA-61 |
BRL-CAD:
03brlcad * r44885 10/brlcad/trunk/doc/deprecation.txt: BU_EXTERN()
is a macro and a bit more tricky to isolate properly, but still
minimally impacting. |
| 16:48.39 |
CIA-61 |
BRL-CAD:
03starseeker * r44886
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Archer's use
of the search command needed updating after the syntax change -
fixed highlighting of related items in Archer. |
| 16:51.35 |
CIA-61 |
BRL-CAD:
03starseeker * r44887 10/brlcad/trunk/NEWS: |
| 16:51.36 |
CIA-61 |
BRL-CAD:
Archer's tree widget can optionally highlight combinations that
would be |
| 16:51.36 |
CIA-61 |
BRL-CAD:
impacted by the editing of the currently selected component - that
feature |
| 16:51.36 |
CIA-61 |
BRL-CAD:
relied on search, and the syntax change threw it off. Fixed syntax,
behavior |
| 16:51.36 |
CIA-61 |
BRL-CAD:
restored. |
| 17:09.15 |
CIA-61 |
BRL-CAD:
03brlcad * r44888 10/brlcad/trunk/doc/deprecation.txt: have been
using emacs syntax to date, but change over to perl syntax so we
can easily show users how to apply a minimally impacting regex to
their file(s) |
| 17:15.27 |
CIA-61 |
BRL-CAD:
03brlcad * r44889 10/brlcad/trunk/doc/deprecation.txt: untested,
but this should swap them from emacs regexp quoting to perl
quoting |
| 17:17.17 |
CIA-61 |
BRL-CAD:
03brlcad * r44890 10/brlcad/trunk/doc/deprecation.txt: meant slurp
mode, not code 7 |
| 17:34.49 |
*** join/#brlcad mafm
(~mafm@193.153.199.74) |
| 17:44.24 |
bhinesley |
starseeker:
You said that it's possible to run Archer from the build directory
uninstalled... but it's still using the installed tcl scripts for
me. What's the trick? |
| 17:45.04 |
bhinesley |
I did a cmake
build out of the source directory |
| 17:46.26 |
bhinesley |
*outside
of |
| 17:50.36 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 17:50.36 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:15.58 |
starseeker |
bhinesley: if
you have an installed BRL-CAD in the same directory as your
CMAKE_INSTALL_PREFIX, BRL-CAD will look there first for
dat |
| 18:16.01 |
starseeker |
data
even |
| 18:16.16 |
bhinesley |
oh, alright
:) |
| 18:16.37 |
starseeker |
you can
either a) re-build BRL-CAD with CMAKE_INSTALL_PREFIX set to a
directory where there is no BRL-CAD or b) remove the installed
version |
| 18:16.46 |
starseeker |
I get bit by
that once in a while too |
| 18:17.18 |
``Erik |
starseeker:
"Consider a Spherical Cow: A Course in Environmental Problem
Solving" by John Harte ( http://en.wikipedia.org/wiki/Spherical_cow
) |
| 18:17.19 |
bhinesley |
anything to
save time testing |
| 18:17.20 |
starseeker |
usually what
I'll do is pass -DCMAKE_BUILD_TYPE=Debug - that sets the install
directory to ../brlcad-install relative to the build directory
(IIRC) |
| 18:17.31 |
starseeker |
``Erik: heh,
yep :-) |
| 18:18.00 |
starseeker |
bhinesley:
then, as long as you don't have the brlcad-install actually
installed, you can run successfully from the build
directory |
| 18:18.13 |
starseeker |
or
brlcad-install actually populated rather |
| 18:18.39 |
bhinesley |
alright, I'll
give that a go |
| 18:18.40 |
``Erik |
"wanted dead
or alive: schrödinger's cat" |
| 18:19.00 |
starseeker |
<snort>
I think that's wanted dead AND alive :-O |
| 18:19.12 |
starseeker |
:-P |
| 18:19.37 |
``Erik |
"a seminar on
time travel will be held two weeks ago" |
| 18:19.45 |
``Erik |
there's
pretty corny :D |
| 18:20.04 |
starseeker |
sooo... you
found the bottom of the internet? :-P |
| 18:20.20 |
``Erik |
it's not as
bad as /b/ |
| 18:23.11 |
*** join/#brlcad athena0
(~ed@ppp-70-226-169-88.dsl.mdsnwi.ameritech.net) |
| 18:26.48 |
starseeker |
hmm - an
auction company in Dallas, TX called Heritage Auctions is selling
dinosaur skeletons |
| 18:27.00 |
starseeker |
just the
thing to put up in the living room :-P |
| 18:27.29 |
starseeker |
(talk about
an efficient way to scare little kids...) |
| 18:29.36 |
bhinesley |
psh... not my
kids. They'd be all over it. |
| 18:36.29 |
athena0 |
I'm having a
brain-fart... brlcad is complaining about a missing library before
compile, and I can't seem to resolve it. |
| 18:36.46 |
athena0 |
$ grep "Xi
library" config.log |
| 18:36.53 |
athena0 |
configure:28705: WARNING: X11 support is
enabled but the Xi library was not found. |
| 18:37.00 |
bhinesley |
mesagl, I
believe |
| 18:37.09 |
bhinesley |
hold
on |
| 18:37.16 |
athena0 |
$ sudo
aptitude search libxi | grep "X11 Input" |
| 18:37.21 |
athena0 |
i libxi-dev
- X11 Input extension library (development
h |
| 18:37.30 |
athena0 |
i libxi6
- X11 Input extension library
|
| 18:37.38 |
athena0 |
p
libxi6-dbg - X11 Input extension library
(debug package |
| 18:38.11 |
athena0 |
Have I
forgotten something obvious here? |
| 18:42.47 |
*** join/#brlcad EricZZZ
(~EricZZZ@ppp-70-226-169-88.dsl.mdsnwi.ameritech.net) |
| 18:44.17 |
bhinesley |
athena0: I'm
pretty sure there is a mesa library missing, but I'm having trouble
proving that. |
| 18:44.29 |
bhinesley |
I've had that
warning before |
| 18:46.22 |
athena0 |
I don't
suppose there'd be any harm in just installing xlibmesa-gl and
xlibmesa-gl-dev and giving it another shot |
| 18:46.36 |
bhinesley |
nods |
| 18:46.39 |
bhinesley |
sorry I can't
say for sure |
| 18:52.45 |
*** part/#brlcad bhinesley
(~bhinesley@99.144.90.118) |
| 18:52.51 |
*** join/#brlcad bhinesley
(~bhinesley@99.144.90.118) |
| 18:53.55 |
athena0 |
Arg. No
dice. Still complaining about Xi library not found |
| 18:54.12 |
bhinesley |
athena0:
Yeah, I see it now. The message is coming from
configure.ac:1220 |
| 18:54.18 |
bhinesley |
libxi,
allegedly |
| 18:55.00 |
bhinesley |
so maybe you
need to do a "make clean" or something |
| 18:56.10 |
athena0 |
Worth a shot.
... |
| 18:57.23 |
athena0 |
No, still
complaining during ./configure after a make clean |
| 18:57.37 |
bhinesley |
:-/ |
| 18:58.33 |
athena0 |
My system
seems pretty convinced it's got the libxi packages. Any chance
it's just hid them away in some strange directory structure? Maybe
this could be solved with a well-placed "ln -s" |
| 19:01.36 |
bhinesley |
do a `sudo
updatdb && locate libXi.so` |
| 19:01.45 |
bhinesley |
mine are in
/usr/lib and /usr/lib64 |
| 19:03.39 |
CIA-61 |
BRL-CAD:
03kunigami * r44891 10/brlcad/trunk/src/liboptical/ (5 files):
Discovered that OSLRender only leaks memory if called by sh_osl.
I've copied the osl raytracer into osl_rt in such a way that it
calls OSLRender class. Valgrind did not identified the memory leaks
present in the rt run |
| 19:03.54 |
athena0 |
$ sudo
updatedb && locate libXi.so |
| 19:04.16 |
athena0 |
<PROTECTED> |
| 19:04.21 |
athena0 |
<PROTECTED> |
| 19:04.27 |
athena0 |
<PROTECTED> |
| 19:13.14 |
bhinesley |
athena0: do
you have libx11-dev installed? |
| 19:16.07 |
athena0 |
Yep.
|
| 19:16.08 |
athena0 |
$ sudo
updatedb && locate libx11-dev |
| 19:16.12 |
athena0 |
<PROTECTED> |
| 19:16.49 |
athena0 |
(output
truncated ...) |
| 19:17.03 |
bhinesley |
yeah, I
believe ya |
| 19:19.41 |
athena0 |
Would it be
possible for the .deb file available for download to work on my
machine when the source doesn't look like it's going to
compile? |
| 19:20.08 |
bhinesley |
yeah |
| 19:20.24 |
athena0 |
ah. Then I'm
gonna give that a shot. |
| 19:21.01 |
bhinesley |
good idea
:) |
| 19:44.22 |
CIA-61 |
BRL-CAD:
03bhinesley * r44892 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl CombEditFrame.tcl): |
| 19:44.22 |
CIA-61 |
BRL-CAD:
Adding '-sorted' to lsearch's in few places where it's clear that
the given list |
| 19:44.22 |
CIA-61 |
BRL-CAD: was
A) sorted '-increasing' B) sorted as ASCII text C) was not modified
before |
| 19:44.22 |
CIA-61 |
BRL-CAD: the
search D) not sorted with any of '-all'/'-not'/'-glob'/'-regexp'.
This |
| 19:44.22 |
CIA-61 |
BRL-CAD:
option results in increased performance, since it forces lsearch to
do a binary |
| 19:44.22 |
CIA-61 |
BRL-CAD:
search, rather than the default linear search. |
| 19:44.23 |
CIA-61 |
BRL-CAD: Of
all 58 instances of lsort in BRL-CAD tcl scripts that were
inspected, only 3 obvious cases of missing 'lsearch -sorted'
options were found following them. |
| 20:00.57 |
*** join/#brlcad roberthl
(~robert@v1.rhl.me.uk) |
| 20:00.57 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 20:04.24 |
athena0 |
Seems to
work! |
| 20:04.45 |
athena0 |
bhinesley:
Thanks very much for your help. |
| 20:05.14 |
bhinesley |
athena0: no
problem, I wish could have helped more |
| 20:10.40 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.142.11) |
| 20:10.40 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:21.58 |
CIA-61 |
BRL-CAD:
03bhinesley * r44893
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Realigned the
definition of mArcherCoreCommands, which was getting a little out
of hand |
| 20:47.31 |
CIA-61 |
BRL-CAD:
03bhinesley * r44894
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Indented a
multi-line string. |
| 21:03.21 |
CIA-61 |
BRL-CAD:
03starseeker * r44895 10/brlcad/trunk/TODO: Archer search usage
fixed, note problems being seen with rtwizard. |
| 21:05.58 |
starseeker |
I think with
that can't find Xi libs thing you might to call out the x11
location using --with-x11 or some such... I ran into something
similar once. |
| 21:06.07 |
starseeker |
wonder if
CMake build would have worked |
| 21:07.35 |
starseeker |
really needs to have another go at getting RamDebugger
running and see if it would help the Tcl/Tk development
process... |
| 21:10.51 |
bhinesley |
starseeker: I
had the problem once before too, but I can't remember what I did. I
thought it was due it some package I installed, because once it was
fixed it never came back. |
| 21:12.50 |
bhinesley |
RamDebugger
looks neat |
| 21:17.51 |
starseeker |
bhinesley:
heh - don't be tempted to waste too much time on it though - I have
a feeling getting it working with BRL-CAD could be a bit of a
trick |
| 21:18.30 |
bhinesley |
I'm
sure |
| 21:19.44 |
starseeker |
I'd have to
start by hooking it all into our CMake tclscripts logic, and then
fixing whatever needs fixing |
| 21:19.56 |
starseeker |
and figure
out which pieces (e.g. tkcvs) we could ditch |
| 21:20.27 |
bhinesley |
Speaking of
which, is there any chance of distcc working? I've tried, but it
complained that it wasn't a valid compiler. |
| 21:20.57 |
bhinesley |
it worked
alright with automake |
| 21:21.13 |
starseeker |
urm |
| 21:22.20 |
bhinesley |
not that it's
a big deal :) |
| 21:22.32 |
starseeker |
looking over
CMake list archives... |
| 21:22.57 |
starseeker |
CC=distcc
gcc" cmake ../brlcad ? |
| 21:23.13 |
bhinesley |
yeah, it
dies |
| 21:23.25 |
starseeker |
dies
how? |
| 21:23.54 |
bhinesley |
something
about distcc not passing compiler checks... I'll try it again in a
bit and let you know. I'm doing another build right
now. |
| 21:24.06 |
starseeker |
huh.
k |
| 21:24.50 |
starseeker |
looks like
distcc has come up before: http://www.cmake.org/pipermail/cmake/2008-January/019292.html |
| 21:35.03 |
bhinesley |
starseeker:
http://pastebin.mozilla.org/1247430 |
| 21:35.33 |
starseeker |
erm. distcc
works in isolation? |
| 21:36.01 |
bhinesley |
it uses
gcc/g++ |
| 21:36.19 |
starseeker |
I mean if you
run the line # |
| 21:36.20 |
starseeker |
I mean if you
run the line /usr/bin/distcc gcc -o
CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c |
| 21:36.23 |
starseeker |
#
/home/bhinesley/brlcad-trunk/build/cmake-withogl-distcc/CMakeFiles/CMakeTmp/testCCompiler.c |
| 21:36.47 |
starseeker |
and then
linke it: # |
| 21:36.47 |
starseeker |
and then
linke it: /usr/bin/distcc gcc
CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -o |
| 21:36.50 |
starseeker |
#
cmTryCompileExec -rdynamic |
| 21:36.54 |
starseeker |
er link it
even |
| 21:38.00 |
bhinesley |
I'm not sure
if the "gcc" is supposed to be there or not |
| 21:38.49 |
starseeker |
bhinesley:
maybe not - I'd experiment with it "in isolation" to make sure you
can get it to work, first |
| 21:42.22 |
bhinesley |
oh, I see
what you mean |
| 21:44.41 |
starseeker |
hrm... looks
like tktreectrl would need a CMake build file... |
| 21:44.47 |
starseeker |
fights the temptation... |
| 22:03.33 |
bhinesley |
what does the
debug flag do besides change the install directory? |
| 22:50.27 |
*** join/#brlcad Yoshi47
(~jan@d72-39-60-53.home1.cgocable.net) |
| 23:07.27 |
starseeker |
bhinesley:
adds -g flag, few other compiler flags |
| 23:19.11 |
*** join/#brlcad mafm
(~mafm@95.Red-88-22-160.staticIP.rima-tde.net) |
| 23:32.58 |
CIA-61 |
BRL-CAD:
03brlcad * r44896 10/brlcad/trunk/ (10 files in 6 dirs): stop using
BU_ARGS, just list the arguments. c89/posix lets us move
forward. |
| 23:50.15 |
*** join/#brlcad archivist_emc
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 00:09.03 |
*** join/#brlcad vtts
(~vytautas@diz.ktu.lt) |
| 00:11.28 |
CIA-49 |
BRL-CAD:
03bhinesley * r44922 10/brlcad/trunk/src/librt/db_open.c: Reverted
code changes introduced by r44903. It introduced a bug, where
raytracing .g files outside of the CWD would fail due to an invalid
path. |
| 00:11.44 |
bhinesley |
starseeker:
^^^ |
| 00:27.46 |
*** join/#brlcad crazy_imp
(~mj@a89-182-248-44.net-htp.de) |
| 00:28.12 |
starseeker |
bhinesley++ |
| 00:28.13 |
starseeker |
nice
find |
| 00:28.59 |
bhinesley |
shoulda found
it earlier, but I didn't realize that the sf commit archives show
OLDEST commits on top |
| 00:29.20 |
bhinesley |
db_open,
duh |
| 00:30.35 |
starseeker |
good job - I
shoulda checked that first, but since it was archer-only behavior
on my machine the first thing that lept to mind was tcl/tk
changes |
| 00:31.01 |
starseeker |
obviously not
:-O |
| 01:03.34 |
brlcad |
hm, that
implies some other bug because those are supposed to be search
paths |
| 01:22.25 |
bhinesley |
Ah okay. I'll
take another look tomorrow. |
| 04:06.32 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 04:23.47 |
CIA-49 |
BRL-CAD:
03brlcad * r44923 10/brlcad/trunk/TODO: eliminate dbi_filepath.
shouldn't need to search for resources. the user specified where
the database is at, paths are merely relative to our pwd at the
time the db was opened or absolute. |
| 04:30.21 |
CIA-49 |
BRL-CAD:
03brlcad * r44924
10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: |
| 04:30.22 |
CIA-49 |
BRL-CAD:
rename RT_CK_DISKMAGIC to NMG_CK_DISKMAGIC since it's not librt api
and is |
| 04:30.22 |
CIA-49 |
BRL-CAD:
internal to just nmg.c; probably doesn't even warrant NMG_ prefix,
but might |
| 04:30.22 |
CIA-49 |
BRL-CAD: need
to get moved to nmg.h when separated out in a diff lib so leave it
be for |
| 04:30.22 |
CIA-49 |
BRL-CAD:
now. |
| 04:40.27 |
CIA-49 |
BRL-CAD:
03brlcad * r44925 10/brlcad/trunk/src/librt/ (8 files in 7 dirs):
some ws indent changes in here got skipped. commit. |
| 04:42.06 |
CIA-49 |
BRL-CAD:
03brlcad * r44926 10/brlcad/trunk/src/librt/db_open.c: premature,
dbip ftw |
| 04:43.38 |
CIA-49 |
BRL-CAD:
03brlcad * r44927 10/brlcad/trunk/include/raytrace.h: dbi_filename
paths are not const if we have to free them! |
| 05:00.14 |
CIA-49 |
BRL-CAD:
03brlcad * r44928 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c:
rename rt_nmg_reindex() to just reindex() since it's not librt
public api. looks like it's even private nmg api so we can drop the
nmg_ prefix. |
| 05:03.23 |
CIA-49 |
BRL-CAD:
03brlcad * r44929 10/brlcad/trunk/src/ (15 files in 12 dirs): ws
indent cleanup after BU_EXTERN removal |
| 05:13.09 |
CIA-49 |
BRL-CAD:
03brlcad * r44930 10/brlcad/trunk/src/librt/librt.3: document the
LIBRT_BOT_MINTIE option in the librt manual page, just so it's
written down somewhere user-visible. |
| 06:37.15 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 09:31.13 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.247.68) |
| 09:31.13 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:16.36 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net) |
| 10:46.02 |
kunigami |
brlcad: the
way I was thinking (string identifying shader), you could define a
new shader "foo.osl", compile it to "foo.oso" and them load it
passing as parameter to sh_osl "foo" |
| 10:46.56 |
kunigami |
today, what
we have is that I have a hard-coded osl shader name "yellow", but
"yellow.oso" was compiled independently of brlcad or
osl |
| 10:48.16 |
kunigami |
"what we have
is that I have" ... lol |
| 10:55.00 |
dloman |
yawns |
| 10:55.51 |
dloman |
mernin
all! |
| 11:00.29 |
kunigami |
morning
:) |
| 11:02.49 |
dloman |
hows gsoc
goin for ya? |
| 11:27.23 |
*** join/#brlcad crazy_imp
(~mj@a89-182-248-44.net-htp.de) |
| 12:15.58 |
CIA-49 |
BRL-CAD:
03brlcad * r44931 10/brlcad/trunk/ (9 files in 8 dirs): |
| 12:15.58 |
CIA-49 |
BRL-CAD: make
bu_vls use size_t/off_t internally for tracking the buffer
size. |
| 12:15.58 |
CIA-49 |
BRL-CAD:
accordingly, make bu_vls_setlen() and bu_vls_strlen() take a size_t
parameter |
| 12:15.58 |
CIA-49 |
BRL-CAD: and
propagate changes down to callers as well so we don't have
signed/unsigned |
| 12:15.59 |
CIA-49 |
BRL-CAD:
mismatching. |
| 12:19.54 |
CIA-49 |
BRL-CAD:
03davidloman * r44932 10/geomcore/trunk/src/GS/FileDataSource.cxx:
Comments fix. No longer use BRLCAD::MinimalObject. Uses ExtObjects
instead. |
| 12:21.46 |
CIA-49 |
BRL-CAD:
03davidloman * r44933 10/geomcore/trunk/src/clients/ (. java/): Add
a dir for client work. Need to reduce confusion by separating the
'interface' work from the 'clients' that use said
interface. |
| 12:25.53 |
CIA-49 |
BRL-CAD:
03davidloman * r44934 10/geomcore/trunk/src/clients/java/ (src/
test/): Add /src and /test to client dirs for GS Java Client
project setup. |
| 12:29.26 |
CIA-49 |
BRL-CAD:
03davidloman * r44935 10/geomcore/trunk/src/clients/java/: More
Project setup. Ignore .* files from eclipse. |
| 12:32.18 |
CIA-49 |
BRL-CAD:
03davidloman * r44936 10/geomcore/trunk/src/clients/java/src/org/
(4 files in 4 dirs): Add initial source package tree to client /src
for GS Java Client project setup. |
| 12:34.09 |
CIA-49 |
BRL-CAD:
03davidloman * r44937 10/geomcore/trunk/src/ (19 files in 4 dirs):
Move client files from interface project to client
project |
| 12:35.00 |
CIA-49 |
BRL-CAD:
03davidloman * r44938
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/:
Drop client dirs from interface project |
| 12:53.51 |
CIA-49 |
BRL-CAD:
03brlcad * r44939 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c):
vls_offset isn't supposed to go negative since it's a positive
index from the front, so make it a size_t too. remove unnecessary
casts now that internal bu_vls members are size_t. |
| 13:15.19 |
CIA-49 |
BRL-CAD:
03brlcad * r44940 10/brlcad/trunk/src/mged/animedit.c: linux size_t
quellage |
| 13:24.56 |
CIA-49 |
BRL-CAD:
03brlcad * r44941 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: got
some unreliable asc2g crashes with the new tclcad handling. thrown
in some asserts where unexpected NULLs were showing up in
gdb. |
| 13:37.10 |
CIA-49 |
BRL-CAD:
03brlcad * r44942 10/brlcad/trunk/src/conv/iges/ (convtree.c
iges_struct.h): MEMCHECK is only used in convtree.c so move from
iges_struct.h; also simplify conditional so we can require a
semicolon on use so formatting stays sane. cleanup. |
| 14:01.35 |
CIA-49 |
BRL-CAD:
03Waters 07http://brlcad.org *
r2919 10/wiki/User:Waters: New page: [http://www.speedmycomputer.net/
how can i speed up my computer] |
| 14:23.50 |
CIA-49 |
BRL-CAD:
03brlcad * r44943 10/brlcad/trunk/include/raytrace.h: |
| 14:23.50 |
CIA-49 |
BRL-CAD: add
a new RT_INIT_COMB_INTERNAL initialization macro for
initializing |
| 14:23.50 |
CIA-49 |
BRL-CAD:
rt_comb_internal structs. add a corresponding
RT_FREE_COMB_INTERNAL() macro |
| 14:23.50 |
CIA-49 |
BRL-CAD:
since we do initialize the vls strings potentially allocating
memory (might want |
| 14:23.50 |
CIA-49 |
BRL-CAD: a
bu_vls_init_empty() or vls INIT macro). |
| 14:24.37 |
CIA-49 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Waters]] with an expiry
time of infinite (account creation disabled, e-mail blocked):
Spamming links to external sites |
| 14:24.57 |
CIA-49 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[User:Waters]]": content was:
'[http://www.....net/ how can i
speed up my computer]' (and the only contributor was
'[[Special:Contributions/Waters|Waters]]') |
| 14:27.57 |
CIA-49 |
BRL-CAD:
03brlcad * r44944 10/brlcad/trunk/src/ (12 files in 4 dirs): use
the new RT_INIT_COMB_INTERNAL macro allowing us to make comb
initialization consistent and consolidated into one
place. |
| 14:30.33 |
brlcad |
bhinesley:
any luck with the dbi_filepath issue? I'm actually not seeing how
that even comes into play during database open (supposed to be used
to find resources like height field files, bitmaps, shader files,
etc) |
| 14:37.54 |
CIA-49 |
BRL-CAD:
03brlcad * r44945 10/brlcad/trunk/misc/Makefile.am: sort &
sync. remove FindCocoa.cmake and FindCorbon.cmake, add
util_macros.cmake. |
| 14:59.32 |
CIA-49 |
BRL-CAD:
03davidloman * r44946
10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/
(CmdConsolePanel.java JTextFieldWithHistory.java): Break out
JTextField into custom subclass. Add cmd history. |
| 15:10.34 |
CIA-49 |
BRL-CAD:
03starseeker * r44947 10/brlcad/trunk/src/other/iwidgets/generic/
(panedwindow.itk tclIndex): Stick in iwidgets panedwindow method
and option that seem to be needed for RamDebugger... |
| 15:11.24 |
CIA-49 |
BRL-CAD:
03davidloman * r44948
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/
(GSConnection.java msg/AbstractNetMsg.java): Make the java
implementation AbstractNetMsg.java match NetMsg.cxx |
| 15:11.47 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.214.98) |
| 15:11.47 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 15:15.08 |
CIA-49 |
BRL-CAD:
03davidloman * r44949
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NetMsgTypes.java:
Update NetMsgTypes from C++ code. |
| 15:42.02 |
CIA-49 |
BRL-CAD:
03davidloman * r44950
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/RemoteNodeNameSetMsg.java:
Comment cleanup |
| 15:42.38 |
CIA-49 |
BRL-CAD:
03davidloman * r44951
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/
(5 files): Implement a few more NetMsg types in java. More on the
way. |
| 15:47.09 |
CIA-49 |
BRL-CAD:
03starseeker * r44952 10/brlcad/trunk/src/other/tktreectrl/ (246
files in 21 dirs): |
| 15:47.10 |
CIA-49 |
BRL-CAD:
Early cut at a CMakeified tktreectrl widget. This and the next few
commits are |
| 15:47.11 |
CIA-49 |
BRL-CAD: only
for the purposes of 'checkpointing' what I have managed to get
working as |
| 15:47.12 |
CIA-49 |
BRL-CAD: far
as RamDebugger goes - not really functional as yet (the basic
RamDebugger |
| 15:47.17 |
CIA-49 |
BRL-CAD:
window comes up, but that's about it), so I'll promptly remove it
again - the |
| 15:47.17 |
CIA-49 |
BRL-CAD: goal
is to have what I did get in svn history if I can devote more
resources to |
| 15:47.17 |
CIA-49 |
BRL-CAD: it
later. |
| 15:53.12 |
kunigami |
dloman: going
well. By now I'm studying how to deal with recursive rays
(reflection and refraction/transmission). will make some
experiments here |
| 16:02.33 |
CIA-49 |
BRL-CAD:
03starseeker * r44953 10/brlcad/trunk/src/other/ (672 files in 38
dirs): |
| 16:02.33 |
CIA-49 |
BRL-CAD:
Tweaked version of RamDebugger - diff with vanilla version 7.8 to
see |
| 16:02.33 |
CIA-49 |
BRL-CAD:
differences. Removed a few extensions and there is more to remove,
if this were |
| 16:02.33 |
CIA-49 |
BRL-CAD: ever
to be properly set up for what BRL-CAD needs - many features like
cvs |
| 16:02.33 |
CIA-49 |
BRL-CAD:
aren't particularly important to us, for example... Changes here
were done |
| 16:02.34 |
CIA-49 |
BRL-CAD:
using the enable-all-local-libs build options. |
| 16:04.19 |
kunigami |
by the way,
is there any variable that stores how many times a given ray hit an
object (or its depth)? |
| 16:04.31 |
CIA-49 |
BRL-CAD:
03starseeker * r44954 10/brlcad/trunk/src/other/ (CMakeLists.txt
RamDebugger/ tktreectrl/): Checkpoint complete, restore previous
src/other CMakeLists.txt logic and remove RamDebugger related
directories. |
| 16:05.36 |
brlcad |
kunigami: you
set up callbacks when you fire a ray for hit/miss that can perform
that book-keeping, or you can make sure a_onehit is unset and
you'll get back a partition list of all objects along that
ray |
| 16:08.45 |
brlcad |
kunigami:
http://brlcad.org/wiki/Example_Application
shows the latter where it iterates over the partition
list |
| 16:12.51 |
CIA-49 |
BRL-CAD:
03davidloman * r44955
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/
(GeometryChunkMsg.java GeometryManifestMsg.java): Add
GeometryManifest and GeometryChunk msgs to java |
| 16:13.13 |
CIA-49 |
BRL-CAD:
03davidloman * r44956
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/
(PingMsg.java PongMsg.java): Add Ping and Pong to java |
| 16:16.11 |
CIA-49 |
BRL-CAD:
03davidloman * r44957
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/
(DirListReqMsg.java DirListResMsg.java): Add DirectoryList request
and response NetMsgs to java. |
| 16:16.49 |
CIA-49 |
BRL-CAD:
03davidloman * r44958
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java:
Update NetMsgfactory with all the recently implemented NetMsg
subclasses. |
| 16:17.11 |
*** join/#brlcad yukonbob
(~bch@S0106002191d1591c.ok.shawcable.net) |
| 16:18.11 |
kunigami |
brlcad:
thanks! this example also shows how to setup the
callback |
| 16:20.03 |
CIA-49 |
BRL-CAD:
03bob1961 * r44959
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added the
ability to create instances of ArcherCore with/without the treeview
or the toolbar. |
| 16:20.50 |
CIA-49 |
BRL-CAD:
03davidloman * r44960
10/geomcore/trunk/src/libNet/netMsg/NewNodeOnNetMsg.cxx: Update
NetMsg type to correct one for this class. |
| 16:21.47 |
kunigami |
if I
understood it right, whenever it hits an object that function will
be called. If, for example, a ray first hits an object A, the
callback will be called with only object A. If this ray further
hits an object B, them both A and B will be in that partition
list? |
| 16:21.51 |
CIA-49 |
BRL-CAD:
03davidloman * r44961
10/geomcore/trunk/src/utility/StringUtils.cxx: Fix incorrect type
and cast. |
| 16:26.03 |
brlcad |
kunigami: it
depends if onehit is set, but if unset then yes |
| 16:26.32 |
yukonbob |
hello,
#brlcad |
| 16:26.41 |
brlcad |
howdy
yukonbob |
| 16:26.53 |
yukonbob |
how're
things? |
| 16:28.46 |
CIA-49 |
BRL-CAD:
03bob1961 * r44962 10/brlcad/trunk/src/tclscripts/rtwizard/
(RaytraceWizard.tcl lib/MGEDpage.itk): Updates to use ArcherCore
instead of Mged which has been deprecated. |
| 16:29.20 |
brlcad |
busy |
| 16:29.34 |
brlcad |
dloman: how
was the type incorrect? |
| 16:29.36 |
yukonbob |
excellent! |
| 16:29.57 |
yukonbob |
hits website to see if there're published stories about
recent(ish) goings-on... |
| 16:30.39 |
brlcad |
maybe a
complaint that bu_free() wasn't being passed a genptr_t (i.e., a
void*), but making it const isn't technically correct |
| 16:32.32 |
brlcad |
starseeker:
hmmm |
| 16:32.46 |
brlcad |
adding
RamDebugger is akin to adding gdb ... kinda odd |
| 16:33.11 |
brlcad |
maybe a
separate branch for 3rd party tools? |
| 16:36.37 |
yukonbob |
what's the
RamDebugger for ? |
| 16:41.00 |
brlcad |
presumably
debugging tcl code |
| 16:41.10 |
brlcad |
it's a gui
ide for tcl debugging |
| 16:43.14 |
starseeker |
brlcad: I
removed it - just wanted to stash it in history
somewhere |
| 16:43.47 |
brlcad |
heh,
okay |
| 16:44.33 |
starseeker |
brlcad:
ultimately it might be interesting to be able to debug tcl scripts
"in MGED" or some such, but for the moment I can't even get the
darn thing to debug ANYTHING |
| 16:46.04 |
starseeker |
I'm sure
it'll do something once I finish widing through the "oh, this
doesn't work either with this version" fun but even then I'm not
sure how well it would do with incrTcl/iwidgets |
| 16:46.46 |
starseeker |
my annoyance
threshold with debugging Tcl/Tk just hit a momentary peak - it'll
fade back to normal background annoyance levels soon
:-P |
| 16:46.55 |
yukonbob |
notes theres also -DTCL_MEM_DEBUG, and the [mem] commands it
presents... |
| 16:47.57 |
yukonbob |
starseeker:
Tcl loves you :) |
| 16:48.34 |
starseeker |
yukonbob:
what I miss most is the ability to step through a tcl file line by
line in an editor DDD style, examining variables and such and
easily seeing which Tcl line ultimately triggered the latest
framebuffer/display manager problem |
| 16:49.25 |
starseeker |
feeding bwish
into gdb does OK if the problem is in our C libraries, but if it's
actually in the Tcl code... |
| 16:49.31 |
dloman |
brlcad: was
supposed to be const char* instead of just char* |
| 16:49.32 |
yukonbob |
nods... a bit more involved than just memory consumption,
ckalloc() guarding... |
| 16:49.41 |
dloman |
brlcad: and i
missed a cast to void* |
| 16:49.54 |
yukonbob |
TclPro has
what you're looking for, I think, but I haven't played w/ that part
of Tcl dev... |
| 16:50.02 |
yukonbob |
is sure starseeker is on the case, though. |
| 16:50.30 |
starseeker |
<snort>
the problem is Tcl/Tk problems of that nature are just rare enough
that we can usually ignore them or have bob1961 track 'em
down |
| 16:51.04 |
starseeker |
TclPro...
isn't that the commerical one? Or wasn't there some free version
that hasn't been updated in a long long time? |
| 16:54.55 |
brlcad |
dloman: it's
not supposed to be const char |
| 16:55.08 |
brlcad |
at least not
if you're going to bu_free it (which the signature
requires) |
| 16:55.33 |
dloman |
okie |
| 16:56.02 |
brlcad |
the cast to
void* (i.e., genptr_t) is the only thing that might have provoked a
warning, but the types should have been golden |
| 16:57.03 |
brlcad |
the constness
is broken by casting to void* anyways |
| 16:57.49 |
starseeker |
hah, cool:
http://labs.qt.nokia.com/2011/06/03/threaded-opengl-in-4-8/ |
| 16:58.27 |
bhinesley |
brlcad: not
yet, I'm just starting for today. To answer your question: I don't
think that it has anything to do with opening the database. It has
to do with the CWD, which is apparently being used
somewhere. |
| 16:58.27 |
bhinesley |
When
attempting to raytrace, we see the path "/CWD//full_path_to_.g/"
being used (two absolute paths concatenated). |
| 17:00.17 |
brlcad |
yeah, i get
the end-effect, and that the full-path cwd is presumably coming
from dbi_fullpath .. but not how the order of search dirs [0] vs
[1] would result in that |
| 17:00.40 |
bhinesley |
that, I will
have to figure out |
| 17:01.01 |
bhinesley |
gets to work |
| 17:01.05 |
brlcad |
I did a full
search for dbi_fullpath and ... if it's the cause, I haven't quite
seen how yet :) |
| 17:01.29 |
CIA-49 |
BRL-CAD:
03davidloman * r44963
10/geomcore/trunk/src/utility/StringUtils.cxx: Cast the data from
bu_basename to (char*) rather than passing around a (const
char*) |
| 17:02.25 |
brlcad |
hmmm |
| 17:02.41 |
brlcad |
I think your
header files are out of date, don't need a cast either
:) |
| 17:02.46 |
brlcad |
(dloman) |
| 17:03.15 |
brlcad |
that's
probably the original problem |
| 17:03.26 |
dloman |
kk |
| 17:04.07 |
dloman |
updates |
| 17:11.00 |
starseeker |
O.o another
one: https://github.com/advancingu/Cutexture |
| 17:12.55 |
brlcad |
http://www.youtube.com/watch?v=b_3xfFuwGOQ |
| 17:14.45 |
starseeker |
brlcad: yeah,
saw that - quite promising |
| 17:14.57 |
starseeker |
that's the
experimental Qt5 apparently |
| 17:15.12 |
brlcad |
same problem
from a couple years ago though |
| 17:15.17 |
brlcad |
still seems
"backwards" |
| 17:15.57 |
starseeker |
you mean
ogre-in-Qt not Qt-in-Ogre? |
| 17:16.05 |
brlcad |
yeah |
| 17:16.20 |
brlcad |
or both
really since you still want qt widgets in the ogre context
too |
| 17:16.38 |
brlcad |
but that your
main window is a qt window, not something ogre
establishes |
| 17:16.58 |
starseeker |
maybe
cutexture is set up more along those lines - I'll have to
check |
| 17:17.17 |
starseeker |
usually the
problem I have testing these suckers is getting Ogre working on my
home box... |
| 17:34.07 |
yukonbob |
Trolltech
ogre? Isn't there a rule against cross-fairytale creature
misappropriation? |
| 17:38.22 |
bhinesley |
brlcad: which
argument is used for what seems to be explicit: if (argv[1][0] !=
'/') |
| 17:39.19 |
bhinesley |
it tests to
see if the second argument is an absolute path, but not the
first |
| 17:39.39 |
bhinesley |
sorry, this
is in db_open.c |
| 17:53.32 |
CIA-49 |
BRL-CAD:
03starseeker * r44964 10/brlcad/trunk/ (5 files in 4 dirs):
Downcase the openNURBS directory to just opennurbs - 'cause macros
are easier when you don't have mixed case in the way. |
| 17:55.39 |
brlcad |
ah, heh .. I
was hunting down dbi_fullpath in other files and it hadn't even
gotten out of db_open()! I see now, it's trying to expand the full
path for dbi_filename() |
| 17:55.51 |
brlcad |
will rewrite that function, no worries --
thanks! |
| 17:56.07 |
bhinesley |
oh alright!
no problem. |
| 17:56.40 |
brlcad |
it was
actually next in my queue to add a cwd routine to libbu
anyways |
| 18:02.40 |
bhinesley |
brlcad:
should I keep working on migrating commands and fixing bugs for
now, or should I start on the libged command registry? I'm not
really sure where to start on the registry, so we might need to
talk about it for a bit before I do. |
| 18:03.13 |
bhinesley |
either is
fine for me |
| 18:11.16 |
*** join/#brlcad bhinesley_
(~bhinesley@99.144.90.118) |
| 18:11.43 |
bhinesley_ |
brlcad: my
machine locked up, so if you said anything i missed it |
| 18:17.26 |
starseeker |
bhinesley: he
didn't yet |
| 18:17.39 |
bhinesley |
thanks
:) |
| 18:24.07 |
brlcad |
bhinesley:
I'd keep with the original plan for now, command migration,
refactoring, and fixing |
| 18:24.25 |
bhinesley |
ok |
| 18:25.30 |
brlcad |
I've got
something started for the registry, but am just a bit overtasked at
the moment to dive down that path just yet |
| 18:26.11 |
brlcad |
nothing fancy
to say the least, but the command work will be more immediately
useful anyways |
| 18:26.23 |
bhinesley |
Oh, don't
worry about it, I know you have a lot on your plate. |
| 18:31.31 |
CIA-49 |
BRL-CAD:
03davidloman * r44965
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java:
Comment clean up. Also added two methods that will need to be
rolled into jBRLCAD's GemetryService Interface |
| 18:32.48 |
CIA-49 |
BRL-CAD:
03davidloman * r44966
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java:
Remove libPKG remnants |
| 18:33.43 |
CIA-49 |
BRL-CAD:
03brlcad * r44967 10/brlcad/trunk/ (TODO src/libged/typein.c): we
allocate the idb_ptr so we know the vls is not initialized. call
bu_vls_init() instead of bu_vls_init_if_uninit(). still warrants a
quick test before the next release, though. |
| 18:34.15 |
CIA-49 |
BRL-CAD:
03davidloman * r44968
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java:
Was incorrectly serializing using the old GSNetProto header.
Removed the two MAGIC values and fixed the msgLen
calculation. |
| 18:35.36 |
CIA-49 |
BRL-CAD:
03brlcad * r44969 10/brlcad/trunk/src/ (conv/dxf/dxf-g.c
mged/vrlink.c): make the vls a pointer so it can sometimes be NULL
and we can test that for determining whether to initialize or not.
call bu_vls_init() instead of the unreliable
bu_vls_init_if_uninit(). |
| 18:36.21 |
CIA-49 |
BRL-CAD:
03brlcad * r44970 10/brlcad/trunk/src/mged/utility1.c: the tmp_vls
isn't used outside the nested scope so pull it down to where it's
used. there we know it's not initialized, so we can just call
bu_vls_init(). |
| 18:37.15 |
CIA-49 |
BRL-CAD:
03brlcad * r44971 10/brlcad/trunk/src/ (libbu/parse.c
librt/parse.c): if they're not initialized, it's an error in the
caller's code. don't try to accommodate the error by
initializing. |
| 18:41.51 |
CIA-49 |
BRL-CAD:
03brlcad * r44972 10/brlcad/trunk/ (doc/deprecation.txt
include/bu.h src/libbu/vls.c): |
| 18:41.52 |
CIA-49 |
BRL-CAD: and
with that, mark the silly inconsistent error-prone
unreliable |
| 18:41.52 |
CIA-49 |
BRL-CAD:
bu_vls_init_if_uninit() function as deprecated. there needs to be
an INIT macro |
| 18:41.52 |
CIA-49 |
BRL-CAD: for
bu_vls structs but bu_vls_init() is the better way to go. the
problem stems |
| 18:41.52 |
CIA-49 |
BRL-CAD: from
memory not getting consistently initialized and/or reset to zero so
that |
| 18:41.52 |
CIA-49 |
BRL-CAD: the
magic check would actually work. using a NULL pointer or
caller-based init |
| 18:41.53 |
CIA-49 |
BRL-CAD: flag
are safer methods. |
| 18:42.04 |
CIA-49 |
BRL-CAD:
03davidloman * r44973
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: |
| 18:42.04 |
CIA-49 |
BRL-CAD:
Added a thread sleep in the GSConnection run loop to keep from
hogging a CPU. |
| 18:42.04 |
CIA-49 |
BRL-CAD:
Fixed buffer size checking in tryMakeNetMsg(), it was incorrectly
thinking there |
| 18:42.04 |
CIA-49 |
BRL-CAD: was
insufficient data to deserialize and bailing out. Also fixed
waitForMsg() |
| 18:42.05 |
CIA-49 |
BRL-CAD: as
the totalRead parameter was not being reset after the loop was
finished. |
| 18:46.10 |
CIA-49 |
BRL-CAD:
03davidloman * r44974
10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/CmdConsolePanel.java:
Removed unused var from doCmd(). Was leftover from
debugging. |
| 18:47.00 |
CIA-49 |
BRL-CAD:
03davidloman * r44975
10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java:
Print the remote nodename to the GUI console upon successful
connection. |
| 18:51.05 |
CIA-49 |
BRL-CAD:
03davidloman * r44976 10/geomcore/trunk/ (include/PortalManager.h
src/libNet/PortalManager.cxx): Make a difference between
'LocalNodeName' and the PortalManager object's name. LocalNodeName
is the name of this PortalManager on the network while the other is
simply the object's name used in Logging. |
| 18:54.19 |
CIA-49 |
BRL-CAD:
03davidloman * r44977
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java:
Eliminate duplicate fn. |
| 19:04.07 |
CIA-49 |
BRL-CAD:
03starseeker * r44978
10/brlcad/trunk/src/other/opennurbs/CMakeLists.txt: bye bye mixed
case |
| 19:07.12 |
CIA-49 |
BRL-CAD:
03davidloman * r44979
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSNetMsgFutureResponse.java:
Add a response handler for NetMsg that should envoke a response
from server. |
| 19:08.53 |
brlcad |
starseeker:
if I recall correctly, mixed case on the product is what was in
their original build files, so there is some value in preserving
that trait |
| 19:10.35 |
brlcad |
further
deviation from their source (with any benefit?) making it more
complicated to swap in a system opennurbs down the road |
| 19:12.34 |
brlcad |
the dir name
is irrelevant, but the product name does have meaning (e.g., mixed
case is highly indicative of C++ libs vs C libs .. a quick scan of
any lib dir and the C++ ones are generally (conventionally) the
ones with upper-case) |
| 19:19.04 |
CIA-49 |
BRL-CAD:
0399.144.90.118 07http://brlcad.org
* r2920 10/wiki/User:Bhinesley: /* Log */ Friday - Monday, plan
today |
| 19:24.36 |
CIA-49 |
BRL-CAD:
03brlcad * r44980 10/brlcad/trunk/include/bu.h: |
| 19:24.36 |
CIA-49 |
BRL-CAD:
implement BU_INIT_VLS() and BU_INIT_VLB() macros to initialize a
vls/vlb struct |
| 19:24.36 |
CIA-49 |
BRL-CAD:
without allocating any memory. also, similar to the convention in
vmath, |
| 19:24.36 |
CIA-49 |
BRL-CAD:
provide BU_VLS_INIT_ZERO/BU_VLB_INIT_ZERO macros suitable for
declaration |
| 19:24.36 |
CIA-49 |
BRL-CAD:
statement initialization. |
| 19:25.45 |
brlcad |
bhinesley:
tell me about ls |
| 19:41.21 |
*** join/#brlcad yiyus (2383vince@je.je.je) |
| 19:55.11 |
CIA-49 |
BRL-CAD:
03davidloman * r44981 10/geomcore/trunk/src/libNet/ (Portal.cxx
PortalManager.cxx): Make Portal/PortalManager respond to a
RemNodeNameSet message rather than automatically sending its
localNodeName. |
| 19:55.28 |
CIA-49 |
BRL-CAD:
03brlcad * r44982 10/brlcad/trunk/include/bu.h: add
BU_LIST_INIT_ZERO, BU_BITV_INIT_ZERO, and BU_INIT_BITV macros for
api consistency (lots more to go) |
| 19:55.51 |
bhinesley |
brlcad: I
noticed that when you enter "ls not-an-obj" it would print
"not-an-obj", which is misleading. I checked ArcherCore.tcl, and
saw that it simply does "return \$expandedArgs" if you don't pass
any options. |
| 19:55.51 |
bhinesley |
I was trying
to get the behavior that MGED has: if you do an 'ls is-an-obj
not-an-obj', it returns something like "is-an-obj (\n ...)
not-an-obj doesn't exist". This doesn't seem possible the way it
works now, since we're not letting libged's ls command print it's
error directly to the command line. If we want ::ls to print the
error, it has to be all or nothing (failure or success), since a
partial match in libged's ls simply returns GED_OK. |
| 19:56.23 |
CIA-49 |
BRL-CAD:
03brlcad * r44983 10/brlcad/trunk/src/libbu/ (list.c malloc.c
mappedfile.c temp.c): no longer need to manually init the bu_list
or ignore init, call BU_LIST_INIT_ZERO instead. |
| 19:57.11 |
bhinesley |
hopefully
that made sense |
| 20:08.43 |
CIA-49 |
BRL-CAD:
03brlcad * r44984 10/brlcad/trunk/include/bu.h: fix BU_INIT_BITV().
we need pointers to pass to BU_INIT_LIST(). group the bu_list init
macros together better and add BU_INIT_LIST (which calls the
existing BU__LIST_INIT that will soon go away). |
| 20:09.00 |
CIA-49 |
BRL-CAD:
03brlcad * r44985 10/brlcad/trunk/src/libbu/bitv.c: initialize the
BU_BITV properly instead of setting the magic manually. |
| 20:41.42 |
brlcad |
bhinesley:
yes, that does make sense |
| 20:42.18 |
brlcad |
that actually
sounds like a prime example for consolidation so that they are
identical |
| 20:43.09 |
brlcad |
so there's no
expansion in mged or archer, that ged_ls() does all the work with
the necessary information returned in the struct ged in some form
that both can display suitably |
| 20:44.06 |
brlcad |
and of course
sorting out what it means to have a partial failure from an api
perspective |
| 20:44.48 |
brlcad |
I'd think
partial failure is still a failure, not GED_OK for
starters |
| 20:44.53 |
bhinesley |
agreed |
| 20:47.05 |
brlcad |
the issue
then just becomes how to have ged_ls() add listings and failures to
the results |
| 20:47.33 |
brlcad |
could be time
to sort out a proper result set instead of the dumb
ged_result_str |
| 20:48.21 |
kunigami |
can I set the
hit callback on the shader setup? |
| 20:50.07 |
brlcad |
e.g., an
array of types and values so that "ls valid invalid valid2" might
return the set { {GED_OBJECT, "valid"}, {GED_ERROR, "ls: invalid:
No such object"}, {GED_OBJECT, "valid2"} } |
| 20:50.35 |
brlcad |
kunigami: you
can set the hit callback any time before rt_shootray() is
called |
| 20:51.56 |
brlcad |
if you're in
the shader, though, then that probably implies that a ray was
already fired, hit callback was made, determined ther shader, and
shader callback was made .. so you'd be firing another ray you set
up |
| 20:54.58 |
kunigami |
true |
| 20:55.24 |
bhinesley |
brlcad: does
::ls even need to know that much? Couldn't just the results be
passed back from ged_ls? |
| 20:55.47 |
kunigami |
it seems that
the variable 'a_level' from application struct counts the depth of
recursion. let me give it a try |
| 20:57.43 |
bhinesley |
and by that,
I mean one long string that is printed |
| 20:58.25 |
bhinesley |
n/m... then
we'd lose the ability to identify which part of it is an
error |
| 20:58.35 |
bhinesley |
for logging
and whatnot |
| 20:58.36 |
brlcad |
bhinesley:
bingo |
| 20:58.44 |
brlcad |
I mean for
now, that'd be an improvement |
| 20:59.16 |
brlcad |
but the goal
is to make the return from the ged_*() functions be
programmatic |
| 21:00.12 |
brlcad |
so I could
write a program that uses ged_ls() to lookup objects, iterate over
them and call other functions etc |
| 21:00.57 |
brlcad |
or in the
case of mged/arhcer, maybe I want to return the list of objects as
a proper list and print the error (interleaved and color-coded) to
stderr |
| 21:02.42 |
bhinesley |
I understand;
I was thinking about it from the perspective of tcl code
duplication. It'd be nice if there was a mechanism for using the
same call to ged_ls for both programs... like how I kinda forced
that with ManBrowser. |
| 21:02.54 |
bhinesley |
that would
prevent problems like this from occurring in the first
place |
| 21:04.25 |
CIA-49 |
BRL-CAD:
03brlcad * r44986 10/brlcad/trunk/ (21 files in 12
dirs): |
| 21:04.25 |
CIA-49 |
BRL-CAD:
replace BU_LIST_UNINITIALIZED() with !BU_LIST_IS_INITIALIZED() as a
minimally |
| 21:04.25 |
CIA-49 |
BRL-CAD:
impacting API change. BU_LIST_UNINITIALIZED() is unnecessary with
the other and |
| 21:04.26 |
CIA-49 |
BRL-CAD:
inconsistent with the API (the only *_uninitialized macro of its
kind). reduce, |
| 21:04.26 |
CIA-49 |
BRL-CAD:
reuse. |
| 21:05.07 |
bhinesley |
shrugs |
| 21:21.06 |
starseeker |
brlcad: uh...
we're writing our own build logic for opennurbs
anyway... |
| 21:22.33 |
starseeker |
brlcad: at
this point I'm very doubtful we'll ever be able to use a system
opennurbs |
| 21:23.01 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177593767.dsl.bell.ca) |
| 21:23.19 |
starseeker |
I'll revert
it if you want and try to find another way to do what I had in
mind... |
| 21:27.08 |
CIA-49 |
BRL-CAD:
03bhinesley * r44987
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Temporary fix
for ::ls to stop echoing nonexistant objects. |
| 21:29.23 |
brlcad |
starseeker:
it should probably still be our goal, not intentionally move away
with a fork |
| 21:29.32 |
brlcad |
if only to
minimize differences the next time we sync |
| 21:29.56 |
brlcad |
that one in
particular, though, gets at the convention issue and the "name" of
the library |
| 21:31.28 |
starseeker |
brlcad: I'm
not sure I agree about forking, but I'll revert the name downcasing
(working on it now) |
| 21:33.50 |
*** part/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177593767.dsl.bell.ca) |
| 21:35.16 |
*** join/#brlcad bhinesley_
(~bhinesley@99.144.90.118) |
| 21:35.43 |
*** join/#brlcad bhinesley_
(~bhinesley@99.144.90.118) |
| 21:36.31 |
CIA-49 |
BRL-CAD:
03starseeker * r44988 10/brlcad/trunk/ (501 files in 11 dirs):
Revert r44964 |
| 21:46.50 |
brlcad |
starseeker: I
still think it's entirely possible to get a pristine openNURBS
working, to move back towards the original goal of having a proper
layer on *top* of opennurbs for our added functionality |
| 21:47.09 |
brlcad |
maybe that
overlay is your libnurbs project |
| 21:47.44 |
brlcad |
anything else
is going to have an ongoing maintenance cost that, well, will suck
more and more over time |
| 21:48.47 |
brlcad |
curious
though -- what prompted that onto your radar to change
it? |
| 21:49.16 |
starseeker |
I'm playing
games with CMake macros to get the distcheck filelists out of
src/other/CMakeLists.txt |
| 21:49.51 |
starseeker |
I was using
some toupper and tolower logic in macros - it may not be strictly
necessary though, so I'm going to revisit those macros |
| 00:27.56 |
*** join/#brlcad crazy_imp
(~mj@a89-182-252-199.net-htp.de) |
| 02:24.16 |
CIA-49 |
BRL-CAD:
03brlcad * r44989 10/brlcad/trunk/src/libbu/vls.c: make sure the
string actually has allocated memory befor trying to set a sanity
char |
| 02:40.45 |
CIA-49 |
BRL-CAD:
03brlcad * r44990 10/brlcad/trunk/include/bu.h: the func is
bu_vls_init(), the macro is BU_INIT_VLS() |
| 02:43.21 |
CIA-49 |
BRL-CAD:
03brlcad * r44991 10/brlcad/trunk/include/raytrace.h: call
BU_INIT_VLS() instead of bu_vls_init() here so we can avoid memory
allocation |
| 03:51.34 |
CIA-49 |
BRL-CAD:
03brlcad * r44992 10/brlcad/trunk/include/raytrace.h: better
comment wording. the struct itself isn't freed so don't say memory
is released. callers still need to call bu_free(). |
| 03:54.25 |
*** join/#brlcad CIA-49
(~CIA@cia.atheme.org) |
| 04:11.53 |
*** join/#brlcad CIA-68
(~CIA@cia.atheme.org) |
| 04:14.27 |
CIA-68 |
BRL-CAD:
03brlcad * r44995 10/brlcad/trunk/include/bu.h: not necessarily
deprecated just yet. we may want to use RT_type_INIT() instead of
RT_INIT_type |
| 04:14.27 |
CIA-68 |
BRL-CAD:
03brlcad * r44994 10/brlcad/trunk/src/mged/utility1.c: vls
overkill, just interpret the help command directly |
| 04:14.27 |
CIA-68 |
BRL-CAD:
03brlcad * r44993 10/brlcad/trunk/src/librt/comb/db_comb.c:
simplify. call RT_FREE_COMB_INTERNAL() instead of manually managing
the struct members. |
| 07:01.47 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 11:33.57 |
CIA-68 |
BRL-CAD:
03davidloman * r44996 10/geomcore/trunk/ (include/Session.h
src/GS/Session.cxx): Make Session::generateSessionInfoMsg() take an
optional 'reply' message as an arg. This allows for proper
RegardingUUID setting in generated msg. |
| 11:34.57 |
CIA-68 |
BRL-CAD:
03davidloman * r44997 10/geomcore/trunk/src/GS/SessionManager.cxx:
Pass the NewSessionRequestMsg as an arg to the SessionInfoMsg
construction in Session::generateSessionInfoMsg() |
| 12:27.11 |
CIA-68 |
BRL-CAD:
03brlcad * r44998 10/brlcad/trunk/ (include/bu.h
src/libbu/bitv.c): |
| 12:27.11 |
CIA-68 |
BRL-CAD:
continue moving towards API consistency and completeness. start
making sure all |
| 12:27.11 |
CIA-68 |
BRL-CAD:
structs have a common set of macros: BU_[type]_INIT(),
BU_[type]_INIT_ZERO, |
| 12:27.11 |
CIA-68 |
BRL-CAD:
BU_[type]_NULL, along with a few others. ensure there's a NULL and
typedef as |
| 12:27.11 |
CIA-68 |
BRL-CAD: well
(even though those may be eliminated down the road). expand doxygen
docs |
| 12:27.12 |
CIA-68 |
BRL-CAD:
while we're at it finishing up bu_list, bu_bitv, and bu_hist for
starters. |
| 12:36.00 |
CIA-68 |
BRL-CAD:
03brlcad * r44999 10/brlcad/trunk/include/bu.h: fill out bu_ptbl
macros and typedef |
| 12:42.39 |
CIA-68 |
BRL-CAD:
03brlcad * r45000 10/brlcad/trunk/include/bu.h: fill out
bu_mapped_file macros and typedef, fix ptbl typedef
typo |
| 12:48.08 |
CIA-68 |
BRL-CAD:
03davidloman * r45001
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/
(GSJavaInterface.java net/GSConnection.java): Rework error handling
on connectToHost() fns. Had to create a custom class to handle all
the possible return values. (This is where callbacks or pointers
would have been nice to have!) |
| 12:50.28 |
CIA-68 |
BRL-CAD:
03davidloman * r45002
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/
(4 files in 2 dirs): Clean up Exception printing. Helps in tracking
down bugs. Lots of future clean up here! |
| 12:50.47 |
CIA-68 |
BRL-CAD:
03brlcad * r45003 10/brlcad/trunk/src/libbu/ (globals.c hook.c):
just use NULL instead of BU_HOOK_NULL |
| 12:51.02 |
CIA-68 |
BRL-CAD:
03brlcad * r45004 10/brlcad/trunk/include/bu.h: expand bu_hook_list
macros, remove BU_HOOK_NULL |
| 12:51.51 |
CIA-68 |
BRL-CAD:
03davidloman * r45005
10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java:
Cascading changes from connectToHost(). It no longer returns a
simple boolean. Instead it returns an int with informational
error/return codes. |
| 12:53.46 |
CIA-68 |
BRL-CAD:
03davidloman * r45006
10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/
(CmdManager.java ListCmd.java LogoutCmd.java): Implement ListCmd
and LogoutCmd |
| 12:56.00 |
CIA-68 |
BRL-CAD:
03davidloman * r45007
10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/CmdConsolePanel.java:
More exception cleanup. |
| 12:56.59 |
CIA-68 |
BRL-CAD:
03davidloman * r45008
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java:
Forgot to remove a debugging statement |
| 12:57.20 |
CIA-68 |
BRL-CAD:
03davidloman * r45009
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java:
Import cleanup |
| 13:03.51 |
CIA-68 |
BRL-CAD:
03brlcad * r45010 10/brlcad/trunk/include/bu.h: include some
clarity that all of the structs that include list elements are
still expected to have a list head node, which should have a magic
type of BU_LIST_HEAD_MAGIC. |
| 13:11.25 |
CIA-68 |
BRL-CAD:
03brlcad * r45011 10/brlcad/trunk/include/bu.h: add avs macros and
typedef |
| 13:16.04 |
CIA-68 |
BRL-CAD:
03brlcad * r45012 10/brlcad/trunk/include/bu.h: api is starting to
stabilize, convention is now BU_[type]_INIT() so change
BU_INIT_VLS() to BU_VLS_INIT(). |
| 13:18.40 |
CIA-68 |
BRL-CAD:
03brlcad * r45013 10/brlcad/trunk/include/raytrace.h: update the
one place where BU_INIT_VLS() was being called too. |
| 13:18.50 |
CIA-68 |
BRL-CAD:
03brlcad * r45014 10/brlcad/trunk/include/bu.h: update vlb the
same |
| 13:31.09 |
kunigami |
I'll take the
rest of the week studying the feasibility of using a brl-cad shader
as an interface to osl system. The example @brlcad showed me made
me think that implementing a stand-alone application for osl would
be feasible. |
| 13:33.32 |
CIA-68 |
BRL-CAD:
03brlcad * r45015 10/brlcad/trunk/include/bu.h: |
| 13:33.33 |
CIA-68 |
BRL-CAD:
expand bu_structparse macros and typedef. since this struct has no
magic, |
| 13:33.33 |
CIA-68 |
BRL-CAD:
BU_STRUCTPARSE_IS_INITIALIZED() can only check whether the pointer
is non-null. |
| 13:33.33 |
CIA-68 |
BRL-CAD:
that's a reminder to make sure all the others are non-null before
we dereference |
| 13:33.33 |
CIA-68 |
BRL-CAD:
too. |
| 13:45.25 |
CIA-68 |
BRL-CAD:
03brlcad * r45016 10/brlcad/trunk/include/bu.h: can't just check
the pointer for truthfulness since static variables will always
return true. fake out the compiler via a pointer cast and
comparison to NULL. |
| 14:00.44 |
brlcad |
aaand we
pause there since bu_external is a bit of a doosie |
| 15:09.48 |
dloman |
``Erik: you
around? |
| 15:10.29 |
dloman |
``Erik: Well,
whenever you are, check this out. kinda neat: http://www.dennisantinori.com/Resources/Ringworld/ |
| 15:44.16 |
dloman |
wow, there's
a Lego CAD app: http://www.ldraw.org |
| 15:44.18 |
dloman |
awesome |
| 16:19.27 |
CIA-68 |
BRL-CAD:
03brlcad * r45017 10/brlcad/trunk/src/libbu/CMakeLists.txt: sync.
add basenametester compilation. |
| 16:32.05 |
CIA-68 |
BRL-CAD:
03starseeker * r45018 10/brlcad/trunk/ (6 files in 4 dirs): This is
an intermediate phase and I doubt it's working, but I need to
checkpoint - reworking distcheck logic to be cleaner, more robust,
etc. |
| 16:40.17 |
*** join/#brlcad bhinesley
(~bhinesley@99.144.90.118) |
| 16:48.54 |
brlcad |
starseeker:
what's the equivalent of noinst_BINARIES ? |
| 16:51.38 |
CIA-68 |
BRL-CAD:
03brlcad * r45019 10/brlcad/trunk/NEWS: past tense rewrite. cliff
fixed a bug in archer's tree view widget to highlight related
objects. |
| 16:59.59 |
*** join/#brlcad bhinesley
(~bhinesley@99.144.90.118) |
| 17:01.21 |
CIA-68 |
BRL-CAD:
03brlcad * r45020 10/brlcad/trunk/NEWS: brandon improved the ls
command error reporting in archer where before it wouldn't report
an error for partial failures if you 'ls valid invalid'. now it at
least displays the lookup failure. |
| 17:06.07 |
bhinesley |
brlcad:
actually, it doesn't display an error in Archer, it just doesn't
echo invalid names anymore. The problem with returning the error in
the struct ged's return string, is that mged would display the
error, too... so it would break any scripted uses of
ls. |
| 17:07.18 |
bhinesley |
plus, I'd
have to to a quiet db_lookup, so that mged didn't show two error
messages. |
| 17:07.29 |
bhinesley |
*to
do |
| 17:10.53 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.214.98) |
| 17:10.53 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:19.43 |
CIA-68 |
BRL-CAD:
03davidloman * r45021
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferReader.java:
Make the ByteBuffer copy in the ByteBufferReader cstr optional.
Reduces the amount of mallocs significantly. |
| 17:21.05 |
brlcad |
bhinesley:
ah, okay -- misunderstood your commit message |
| 17:21.43 |
brlcad |
fortunately
the news line itself is vague enough that it still
applies |
| 17:21.48 |
bhinesley |
nods |
| 17:21.55 |
brlcad |
it's
improved, just not the way the comment says ;) |
| 17:32.47 |
CIA-68 |
BRL-CAD:
03brlcad * r45022 10/brlcad/trunk/doc/deprecation.txt: |
| 17:32.47 |
CIA-68 |
BRL-CAD:
unlike the other lists, finding the latest minimally impacting
change needs to |
| 17:32.47 |
CIA-68 |
BRL-CAD: be
deterministic. so list them in chronological order so the most
recent are at |
| 17:32.47 |
CIA-68 |
BRL-CAD: the
end of the file. the same doesn't hold true for the incompatible
changes so |
| 17:32.47 |
CIA-68 |
BRL-CAD:
leave them in reverse chrono order. |
| 17:38.05 |
CIA-68 |
BRL-CAD:
03brlcad * r45023 10/brlcad/trunk/doc/deprecation.txt: with the
list now in chrono order, go ahead and add the massive 6.0 release
API overhaul (sed script lines) |
| 17:39.14 |
CIA-68 |
BRL-CAD:
03brlcad * r45024 10/brlcad/trunk/include/ (Makefile.am sed4): the
old sed4 script is no more. see doc/deprecation for the goods and
additional API changes. |
| 17:53.55 |
CIA-68 |
BRL-CAD:
03brlcad * r45025 10/brlcad/trunk/doc/deprecation.txt: |
| 17:53.55 |
CIA-68 |
BRL-CAD:
BU_INIT_EXTERNAL() to be renamed to BU_EXTERNAL_INIT() so the API
is consistent. |
| 17:53.55 |
CIA-68 |
BRL-CAD: same
for RT_INIT_DB_INTERNAL. both have been around for a long while, so
some |
| 17:53.55 |
CIA-68 |
BRL-CAD:
external code updates shold be expected. alas, they are still
minimally |
| 17:53.55 |
CIA-68 |
BRL-CAD:
impacting API changes. |
| 17:56.50 |
CIA-68 |
BRL-CAD:
03davidloman * r45026
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java:
Remove try/catch block from NetMsgFactory.makeMsg() We want any
exceptions to be thrown to the caller of NetMsgFactory.makeMsg() so
they can deal with it appropriately. |
| 17:59.44 |
CIA-68 |
BRL-CAD:
03Sean 07http://brlcad.org * r2921
10/wiki/Community_Publication_Portal: as more API changes are made,
we'll need to talk about the deprecation process |
| 18:00.53 |
CIA-68 |
BRL-CAD:
03brlcad * r45027 10/brlcad/trunk/ (25 files in 13
dirs): |
| 18:00.53 |
CIA-68 |
BRL-CAD:
rename BU_INIT_EXTERNAL() to BU_EXTERNAL_INIT() so that the API is
consistent. |
| 18:00.53 |
CIA-68 |
BRL-CAD: as
this symbol is so frequently used, it's likely to affect external
codes but |
| 18:00.53 |
CIA-68 |
BRL-CAD: the
change is still minimally impacting and trivial to
accommodate. |
| 18:09.20 |
CIA-68 |
BRL-CAD:
03starseeker * r45028 10/brlcad/trunk/src/other/dlists/ (19 files):
Whoops - helps to commit everything. |
| 18:09.42 |
starseeker |
brlcad: erm.
what did noinst_BINARIES do? |
| 18:10.47 |
starseeker |
if you want
to build a binary that you're not wanting to install, just do
add_executable followed by target_link_libraries |
| 18:11.33 |
starseeker |
take a look
at htester and timetester in libbu |
| 18:14.07 |
CIA-68 |
BRL-CAD:
03brlcad * r45029 10/brlcad/trunk/ (5 files in 4 dirs): rename
RT_CK_DBTR and RT_DBTR_MAGIC to RT_CK_DB_TRAVERSE and
RT_DB_TRAVERSE_INIT for api consistency. |
| 18:19.32 |
CIA-68 |
BRL-CAD:
03brlcad * r45030 10/brlcad/trunk/doc/deprecation.txt: last jump,
renaming all of the RT_INIT_[type] macros to RT_[type]_INIT for API
consistency. this unfortunately affects a LOT of code (including
3rd party) but it's minimally impacting and improves the
API. |
| 18:21.25 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 18:24.10 |
CIA-68 |
BRL-CAD:
03brlcad * r45031 10/brlcad/trunk/doc/deprecation.txt:
RT_INIT_DB_INTERNAL is included in the more general case so remove
it |
| 18:27.41 |
CIA-68 |
BRL-CAD:
03brlcad * r45032 10/brlcad/trunk/ (93 files in 32 dirs): API
consistency overhaul. all struct INIT routines are now all
RT_[type]_INIT() instead of being a mix of INIT before and after
the type. 's/RT_INIT_([A-Z_]*)/RT_\1_INIT/g' |
| 18:28.20 |
CIA-68 |
BRL-CAD:
03brlcad * r45033 10/geomcore/trunk/ (5 files in 3 dirs): update to
the API changes on trunk for libbu and libbn. INIT now trails the
type. you'll have to update your installed brlcad headers for this
one. |
| 18:30.56 |
CIA-68 |
BRL-CAD:
03davidloman * r45034
10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NetMsgChangeTracker.java:
Loosen restrictions on NetMsgChangeTracker. Make it a simple data
container. Shift from using byte to int for change value. No need
to optimize memory useage quite yet. |
| 18:31.03 |
CIA-68 |
BRL-CAD:
03brlcad * r45035 10/brlcad/trunk/misc/Doxyfile: BU_EXTERN is no
more |
| 18:31.40 |
CIA-68 |
BRL-CAD:
03brlcad * r45036 10/geomcore/trunk/doc/doxygen/Doxyfile.in:
BU_EXTERN is no more |
| 18:32.57 |
brlcad |
starseeker:
it does exactly what you described, builds but doesn't install --
so then what do I add to install it in addition to add_exec and
target_link_.. ? |
| 18:35.15 |
brlcad |
mmmmee no
likie the .dist files .. that's even more error prone than how we
do it for autotools... |
| 18:36.21 |
brlcad |
should at
least be localized to each dir's CMakeLists.txt file akin to
EXTRA_DIST, not in some remote dir (out of sight, out of
mind) |
| 18:36.50 |
brlcad |
better would
be to pull the svn manifest |
| 18:37.09 |
starseeker |
I'm trying to
set this up so we don't have to put anything extra in the src/other
directory in cases where the src/other directory has its own
CMakeLists.txt file |
| 18:38.06 |
starseeker |
previously
everything was in src/other/CMakeLists.txt, which was really
messing with the readibility of that file |
| 18:38.15 |
brlcad |
is the
problem because there's just one CMakeLists.txt file for all of the
src/other targets? |
| 18:38.46 |
starseeker |
no - the
problem is we can't count on src/other CMake logic to give us what
we need for distcheck |
| 18:39.58 |
starseeker |
I have been
working very hard with the src/other design to get as close as I
possibly can to being able to just "drop in" a CMakeified src/other
library and have it "just work" |
| 18:40.17 |
brlcad |
the problem
is the separation of the file list from the actual files ..
instantly out of sync and the dev can't really be faulted for
missing it |
| 18:40.46 |
starseeker |
make
distcheck will show it instantly (first thing checked, in
fact) |
| 18:41.07 |
brlcad |
what about at
least making the files more visible? |
| 18:41.20 |
starseeker |
how-so?
store them toplevel in src/other? |
| 18:41.22 |
brlcad |
mv
dlists/*.dist . |
| 18:41.28 |
starseeker |
I did that
initially, but it seemed messy |
| 18:41.28 |
brlcad |
make the file
name match the dir name |
| 18:41.46 |
brlcad |
it is messy,
but less error prone |
| 18:41.53 |
starseeker |
shrugs - sure, not a problem |
| 18:42.02 |
brlcad |
hopefully
reminded every time you cd into a dir to add/update a file that
there is a dist list that probably needs updating |
| 18:42.14 |
starseeker |
nods |
| 18:44.12 |
brlcad |
does
distcheck look at the svn manifest to compare then? |
| 18:44.56 |
starseeker |
not in that
stage |
| 18:45.06 |
starseeker |
it's using
the CMake build logic itself |
| 18:45.14 |
brlcad |
how does it
know when something is missing? |
| 18:46.20 |
starseeker |
there's an
error routine that reports when you try to ignore something that
isn't present, and CMake itself wipes out if you try to call out a
file in the build logic that isn't there |
| 18:46.45 |
brlcad |
unrelated,
was the 7.20.0 windows release made with cmake or the msvc files?
someone asking if step-g is included |
| 18:46.49 |
starseeker |
I was
assuming we wanted it to function without svn... |
| 18:47.23 |
starseeker |
CMake, but
step-g doesn't build on Windows right now |
| 18:47.30 |
starseeker |
(that depends
on the flex/byacc stuff) |
| 18:47.56 |
starseeker |
That's high
on my todo list, once I get my current mess cleaned up |
| 18:48.57 |
starseeker |
brlcad: I'm
in-process on reworking the distcheck logic - I didn't really want
to commit yet, but it was getting too complex to keep going without
some sort of checkpoint - I'll give a shout-out when it looks ready
for testing |
| 18:50.24 |
brlcad |
definitely
should work if SVN isn't available, but doesn't mean it can't
leverage when it clearly is available too |
| 18:51.10 |
brlcad |
that's what
autotools distcheck does now (see dist-hook: in top-level
Makefile.am, first line) |
| 18:51.46 |
CIA-68 |
BRL-CAD:
03starseeker * r45037 10/brlcad/trunk/ (40 files in 4 dirs): move
the dist lists to src/other toplevel. |
| 18:51.57 |
brlcad |
basically,
for any entries files it finds (i.e., manifest files), make sure
the files listed are in the dist |
| 18:51.59 |
starseeker |
brlcad: I've
got two separate checks - one to see if the build logic covers the
files, and then (if svn is available) to see if svn status reports
anything |
| 18:52.22 |
brlcad |
svn
status? |
| 18:52.32 |
starseeker |
checks for
un-committed changes |
| 18:52.37 |
brlcad |
hm,
ok |
| 18:52.39 |
starseeker |
or files svn
doesn't know about |
| 18:52.54 |
brlcad |
I always have
dozens or hundreds of those, works in progress |
| 18:53.28 |
starseeker |
the
assumption is that for a tarball build a clean checkout will be
used - CPack grabs everything not on it's exclude list |
| 18:53.59 |
brlcad |
that'll take
some getting used to |
| 18:54.53 |
starseeker |
's take on it was that it's way simpler to do a clean
checkout and use that than to try and maintain all the logic to
sort out what should and shouldn't be included from a working
tree |
| 18:55.26 |
brlcad |
simpler, sure
.. but much more time consuming :) |
| 18:55.45 |
starseeker |
really? for
me a clean tree checkout is a drob in the bucket compared to the
rest of the checklist |
| 18:56.19 |
starseeker |
I usually do
it anyway just to try and make sure I haven't messed up getting
something in to svn |
| 18:57.12 |
brlcad |
well that's
why it's also important to make the dist, then do distchecks on the
dist tarball since that's what's actually uploaded |
| 18:57.25 |
brlcad |
that's my
"clean checkout" there |
| 18:57.52 |
brlcad |
no extra
download, I should test the final build regardless |
| 19:00.32 |
brlcad |
no matter,
the bigger issue is that we make sure all files that are in a
checkout are in the dist (including simple doc/text files that
aren't listed in build rules) -- however that happens |
| 19:01.00 |
starseeker |
nods - let me finish ironing out the bugs of this rework and
I'll volunteer it for a stress test |
| 19:02.09 |
brlcad |
pulling the
manifest is the easiest (only?) way to ensure files get
included |
| 19:02.14 |
brlcad |
nods |
| 19:09.43 |
CIA-68 |
BRL-CAD:
03starseeker * r45038 10/brlcad/trunk/src/other/dlists/: remove
dlists dir |
| 19:10.55 |
brlcad |
starseeker:
new files missing from src/other/Makefile.am :) ... have to
maintain both just a while longer |
| 19:12.09 |
CIA-68 |
BRL-CAD:
03starseeker * r45039
10/brlcad/trunk/src/other/togl/demo/CMakeLists.txt: rather than
turning this off completely, disable it on WIN32 for now. Should
eventually fix this |
| 19:13.24 |
starseeker |
brlcad: yeah,
I know - figured I'd update those when the dust settles |
| 19:16.24 |
brlcad |
only
mentioning it because it'll halt my build testing in the meantime
-- I have a continuous distcheck build loop going for all of the
API changes I've been making |
| 19:16.40 |
brlcad |
lots more to
go, so it helps make sure I don't accidentally break the build for
more than a few minutes |
| 19:18.26 |
starseeker |
winces - sorry |
| 19:20.55 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 19:25.12 |
dloman |
oh dayum:
http://www.youtube.com/watch?v=PNFAsKwCCHw&feature=feedrec_grec_index |
| 19:40.48 |
brlcad |
bhinesley: if
you're looking for a refactoring, merging erase and erase_all into
one command would be a good one |
| 19:41.28 |
brlcad |
the latter as
an option to the prior, unify syntax |
| 19:42.08 |
bhinesley |
alright, that
sounds good. I'm trying to see what migrating oed is going to take
right now. |
| 19:42.39 |
starseeker |
bhinesley:
heh - watch out for that one |
| 19:42.48 |
bhinesley |
er rather,
oed-related translations, since we want it stateless |
| 19:43.41 |
bhinesley |
starseeker:
yeah, I'm starting to wonder what I got myself into :) |
| 19:43.56 |
starseeker |
brlcad: hrm.
how did you want to see oed translated into Archer, now that I
think about it? |
| 19:44.28 |
brlcad |
kunigami:
how's it going? progress on the crashes? |
| 19:45.25 |
brlcad |
fwiw, memory
leaks don't generally lead to crashes -- overrunning bounds and
resource contention do, though |
| 19:46.21 |
brlcad |
starseeker:
oed becomes a standard set of options for the translate, rotate,
and scale commands |
| 19:46.34 |
brlcad |
so oed itself
doesn't migrate, but what it does .. does |
| 19:46.44 |
brlcad |
i.e., sets up
a selection and a keypoint |
| 19:47.32 |
CIA-68 |
BRL-CAD:
03starseeker * r45040 10/brlcad/trunk/ (8 files in 8 dirs): Hmm.
OK, that's promising - distcheck called out some files that, upon
examination, make sense. This might do it, but needs a LOT more
checking/hammering. |
| 19:48.00 |
brlcad |
oed itself
might just turn into a simple keypoint option |
| 19:51.43 |
kunigami |
brlcad: I
kinda ignored the crashes by now, since it seems to be a
multi-thread issue. I've been using P=1 and no problems happened
until now |
| 19:57.42 |
CIA-68 |
BRL-CAD:
03starseeker * r45041 10/brlcad/trunk/src/other/ (URToolkit.dist
step.dist): couple dist additions that got swatted in the
move. |
| 19:57.44 |
brlcad |
ignoring
syntax and whatever the current code does, you basically have:
{translate|rotate|scale} [--keypoint
{bb_corner|bb_center}:{object_name} | {3d position}] [--relative
xdist [ydist [zdist]] | --absolute xpos [ypos [zpos]]]
[object(s)] |
| 19:58.45 |
brlcad |
not exact, of
course, since rotate is relative or absolute angles or ypr or aet
and scale is relative or aboslute scale factors |
| 19:59.19 |
brlcad |
but oed is
basically that --keypoint option |
| 20:00.12 |
brlcad |
specifically
one subset where it's bb_default which is usually the bottom left
corner of the object |
| 20:00.49 |
brlcad |
or some other
"natural" origin |
| 20:01.42 |
brlcad |
kunigami: ah,
okay .. so then if you got a disk shaded using your yellow osl
shader, what happens if you set it to one of the other default osl
shaders? |
| 20:02.22 |
kunigami |
I tried using
the mirror shader, but I renders to black, but I'm not doing
recursion right |
| 20:02.45 |
brlcad |
ouch |
| 20:02.48 |
brlcad |
wouldn't
start with mirror :) |
| 20:02.51 |
brlcad |
try something
diffuse :) |
| 20:03.26 |
brlcad |
they have a
phong or gouraud shader? |
| 20:04.00 |
kunigami |
the yellow
shader was a (perfect) diffuse one |
| 20:04.32 |
kunigami |
now, I don't
have such shader, but I can research about |
| 20:05.22 |
brlcad |
basically
implemented a flat shader, not really diffuse |
| 20:05.45 |
brlcad |
if it were a
curved surface, you should get highlight and shadow with
diffuse |
| 20:06.19 |
brlcad |
I wouldn't
spend time implementing shaders .. iirc, they had five or six
example shaders |
| 20:07.17 |
kunigami |
the yellow
shader is the same from the sphere of this image: http://kuniga.files.wordpress.com/2021/05/image.png |
| 20:07.39 |
kunigami |
maybe I'm not
setting up the global parameters (normal, incident ray)
correctly |
| 20:07.51 |
kunigami |
I'll try
assigning it to a sphere |
| 20:09.17 |
CIA-68 |
BRL-CAD:
03brlcad * r45042 10/brlcad/trunk/include/raytrace.h: DBTR got
expanded to DB_INTERNAL, no good. expand to
DB_TRAVERSE. |
| 20:11.47 |
brlcad |
looks like
some sort of path trace |
| 20:12.26 |
brlcad |
we have a
cornell box in the db directory iirc, so you can play with similar
scenes |
| 20:12.42 |
brlcad |
if not, it's
trivial to set one up |
| 20:13.07 |
CIA-68 |
BRL-CAD:
03starseeker * r45043
10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: Remove
debug messages |
| 20:15.30 |
kunigami |
yeah, I added
a sphere to the scene, but it was rendered as a yellow circle
>.< |
| 20:16.19 |
kunigami |
gotta take a
look at the parameters. just for clarification: u and v and their
dP/du and dP/dv are only useful if we're going to do some kind of
mapping, right? |
| 20:16.53 |
brlcad |
yes for u/v
.. what's the dP/du you're referring to? |
| 20:17.37 |
brlcad |
the normal
isn't necessarily calculated by default -- you'll probably need
that to calculate a diffuse falloff |
| 20:17.38 |
kunigami |
as far as I
understood P is the hit point and dP/du are the derivatives
regarding u and v directions |
| 20:18.05 |
kunigami |
hmm, I was
setting the normal from swp->sw_hit.hit_normal |
| 20:19.00 |
brlcad |
I'd make sure
that value has been calculated, you may need to call
RT_HIT_NORMAL() |
| 20:20.06 |
kunigami |
I added
MFI_NORMAL on mfuncs, but I'll double check |
| 20:20.32 |
brlcad |
ah, and for
the other, yes -- those are all curvature related values, for
texture/image mapping |
| 20:20.41 |
brlcad |
ah,
okay |
| 20:24.26 |
starseeker |
brlcad:
ERROR: bad pointer 0xd7fc488: s/b bu_vls(x89333bbb), was
Zero_Magic_Number(x0), file src/libbu/vls.c, line 301 |
| 20:24.41 |
starseeker |
shaders
regression test |
| 20:26.55 |
brlcad |
backtrace?
there was a couple places in the code that were calling
BU_VLS_INIT_IF_UNINIT() unreliably, may need an explicit
BU_VLS_INIT() now |
| 20:27.13 |
starseeker |
let me see if
I can generate one, hang on... |
| 20:27.21 |
brlcad |
it should
have auto-dumped one |
| 20:27.25 |
brlcad |
bomb.log |
| 20:29.41 |
starseeker |
hmm - don't
see it |
| 20:29.44 |
starseeker |
one
sec... |
| 20:30.31 |
CIA-68 |
BRL-CAD:
03brlcad * r45044 10/brlcad/trunk/TODO: merge erase/erase_all and
notes on oed migration |
| 20:30.35 |
brlcad |
*-bomb.log |
| 20:31.40 |
brlcad |
kunigami: you
may also need an osl light source for proper calcs, don't
know |
| 20:31.48 |
brlcad |
I do recall
an emitter shader for lights |
| 20:38.25 |
starseeker |
doesn't seem
to be dropping a bomb log |
| 20:38.29 |
brlcad |
k |
| 20:46.07 |
*** join/#brlcad CIA-62
(~CIA@cia.atheme.org) |
| 20:49.33 |
starseeker |
feeding
anything at all after the <<EOF seems to trigger the crash -
not specific to any one command |
| 20:49.50 |
starseeker |
(in
shaders.rt) |
| 20:50.00 |
*** join/#brlcad dli
(~dli@dsl-67-55-7-45.acanac.net) |
| 20:51.58 |
starseeker |
ah
hah |
| 20:51.58 |
CIA-62 |
BRL-CAD:
03brlcad * r45045 10/brlcad/trunk/src/libdm/dm-ogl.c: GL/gl.h needs
the same protection as glx.h did. encountered y1 shadow warnings on
mac 10.5, gcc4.0.1 |
| 20:52.42 |
CIA-62 |
BRL-CAD:
03brlcad * r45046 10/brlcad/trunk/src/mged/dm-ogl.c: GL headers
need the same protections used in libdm's dm-ogl.c file so we don't
get shadow warnings and compilation failure. |
| 20:55.10 |
starseeker |
brlcad: here
we go: http://pastebin.mozilla.org/1250287 |
| 20:56.00 |
CIA-62 |
BRL-CAD:
03brlcad * r45047 10/brlcad/trunk/src/libdm/focus.c: |
| 20:56.00 |
CIA-62 |
BRL-CAD: may
need revisiting, but unsetting and resetting __GNUC_MINOR__ (gcc
4.0.1, mac |
| 20:56.00 |
CIA-62 |
BRL-CAD:
10.5) leaves the compiler in some odd state where subsequent header
inclusion |
| 20:56.00 |
CIA-62 |
BRL-CAD:
still think it is undefined (even though #ifdef before their
inclusion shows it |
| 20:56.00 |
CIA-62 |
BRL-CAD:
is!). removing the protections makes things work again so will have
to |
| 20:56.00 |
CIA-62 |
BRL-CAD:
rediscover a different fix for whatever environment was failing if
it still |
| 20:56.01 |
CIA-62 |
BRL-CAD:
fails. |
| 21:28.11 |
*** join/#brlcad merzo
(~merzo@48-55-133-95.pool.ukrtel.net) |
| 21:29.51 |
kunigami |
brlcad: the
parameters seems right. the problem, I think, comes from the fact
that I'm not considering recursion. The osl-system returns only the
color of the sphere, but I think the attenuation will depend on the
ray going out towards the light and the sphere normal |
| 21:54.42 |
*** join/#brlcad crazy_imp
(~mj@a89-182-252-199.net-htp.de) |
| 22:33.51 |
CIA-62 |
BRL-CAD:
03brlcad * r45048 10/brlcad/trunk/src/libbu/brlcad_path.c: can't
bu_free() a static buffer. supposed to be tmp_basename from
bu_basename(). |
| 22:59.32 |
*** join/#brlcad DarkCalf
(DC@2002:ade7:2862::ade7:2862) |
| 23:01.25 |
CIA-62 |
BRL-CAD:
03brlcad * r45049 10/brlcad/trunk/src/libbu/basenametester.c: quell
warning, call bu_fgets() instead of calling fgets()
directly. |
| 23:08.38 |
CIA-62 |
BRL-CAD:
03bhinesley * r45050 10/brlcad/trunk/ (13 files in 8
dirs): |
| 23:08.39 |
CIA-62 |
BRL-CAD:
Removed all occurences of erase_all command and the dall alias. The
same |
| 23:08.39 |
CIA-62 |
BRL-CAD:
operation is now performed by "erase -r". Usage statement corrected
to no longer |
| 23:08.39 |
CIA-62 |
BRL-CAD:
print first arg instead of cmd name. Fixed ArcherCore::erase that
was using |
| 23:08.39 |
CIA-62 |
BRL-CAD:
lappend without initialization. Updated NEWS. |
| 23:09.35 |
bhinesley |
hm. it says
that the commit failed |
| 23:23.53 |
bhinesley |
good god sf,
it's one line, commit already |
| 23:26.47 |
CIA-62 |
BRL-CAD:
03bhinesley * r45051 10/brlcad/trunk/src/libged/erase.c: Revised
usage statement to make it clear that if -r is specified, all other
options are ignored. |
| 23:27.50 |
bhinesley |
puts away the plunger |
| 23:42.14 |
*** join/#brlcad piksi_ (piksi@pi-xi.net) |
| 23:42.18 |
*** join/#brlcad dloman_
(~claymore@BZ.BZFLAG.BZ) |
| 23:43.08 |
CIA-62 |
BRL-CAD:
03brlcad * r45052 10/brlcad/trunk/regress/shaders.sh: document in
detail why shaders must run single-threaded (it's because of the
random transparency shader). also pass extra parameters normally --
no need for them to be in the rt script file. |
| 23:44.51 |
CIA-62 |
BRL-CAD:
03brlcad * r45053
10/brlcad/trunk/src/liboptical/sh_prj.c: |
| 23:44.52 |
CIA-62 |
BRL-CAD: fix
the uninitialized vls bug reported by starseeker. indeed, the
source name |
| 23:44.52 |
CIA-62 |
BRL-CAD: of
the shader was not being initialized properly before bu_structparse
expands a |
| 23:44.52 |
CIA-62 |
BRL-CAD: %V
table entry and calls bu_vls_strcpy(). instead of just initializing
the vls, |
| 23:44.52 |
CIA-62 |
BRL-CAD:
though, go ahead and initialize the entire img_specific struct just
because it's |
| 23:44.53 |
CIA-62 |
BRL-CAD: the
awesome thing to do. profile showed performance unaffected by the
setup |
| 23:44.54 |
CIA-62 |
BRL-CAD:
memcpy(). |
| 23:52.13 |
*** part/#brlcad bhinesley
(~bhinesley@99.144.90.118) |
| 23:52.20 |
*** join/#brlcad bhinesley
(~bhinesley@99.144.90.118) |
| 23:59.59 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 23:59.59 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net) |
| 01:20.46 |
CIA-62 |
BRL-CAD:
03brlcad * r45109 10/brlcad/trunk/include/bu.h: prefix all doxygen
file markers with the library they belong to in order to avoid
conflicts with same-named files in other directories being
processed simultaneously. |
| 02:10.22 |
CIA-62 |
BRL-CAD:
03brlcad * r45110 10/brlcad/trunk/include/bu.h: this file isn't in
the libbu dir |
| 02:11.22 |
CIA-62 |
BRL-CAD:
03brlcad * r45111 10/brlcad/trunk/src/libbn/ (22 files): prefix all
of the doxygen file commands with libbn so we don't conflict with
same-named files in other directories |
| 02:22.22 |
CIA-62 |
BRL-CAD:
03brlcad * r45112 10/brlcad/trunk/src/ (425 files in 15 dirs):
prefix all of the library @file doxygen commands with the library
dir/name in order to avoid conflicts with same-named files in other
directories. was causing processing woes. |
| 02:26.07 |
CIA-62 |
BRL-CAD:
03brlcad * r45113 10/brlcad/trunk/src/ (168 files in 5 dirs): more
@file prefixing in order to deconfuse doxygen bulk processing where
file names are non-unique. |
| 02:40.31 |
CIA-62 |
BRL-CAD:
03brlcad * r45114 10/brlcad/trunk/src/ (469 files in 10 dirs): more
@file directive clarification for doxygen to avoid naming conflicts
with other same-named files in other directories. |
| 02:43.38 |
CIA-62 |
BRL-CAD:
03brlcad * r45115 10/brlcad/trunk/src/ (59 files in 3 dirs): few
more @file doxygen conflict cases |
| 02:44.14 |
CIA-62 |
BRL-CAD:
03brlcad * r45116 10/brlcad/trunk/src/proc-db/brep_cube.cpp: proper
header |
| 03:13.07 |
CIA-62 |
BRL-CAD:
03brlcad * r45117 10/brlcad/trunk/src/proc-db/ (brep_cube.cpp
brep_simple.cpp csgbrep.cpp): header cleanup, refer to the proper
filename |
| 03:17.22 |
CIA-62 |
BRL-CAD:
03brlcad * r45118 10/brlcad/trunk/src/vfont/vfont.h: filename is
vfont |
| 03:21.09 |
CIA-62 |
BRL-CAD:
03brlcad * r45119 10/brlcad/trunk/include/vector_fpu.h: add missing
common.h include for UNUSED() definition. |
| 03:25.55 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 07:02.21 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 08:16.14 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 09:05.10 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.214.98) |
| 09:05.10 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:56.20 |
CIA-62 |
BRL-CAD:
03Kunigami 07http://brlcad.org *
r2924 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports
*/ |
| 10:57.57 |
CIA-62 |
BRL-CAD:
03Kunigami 07http://brlcad.org *
r2925 10/wiki/User:Kunigami/GSoc2011/Proposal: /* Timeline */
updated timeline |
| 14:28.53 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 14:37.35 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.151.196) |
| 14:37.35 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:50.11 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45120 10/brlcad/trunk/include/raytrace.h: Some
parsers freak out when they see */*stp*/, thinking it's an end of
comment. Adding a space seems to make them happy. |
| 15:11.48 |
brlcad |
wb |
| 15:12.31 |
``Erik |
yargh |
| 15:12.43 |
``Erik |
vacations
never last long enough. :/ |
| 15:22.20 |
CIA-62 |
BRL-CAD:
03brlcad * r45121 10/brlcad/trunk/src/ (52 files in 7 dirs): (log
message trimmed) |
| 15:22.20 |
CIA-62 |
BRL-CAD:
remove the SCLLOG/SCLBOOL wrappers on the SCL Boolean and Logical
enums. they |
| 15:22.20 |
CIA-62 |
BRL-CAD: were
being conditionally put into a namespace in order to be protected
in case |
| 15:22.20 |
CIA-62 |
BRL-CAD:
they're used within a 3rd party context (like CORBA) that might
also define |
| 15:22.20 |
CIA-62 |
BRL-CAD:
same-named enums, but the macrofied protection just adds
complexity. iff a |
| 15:22.21 |
CIA-62 |
BRL-CAD:
conflict is encountered, the types can be put into an SCL or P23 or
SDAI |
| 15:22.22 |
CIA-62 |
BRL-CAD:
namespace. 'Boolean' would be prime for outright
removal/replacement with |
| 15:22.36 |
brlcad |
kunigami:
make sure all files you add have a proper header and footer, e.g.:
sh/header.sh lgpl src/liboptical/osl-renderer.cpp |
| 15:23.30 |
brlcad |
sh/header.sh,
sh/footer.sh, or sh/template.sh (to apply both header and
footer) |
| 15:23.58 |
brlcad |
sh/ws.sh and
sh/indent.sh will clean up the formatting so it's consistent with
the rest of the source code |
| 15:24.50 |
brlcad |
just make
sure any cleanup commits aren't mixed with actual code/logic
changes |
| 15:40.15 |
CIA-62 |
BRL-CAD:
03kunigami * r45122
10/brlcad/trunk/src/liboptical/osl-renderer.cpp: Cleaning up
formatting of osl-renderer.cpp |
| 15:50.21 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45123 10/brlcad/trunk/src/other/m4/lib/ohash.h:
include sys/types.h for u_int32_t |
| 16:28.43 |
CIA-62 |
BRL-CAD:
03starseeker * r45124 10/brlcad/trunk/src/other/m4/ (eval.c gnum4.c
main.c misc.c): Try the BRL-CAD wrapper for unistd.h
here... |
| 16:31.10 |
kunigami |
when I run
indent with osl-renderer.h it changes spacing to 2 while in
osl-renderer.cpp it keeps 4. it that the default? |
| 16:34.11 |
kunigami |
hmm, actually
I'd rather ask why footer.sh does not add "c-basic-offset: 4"
line? |
| 16:48.32 |
CIA-62 |
BRL-CAD:
03starseeker * r45125 10/brlcad/trunk/src/other/m4/lib/libyywrap.c:
Hmm - MSVC doesn't like __P for some reason. |
| 16:49.32 |
CIA-62 |
BRL-CAD:
03kunigami * r45126 10/brlcad/trunk/src/liboptical/
(osl-renderer.cpp osl-renderer.h osl_rt.cpp osl_rt2.c): formatting
changes for several files |
| 16:50.21 |
CIA-62 |
BRL-CAD:
03starseeker * r45127
10/brlcad/trunk/src/other/m4/generated/tokenizer.c: one more
unistd.h case |
| 16:52.44 |
CIA-62 |
BRL-CAD:
03kunigami * r45128
10/brlcad/trunk/src/liboptical/osl-renderer.cpp: typo on
osl-renderer.cpp local variables |
| 16:53.23 |
brlcad |
starseeker:
egads man |
| 16:53.56 |
brlcad |
if you had to
paste it just twice .. should've been a hint to refactor
:) |
| 16:54.21 |
brlcad |
put that mess
into a header and just #include it... |
| 16:57.27 |
brlcad |
I know you're
just trying to "get it to work" .. but egads .. that's passing the
buck and really making more work for later |
| 16:59.35 |
CIA-62 |
BRL-CAD:
03starseeker * r45129 10/brlcad/trunk/src/other/m4/ (eval.c
extern.h gnum4.c main.c mdef.h): Remove the doesyscmd option from
the m4 logic. May have to revisit this if it turns out later we
need it, but this will be problematic on Win32. |
| 17:00.45 |
brlcad |
also, fwiw,
__P is undoubtedly defined like BU_ARGS() used to be .. it makes
the parameter list conditional |
| 17:01.17 |
brlcad |
the __P
protection belongs where it's defined, not where it was used in
libyywrap.c |
| 17:04.43 |
CIA-62 |
BRL-CAD:
03starseeker * r45130 10/brlcad/trunk/src/other/m4/ (14 files in 2
dirs): |
| 17:04.43 |
CIA-62 |
BRL-CAD:
Hack, slash and burn approach to MSVC building - this has lots of
unresolved |
| 17:04.43 |
CIA-62 |
BRL-CAD:
external symbols and may not function at all anywhere, but it
should indicate |
| 17:04.43 |
CIA-62 |
BRL-CAD: what
further changes are needed. Will also need regex linked in, need to
take |
| 17:04.43 |
CIA-62 |
BRL-CAD: care
of that. |
| 17:05.02 |
brlcad |
kunigami:
c-file-style: "Stroustrup" sets 4-char indents |
| 17:06.27 |
starseeker |
brlcad: oh, I
know - I've got a lot of refactoring to do - I'm just trying to get
a feel for the scope of what's needed |
| 17:06.37 |
kunigami |
that's
strange. even with that line indent.sh used 2 spaces. When I added
c-basic-offset:4 it correclty used 4 |
| 17:07.00 |
starseeker |
brlcad: it
wasn't immediately clear how deep into "unixy" coding this m4
was |
| 17:10.02 |
CIA-62 |
BRL-CAD:
03brlcad * r45131 10/brlcad/trunk/src/liboptical/osl-renderer.h:
restructure around a WITH_OSL keyword instead of __cplusplus since
it should always be possible to compile the sh_osl C
interface. |
| 17:11.07 |
brlcad |
starseeker:
http://gnuwin32.sourceforge.net/packages/m4.htm |
| 17:11.50 |
brlcad |
enough to
warrant someone making a fork instead of trying to make it
portable |
| 17:11.57 |
brlcad |
but then that
could have just been laziness or simplicity |
| 17:12.14 |
starseeker |
nods - yeah, saw that - but this isn't GNU
m4 |
| 17:12.25 |
starseeker |
it's the
netbsd port of the openbsd m4 |
| 17:12.41 |
starseeker |
was going for
the smallest m4 that looked like it might have a hope of working
with flex |
| 17:12.55 |
starseeker |
both for
build simplicity/porting simplicity and to keep the size of
src/other smaller :-P |
| 17:13.25 |
starseeker |
so far this
feels a lot like working with the find code for the search
command |
| 17:13.54 |
kunigami |
brlcad: I
didn't understand your changes to osl-renderer.h. It was already
possible to compile with sh_osl C interface. |
| 17:14.34 |
brlcad |
if we really
wanted simplicity and a small src/other, we'd just generate the
files, add them to svn, and compile those on windows :) |
| 17:14.39 |
CIA-62 |
BRL-CAD:
03starseeker * r45132 10/brlcad/trunk/src/other/m4/lib/libyywrap.c:
Ah, that's why cdefs was included here. Win32 doesn't have cdefs,
so be more direct... |
| 17:15.02 |
brlcad |
way more
simple than these 3-4 new dependencies, build system mods,
maintenance woes |
| 17:15.20 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
| 17:15.21 |
kunigami |
the reason
for __cplusplus was that C++ code would see a different interface
than C code |
| 17:16.31 |
brlcad |
kunigami:
which C++ code? |
| 17:16.56 |
kunigami |
brlcad:
osl-renderer.cpp which is an interface to osl system |
| 17:17.25 |
kunigami |
both
osl-renderer.cpp and sh_osl.c share the interface
osl-renderer.h |
| 17:18.05 |
brlcad |
iirc,
technically doesn' sh_osl.c only "share" the inteface via the C
callbacks declared at the bottom of osl-renderer.h? |
| 17:18.26 |
*** join/#brlcad yukonbob
(~bch@S0106002191d1591c.ok.shawcable.net) |
| 17:18.26 |
brlcad |
it's "declare
class" or "declare typedefs and C funcs" |
| 17:18.31 |
yukonbob |
hello,
#brlcad |
| 17:18.41 |
brlcad |
rather, it
was |
| 17:18.46 |
brlcad |
hello
yukonbob |
| 17:19.26 |
brlcad |
kunigami:
something to consider, sh_osl doesn't have to be C -- it can be a
C++ file |
| 17:19.55 |
brlcad |
so you can
call right into osl-renderer.h classes |
| 17:20.17 |
brlcad |
the only
protection really necessary is whether we have OSL or
not |
| 17:21.18 |
brlcad |
that was the
motivation, move towards blocking based on the build feature, since
the compilation of the interface file is already
built-in |
| 17:22.35 |
kunigami |
I'm not sure
if I understood what you meant, but when OSL is not enabled,
osl-renderer.h is not even compiled. |
| 17:23.42 |
brlcad |
right, it's
either on and OSL is available or it's off |
| 17:23.51 |
brlcad |
sh_osl.c
doesn't get compiled if it's off, right? |
| 17:23.56 |
kunigami |
yup |
| 17:24.10 |
kunigami |
I added a
conditional on CMakeLists.txt |
| 17:24.28 |
brlcad |
so then if
it's only on when osl is compiled, and osl is c++, then sh_osl can
be c++ |
| 17:24.41 |
brlcad |
and the c
wrapping isn't needed |
| 17:25.07 |
brlcad |
just adds
complexity and code that won't ever get executed/used |
| 17:25.22 |
brlcad |
make
sense? |
| 17:25.32 |
kunigami |
brlcad:
right. I didn't know that sh_osl could be c++. |
| 17:26.01 |
brlcad |
yep, you
could svn mv sh_osl.c sh_osl.cpp if you really wanted |
| 17:26.18 |
brlcad |
the only
important part is that C++ types aren't publicly exposed by
liboptical |
| 17:26.56 |
brlcad |
so if you
find yourself needing to add a C++ class / typedef into a header
file in the top-level include/ directory, then it might be an issue
and require some rethought |
| 17:27.24 |
kunigami |
but if sh_osl
is C++ then I'll have to export functions using "extern C" anyway,
because AFAIK C++ exports mangled functions names |
| 17:27.52 |
brlcad |
sure, if you
call C functions |
| 17:28.11 |
brlcad |
and call them
outside that compilation unit |
| 17:28.43 |
brlcad |
the c
functions you had looked like logic that wouldn't need to live in
osl-renderer, they'd just be part of the logic in
sh_osl.c |
| 17:28.47 |
brlcad |
er
sh_osl.cpp |
| 17:29.24 |
brlcad |
i.e., you
don't need wrappers, you'd just create OSL_Renderer objects and use
them |
| 17:29.44 |
kunigami |
perfect |
| 17:29.50 |
kunigami |
I'll give it
a try |
| 17:30.32 |
brlcad |
at most,
you'd maybe have to stash an OSL_Renderer* object into a struct so
you could pass it around as a void* through the various liboptical
callback functions |
| 17:30.42 |
brlcad |
(the 'dpp'
parameter) |
| 17:30.56 |
brlcad |
that's a user
data pointer |
| 17:31.22 |
brlcad |
and that's
only because c++ forbids casting objects through void*, have to
stash in struct and cast the struct through void* |
| 17:32.00 |
brlcad |
make sure you
quell all warnings ;) |
| 17:32.44 |
kunigami |
right |
| 17:34.35 |
brlcad |
starseeker:
those big repeated code blocks are more a mentality issue, not
letting yourself create extra work in the first place |
| 17:35.14 |
*** join/#brlcad crazy_imp
(~mj@a89-182-170-199.net-htp.de) |
| 17:35.56 |
brlcad |
plus, i've
heard you say something to the effect of "I've got a lot of
refactoring to do" |
| 17:35.59 |
brlcad |
with plans to
clean some bit of code up "later" on at least three other occasions
now :D |
| 17:36.24 |
brlcad |
and that
"later" never manifested itself |
| 17:36.54 |
brlcad |
code
complete, deep not wide |
| 17:45.04 |
brlcad |
kunigami: not
sure about the 2 vs 4 indents -- maybe something in your .emacs
file? if I move mine out of the way, I get 4char
indents |
| 17:45.10 |
CIA-62 |
BRL-CAD:
03starseeker * r45133 10/brlcad/trunk/src/other/m4/ (common.h
eval.c gnum4.c main.c misc.c pstdint.h): move unistd.h wrapper to
common file, add portability guarantee with pstdint.h |
| 17:52.33 |
CIA-62 |
BRL-CAD:
03starseeker * r45134 10/brlcad/trunk/src/other/m4/ (expr.c look.c
trace.c): Replace a few direct calls to stdint.h |
| 17:53.40 |
CIA-62 |
BRL-CAD:
03brlcad * r45135 10/brlcad/trunk/src/other/m4/lib/libyywrap.c:
even simpler, it's a preansiism |
| 17:59.14 |
CIA-62 |
BRL-CAD:
03starseeker * r45136 10/brlcad/trunk/src/other/m4/
(generated/tokenizer.c parser.y tokenizer.l): Ah, hiding in the
tokenizer. Should get us down to the regex header. |
| 18:00.44 |
CIA-62 |
BRL-CAD:
03starseeker * r45137 10/brlcad/trunk/src/other/m4/lib/ohash_int.h:
Nope, one more - ohash |
| 18:05.46 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45138
10/brlcad/trunk/src/other/m4/generated/parser.c: remove stdint.h in
favor of common.h/pstdint.h |
| 18:06.49 |
*** join/#brlcad yukonbob
(~bch@S0106002191d1591c.ok.shawcable.net) |
| 18:09.59 |
CIA-62 |
BRL-CAD:
03starseeker * r45139 10/brlcad/trunk/src/other/m4/ (CMake/
CMake/FindREGEX.cmake CMakeLists.txt): Add logic to locate and link
in regex library. |
| 18:14.20 |
brlcad |
starseeker:
so how's the prognosis looking ... have a thought that might make
the effort somewhat moot |
| 18:14.32 |
starseeker |
brlcad: not
bad, actually |
| 18:14.36 |
starseeker |
at least, not
so far |
| 18:14.41 |
starseeker |
what's the
though? |
| 18:15.10 |
brlcad |
ditch
lex/yacc for antlr |
| 18:15.10 |
CIA-62 |
BRL-CAD:
03starseeker * r45140 10/brlcad/trunk/src/other/m4/CMakeLists.txt:
Dur - try linking the library, not compiling it. |
| 18:15.26 |
brlcad |
it's half the
code side and supports windows |
| 18:15.42 |
starseeker |
huh, never
heard of it before |
| 18:15.43 |
brlcad |
but would
require rewriting our few existing lex/yacc files in their syntax
(which is nearly identical) |
| 18:15.50 |
starseeker |
reads... |
| 18:17.03 |
starseeker |
brlcad: it's
java based? |
| 18:18.24 |
starseeker |
or are you
looking at the C runtime distributions? |
| 18:19.01 |
brlcad |
http://www.antlr.org/wiki/display/ANTLR3/Five+minute+introduction+to+ANTLR+3 |
| 18:23.03 |
brlcad |
another
tutorial:
http://supportweb.cs.bham.ac.uk/docs/tutorials/docsystem/build/tutorials/antlr/antlr.html |
| 18:23.53 |
starseeker |
don't we need
java to run antlr and generate the code though? |
| 18:26.13 |
brlcad |
either hook
in the java binary (which we could probably bundle precompiled if
it's small enough), or compile them via the C runtime (which is
about 25k lines of code, about the size of flex) |
| 18:27.03 |
brlcad |
if I'm
understanding their setup correctly, that would even be more ideal
than the lex/yacc approach for things like libgcv where we just
want the parsing functions, not a main() |
| 18:28.06 |
brlcad |
of course,
the java app may still be required to compile the functions and
then the C runtime to use them, not 100% sure on that
detail |
| 18:28.13 |
starseeker |
I'm trying to
figure out if the runtime can eat the grammer and execute code, or
if you still need the java tools to generate the code |
| 18:28.17 |
starseeker |
er, yeah
:-) |
| 18:29.51 |
starseeker |
I'm thinking
you need java to compile the grammar - I just built libantlr3c and
there's no tool I can see to generate C code... |
| 18:30.34 |
starseeker |
I did a
survey a while back looking for lex/yacc alternatives that were in
C and I remember coming up rather short... |
| 18:33.12 |
starseeker |
hmm... |
| 18:33.26 |
starseeker |
brlcad: maybe
http://www.hwaci.com/sw/lemon/
? |
| 18:35.06 |
starseeker |
if we're
willing to rewrite our definitions, that might be a way to
go |
| 18:35.54 |
*** join/#brlcad crazy_imp
(~mj@a89-182-141-171.net-htp.de) |
| 18:36.25 |
kunigami |
I didn't know
in C it's allowed to set a function like "void foo(int x)" to a
function pointer "void (*fp)()". In C++ it seems it is not allowed.
Any suggestions? |
| 18:36.55 |
brlcad |
starseeker:
it'd be worth giving it a try, maybe start with the simple parser
in src/mged/points |
| 18:37.42 |
brlcad |
that's a
prime simple test case for conversion, if it works, that'd probably
be good enough proof of concept to run forward with it |
| 18:39.09 |
brlcad |
not nearly as
complicated as the others |
| 18:39.23 |
starseeker |
nods - sounds good |
| 18:39.24 |
brlcad |
kunigami: I'm
working on fixing that right now |
| 18:39.39 |
brlcad |
kunigami:
that's an old carry-over from k&r days of C |
| 18:39.57 |
kunigami |
brlcad: ok,
thanks! |
| 18:42.11 |
brlcad |
c++ has the
same behavior as the concept of "calling a function" in either is
as simple as jumping to a pointer address |
| 18:42.39 |
brlcad |
it just adds
type safety during compilation so it can enforce only jumping to a
"compatible" address |
| 18:44.07 |
yukonbob |
starseeker:
what are you looking for lex/yacc alternatives for? |
| 18:44.34 |
brlcad |
C will
happily jump to whatever you ask, compiler won't even warn by
default unless you ask it to |
| 18:44.47 |
kunigami |
hmm
interesting |
| 18:45.08 |
starseeker |
yukonbob: we
need to be able to handle a (potentially large) number of grammar
definitions for geometry format conversion (and other uses, like
MGED's point abilities) |
| 18:45.35 |
starseeker |
we also need
to be portable, and (right now) recent flex versions aren't working
on Windows |
| 18:45.46 |
yukonbob |
starseeker:
and lex/yacc are unsuitable for some reason? |
| 18:45.48 |
starseeker |
we also need
something that's LGPL-or-freer |
| 18:45.51 |
yukonbob |
ah |
| 18:46.07 |
yukonbob |
checks. |
| 18:46.14 |
starseeker |
The best
combination I had come up with so far was the netbsd m4 + byacc +
flex |
| 18:46.21 |
brlcad |
license
compatible and portable to windows .. good luck ;) |
| 18:46.21 |
starseeker |
but that'll
have to be ported to Windows |
| 18:46.47 |
yukonbob |
heh -- that's
what I was just looking up. |
| 18:47.04 |
yukonbob |
NetBSD runs
everything, even if it's not. |
| 18:47.13 |
yukonbob |
;) |
| 18:47.29 |
starseeker |
the commits
you saw earlier were me and ``Erik getting NetBSD's m4 compiling on
MSVC |
| 18:47.59 |
starseeker |
as long as we
don't have to run system commands, it doesn't look too bad - mostly
just need to swat all the uses of err, warnx, etc. |
| 18:48.45 |
starseeker |
flex will be
a bit trickier, since it wants to run m4 from within it's own
source code (ick) |
| 18:49.09 |
yukonbob |
starseeker:
like exec("m4"...");? |
| 18:49.10 |
starseeker |
fortunately
we just need to run 'em during build, and don't have to install
them |
| 18:49.23 |
starseeker |
pretty
much |
| 18:49.27 |
yukonbob |
sweet. |
| 18:50.38 |
starseeker |
byacc I'm
more hopeful about - the dev was very helpful and added a couple
Bison features to get our libobj examples working |
| 18:50.55 |
starseeker |
but of course
that too is untried on Windows |
| 18:51.16 |
starseeker |
yukonbob: if
you know of something less gnarly we'd LOVE to hear about it
:-P |
| 18:51.16 |
yukonbob |
starseeker: I
haven't worked w/ flex/yacc in ages, but aren't their artifacts
just .c and .h? Considered just generating those on a *nix and
shipping those artifacts as part of the repo? |
| 18:51.47 |
starseeker |
yukonbob: the
problem with that is the grammar definitions are what you edit
during the development process |
| 18:52.17 |
starseeker |
we want
potential developers to edit the source, type "make" (or do the
MSVC thing on Windows) and have it Just Work |
| 18:52.50 |
yukonbob |
ya -- my
suggestion is certainly non-elegant in that regard. |
| 18:52.51 |
starseeker |
the
temptation when you have generated source files is to tweak those
files and not the original grammar definitions, which very quickly
divorces the code (and fixes) from what should be the canonical
source code |
| 18:53.28 |
yukonbob |
inlucde a
comment "Edit this code under threat of death as
punishment"... |
| 18:53.34 |
starseeker |
a geometry
conversion library may potentially grow to have dozens of grammars
that need to be handled, and that will be quite a job even if we
AREN'T having to worry about syncing back and forth |
| 18:53.46 |
starseeker |
heh |
| 18:54.10 |
starseeker |
that's a
great way to encourage contributions :-P |
| 18:54.35 |
yukonbob |
starseeker:
anybody who's able to contribute to a lexer/parser will know what
it means. |
| 18:55.12 |
yukonbob |
but meh...
best case is a truly portable lex/yacc |
| 18:55.25 |
starseeker |
yukonbob: if
we're building just the sources though, new devs may head straight
for the sources to fix a problem |
| 18:55.37 |
starseeker |
would probably do that, without knowing
better |
| 18:55.56 |
starseeker |
and would
probably run screaming :-P |
| 18:57.45 |
yukonbob |
starseeker:
is your list of candidates posted anywhere?| |
| 18:57.49 |
starseeker |
because the
lex/yacc or whatever files are the "user editable" form of the
logic, we also want to make sure they continue to work and don't
"bit rot" - if the C files work, but no one has done the generation
in a few years, who knows what may have gone wrong next time we
NEED to do the generation? |
| 18:57.59 |
starseeker |
yukonbob: uh
- src/other? :-P |
| 18:58.12 |
starseeker |
will make a wiki page quick... |
| 19:05.59 |
yukonbob |
starseeker:
re: bit rot -- build is automated for producing various binaries,
no? |
| 19:07.22 |
starseeker |
er,
huh? |
| 19:07.56 |
yukonbob |
on major
releases, you have a system that generates binaries,
no? |
| 19:08.15 |
starseeker |
Oh, you mean
binary releases? yeah |
| 19:09.21 |
yukonbob |
so for case
of ppl tweaking lex/yacc artifacts and not being able to actually
produce them canonically, that'd be tested periodically w/ testing
for formal releases... |
| 19:09.58 |
yukonbob |
should stop worrying about project-wide builds and see if his
NetBSD build still stands up to latests
sources... |
| 19:10.01 |
starseeker |
yukonbob: but
if it's not integrated into our build, it becomes an extra
overhead/step that consumes developer time (a lot of it, over the
long pull) |
| 19:18.34 |
yukonbob |
! -- this has
bumped 2 minor versions since I last checked... |
| 19:21.07 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2926 10/wiki/Lexer_Parser: Stub in a page for discussing
lexers/parsers |
| 19:21.48 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2927 10/wiki/Lexer_Parser: |
| 19:26.08 |
starseeker |
hmm - re2c
actually might be interesting |
| 19:28.20 |
starseeker |
http://lekernel.net/blog/2009/02/re2c-and-lemon-an-elegant-alternative-to-flex-and-bison/ |
| 19:31.20 |
starseeker |
O.o
apparently someone is building re2c on MSVC? |
| 19:31.52 |
yukonbob |
familiar w/ lemon, but not re2c |
| 19:32.11 |
starseeker |
yukonbob:
what do you think of lemon? |
| 19:35.16 |
yukonbob |
likes things that come from drh |
| 19:35.24 |
starseeker |
yukonbob:
know anything about styx? http://speculate.de/ |
| 19:35.58 |
yukonbob |
like I said,
I haven't played in that domain for a while, but conceptually,
lemon is nice, and is thoroughly tested via sqlite |
| 19:36.20 |
starseeker |
huh - styx
has Express (from STEP) as an example grammar |
| 19:36.26 |
yukonbob |
likes this "non statement" in the re2c: |
| 19:36.33 |
yukonbob |
"...equal to
hand-written code in terms of size, speed and quality." |
| 19:36.43 |
yukonbob |
*re2c
site.. |
| 19:37.25 |
yukonbob |
my
understanding w/ parser code is that rolling your own is often
error-prone, difficult, often inefficient, etc., etc. |
| 19:38.09 |
starseeker |
heh - if I
read that right, it dates back to when people were hand-tuning code
due to machine speed constraints |
| 19:38.35 |
yukonbob |
ya -- /me
just getting into site, so may be pulling out of context, but still
made me chuckle. |
| 19:39.24 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2928 10/wiki/Lexer_Parser: Add a few more notes |
| 19:39.37 |
yukonbob |
heh -- oh,
and holding up PHP as a flagship project... |
| 19:42.50 |
starseeker |
still - if it
doesn't need m4 and already builds on Windows... |
| 19:46.07 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 19:46.44 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2929 10/wiki/Lexer_Parser: not links |
| 19:53.59 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2930 10/wiki/Lexer_Parser: Few more comments on re2c, link to
example using lemon |
| 20:30.13 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45141 10/brlcad/trunk/src/other/m4/ (14 files in
3 dirs): rename common.h to commonm4.h, as our regex.h requires
include/common.h |
| 20:30.30 |
starseeker |
nods - good catch |
| 20:38.08 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45142 10/brlcad/trunk/src/other/m4/ (gnum4.c
main.c misc.c): errx->m4errx |
| 20:40.06 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2931 10/wiki/Lexer_Parser: Add notes on Antlr |
| 20:48.17 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45143 10/brlcad/trunk/src/other/m4/misc.c: add
some windows portability functions. Includes getopt from libbu,
LGPL pollution. |
| 20:51.09 |
CIA-62 |
BRL-CAD:
03starseeker * r45144 10/brlcad/trunk/src/other/byacc/main.c: Looks
like this is the only use byacc makes of unistd, so just wrap it
here. |
| 20:51.32 |
kunigami |
When I finish
porting sh_osl.c to sh_osl.cpp, OSLRenderer object will need to be
declared at a global scope. In which place do you think it's better
to keep it? I though of putting it on "struct application", but
this struct is not passed as parameter to osl_setup. |
| 20:59.49 |
kunigami |
hmm the
problem of letting OSLRenderer global is that we will need a opaque
pointer because it will be visible for C code. |
| 21:01.22 |
kunigami |
Is it
possible to declare it in such a way that it is visible to all
sh_osl instances as a global object, while not exposing it to C
code? |
| 21:02.54 |
brlcad |
you mean like
static? :) |
| 21:06.52 |
kunigami |
probably is
that what I want |
| 21:08.31 |
brlcad |
definitely
don't want something globally visible |
| 21:09.09 |
brlcad |
a static
global will limit scope to that file, a static variable inside a
callback will limit scope even further to callers of an accessor
function |
| 21:09.32 |
CIA-62 |
BRL-CAD:
03starseeker * r45145 10/brlcad/trunk/src/other/flex/ (CMake/
CMake/FindREGEX.cmake CMakeLists.txt): flex will need the regex lib
too (and a good deal more, but start with this.) |
| 21:09.49 |
brlcad |
what else
does flex need? |
| 21:10.03 |
starseeker |
er, sorry -
phrased that wrong |
| 21:10.16 |
starseeker |
needs tests
(limit.h, sys/wait.h, etc.) |
| 21:10.24 |
brlcad |
ah |
| 21:16.48 |
kunigami |
I was
thinking about a possible problem: I only managed to make
OSLRenderer work when I grouped all osl shaders in a single class
(I've tried using a OSLRenderer for each osl shader, but it didn't
work). It's probably the case that some information must be stored
in a global context and shared among the shaders. If this is true,
it won't be possible to mix brl-cad and osl shaders :( I've to
investigate it further... |
| 21:26.51 |
CIA-62 |
BRL-CAD:
03starseeker * r45146
10/brlcad/trunk/src/other/flex/CMakeLists.txt: No doubt a fair
number of these tests need to be more sophisticated, but this gives
us a first cut at supporting most of conf.in's
variables. |
| 21:57.29 |
CIA-62 |
BRL-CAD:
03starseeker * r45147
10/brlcad/trunk/src/other/flex/CMakeLists.txt: Whoops - add in the
REGEX include dir too. |
| 21:58.57 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 22:01.02 |
CIA-62 |
BRL-CAD:
03brlcad * r45148 10/brlcad/trunk/include/optical.h: document
optical_shader_init() |
| 22:04.54 |
CIA-62 |
BRL-CAD:
03starseeker * r45149 10/brlcad/trunk/src/other/flex/scan.c: wrap
unistd.h in scan.c - will need to fix the generation in some
fashion for this, probably add the wrapper to the
skeleton... |
| 22:07.35 |
CIA-62 |
BRL-CAD:
03starseeker * r45150 10/brlcad/trunk/src/other/flex/scan.c: Hmm...
need something a bit different here, apparently... - try going
minimal... |
| 22:07.37 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net) |
| 22:10.12 |
CIA-62 |
BRL-CAD:
03starseeker * r45151 10/brlcad/trunk/src/other/flex/parse.c: Hmm.
Possibly a stray semicolon, could also be an error in the if/else
logic... |
| 23:06.52 |
brlcad |
kunigami: if
it's hooked through our shader system, there really is no
limitation on mixing shader types because the mixing is per-pixel
and happening on our end |
| 23:07.19 |
brlcad |
you might not
be able to get neat blending effects, like a caustic on a non-osl
shader, but that's okay |
| 23:07.58 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 23:08.39 |
brlcad |
it's really a
question of whether osl can shade a single pixel without shooting
the ray itself -- if it can, then it should be entirely
possible |
| 23:09.06 |
brlcad |
finally finishes an exhaustive day refactoring liboptical ..
now to make sure it still works! |
| 23:09.15 |
*** part/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
| 23:35.52 |
CIA-62 |
BRL-CAD:
03bhinesley * r45152 10/brlcad/trunk/src/libged/translate.c: adding
'f_tr_obj' functionality to 'translate' |
| 00:31.27 |
brlcad |
bhinesley:
rough going? :) |
| 00:37.13 |
bhinesley |
brlcad:
yeah... |
| 00:37.30 |
bhinesley |
reading
through code and trying to figure things out |
| 02:39.23 |
brlcad |
bhinesley:
have you read through the oed tutorial? if not, I would recommend
it as it explains a lot of 'why' oed behaves the way it does, which
mostly relates to implementation detail |
| 02:40.05 |
brlcad |
like how a
keypoint is specified (it's the right-hand side, first natural
coordinate) |
| 03:21.34 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 03:36.43 |
CIA-62 |
BRL-CAD:
03brlcad * r45153 10/brlcad/trunk/bench/run.sh: |
| 03:36.43 |
CIA-62 |
BRL-CAD: fix
off-by-one bug where TIMEFRAME=0 was causing all testing to get
skipped. it |
| 03:36.43 |
CIA-62 |
BRL-CAD:
should at least run all tests once. also fixed a bug where it was
reporting |
| 03:36.43 |
CIA-62 |
BRL-CAD:
success if previous pix files were still in the run directory, even
if rt |
| 03:36.43 |
CIA-62 |
BRL-CAD:
failed. now handles negative time values too (by clamping to
min). |
| 03:45.01 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 03:53.01 |
CIA-62 |
BRL-CAD:
03brlcad * r45154 10/brlcad/trunk/ (38 files in 3 dirs): (log
message trimmed) |
| 03:53.01 |
CIA-62 |
BRL-CAD:
major refactoring of the liboptical callback api to expand the
function |
| 03:53.01 |
CIA-62 |
BRL-CAD:
callbacks with their respective parameters. in doing so, the headp
mfuncs list |
| 03:53.01 |
CIA-62 |
BRL-CAD:
parameter was removed (only used by stack and text shaders) in
favor of just |
| 03:53.01 |
CIA-62 |
BRL-CAD:
generating a new headp via optical_shader_init(). also ended up
propagating a |
| 03:53.02 |
CIA-62 |
BRL-CAD: slew
of genptr_t's instead of char* and some basic constness. the
stronger ansi |
| 03:53.03 |
CIA-62 |
BRL-CAD: type
checking revealed several inconsistencies that got caught up in the
cleanup |
| 04:12.56 |
CIA-62 |
BRL-CAD:
03brlcad * r45155 10/brlcad/trunk/src/ (16 files in 8 dirs): remove
the antiquated msvc build files from long ago. no longer relevant
with the new cmake build. |
| 04:22.44 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1128565141.dsl.bell.ca) |
| 04:30.32 |
CIA-62 |
BRL-CAD:
03brlcad * r45156 10/brlcad/trunk/src/liboptical/ (material.c
sh_stack.c shade.c): add some sanity checks. make sure the
callbacks aren't null before we call them. make sure other related
struct dereferences aren't null as well otherwise do something else
to avoid crashing. |
| 04:30.54 |
*** part/#brlcad IriX64
(~kvirc@bas2-sudbury98-1128565141.dsl.bell.ca) |
| 04:36.26 |
CIA-62 |
BRL-CAD:
03brlcad * r45157 10/brlcad/trunk/src/liboptical/sh_wood.c: remove
the unnecessary wood_init() routine and respective eRT dead code
sections. can init to null on decl and avoid the book-keeping and
function call altogether. |
| 04:41.13 |
bhinesley |
brlcad: yes,
I've read the oed tutorial. |
| 04:43.11 |
bhinesley |
I haven't
really done anything that involves directly manipulating graphics
objects, until now. It's taking a lot to understand how that
works. |
| 04:44.39 |
bhinesley |
(for me)
:) |
| 04:45.47 |
CIA-62 |
BRL-CAD:
03brlcad * r45158 10/brlcad/trunk/src/burst/Hm.h: comment cleanup
and s/<control>/CONTROL/ |
| 04:48.09 |
CIA-62 |
BRL-CAD:
03bhinesley * r45159 10/brlcad/trunk/src/libged/translate.c: use
struct db_full_path, not char[] |
| 04:55.09 |
CIA-62 |
BRL-CAD:
03brlcad * r45160 10/brlcad/trunk/src/conv/ (g-xxx.c
walk_example.c): don't declare UNUSED params to doxygen, just
bitches about them. if you list some params, though, you should
list all of them (except UNUSED ones). |
| 04:56.07 |
CIA-62 |
BRL-CAD:
03brlcad * r45161 10/brlcad/trunk/src/libbn/axis.c: add param docs
missing from a couple funcs |
| 04:59.08 |
CIA-62 |
BRL-CAD:
03bhinesley * r45162 10/brlcad/trunk/src/libged/translate.c: fix
whitespace (ws.sh) |
| 05:52.11 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 06:43.22 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.214.98) |
| 06:43.22 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:20.02 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 07:32.29 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 07:32.29 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:23.39 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 08:57.51 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.214.98) |
| 08:57.51 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 09:17.30 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 09:17.30 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:03.41 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 10:32.18 |
CIA-62 |
BRL-CAD:
03brlcad * r45163
10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: wrap diagrams
in @code/@endcode |
| 10:38.43 |
CIA-62 |
BRL-CAD:
03brlcad * r45164 10/brlcad/trunk/src/rt/do.c: remove appearance of
tags for parsing |
| 10:41.58 |
CIA-62 |
BRL-CAD:
03brlcad * r45165 10/brlcad/trunk/src/shapes/fence.h: doxygenify
comments |
| 10:45.37 |
CIA-62 |
BRL-CAD:
03brlcad * r45166 10/brlcad/trunk/src/util/pixfade.c: remove tag
appearance |
| 10:45.54 |
CIA-62 |
BRL-CAD:
03brlcad * r45167 10/brlcad/trunk/src/vdeck/vdeck.c: wrap table in
@code/@endcode |
| 10:59.02 |
CIA-62 |
BRL-CAD:
03kunigami * r45168 10/brlcad/trunk/src/liboptical/ (6 files):
moving sh_osl.c to sh_osl.cpp |
| 11:00.16 |
CIA-62 |
BRL-CAD:
03brlcad * r45169 10/brlcad/trunk/include/bu.h: match @param
variable names with the function so it knows which is which. clean
up formatting on the @code/@endcode sections |
| 11:00.38 |
CIA-62 |
BRL-CAD:
03brlcad * r45170 10/brlcad/trunk/include/wdb.h: if you're going to
annotate one of the parameters, they all have to be
annotated. |
| 11:01.05 |
CIA-62 |
BRL-CAD:
03brlcad * r45171 10/brlcad/trunk/src/librt/vlist.c: document the
other param |
| 11:03.04 |
CIA-62 |
BRL-CAD:
03brlcad * r45172 10/brlcad/trunk/src/libwdb/reg.c: if you document
one of them, document all of them |
| 11:07.46 |
CIA-62 |
BRL-CAD:
03brlcad * r45173 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp:
function sig consistency |
| 11:14.21 |
CIA-62 |
BRL-CAD:
03brlcad * r45174 10/brlcad/trunk/include/rtgeom.h: comment
cleanup. put latex equation into a code block. |
| 12:25.22 |
CIA-62 |
BRL-CAD:
03kunigami * r45175 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt
init.c osl_rt.cpp): implemented a simple mirror shader on osl_rt to
make sure we can combine osl shaders with other shaders. it
worked\! |
| 12:26.59 |
kunigami |
brlcad: any
news on the "struct mfuncs" support to C++? |
| 12:30.42 |
CIA-62 |
BRL-CAD:
03starseeker * r45176 10/brlcad/trunk/src/other/CMakeLists.txt:
Reorder things a bit. |
| 12:31.09 |
CIA-62 |
BRL-CAD:
03starseeker * r45177 10/brlcad/trunk/src/ (8 files in 8 dirs): dsp
files are no more, so we don't need to ignore them. |
| 14:41.43 |
*** join/#brlcad crazy_imp
(~mj@a89-182-132-98.net-htp.de) |
| 14:42.18 |
brlcad |
kunigami: I
just checked in all of the changes this morning |
| 14:42.52 |
brlcad |
er, last
night even .. r45154 |
| 14:43.50 |
brlcad |
so now
they're properly expanded global function callbacks |
| 14:44.54 |
brlcad |
you'll still
want extern "C" linkage, but should be able to hook in your
callbacks from the C++ side warning-free |
| 15:01.30 |
*** join/#brlcad _psilva
(~silvap@static-96-255-52-7.washdc.fios.verizon.net) |
| 15:46.34 |
brlcad |
kunigami: you
may have noticed, but larry just added a slew of comments to the
testshader example, explaining everything in more
detail |
| 15:46.38 |
brlcad |
https://github.com/lgritz/OpenShadingLanguage/blob/e7673afe1c1c9467eba48e7a836904999f80a1cf/src/testshade/testshade.cpp |
| 15:46.46 |
kunigami |
besides
declaring each _setup, _render, _print and _free surrounded with
extern "C", should I take any other care? The compiling goes fine,
but when I try to run ./rt, it gives me undefined symbol for
osl_setup |
| 15:47.24 |
brlcad |
you declare
the bu_structparse table, then add that table to init.c |
| 15:47.43 |
brlcad |
I think I saw
a recent previous commit where you removed it from init |
| 15:48.08 |
kunigami |
I added it
back already |
| 15:48.54 |
brlcad |
there's
nothing more to it other than those two steps that come to
mind |
| 15:48.58 |
brlcad |
what's the
actual error? |
| 15:49.20 |
kunigami |
./rt: symbol
lookup error:
/home/kunigami/workspace/dev/bin/brlcad-bin/lib/liboptical.so.19:
undefined symbol: osl_setup |
| 15:49.41 |
kunigami |
I'll try a
clean compiling here (I've been updating only from
src/liboptical) |
| 15:50.16 |
brlcad |
the function
is implemented in an extern "C" block too? |
| 15:50.40 |
kunigami |
no, but it's
hidden from the C code |
| 15:52.42 |
kunigami |
about the
testrender update: great! I'll read it later! Maybe it helps me
improving the current system I've been using almost like copy &
paste |
| 15:52.53 |
brlcad |
what do you
mean hidden? |
| 15:53.02 |
brlcad |
the callback
functions aren't "hidden" |
| 15:53.32 |
brlcad |
they can be
HIDDEN (i.e., static), but have to be globally addressable
otherwise you'll get ... a runtime error ;) |
| 15:53.59 |
brlcad |
I'm betting
it's extern "C" linkage |
| 15:54.05 |
brlcad |
add that to
the function decl |
| 15:54.17 |
brlcad |
extern "C"
int osl_setup(...) { ... |
| 16:00.10 |
kunigami |
hmm ok! I
don't know why I though that each shader was compiled as a
separated unit and then dynamically linked to liboptical :P Fixing
that |
| 16:10.16 |
kunigami |
worked.
thanks! |
| 16:10.17 |
brlcad |
there is code
in there that will dynamically load new shaders |
| 16:10.38 |
brlcad |
but they'd
still need to be extern "C" so the symbol names are
mangled |
| 16:16.54 |
CIA-62 |
BRL-CAD:
03178.73.220.94 07http://brlcad.org
* r2932 10/wiki/MGED_CMD_saveview: |
| 16:19.02 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2933
10/wiki/MGED_CMD_saveview: Reverted edits by
[[Special:Contributions/178.73.220.94|178.73.220.94]] ([[User
talk:178.73.220.94|Talk]]); changed back to last version by
[[User:Sean|Sean]] |
| 16:19.14 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:178.73.220.94]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 16:39.25 |
CIA-62 |
BRL-CAD:
03brlcad * r45178 10/brlcad/trunk/TODO: notes on benchmark
suite |
| 16:39.49 |
CIA-62 |
BRL-CAD:
03brlcad * r45179 10/brlcad/trunk/TODO: erase/erase_all
merged |
| 16:44.12 |
CIA-62 |
BRL-CAD:
03brlcad * r45180 10/brlcad/trunk/TODO: the rename will ideally
have to wait until the next minor update now |
| 16:50.53 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.27.251) |
| 16:50.53 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:17.25 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 17:17.33 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.27.251) |
| 17:17.33 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:19.51 |
*** join/#brlcad yukonbob
(~bch@S0106002191d1591c.ok.shawcable.net) |
| 17:31.20 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 17:41.09 |
kunigami |
hmm I think
I'm doing something wrong :P the sphere was supposed to be the osl
shader http://imageshack.us/photo/my-images/16/weirdje.png/ |
| 17:47.13 |
kunigami |
I'll try
adding supersampling |
| 18:04.50 |
CIA-62 |
BRL-CAD:
03kunigami * r45181 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt
init.c osl-renderer.cpp sh_osl.cpp): finished porting sh_osl.c to
sh_osl.cpp and added some code to integrate osl (but is not working
properly) |
| 18:49.49 |
brlcad |
kunigami:
your #ifdef __cplusplus sections in sh_osl.cpp ... |
| 18:49.57 |
brlcad |
when will
they ever be false? :) |
| 18:52.12 |
kunigami |
hmm probably
not :) |
| 18:53.49 |
CIA-62 |
BRL-CAD:
03kunigami * r45182 10/brlcad/trunk/src/liboptical/sh_osl.cpp:
removed useless cplusplus macros |
| 18:53.53 |
brlcad |
the only
conditional you might consider would be a toggle on whether OSL is
available or not, OSL_ENABLED or WITH_OSL or somesuch |
| 18:54.10 |
brlcad |
but that'd
only be so you could print "oops, osl not available" |
| 18:55.32 |
brlcad |
so educate me
a little bit -- how does osl shade a pixel given a hit point and
normal? |
| 18:55.44 |
brlcad |
what do you
provide to osl? |
| 18:59.42 |
kunigami |
From the
testrender example, I think for each pixel we need to provide osl
with object normal, incident ray and hit point -- for the most
basic case |
| 19:02.45 |
brlcad |
so then how
does it shade given that info? |
| 19:03.46 |
kunigami |
actually we
also need to provide a shaderstate, which seems to contain
information about which osl shader is being used |
| 19:04.01 |
brlcad |
how might I
take light source visibility into an account, for example, if I'm
trying to write an osl shader |
| 19:05.01 |
kunigami |
I think that
it's done through recursion. When a ray hit a non-emitter surface,
it is propagated |
| 19:05.28 |
kunigami |
when it
finally hits a emitter, it just return its color |
| 19:05.33 |
brlcad |
how does that
happen? osl didn't shoot the primary ray |
| 19:06.59 |
kunigami |
it calculates
the output direction from the incident ray and the normal, I
think |
| 19:07.33 |
brlcad |
that would
imply to me that there has to be some way either to register with
osl how rays are fired (e.g. register a callbackup that ends up
calling rt_shootray()), or call into osl for info to know when a
new ray needs to be fired to compute some shader info |
| 19:07.57 |
brlcad |
sure, it'll
know the direction, but it doesn't exactly have any logic to shoot
a ray |
| 19:09.00 |
brlcad |
otherwise,
osl would also require the geometry in some format and it wouldn't
be a shading library, it'd be a raytracer :) |
| 19:09.15 |
kunigami |
In testrender
this logic was implemented along the radiance function. In sh_osl
I'm explict calling rt_shootray |
| 19:10.29 |
CIA-62 |
BRL-CAD:
03brlcad * r45183 10/brlcad/trunk/src/libged/translate.c: c99-style
// comments can't be used in C files, must be c89
compliant |
| 19:11.28 |
brlcad |
i'm not
familiar with testrender .. is the radiance function something
written in C/C++ and provided to OSL? |
| 19:12.28 |
kunigami |
no, radiance
was a function written by the author of testrender. It's a simple
intersection system to find which of the spheres of the scene was
hit by the given ray |
| 19:13.37 |
brlcad |
so in your
weirdje image, which shader is on that sphere? |
| 19:14.25 |
brlcad |
the reason
I'm asking, trying to understand how we'll put this integration to
use down the road |
| 19:14.44 |
kunigami |
that's an osl
shader, which should be a perfect diffuse yellow |
| 19:15.06 |
brlcad |
I know from a
high-high level what OSL is capable of, it's how it gets integrated
that seems still to be a mystery |
| 19:16.04 |
brlcad |
so perfect
diffuse, it should be a shader that just needs the ray, object hit
point, and surface normal |
| 19:16.14 |
kunigami |
yes |
| 19:16.19 |
brlcad |
so it shades
based on the cosine angle, basically light coming from the
camera |
| 19:16.42 |
brlcad |
so why is the
bottom of the sphere bright and the top dark then? :) |
| 19:17.40 |
brlcad |
that also
implies an another open question: how might one implement a phong
shader with OSL |
| 19:18.15 |
kunigami |
It seems it's
acting like a mirror (the top of the scene is dark and the floor is
bright) |
| 19:18.43 |
brlcad |
hm,
true |
| 19:19.33 |
brlcad |
ah, your
firing a ray for each hit point, aren't you -- a ray down the
normal or something |
| 19:19.53 |
brlcad |
the color it
gets will be a mirror-like color |
| 19:21.29 |
kunigami |
yes, but it's
exactly the same thing I do on osl_rt and there the color is as
expected |
| 19:21.55 |
brlcad |
apparently
not "exactly" the same :) |
| 19:25.05 |
kunigami |
the
difference is that in osl_rt all shaders (except the mirror) are
osl ones. Probably some information is being stored in the system
when a ray jumps from an object to another. |
| 19:25.15 |
brlcad |
once you get
diffuse working, I'd suggest trying to get a simplistic phong
shader implemented, since that really begs questions on how the OSL
API is supposed to handle secondary queries |
| 19:28.58 |
brlcad |
you could use
the cornell box example and make all objects have an osl
shader |
| 19:29.06 |
brlcad |
no sense
making it more complicated than it needs to be |
| 19:44.37 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 19:50.52 |
CIA-62 |
BRL-CAD:
03r_weiss * r45184 10/brlcad/trunk/src/libbu/list.c: Fixed a bug in
function 'bu_list_reverse' within file 'list.c' of the 'libbu'
library. A 'struct bu_list' was not initialized correctly causing a
segmentation fault. |
| 19:58.07 |
CIA-62 |
BRL-CAD:
03r_weiss * r45185
10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 19:58.07 |
CIA-62 |
BRL-CAD:
Updated function 'nmg_booltree_evaluate' within file 'nmg_bool.c'.
Removed the |
| 19:58.07 |
CIA-62 |
BRL-CAD: call
to 'nmg_model_fuse' since it is not necessary here. This is called
later |
| 19:58.08 |
CIA-62 |
BRL-CAD:
within function 'nmg_bool'. This change will increase the speed in
which nmg |
| 19:58.08 |
CIA-62 |
BRL-CAD:
boolean operations are performed. For example, the mged command
'facetize' will |
| 19:58.08 |
CIA-62 |
BRL-CAD: run
faster. |
| 20:13.48 |
CIA-62 |
BRL-CAD:
03r_weiss * r45186
10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: |
| 20:13.48 |
CIA-62 |
BRL-CAD:
Updated functions 'nmg_class_pt_s', 'class_eu_vs_s' and
'class_fu_vs_s' within |
| 20:13.48 |
CIA-62 |
BRL-CAD: file
'nmg_class.c'. The changes will increase the speed in which nmg
boolean |
| 20:13.48 |
CIA-62 |
BRL-CAD:
operations are performed. For example, the mged command 'facetize'
will run |
| 20:13.48 |
CIA-62 |
BRL-CAD:
faster. The change adds a compare to the shell bounding box to
exclude nmg |
| 20:13.49 |
CIA-62 |
BRL-CAD:
objects (shell,face,loop,edge,vertex) as early as possible in the
classification |
| 20:13.50 |
CIA-62 |
BRL-CAD: to
prevent extra processing. |
| 20:17.12 |
CIA-62 |
BRL-CAD:
03brlcad * r45187 10/brlcad/trunk/db/ (CMakeLists.txt Makefile.am
cornell.rt): add a view script for the cornell box that can be used
to restore a prototypical view inside the box. |
| 20:18.29 |
brlcad |
kunigami:
that view script may be of interest -- if you run it (sh
cornell.rt), it should render a typical view of the existing
cornell.g model |
| 20:18.47 |
CIA-62 |
BRL-CAD:
03r_weiss * r45188 10/brlcad/trunk/include/vmath.h: |
| 20:18.47 |
CIA-62 |
BRL-CAD:
Added macro 'V3PT_OUT_RPP_TOL' to file 'vmath.h' which tests if a
vertex is |
| 20:18.47 |
CIA-62 |
BRL-CAD:
outside a bounding box by at least the distance tolerance. This
macro supports |
| 20:18.47 |
CIA-62 |
BRL-CAD:
changes to functions 'nmg_class_pt_s' and 'class_eu_vs_s' within
file |
| 20:18.47 |
CIA-62 |
BRL-CAD:
'nmg_class.c'. |
| 20:18.48 |
brlcad |
may be useful
for tweaking the cornell.g model to be all osl shaders |
| 20:18.55 |
brlcad |
for
testing |
| 20:25.17 |
CIA-62 |
BRL-CAD:
03r_weiss * r45189
10/brlcad/trunk/src/librt/primitives/nmg/nmg_pt_fu.c: |
| 20:25.17 |
CIA-62 |
BRL-CAD:
Updated function 'nmg_class_pt_lu_except' within file
'nmg_pt_fu.c'. Improved |
| 20:25.17 |
CIA-62 |
BRL-CAD: the
test against the loop bounding box by added the distance tolerance
and |
| 20:25.17 |
CIA-62 |
BRL-CAD:
changed the macro so that the point must be at least the distance
tolerance |
| 20:25.17 |
CIA-62 |
BRL-CAD:
outside the loop bounding box to be excluded. |
| 20:31.03 |
CIA-62 |
BRL-CAD:
03brlcad * r45190 10/brlcad/trunk/include/bu.h: don't let
BU_LIST_INIT_ZERO set the magic number to BU_LIST_HEAD_MAGIC since
the pointers are still NULL. the macro is only useful as a
zero-initializer. |
| 20:31.37 |
kunigami |
brlcad:
thanks! I was trying to setup that scene here without much
sucess |
| 20:33.23 |
CIA-62 |
BRL-CAD:
03brlcad * r45191 10/brlcad/trunk/NEWS: |
| 20:33.24 |
CIA-62 |
BRL-CAD:
through a variety of enhancements, richard has been making headway
on improving |
| 20:33.24 |
CIA-62 |
BRL-CAD: the
performance and reliability of the nmg/bot processing code. in
particular, |
| 20:33.24 |
CIA-62 |
BRL-CAD: he
has eliminated duplicative model fusing and improve topology
connectivity |
| 20:33.24 |
CIA-62 |
BRL-CAD:
evaluations so objects that previously wouldn't convert
can. |
| 20:33.53 |
brlcad |
kunigami:
it's a little screwy because that model uses the original cornell
specification |
| 20:34.06 |
brlcad |
with exact
positioning and orientation, which doesn't match our coordinate
system |
| 20:34.39 |
brlcad |
plus you want
perspective for that model since you're in such a small confined
space, which isn't the default |
| 20:36.15 |
brlcad |
someone needs
to remodel the box to fix our render expectations a little bit
better, and if only to toss in a sphere :) |
| 20:39.50 |
``Erik |
ferrofluid
http://www.youtube.com/watch?v=OsW8zctD7CM |
| 20:44.21 |
CIA-62 |
BRL-CAD:
03r_weiss * r45192
10/brlcad/trunk/src/librt/primitives/ars/ars.c: |
| 20:44.21 |
CIA-62 |
BRL-CAD:
Updated the 'rt_ars_tess' function within file 'ars.c'. This change
simplifies |
| 20:44.21 |
CIA-62 |
BRL-CAD: the
'ars' primitive geometry to improve the success of performing nmg
boolean |
| 20:44.21 |
CIA-62 |
BRL-CAD:
operations with 'ars' primitives. Commands such as mged 'facetize'
will have |
| 20:44.22 |
CIA-62 |
BRL-CAD:
greater success when the geometry to facetize contains 'ars'
primitives. |
| 21:05.33 |
CIA-62 |
BRL-CAD:
03128.63.32.62 07http://brlcad.org
* r2934 10/wiki/Lexer_Parser: /* Parsers */ - add note pointing to
lemon example |
| 21:40.57 |
CIA-62 |
BRL-CAD:
03r_weiss * r45193
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message
trimmed) |
| 21:40.57 |
CIA-62 |
BRL-CAD:
Fixed a bug in function 'nmg_triangulate_rm_degen_loopuse' which
caused an |
| 21:40.57 |
CIA-62 |
BRL-CAD:
infinite loop when a loopuse contains a single vertexuse instead of
a list of |
| 21:40.57 |
CIA-62 |
BRL-CAD:
edgeuse. The function now also kills all loopuse which contain only
a single |
| 21:40.57 |
CIA-62 |
BRL-CAD:
vertexuse. The associated single vertexuse is also killed. This
function |
| 21:40.57 |
CIA-62 |
BRL-CAD:
supports the new prototype function 'nmg_triangulate_fu' (nmg
triangulate |
| 21:40.58 |
CIA-62 |
BRL-CAD:
faceuse). Preprocessor commands are added so these
updates/additions are |
| 21:57.34 |
*** join/#brlcad crazy_imp
(~mj@a89-182-130-99.net-htp.de) |
| 22:00.00 |
*** join/#brlcad dloman
(~claymore@BZ.BZFLAG.BZ) |
| 22:00.01 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
| 22:00.35 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 00:09.47 |
brlcad |
not
surprising |
| 00:09.54 |
CIA-62 |
BRL-CAD:
03brlcad * r45277 10/brlcad/trunk/src/libged/ (100 files):
remainder of ws indent consistency cleanup. reorder to eliminate
some forward decls too. |
| 00:11.05 |
brlcad |
improving
code quality is always fair game |
| 00:12.05 |
brlcad |
whether it's
some bit of logic that could be cleaned up or a usage pattern that
begs refactoring or outright crap code that needs to be taken out
back and shot |
| 00:14.13 |
CIA-62 |
BRL-CAD:
03brlcad * r45278 10/brlcad/trunk/src/libged/ (CMakeLists.txt
Makefile.am subtype.c): subtyping is something that should be
defined within the objects themselves down in librt, not at this
high level. no matter, the code is a ways off from compiling
anyways, so removed from dist. |
| 00:15.00 |
*** join/#brlcad merzo
(~merzo@157-86-133-95.pool.ukrtel.net) |
| 00:15.41 |
CIA-62 |
BRL-CAD:
03brlcad * r45279 10/brlcad/trunk/src/libged/ (vdraw.c
wdb_vdraw.c): vmath provides M_SQRT2 |
| 00:23.33 |
CIA-62 |
BRL-CAD:
03brlcad * r45280 10/brlcad/trunk/src/libged/adc.c: remove ged_
prefix on non-public functions, reorder to eliminate forward
decls |
| 00:30.31 |
CIA-62 |
BRL-CAD:
03brlcad * r45281 10/brlcad/trunk/src/libged/ged.c: don't blindly
close the wdbp |
| 00:38.49 |
CIA-62 |
BRL-CAD:
03brlcad * r45282 10/brlcad/trunk/src/libged/ged.c: initialize the
other struct ged members during ged_init() so they can be properly
memory-managed. |
| 00:39.34 |
CIA-62 |
BRL-CAD:
03brlcad * r45283 10/brlcad/trunk/src/libged/ged.c: bah, fix
typos |
| 00:46.34 |
*** join/#brlcad crazy_imp
(~mj@a89-182-231-95.net-htp.de) |
| 00:50.03 |
bhinesley |
brlcad: yeah,
I should have taken a closer look at otranslate/ptranslate. That
helps a lot. |
| 01:14.24 |
CIA-62 |
BRL-CAD:
03bhinesley * r45284 10/brlcad/trunk/src/libged/ (path.c
translate.c): ensure path is initialized and isn't / before trying
to access it's directories |
| 01:24.06 |
CIA-62 |
BRL-CAD:
03bhinesley * r45285 10/brlcad/trunk/src/libged/translate.c:
translate.c accidentally included in last commit... inverse merge
45284 |
| 02:44.30 |
CIA-62 |
BRL-CAD:
03bhinesley * r45286 10/brlcad/trunk/src/librt/db_fullpath.c: it is
already assumed that an empty string corresponds to '/', so handle
a NULL string the same way (rather than bombing) |
| 02:48.49 |
CIA-62 |
BRL-CAD:
03brlcad * r45287 10/brlcad/trunk/src/librt/wdb.c: if we're closing
a wdbp, make sure all memory is released. set the magic to 0 for
sanity too in case someone looks at that memory again
later. |
| 04:08.47 |
*** join/#brlcad DarkCalf
(DC@2002:ade7:2862::ade7:2862) |
| 04:24.56 |
brlcad |
starseeker:
definitely related, though how to fix this correctly is going to be
very tricky .. spagetti code intermingled on the tcl and c sides,
both trying to manage that wdbp |
| 04:53.01 |
CIA-62 |
BRL-CAD:
03bhinesley * r45288 10/brlcad/trunk/src/ (libged/translate.c
tclscripts/archer/ArcherCore.tcl): tranlation of all objects in a
single combination's tree is now working: 'translate -r 5 5 5 /
obj1.c', or equivalently 'translate 5 5 5 obj1.c' |
| 05:04.23 |
*** join/#brlcad DarkCalf
(DC@173.231.40.98) |
| 05:21.14 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 05:45.00 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r2939 10/wiki/User:Bhinesley: /* Log */ Friday, yesterday, today,
plan for the week |
| 05:54.12 |
bhinesley |
brlcad: I'm
getting a segfault when I run 'make'. I see that you might still be
working on it, so I'll just say that after an inverse merge of
r45287 it goes away. http://pastebin.mozilla.org/1260422 |
| 06:20.30 |
CIA-62 |
BRL-CAD:
03brlcad * r45289 10/brlcad/trunk/src/librt/wdb.c: better wdb init.
don't just set the magic, the forw/back list pointers need
initializing. init both vls, not just one of them. |
| 06:24.31 |
CIA-62 |
BRL-CAD:
03brlcad * r45290 10/brlcad/trunk/src/librt/wdb.c: set the magic
properly useing BU_LIST_MAGIC_SET() |
| 06:25.50 |
CIA-62 |
BRL-CAD:
03brlcad * r45291 10/brlcad/trunk/src/libged/wdb_obj.c: don't
wdb_close does the dequeue and vls frees for us |
| 06:26.56 |
CIA-62 |
BRL-CAD:
03brlcad * r45292 10/brlcad/trunk/src/libged/ged.c: be careful the
gdp is not already allocated (should get set to null when
deallocated) |
| 06:35.24 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.214.98) |
| 06:35.24 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:42.27 |
CIA-62 |
BRL-CAD:
03brlcad * r45293 10/brlcad/trunk/src/mged/setup.c: protect this
file from auto-formatting by making the expansion of ',' into a
compile-time error. the 35,25 and 45,45 commands along with the
mged_display tcl variable relies on there being no spaces around
the comma. |
| 06:48.05 |
CIA-62 |
BRL-CAD:
03brlcad * r45294 10/brlcad/trunk/src/mged/mged.c: (log message
trimmed) |
| 06:48.05 |
CIA-62 |
BRL-CAD: the
wdb tcl objects and ged structures both assume they get to own the
wdbp they |
| 06:48.05 |
CIA-62 |
BRL-CAD: were
passed. can't just remove the wdb_close() from wdb_deleteProc() as
there |
| 06:48.05 |
CIA-62 |
BRL-CAD:
doesn't seem to be any place in mged where the .inmem wdb is
actually recorded |
| 06:48.05 |
CIA-62 |
BRL-CAD:
(it's stored inside a tcl callback). so let the tcl objects do
their thing, but |
| 06:48.05 |
CIA-62 |
BRL-CAD: then
that means the ged needs to acquire a full-fledged copy of the wdb
and gets |
| 06:48.06 |
CIA-62 |
BRL-CAD:
treated as another dbi observer. this requires more extensive
testing for |
| 06:49.26 |
brlcad |
starseeker:
that should fix it, but it definitely needs more testing
(particularly memory testing) ... the open/close code is a royal
mess, so it really warrants a valgrinding |
| 06:59.22 |
CIA-62 |
BRL-CAD:
03brlcad * r45295 10/brlcad/trunk/src/libged/analyze.c: reorder in
order to eliminate forward references and disambiguate private
functions from public API by not using ged_ prefix. |
| 07:06.50 |
CIA-62 |
BRL-CAD:
03brlcad * r45296 10/brlcad/trunk/src/libged/ (dg_obj.c vdraw.c
wdb_vdraw.c): reorder and rename in order to remove the ged_ prefix
on non-API functions. disambiguate with the tcl-based vdraw_cmd(),
renaming to vdraw_cmd_tcl(). |
| 07:21.13 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 10:52.19 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 11:32.53 |
starseeker |
brlcad: so
should we hold off on the release for now? |
| 11:33.08 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 11:36.10 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 12:08.53 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:28.10 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 13:02.30 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:28.35 |
kunigami |
<PROTECTED> |
| 13:30.31 |
kunigami |
I've been
reading refract.c but |
| 13:31.04 |
kunigami |
I couldn't
notice any difference, except that it changes the hit
callback. |
| 13:34.50 |
kunigami |
In osl_rt,
first I detect the ray is a refraction one (which occurs when the
next ray to be shot and the normal vector -- which I assume is
pointing outwards -- have dot product less than zero). After
shooting this new ray, I invert the normal given by the
application. |
| 13:35.55 |
brlcad |
starseeker: I
wouldn't think so, if we pass all release testing -- just have to
make sure everything really works with actual hands-on
modeling |
| 13:37.06 |
brlcad |
kunigami: if
you're inside an object, you won't get a hit until you encounter
another object exterior |
| 13:37.19 |
brlcad |
i believe
you'll want to back the ray out of anything that you're
in |
| 13:37.55 |
brlcad |
at least for
onehit |
| 13:38.19 |
starseeker |
/src/libged/draw.c |
| 13:38.20 |
starseeker |
{standard
input}:13976:non-relocatable subtraction expression,
"_dgo_open_tcl" minus "L00000000002$pb" |
| 13:39.38 |
brlcad |
unclean
build? that was just a function that was renamed from dgo_open to
dgo_open_tcl |
| 13:40.28 |
brlcad |
not used in
draw.c, so a lil mystery there |
| 13:41.41 |
kunigami |
brlcad: I'm
not sure if I understand what you said. When a ray hits a glass
object, I need to shoot a refraction ray. This ray will hit this
same glass object from inside. I think I need to pass this
"internal" ray to OSL system. |
| 13:42.12 |
starseeker |
ah,
OK |
| 13:42.19 |
starseeker |
mutters under his breath about
autotools... |
| 13:44.21 |
CIA-62 |
BRL-CAD:
03brlcad * r45297 10/brlcad/trunk/src/libged/draw.c: remove the dgo
references in here since this file no longer has anything to do
with the dgo interface. |
| 13:45.59 |
brlcad |
kunigami: so
in that case, your incoming ray hits glass, you determine that you
need to refract, so you don't need to "rehit" that glass surface
(so you don't need to back the ray out) -- you just fire from the
interior |
| 13:46.23 |
brlcad |
you may need
to move the ray forward just an epsilon so that it doesn't
accidentically rehit the surface due to floating point
fuzz |
| 13:49.33 |
CIA-62 |
BRL-CAD:
03brlcad * r45298 10/brlcad/trunk/src/libged/bev.c: replace the
ged_ prefix on non-public API |
| 13:52.35 |
kunigami |
brlcad: I
didn't considered that! Let me try moving the starting point a
little bit in the ray direction. |
| 13:53.35 |
CIA-62 |
BRL-CAD:
03starseeker * r45299
10/brlcad/trunk/src/other/libpng/CMakeLists.txt: This symlink
probably shouldn't be pointing to the build directory - point it to
the final installed location and see if that works... |
| 13:53.53 |
CIA-62 |
BRL-CAD:
03brlcad * r45300 10/brlcad/trunk/src/libged/bot_dump.c: more ged_
prefix removal on non-public API |
| 14:08.59 |
*** join/#brlcad _psilva
(~silvap@static-96-255-52-7.washdc.fios.verizon.net) |
| 14:09.10 |
_psilva |
mornin |
| 14:09.13 |
brlcad |
howdy |
| 14:09.33 |
_psilva |
i'll try svn
tonight |
| 14:11.28 |
CIA-62 |
BRL-CAD:
03starseeker * r45301
10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Spoke too soon -
might be a problem with how BRL-CAD is setting
CMAKE_LIBRARY_OUTPUT_DIRECTORY |
| 14:12.20 |
CIA-62 |
BRL-CAD:
03starseeker * r45302 10/brlcad/trunk/CMakeLists.txt: See whether
we actually needed to specify the BRLCAD_BINARY_DIR - if we don't,
this may avoid libpng's problem. |
| 14:20.00 |
CIA-62 |
BRL-CAD:
03starseeker * r45303 10/brlcad/trunk/CMakeLists.txt: Ah, that's
right - that's what gives us the ability to duplicate the installed
layout. Will need to do something else with libpng. |
| 14:25.45 |
starseeker |
dg_obj.c:339:
warning: implicit declaration on vdraw_cmd_t |
| 14:29.12 |
_psilva |
i found g_var
still in the distro |
| 14:29.22 |
_psilva |
doubt it's
used by anyone |
| 14:35.33 |
CIA-62 |
BRL-CAD:
03brlcad * r45304 10/brlcad/trunk/src/libged/ (clip.c color.c
ged_private.h): more ged_ (and _ged_) prefix removal. great example
where reordering eliminates the need for forward decls and the
unnecessary inclusion of the color funcs in ged_private (implying
internal reuse API). |
| 14:36.04 |
starseeker |
brlcad: are
you able to get a build of BRL-CAD right now? I can't even in
non-strict mode... |
| 14:36.18 |
starseeker |
src/libged/vdraw.c:740: error: conflicting
types for ‘vdraw_cmd’ |
| 14:36.30 |
starseeker |
include/dg.h:264: error: previous
declaration of ‘vdraw_cmd’ was here |
| 14:39.38 |
CIA-62 |
BRL-CAD:
03brlcad * r45305 10/brlcad/trunk/src/libged/comb_std.c: ged_/GED_
prefix removal on non-public API |
| 14:40.07 |
brlcad |
starseeker: I
do get a clean build, lemme see if I have uncommitted
files |
| 14:41.24 |
CIA-62 |
BRL-CAD:
03brlcad * r45306 10/brlcad/trunk/include/dg.h: sure enough,
uncommitted file. vdraw_cmd() was renamed to
vdraw_cmd_tcl(). |
| 14:42.24 |
brlcad |
_psilva: it's
not been a maintenance burden, so it's been left alone |
| 14:43.02 |
brlcad |
dead code
tends to get left alone unless/until it incurs a maintenance
cost |
| 14:44.16 |
starseeker |
brlcad: ah,
phew - thanks |
| 14:44.26 |
starseeker |
(kinda makes
release testing harder :-P) |
| 14:45.29 |
_psilva |
just saying
practically it really has no use |
| 14:45.40 |
_psilva |
i suppose
maybe as a reference for another convertor |
| 14:45.44 |
_psilva |
it has some
value |
| 15:21.19 |
brlcad |
_psilva: you
have the ability to make it useful ;) |
| 15:25.40 |
_psilva |
heh, just
saying |
| 16:48.59 |
*** join/#brlcad yukonbob
(~bch@S0106002191d1591c.ok.shawcable.net) |
| 17:25.48 |
CIA-62 |
BRL-CAD:
03kunigami * r45307 10/brlcad/trunk/src/liboptical/osl_rt.cpp:
osl-rt can read number of samples from input |
| 17:52.03 |
CIA-62 |
BRL-CAD:
03starseeker * r45308
10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Try an alternative
approach to the symlink issue. |
| 17:55.31 |
brlcad |
_psilva: just
saying you're going to do it? |
| 17:58.41 |
brlcad |
actually, I
recall looking at that converter a few months back and decided to
keep it around because it might be useful as a plugin to our
geometry conversion library |
| 17:58.41 |
CIA-62 |
BRL-CAD:
03starseeker * r45309
10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Fix up
indenting. |
| 18:21.20 |
CIA-62 |
BRL-CAD:
03starseeker * r45310
10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Need to use the
location property for the active configuration. Probably other
places in BRL-CAD where I need to make this change. |
| 18:35.33 |
CIA-62 |
BRL-CAD:
03starseeker * r45311
10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Make sure we flush
any old symlinks when re-running cmake. |
| 18:36.50 |
CIA-62 |
BRL-CAD:
03bhinesley * r45312 10/brlcad/trunk/src/libged/ptranslate.c: after
pointer arithmetic, argv[0] doesn't point to command
name |
| 18:48.27 |
CIA-62 |
BRL-CAD:
03starseeker * r45313
10/brlcad/trunk/src/other/libpng/CMakeLists.txt: |
| 18:48.27 |
CIA-62 |
BRL-CAD:
Since Windows doesn't symlink, we need to do something else. Rather
than run |
| 18:48.28 |
CIA-62 |
BRL-CAD: code
on installation, just add a target to do the copy that depends on
the |
| 18:48.28 |
CIA-62 |
BRL-CAD:
library target. Can do this for the symlink if need but, but so far
it doesn't |
| 18:48.28 |
CIA-62 |
BRL-CAD: look
like we need to. Untested on Windows. |
| 18:52.07 |
*** join/#brlcad merzo
(~merzo@226-207-132-95.pool.ukrtel.net) |
| 18:55.26 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r2940 10/wiki/User:Bhinesley: /* Log */ real oed command requires
a keypoint |
| 19:00.50 |
CIA-62 |
BRL-CAD:
03starseeker * r45314 10/brlcad/trunk/CMakeLists.txt: LOCATION
-> LOCATION_ |
| 19:15.05 |
CIA-62 |
BRL-CAD:
03starseeker * r45315 10/brlcad/trunk/CMakeLists.txt: |
| 19:15.05 |
CIA-62 |
BRL-CAD: Most
of the time if you're compiling you want Debug build, and when you
don't |
| 19:15.05 |
CIA-62 |
BRL-CAD: want
that you're specifying Release build - it's extremely rare to
really WANT |
| 19:15.05 |
CIA-62 |
BRL-CAD: to
not have the build type set. Make the default behavior the common
case. |
| 19:27.47 |
``Erik |
http://www.youtube.com/watch?v=X9eriClHWLw
adam savage singing "I will survive" as gollum |
| 19:34.58 |
CIA-62 |
BRL-CAD:
03bhinesley * r45316 10/brlcad/trunk/src/libged/translate.c: Enable
support for translating all instances of a primitive. Negative
coordinates no longer mistaken for arguments. |
| 19:45.22 |
starseeker |
bites back cuss words - CMake has it's own notion of
permissions, independent of umask |
| 20:44.15 |
*** join/#brlcad bhinesley
(~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net) |
| 20:48.32 |
starseeker |
bhinesley:
I'm seeing the following: |
| 20:48.34 |
starseeker |
../../../src/libged/translate.c: In
function 'ged_translate': |
| 20:48.34 |
starseeker |
../../../src/libged/translate.c:237:
error: expected ')' before 'restrict' |
| 20:48.49 |
bhinesley |
huh,
ok |
| 20:50.45 |
*** join/#brlcad yukonbob
(~bch@S0106002191d1591c.ok.shawcable.net) |
| 20:53.38 |
CIA-62 |
BRL-CAD:
03bhinesley * r45317 10/brlcad/trunk/src/libged/translate.c:
restrict qualifier causing build errors |
| 20:54.06 |
bhinesley |
I'm
rebuilding from scratch right now, so I haven't tested that, but it
should get you by (possibly with a warning) |
| 21:18.57 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2941
10/wiki/ESA_Summer_of_Code_in_Space: initial description of SOCIS
announcing intent to apply |
| 21:22.26 |
CIA-62 |
BRL-CAD:
03kunigami * r45318 10/brlcad/trunk/src/liboptical/ (7 files):
changed osl-renderer to liboslrend |
| 21:30.15 |
kunigami |
I can't get
refraction to work. In the following render, the tall box is from
glass : http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-29.png |
| 21:40.09 |
CIA-62 |
BRL-CAD:
03r_weiss * r45319
10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 21:40.09 |
CIA-62 |
BRL-CAD:
Improved function 'nmg_bool' within file 'nmg_bool.c'. These
changes will, under |
| 21:40.09 |
CIA-62 |
BRL-CAD:
certain conditions, increase the speed in which boolean operations
are performed |
| 21:40.09 |
CIA-62 |
BRL-CAD: on
nmg structures. This will increase the speed of operations such as
when using |
| 21:40.09 |
CIA-62 |
BRL-CAD: the
mged 'facetize' or 'ev' command. |
| 21:49.56 |
brlcad |
kunigami1:
would be a good question to pose to the mailing list, maybe see if
Rossberg has some suggestions |
| 21:50.36 |
brlcad |
you're
definitely getting some interesting effects, but reflectivity is
clearly dominant |
| 22:13.16 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2942
10/wiki/ESA_Summer_of_Code_in_Space: simplify |
| 22:18.00 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2943
10/wiki/ESA_Summer_of_Code_in_Space: link proj ideas, needs
customization to socis |
| 22:19.24 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Google Summer of Code/Checklist]] moved
to [[Summer of Code/Checklist]]: want to reuse the checklist since
ESA is running their own SoC |
| 22:24.26 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2946
10/wiki/Summer_of_Code/Checklist: generalize and
specify |
| 22:25.37 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Google Summer of Code/Application
Guidelines]] moved to [[Summer of Code/Application Guidelines]]:
Now supports two SoC programs |
| 22:26.30 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2949
10/wiki/Summer_of_Code/Application_Guidelines: socify |
| 22:27.01 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2950
10/wiki/Summer_of_Code/Checklist: simplify category |
| 22:27.46 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Google Summer of Code/Acceptance]]
moved to [[Summer of Code/Acceptance]]: now supporting two soc
programs |
| 22:32.05 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2953
10/wiki/Summer_of_Code/Acceptance: generalize |
| 22:32.56 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Google Summer of Code/Expectations]]
moved to [[Summer of Code/Expectations]]: now supporting two SoC
programs |
| 22:37.12 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2956
10/wiki/Summer_of_Code/Expectations: generalize |
| 22:37.51 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2957
10/wiki/Summer_of_Code/Checklist: be abnoxious |
| 22:38.53 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2958
10/wiki/Summer_of_Code/Checklist: or not |
| 22:40.26 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2959
10/wiki/Google_Summer_of_Code: |
| 22:41.38 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2960
10/wiki/Google_Summer_of_Code/2011: |
| 22:59.55 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2961
10/wiki/ESA_Summer_of_Code_in_Space: generalize |
| 23:01.59 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Category:Google Summer of
Code]]": content was: '[[category:Projects]]' (and the only
contributor was '[[Special:Contributions/Ssd|Ssd]]') |
| 23:02.53 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2962
10/wiki/Google_Summer_of_Code/2008: |
| 23:03.26 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/move: [[Google Summer of Code/Proposal
Evaluation]] moved to [[Summer of Code/Proposal Evaluation]]:
generalize |
| 23:05.04 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2965
10/wiki/Summer_of_Code/Proposal_Evaluation: generalify |
| 23:05.50 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2966
10/wiki/User:EBautu: cat |
| 23:06.33 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2967
10/wiki/More_Changelog: cat |
| 23:07.00 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2968
10/wiki/Google_Summer_of_Code/Flyers: |
| 23:07.27 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2969
10/wiki/Google_Summer_of_Code/2009/Project_Ideas: cat |
| 23:07.50 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2970
10/wiki/Google_Summer_of_Code/2008/Project_Ideas: cat |
| 23:08.01 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2971
10/wiki/Google_Summer_of_Code/2009: cat |
| 23:08.27 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2972
10/wiki/Google_Summer_of_Code/2009/Project_Ideas: stray
. |
| 23:11.08 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2973
10/wiki/Google_Summer_of_Code/Project_Ideas: generalize |
| 23:14.19 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2974
10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: initial stab at
ideas for SOCIS, starting with the GSoC list |
| 23:59.32 |
``Erik |
*grouse* I
might have to play a game with highlighters and a trip to someone
with a free tube tester O.o |
| 00:47.07 |
*** join/#brlcad crazy_imp
(~mj@a89-182-123-98.net-htp.de) |
| 01:26.50 |
*** part/#brlcad milamber
(~devlin@d118-75-70-176.try.wideopenwest.com) |
| 04:15.18 |
CIA-62 |
BRL-CAD:
03brlcad * r45320 10/brlcad/trunk/src/libged/concat.c: reorder to
remove forward decls, remove misleading ged_ prefix from static
functions |
| 04:27.16 |
CIA-62 |
BRL-CAD:
03brlcad * r45321 10/brlcad/trunk/src/libged/draw.c: reorder to
remove forward decls, remove misleading ged_ prefix from static
functions |
| 04:38.02 |
CIA-62 |
BRL-CAD:
03brlcad * r45322 10/brlcad/trunk/src/libged/ (9 files): even more
reordering to remove forward decls, remove misleading ged_ prefix
from static functions |
| 05:02.36 |
CIA-62 |
BRL-CAD:
03bhinesley * r45323 10/brlcad/trunk/src/libged/translate.c: added
support for translating 'only a particular instance' of an object
(like 'oed obj1.c obj2.c/kp.s') |
| 05:05.37 |
bhinesley |
really
feeling like I understand what needs to happen now. The rest should
be muuuch faster :) |
| 05:06.10 |
bhinesley |
took every
neuron in my central nervous system to figure it out,
though |
| 05:08.19 |
bhinesley |
yawns |
| 05:24.32 |
CIA-62 |
BRL-CAD:
03bhinesley * r45324 10/brlcad/trunk/src/libged/translate.c: Enable
support for 'instance only' and 'all instances' translation of
primitives. The main things left to do, are: enabling support for
absolute/keypoint positioning and accepting multiple object
arguments. |
| 05:28.38 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r2975 10/wiki/User:Bhinesley: /* Log */ today |
| 05:29.54 |
CIA-62 |
BRL-CAD:
03brlcad * r45325 10/brlcad/trunk/src/libged/ (20 files): remainder
of reordering to remove forward decls and removal of misleading
ged_ prefix from static non-public api functions |
| 05:31.17 |
brlcad |
bhinesley:
haha, outstanding :) |
| 05:33.17 |
brlcad |
you got/get
how the current way oed behaves is to use the natural (aka
arbitrary coded keypoint) coordinate system origin of a specified
primitive as the origin to use for a keypoint? |
| 05:34.49 |
bhinesley |
I get what
you're saying |
| 05:37.03 |
bhinesley |
should the
'new' way allow the user to specify any coordinate as well as any
object's origin? |
| 05:37.28 |
brlcad |
ideally,
yeah |
| 05:37.46 |
bhinesley |
anything
else? |
| 05:40.57 |
brlcad |
three use
cases that come to mind are an arbitrary xyz, a 'natural' origin
keypoint akin to what oed does now, and a 'default' origin on an
object's minimum bounding box center |
| 05:41.51 |
brlcad |
there isn't
presently a routine to get the third one at the moment, but that's
probably the ideal default |
| 05:42.28 |
brlcad |
for now it
can just be the AABB center or stubbed into the command-line api
but unimplemented |
| 05:43.00 |
bhinesley |
ok |
| 05:43.01 |
brlcad |
need some
syntax to differentiate an object name refering to the natural vs
centered keybpoint |
| 05:43.56 |
bhinesley |
could just
use different switches (-n -c) |
| 05:44.06 |
brlcad |
sure |
| 06:44.04 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.252.52) |
| 06:44.04 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:28.21 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.211.204) |
| 07:28.21 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:46.23 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 10:54.45 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 11:09.01 |
CIA-62 |
BRL-CAD:
03brlcad * r45326 10/brlcad/trunk/src/libged/ged.c: yet another
tweak that 'should be safe' but might not be. release the ged_gdp
that we allocated during init. assume that init isn't being called
on something already initialized too. |
| 11:52.08 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 12:24.23 |
CIA-62 |
BRL-CAD:
03brlcad * r45327 10/brlcad/trunk/ (259 files in 7
dirs): |
| 12:24.23 |
CIA-62 |
BRL-CAD:
change ged_log an ged_result_str from being directly embedded
bu_vls structs to |
| 12:24.23 |
CIA-62 |
BRL-CAD:
being pointers. this makes the struct smaller but more importantly
lets us |
| 12:24.23 |
CIA-62 |
BRL-CAD:
manage memory and initialization more easily. sure, the pointer
might now be |
| 12:24.23 |
CIA-62 |
BRL-CAD:
null, but that'll be wrapped soon anyways (and can be validated).
happens to |
| 12:24.24 |
CIA-62 |
BRL-CAD: save
a lot of '&' typing too. ;) |
| 12:32.44 |
brlcad |
starseeker:
do you happen to have a set of already-rendered nifty NURBS images
handy? |
| 12:33.12 |
brlcad |
ideally
showcasing relatively simple objects that would be rather
complicated to implement as CSG |
| 12:33.47 |
brlcad |
I know
there's the phone images, any others? |
| 12:35.40 |
brlcad |
ideally
something that doesn't require release approval, looking to publish
an overview of step on the wiki and mailing list really
soon |
| 12:36.27 |
CIA-62 |
BRL-CAD:
03brlcad * r45328 10/brlcad/trunk/src/bwish/ (cadAppInit.c main.c):
not calling ged_init() |
| 12:37.07 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 12:38.47 |
CIA-62 |
BRL-CAD:
03brlcad * r45329 10/brlcad/trunk/src/libged/ged.c: have to
bu_free() the gedp itself now since ged_free() releases the
internal memory (so it can still release memory for ged structs on
the stack) |
| 12:58.29 |
CIA-62 |
BRL-CAD:
03brlcad * r45330 10/brlcad/trunk/src/libged/ged.c: |
| 12:58.29 |
CIA-62 |
BRL-CAD: fix
compile, missed commit. don't free the gedp itself during
ged_free() so we |
| 12:58.29 |
CIA-62 |
BRL-CAD: can
still pass static struct ged entities and have their memory
allocations |
| 12:58.29 |
CIA-62 |
BRL-CAD:
released. this matches with other bu structs and their respective
free |
| 12:58.29 |
CIA-62 |
BRL-CAD:
functions (e.g. bu_vls_free()). |
| 13:00.24 |
epileg |
I'm using
-DBRLCAD_INSTALL_DATA_DIR= and -DDDATA_DIR= to set share folder,
but without success. How can I properly set it? |
| 13:00.49 |
CIA-62 |
BRL-CAD:
03brlcad * r45331 10/brlcad/trunk/src/shapes/ (human.c tire.c): we
can now call ged_free() so we're not leaking memory (albeit during
exit) |
| 13:08.49 |
brlcad |
is DDDATA_DIR
a typo? |
| 13:09.42 |
CIA-62 |
BRL-CAD:
03brlcad * r45332 10/brlcad/trunk/src/ (libged/wdb_obj.c
mged/mged.c mged/setup.c): plug various ged memory leakages. if we
fail, reset back to null. |
| 13:10.21 |
epileg |
brlcad: is as
starseeker typed |
| 13:11.06 |
brlcad |
looks like
one too many D's to me |
| 13:11.52 |
epileg |
ok, i'll try
removing a D |
| 13:15.53 |
brlcad |
starseeker:
cmake --help-variable-list and all the other various --help-*
commands seem to be somewhat useless ... can all the various
BRL-CAD vars get added to a BRLCAD module? |
| 13:17.03 |
brlcad |
epileg: I do
see that CMAKE_INSTALL_PREFIX is the equivalent of ./configure
--prefix= |
| 13:18.05 |
epileg |
yes, i know.
what 's BRLCAD_PREFIX? |
| 13:19.00 |
brlcad |
presumably
the same thing, where do you see that? |
| 13:19.58 |
epileg |
I' see it
with "cmake-gui" |
| 13:20.05 |
brlcad |
starseeker:
also, INSTALL.cmake looks like it's incomplete? still has all the
configure options, no itemized cmake build options |
| 13:21.52 |
brlcad |
epileg: ah,
yeah -- the CMakeLists file says it's also the install prefix, an
advanced option of some sort |
| 13:22.26 |
brlcad |
it's set to
CMAKE_INSTALL_PREFIX, so perhaps just an internal
variable |
| 13:23.15 |
epileg |
brlcad: ok,
thanks. removing a D for share folder properly worked! |
| 13:24.00 |
brlcad |
form is -D
VAR=VAL |
| 13:24.13 |
brlcad |
so it was
suspicious that there'd be a DDATA_DIR var |
| 13:24.20 |
epileg |
aha |
| 13:25.21 |
brlcad |
from my
reading of the usage, the space is even optional so it'd probably
be more clear to put the space in our docs |
| 13:25.25 |
``Erik |
BRLCAD_PREFIX
is something starseeker added to prevent using old installed
BRL-CAD libs to link during build, should be marked as
advanced |
| 13:26.06 |
``Erik |
CMAKE_INSTALL_PREFIX is the one you want
to use |
| 13:27.28 |
epileg |
Thanks brlcad
``Erik |
| 13:27.30 |
CIA-62 |
BRL-CAD:
03starseeker * r45333 10/brlcad/trunk/CMakeLists.txt: Readibility
improvement. |
| 13:27.46 |
epileg |
now I only
need text to properly rendering. Is there a way to do that in
cmake? |
| 13:30.56 |
kunigami |
I made a
scene consisting of a sphere with center (0,0,0) and radius 1 and
shot a ray from (-10, 0, 0) with direction (1, 0, 0) |
| 13:31.51 |
kunigami |
when I call
the first rt_shootray it returns (-1, 0, 0) as the hit point (OK).
OSL code returns the direction (1, 0, 0) (OK) |
| 13:32.45 |
kunigami |
then I
forward the hit point a little bit to (-0.9999, 0, 0) and shoot a
new ray from there with direction (1, 0, 0). rt_shootray returns
(-0.9999, 0, 0) as the hit point |
| 13:34.01 |
kunigami |
I'll send
this information to the mail list as suggested. I'm probably not
setting something right before calling rt_shootray the second
time |
| 13:56.45 |
d_rossberg |
kunigami:
(-0.9999, 0, 0) is OK but you are probable interested in the
pt_outhit |
| 14:35.38 |
starseeker |
brlcad:
seeing a crash: http://pastebin.mozilla.org/1261320 |
| 14:35.55 |
starseeker |
brlcad: urm.
NURBS images... probably just the phone image handy |
| 14:36.30 |
starseeker |
http://bzflag.bz/~starseeker/phone_large.png |
| 14:40.59 |
starseeker |
let me see if
I can get an openbook image rendered |
| 14:44.49 |
starseeker |
http://bzflag.bz/~starseeker/openbook_d2.png |
| 14:53.45 |
starseeker |
brlcad: um...
the cmake help commands are help for cmake developers, not about a
particular project |
| 14:55.16 |
starseeker |
INSTALL.cmake
was/is a work in progress. I haven't pushed to finish it up
yet |
| 14:55.58 |
starseeker |
I didn't
figure we would be pushing the CMake build as primary until after
this release, so I wasn't worried about it yet. |
| 14:59.40 |
*** join/#brlcad Ralith_
(~ralith@S010600221561996a.vc.shawcable.net) |
| 15:00.44 |
*** part/#brlcad Ralith_
(~ralith@S010600221561996a.vc.shawcable.net) |
| 15:05.07 |
brlcad |
kunigami: ah,
probably because you're inside an object, so it's instantly a hit.
since you know you're a refraction ray, you may want to set onehit
to false and skip the first partition |
| 15:05.47 |
brlcad |
otherwise,
you have no idea how far forward you'll need to nudge forward to
get past that object |
| 15:06.21 |
brlcad |
ah, or what
d_rossberg said :) |
| 15:07.02 |
kunigami |
:) I'm
implementing that. For a render with few samples it seems to have
worked. Checking with more samples now |
| 15:07.41 |
brlcad |
starseeker:
yeah, looking for something better than those |
| 15:07.57 |
brlcad |
phone_large
is interesting, but isn't "nurbs-compelling" |
| 15:08.14 |
brlcad |
openbook_d2
is "nurbs-compelling", but just not very interesting |
| 15:08.49 |
starseeker |
brlcad: yeah,
then I don't have anything handy |
| 15:09.17 |
brlcad |
evan a simple
closed surface deformed to all hell wibbly wobbly would probably
work, but a real object would be better |
| 15:09.19 |
starseeker |
sorry
:-/ |
| 15:10.03 |
starseeker |
are you
seeing that bomb issue with ged_init? |
| 15:10.28 |
brlcad |
looking at
that now |
| 15:10.46 |
brlcad |
everyone
should see it given that report |
| 15:11.04 |
brlcad |
didn't you
read it? :) |
| 15:11.28 |
starseeker |
I did - but
figured you'd probably tested the recent commits, so I thought
perhaps there was another uncommitted file or some such |
| 15:13.06 |
brlcad |
tested, but
apparently not code that exercised ged_init() |
| 15:13.52 |
CIA-62 |
BRL-CAD:
03brlcad * r45334 10/brlcad/trunk/src/libged/ged.c: have to
allocate memory now before init can occur since they're just
pointers |
| 15:19.22 |
starseeker |
yep, that's
got it - thanks |
| 15:33.03 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.146.37) |
| 15:33.03 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:15.46 |
starseeker |
kunigami:
might want to update the Makefile.am in liboptical |
| 16:16.01 |
kunigami |
ouch, I
always forget |
| 16:17.23 |
starseeker |
brlcad: I
doubt it's "nurbsy" enough, but here's a rendering of the bugbase
model: http://bzflag.bz/~starseeker/bugbase.png |
| 16:19.42 |
CIA-62 |
BRL-CAD:
03kunigami * r45335 10/brlcad/trunk/src/liboptical/Makefile.am:
changed osl-renderer to liboslrend in Makefile.am |
| 16:20.20 |
brlcad |
better, but
similarly kind of bland |
| 16:21.01 |
starseeker |
kunigami:
thanks |
| 16:30.07 |
kunigami |
http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-30.png |
| 16:30.31 |
kunigami |
The light is
a bit too strong, but I think the glass is being rendered right
now. |
| 16:32.23 |
starseeker |
kunigami:
nice! |
| 16:50.14 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 16:52.21 |
starseeker |
brlcad: hmm -
still getting complaints about leftover files from distcheck in the
bench directory: http://pastebin.mozilla.org/1261343 |
| 16:53.40 |
brlcad |
kunigami:
awesome .. curious interaction on the ground but not yet clear
whether it's "right" or not |
| 16:53.44 |
brlcad |
definitely
better though |
| 16:54.49 |
brlcad |
one thing I
remembered to ask you about... are you running through rt or is
this through that osl front-end tracer set up to shoot librt
rays? |
| 16:55.42 |
brlcad |
reason I ask,
the image looks flipped |
| 16:56.06 |
kunigami |
I'm running
from the second one. My next step is to port is to rt so that I can
try to integrate with BRL-CAD shaders |
| 17:01.38 |
CIA-62 |
BRL-CAD:
03brlcad * r45336 10/brlcad/trunk/bench/Makefile.am: try making
these 'local' overrides since something is apparently stopping
regular generated files from getting cleaned up during
distcheck. |
| 17:01.40 |
brlcad |
yeah, getting
that same output, even without any other brl-cad shaders, via rt
would be good |
| 17:02.41 |
brlcad |
and gets
closer towards answering those outstanding questions I had
regarding how secondary rays are going to play with arbirary osl
shaders |
| 17:06.13 |
CIA-62 |
BRL-CAD:
03brlcad * r45337 10/brlcad/trunk/TODO: mater command
bustage?? |
| 17:28.11 |
CIA-62 |
BRL-CAD:
03kunigami * r45338 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt
Makefile.am osl_rt.cpp): added suport for refraction to osl_rt.
Also added it no Makefile.am |
| 17:28.24 |
kunigami |
*to |
| 17:36.00 |
CIA-62 |
BRL-CAD:
03brlcad * r45339 10/brlcad/trunk/include/bu.h: add some assertions
and protections to the bu_list insertion/dequeue macros. make them
not dereference null or at least assert gracefully so we don't
crash. |
| 17:39.10 |
CIA-62 |
BRL-CAD:
03brlcad * r45340 10/brlcad/trunk/ (NEWS
src/liboptical/sh_light.c): |
| 17:39.10 |
CIA-62 |
BRL-CAD:
encountered a crash during raytrace rendering a scene that had just
one light |
| 17:39.10 |
CIA-62 |
BRL-CAD: with
an invalid parameter specification. structparse failed
causing |
| 17:39.10 |
CIA-62 |
BRL-CAD:
light_free() to be called, which crashed on the light list (that
had none added |
| 17:39.10 |
CIA-62 |
BRL-CAD:
yet). fixed the bug on both ends, making the list dequeue safe and
initializing |
| 17:39.11 |
CIA-62 |
BRL-CAD: the
list properly. |
| 17:46.06 |
*** join/#brlcad yukonbob
(~bch@S0106002191d1591c.ok.shawcable.net) |
| 18:14.52 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:47.49 |
CIA-62 |
BRL-CAD:
03kunigami * r45341 10/brlcad/trunk/src/liboptical/ (osl_rt.cpp
sh_osl.cpp): rt now correctly renders reflection |
| 18:48.41 |
kunigami |
For
refraction, I'll probably have to create a new callback in the
fashion of rr_render |
| 19:04.06 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.146.37) |
| 19:04.06 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:41.19 |
CIA-62 |
BRL-CAD:
03starseeker * r45342 10/brlcad/trunk/ (NEWS TODO
src/libged/mater.c): |
| 19:41.19 |
CIA-62 |
BRL-CAD: Fix
a bug in the mater command - wasn't respecting the attribute
syncing needed |
| 19:41.19 |
CIA-62 |
BRL-CAD: for
the new system. Ultimately this should be rewritten to just act
on |
| 19:41.19 |
CIA-62 |
BRL-CAD:
attributes and not the comb structure, but that's a bit more
extensive. |
| 19:44.32 |
CIA-62 |
BRL-CAD:
03starseeker * r45343 10/brlcad/trunk/ (NEWS TODO): Bob fixed a
number of issues with rtwizard by porting it to use the new
ArcherCore framework (handling unknown units, freezing on some .g
files.) |
| 19:45.41 |
starseeker |
``Erik: I'm
assuming that osX link line TODO is the one for CMake? |
| 19:47.44 |
CIA-62 |
BRL-CAD:
03starseeker * r45344 10/brlcad/trunk/TODO: Move a few tasks that
aren't going to be handled this go-around. |
| 19:49.51 |
starseeker |
brlcad: um.
is "revolve typein" the MGED command line input for our revolve
primitive? |
| 19:51.29 |
starseeker |
fires off distcheck again |
| 19:56.21 |
brlcad |
starseeker:
i'm not sure the mater color problem was occuring before 7.20.0,
only noticed it afterwards |
| 19:56.53 |
brlcad |
and yes, "in
rev revolve ..." |
| 19:57.12 |
brlcad |
that avs code
seems incredibly complicated for what it's doing |
| 19:59.34 |
kunigami |
http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-Refraction-Corrected-2011-06-30.png |
| 20:00.43 |
kunigami |
I was using a
wrong index of refraction inside BRL-CAD, so it could be
calculating hitting points wrongly |
| 20:33.58 |
starseeker |
woot -
distcheck passed on linux |
| 20:37.36 |
CIA-62 |
BRL-CAD:
03starseeker * r45345 10/brlcad/trunk/misc/Makefile.am: Need the
Doxygen.in file in extradist |
| 20:58.11 |
CIA-62 |
BRL-CAD:
03bhinesley * r45346 10/brlcad/trunk/src/libged/translate.c: Clean
up some logic, clarify comments |
| 21:05.11 |
starseeker |
``Erik: With
the inclusion of Doxygen.in, I think the CMake build is now
functioning from the autotools tarball |
| 21:12.03 |
brlcad |
kunigami:
yeah, *that* is looking much better :) |
| 21:12.20 |
brlcad |
did you make
the light bigger? |
| 21:13.28 |
kunigami |
yup :P but I
did not the right way. Now when I render I get way more overlap
messages (just scaled both the ceiling hole and the rectangle by
hand) |
| 21:15.54 |
starseeker |
brlcad: in
rev.s revolve 0 0 0 0 0 1 0 1 0 190 test_sketch works for
me |
| 21:16.14 |
starseeker |
was there
something specific that was a concern? |
| 21:17.39 |
CIA-62 |
BRL-CAD:
03brlcad * r45347 10/brlcad/trunk/src/libged/mater.c: improve
handling of the color arguments by properly trimming whitespace
before making comparisons or parsing values. |
| 21:18.24 |
CIA-62 |
BRL-CAD:
03kunigami * r45348 10/brlcad/trunk/src/liboptical/sh_osl.cpp:
added a callback to be called whenever a refraction ray is shoot.
I'm getting some runtime errors like mis-aligned struct hit
pointer. |
| 21:20.13 |
CIA-62 |
BRL-CAD:
03brlcad * r45349 10/brlcad/trunk/src/libged/mater.c: free the
right vls |
| 21:21.40 |
kunigami |
Current
render by rt for a mirror shader (tall box):
http://dl.dropbox.com/u/1399996/GSoC/OSL_Shader_Mirror_Test_2011-06-30.png |
| 21:22.08 |
kunigami |
... and for
glass shader (tall box):
http://dl.dropbox.com/u/1399996/GSoC/OSL_Shader_Glass_Test_2011-06-30.png |
| 21:22.50 |
kunigami |
wrong, by the
way |
| 21:22.51 |
brlcad |
kunigami:
avoid forward decls unless you have a cyclic loop |
| 21:23.11 |
kunigami |
brlcad: ok!
I'll fix that |
| 21:25.47 |
CIA-62 |
BRL-CAD:
03starseeker * r45350 10/brlcad/trunk/TODO: revolve in seems to
function. |
| 21:25.50 |
CIA-62 |
BRL-CAD:
03kunigami * r45351 10/brlcad/trunk/src/liboptical/sh_osl.cpp:
avoiding forward decls |
| 21:26.39 |
starseeker |
brlcad: I'm
guessing that mater bug probably does appear in 7.20.0 - it's
almost certainly a consequence of the attribute/red
work |
| 21:27.08 |
brlcad |
starseeker:
nope, just a quick sanity check since the typein interface for it
was changed -- maybe try that same in command interactively if it
wasn't so it builds up the args |
| 21:27.28 |
starseeker |
brlcad:
that's how I generated that command - interactively :-P |
| 21:27.33 |
starseeker |
didn't know the parameters |
| 21:27.38 |
brlcad |
k,
cool |
| 21:27.45 |
brlcad |
good
enough! |
| 21:28.23 |
starseeker |
I think that
OSX thing is the CMake logic not sorting out multiple X11 installs
on a Mac - probably don't need to swat that right now, that'll
involve some fairly heavy duty mucking with
FindX11.cmake |
| 21:34.46 |
CIA-62 |
BRL-CAD:
03starseeker * r45352 10/brlcad/trunk/TODO: Move the OSX X11 search
issue, add some more notes about what will need to be
done. |
| 21:37.50 |
CIA-62 |
BRL-CAD:
03brlcad * r45353 10/brlcad/trunk/src/libged/mater.c: remove the
debug avs printing |
| 21:39.29 |
brlcad |
does the
build automatically look in the ports dir or did the user specify
an additional dyld_library_path? |
| 21:39.40 |
brlcad |
it shouldn't
be looking in the ports dir automatically in the first
place |
| 21:39.57 |
brlcad |
unless
someone points there with flags |
| 21:41.15 |
brlcad |
if it's a
user setting, then we can try to detect that and/or tell people to
unset their paths |
| 21:41.48 |
starseeker |
dunno - have
to look at FindX11 and what the find paths are by default on
OSX |
| 21:43.50 |
starseeker |
it can
probably be handled cleanly, but I don't have time to tackle it for
this release |
| 21:44.06 |
brlcad |
I don't see
/opt in the list (except a stray include dir) |
| 21:44.20 |
starseeker |
would want to
include ``Erik in that discussion, since he spotted the issue
first |
| 21:44.33 |
brlcad |
also don't
see the default mac install location either, though |
| 21:44.54 |
starseeker |
nods - that's why I want to check ``Erik's setup in more
detail |
| 21:49.50 |
CIA-62 |
BRL-CAD:
03brlcad * r45354 10/brlcad/trunk/misc/CMake/FindX11.cmake: look in
/usr/X11/lib followed by the older convention, X11 subdirs in the
system lib. |
| 21:56.24 |
CIA-62 |
BRL-CAD:
03brlcad * r45355 10/brlcad/trunk/src/libged/mater.c: if the avs
isn't initialized before it's needed, then we don't need to free it
on all the error conditions. also emphasizes the curious
double-standardize... intentional? |
| 21:56.25 |
CIA-62 |
BRL-CAD:
03starseeker * r45356
10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Tweak the png
linking mechanism a bit - test this on a few more
platforms. |
| 21:57.29 |
starseeker |
brlcad: urm.
IIRC, I think I standardized on import to make sure any changes to
the color attribute would override any pre-existing color
attributes... |
| 21:58.33 |
starseeker |
not sure if
both are still needed |
| 21:58.58 |
starseeker |
that whole
thing needs to be rewritten - it shouldn't be acting on the comb
structure directly at all, except for the avs |
| 21:59.21 |
starseeker |
i gotta run,
bbl |
| 22:13.45 |
brlcad |
nods |
| 22:14.53 |
brlcad |
curious that
the old way has stopped working through -- that's not
bidirectional, I'd expect the write of a db_comb_internal to sync
comb to attr, then attr to comb, then write out |
| 22:16.10 |
brlcad |
since the
comb fields are "fixed" and have flags when fields are invalid,
they can be used to detect deletions and such that you don't get
otherwise |
| 22:23.46 |
CIA-62 |
BRL-CAD:
0376.252.190.26 07http://brlcad.org
* r2976 10/wiki/STEP: update/reword scl, esa/nasa
sections |
| 22:35.46 |
CIA-62 |
BRL-CAD:
0383.85.24.171 07http://brlcad.org
* r2977 10/wiki/ESA_Summer_of_Code_in_Space: |
| 22:38.04 |
bhinesley |
is there a
standard character we should use for commands skipping coordinate
arguments? |
| 22:38.05 |
bhinesley |
Ex: translate
- - 5 sph.s ;# move sph.s up z-axis 5 units |
| 22:39.39 |
bhinesley |
In that case,
zero would work, but there are cases zero would not
suffice |
| 22:40.28 |
bhinesley |
Ex: translate
-c - - 5 sph.s ;# move center of sph.s 5 units up
z-axis |
| 22:41.07 |
bhinesley |
er to z=5,
rather |
| 23:42.22 |
CIA-62 |
BRL-CAD:
03r_weiss * r45357
10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: |
| 23:42.22 |
CIA-62 |
BRL-CAD:
Updated functions 'nmg_two_face_fuse' and 'nmg_model_face_fuse'
within file |
| 23:42.22 |
CIA-62 |
BRL-CAD:
'nmg_fuse.c'. These changes improve the fusing of coplanar faces
during boolean |
| 23:42.22 |
CIA-62 |
BRL-CAD:
operations of nmg objects. The changes can be seen on curved
objects such as |
| 23:42.22 |
CIA-62 |
BRL-CAD:
spheres which are not distorted due to improper face fusing. The
changes effect |
| 23:42.23 |
CIA-62 |
BRL-CAD:
functions such the mged 'facetize' and 'ev' commands. |
| 00:17.15 |
CIA-62 |
BRL-CAD:
03r_weiss * r45358
10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: |
| 00:17.15 |
CIA-62 |
BRL-CAD:
Updated function 'nmg_shell_coplanar_face_merge' within file
'nmg_mod.c'. This |
| 00:17.15 |
CIA-62 |
BRL-CAD:
update improves the success of boolean operations on nmg objects
which contain |
| 00:17.15 |
CIA-62 |
BRL-CAD:
coplanar faces. This change effects functions such as the mged
'facetize' and |
| 00:17.15 |
CIA-62 |
BRL-CAD: 'ev'
commands. |
| 00:27.57 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 00:46.26 |
*** join/#brlcad crazy_imp
(~mj@a89-182-114-102.net-htp.de) |
| 01:01.59 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
| 01:57.08 |
*** join/#brlcad _psilva1
(~Adium@pool-74-96-114-18.washdc.fios.verizon.net) |
| 01:57.30 |
_psilva1 |
eh |
| 01:59.47 |
_psilva1 |
test |
| 01:59.52 |
*** part/#brlcad _psilva1
(~Adium@pool-74-96-114-18.washdc.fios.verizon.net) |
| 02:00.06 |
*** join/#brlcad _psilva1
(~Adium@pool-74-96-114-18.washdc.fios.verizon.net) |
| 02:00.17 |
_psilva1 |
test
2 |
| 02:01.42 |
_psilva1 |
anyone
compile pkg-config lately? |
| 02:03.11 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 02:49.54 |
``Erik |
we were doing
a hard push on a release until someone did a metric fuckton of
libged commits.. with any luck, we'll finish the release cycle this
week with a build that is auto*, cmake and pkg friendly
:/ |
| 02:55.00 |
``Erik |
starseeker:
you have access to the box that's causing issue, I'd not qualify it
as a show stopper for the release, just a "needs to be looked into
soon" issue |
| 03:31.31 |
brlcad |
bhinesley:
probably opt for your previous suggestion, making different options
-c # # # == -x # -y # -z # |
| 03:32.21 |
bhinesley |
alright |
| 03:33.08 |
bhinesley |
I have an
idea to make the oed-ish commands more versatile |
| 03:33.25 |
bhinesley |
I'll show you
later |
| 03:33.40 |
brlcad |
xyz or
ijk |
| 03:33.41 |
brlcad |
ok |
| 03:34.18 |
brlcad |
could use xyz
for points and ijk for angles or somesuch |
| 03:34.42 |
brlcad |
or gang them
together, just a lil messier to validate |
| 03:36.20 |
bhinesley |
hmm so you
don't like "translate 5 # 7 object2.c"? |
| 03:36.49 |
bhinesley |
I'm not quite
following |
| 04:08.57 |
brlcad |
not
particularly |
| 04:09.13 |
brlcad |
that would be
introducing a new 'convention' of sorts |
| 04:09.28 |
brlcad |
and not one
particularly obvious |
| 04:09.36 |
bhinesley |
yeah, I was
hoping there was one |
| 04:15.10 |
bhinesley |
what about
using the -x -y -z's as placeholders: "translate -k -x -y 5 -x -y 6
obj.c" would move obj.c from 5 to 6 on the z-axis |
| 04:16.11 |
bhinesley |
well not
exactly... it would be equivalent to 'translate -x -y 1
obj.c' |
| 04:16.30 |
brlcad |
that doesn't
make a whole lot of immediate sense to me either |
| 04:17.16 |
bhinesley |
the trouble
with the way you mentioned, is that you can't tell the difference
between a -x for a keypoint and a -x for a delta |
| 04:17.59 |
bhinesley |
there's
something similar to this in AutoCAD called point filters...
extremely useful and underused |
| 04:19.09 |
brlcad |
oh but there
is, missing opts |
| 04:20.28 |
brlcad |
translate -a
-c 1 2 3 foo ; translate -r -x 2 -y 1 foo ; foo is at 3 3
3 |
| 04:20.45 |
brlcad |
absolute and
relative options |
| 04:21.46 |
brlcad |
or one could
be the default so you only need the option to specify the
other |
| 04:22.01 |
brlcad |
e.g.,
relative as default, then -a for absolute |
| 04:24.34 |
brlcad |
since all
three commands need to work together and writing argv/argc parsing
sucks, write out the synopsis first |
| 04:24.42 |
brlcad |
for tra, sca,
rot |
| 04:25.10 |
bhinesley |
I did for my
idea... I should show you now. |
| 04:25.28 |
brlcad |
so we don't
end up with -c coordinate, -p point, -k keypoint, all meaning the
same thing |
| 04:26.08 |
bhinesley |
Alright, keep
in mind that I was thinking that using a placeholder like '-' would
be okay when I wrote this: http://pastebin.mozilla.org/1261895 |
| 04:27.21 |
bhinesley |
formatting
got a little screwed up |
| 04:29.50 |
brlcad |
halfway
through |
| 04:30.05 |
brlcad |
that's
actually looking pretty good |
| 04:31.50 |
brlcad |
still think
the - is a bit screwy -- we do have a convention of using '.' with
another command so that'd be the only relevant convention, but I
think that explicit axis opts would provide more clarity and the
'.'s would just be a shorthand for experts |
| 04:33.15 |
bhinesley |
that sounds
good; there's one case that it may be problematic to use the
-x/-y/-z with: 'translate -k -x 1 -y 2 -z 3 object' is ambiguous...
but it may not be a valid command anyways |
| 04:33.28 |
brlcad |
another
convention used is a field separator, e.g., "5/2/3" or "3,1,3" ..
where you allow empty fields "/2/3" and ",,3" |
| 04:36.21 |
brlcad |
not a huge
fan, though |
| 04:36.44 |
bhinesley |
I think the
-x/-y/-z and '.' thing works |
| 04:36.50 |
bhinesley |
any ideas for
alternatives to the '-' arguments for the -c/-o
options? |
| 04:42.59 |
bhinesley |
I suppose I
could allow use of '.' intended for experts as with -x/-y/-z, and
everyone else just types out the path/obj again |
| 04:46.02 |
bhinesley |
or sets it to
a TCL variable |
| 04:49.23 |
epileg |
starseeker:
mged compiled with cmake has these more dependencies http://paste.debian.net/121565/
than the mged compiled with autotools |
| 04:50.27 |
brlcad |
bhinesley:
avoid any interaction with tcl on the libged side of
things |
| 04:50.38 |
bhinesley |
I meant that
the user could |
| 04:50.46 |
brlcad |
k |
| 04:50.57 |
brlcad |
the goal is
to make the core libs completely devoid of tcl, long term
project |
| 04:51.16 |
brlcad |
basically
undoing integration from the past 15 years :) |
| 04:51.23 |
bhinesley |
hehe |
| 04:53.34 |
brlcad |
bhinesley: I
like the write up |
| 04:53.42 |
brlcad |
clearly put a
good bit of thought into this |
| 04:53.51 |
bhinesley |
cool,
thanks |
| 04:54.46 |
bhinesley |
...thanks for
taking it seriously |
| 04:54.58 |
bhinesley |
would have
been easy to say "meh. do it my way." |
| 04:55.35 |
brlcad |
meh, it's not
that bad ;) |
| 04:55.43 |
bhinesley |
hehe |
| 04:55.57 |
brlcad |
I think
-x/-y/-z and '.' will help be more consistent |
| 04:56.55 |
brlcad |
except in
this context... 0.0 vs 0. vs .0 vs . are all pretty similar
:) |
| 04:58.26 |
brlcad |
something
about this is bothersome: translate -k -23 4 17 9 2 1
bowl.c |
| 04:58.50 |
brlcad |
I think it's
the slew of labeled and unlabeled numbers |
| 05:00.01 |
bhinesley |
could make a
-d (delta) switch, that is optional/only required when -k is
used |
| 05:00.25 |
bhinesley |
"translate -k
-23 4 17 -d 9 2 1 bowl.c" |
| 05:00.49 |
bhinesley |
honestly,
that is nothing more than a relative translation that does some
math for you |
| 05:03.41 |
brlcad |
nods |
| 05:03.46 |
brlcad |
it's more
important for rotate |
| 05:04.46 |
brlcad |
I think it
gets back to an optional [-a|-r] for the TO |
| 05:05.12 |
brlcad |
translate -k
-23 3 17 -r 9 2 1 bowl.c |
| 05:05.26 |
brlcad |
which is same
as translate -k -23 4 17 9 2 1 bowl.c |
| 05:05.33 |
bhinesley |
good
idea |
| 05:05.34 |
brlcad |
i.e., -r is
optional and default |
| 05:05.42 |
brlcad |
but makes
documenting instructions more clear |
| 05:06.17 |
brlcad |
and in that
context -k with -a would be pointless since -a wins, but no harm to
specify it |
| 05:07.35 |
bhinesley |
shouldn't it
be "translate -k -23 3 17 -a 9 2 1 bowl.c" though, since the 9,2,1
are absolute coordinates |
| 05:07.57 |
bhinesley |
and then
"translate -r 5 5 5 obj" == "translate 5 5 5 obj" |
| 05:09.05 |
bhinesley |
n/m I read
your last sentence |
| 05:09.33 |
*** join/#brlcad _psilvah
(~prasad@pool-74-96-114-18.washdc.fios.verizon.net) |
| 05:09.39 |
_psilvah |
brlcad: w00t!
:D |
| 05:10.06 |
brlcad |
heh |
| 05:10.08 |
_psilvah |
finally
progress |
| 05:10.25 |
_psilvah |
thanks
btw |
| 05:12.39 |
brlcad |
hey, it's for
a good cause if it gets you back into useful coding ;) |
| 05:12.54 |
_psilvah |
3 |
| 05:13.24 |
_psilvah |
bench is
next |
| 05:13.39 |
_psilvah |
tho i need to
brush up on svn commands |
| 05:13.55 |
_psilvah |
now how do i
switch to window 3.. |
| 05:13.58 |
_psilvah |
:( |
| 05:14.12 |
brlcad |
bhinesley: my
understanding is => translate -k 10 10 10 -a -10 0 10 bowl.c
=> -10,0,10 and... |
| 05:15.16 |
brlcad |
translate -k
10 10 10 -r -10 0 10 bowl.c => translate -k 10 10 10 -10 0 10
bowl.c => translate -k 10 10 10 -10 . 10 bowl.c =>
0,10,20 |
| 05:18.16 |
bhinesley |
that's the
exact opposite of what I was thinking :) |
| 05:18.39 |
brlcad |
hah,
outstanding then |
| 05:19.46 |
brlcad |
how does a
relative translate get you to absolute coordinates from a
keypoint? |
| 05:21.58 |
brlcad |
would be nice
to combine the -c -o -k options, to simplify usage |
| 05:22.08 |
brlcad |
-k object
makes perfect sense to me |
| 05:23.41 |
brlcad |
just need to
know which point in object |
| 05:25.21 |
bhinesley |
I think I
just misunderstood what you were saying... translate -k 10 10 10 -a
-10 0 10 bowl.c would move you a relative -20,-10,0,
right? |
| 05:25.50 |
bhinesley |
when I'm
thinking of "-a", I'm thinking, these coordinates are
absolute |
| 05:26.25 |
bhinesley |
may be too tired to think straight |
| 05:26.33 |
brlcad |
you didn't
misunderstand, that's not what I wrote -- but that would make
sense |
| 05:26.41 |
brlcad |
I was
thinking -k was completely meaningless with -a |
| 05:27.21 |
brlcad |
with the
reasoning that if you translate to an absolute position (from ANY
keypoint), you end up at that position |
| 05:27.56 |
bhinesley |
I
see |
| 05:28.16 |
brlcad |
I get your
idea too, rather different |
| 05:29.01 |
brlcad |
and from a
utilitarian perspective, yours probably makes more sense since mine
is achieved by simply dropping the -k |
| 05:30.21 |
brlcad |
whereas yours
you can use to calculate |
| 05:31.50 |
brlcad |
basically "a
- k = point" giving -20,-10,0 |
| 05:31.59 |
bhinesley |
right |
| 05:32.26 |
brlcad |
and "k + r =
point" for relative |
| 05:33.35 |
brlcad |
? |
| 05:33.39 |
bhinesley |
not
exactly |
| 05:34.10 |
bhinesley |
r does
movements relative to the current position |
| 05:34.21 |
bhinesley |
so a -r from
any keypoint is the same |
| 05:37.24 |
brlcad |
if bowl.c is
at 100,100,100, then I believe you're saying "translate -k 10 10 10
-a -10 0 10 bowl.c" puts it at 80,90,100 (calculated a -20,-10,0
vector) |
| 05:38.23 |
bhinesley |
correct |
| 05:38.34 |
brlcad |
if bowl.c is
at 100,100,100, then "translate -k 10 10 10 -r -10 0 10 bowl.c"
puts it at ... |
| 05:39.21 |
bhinesley |
-k is
ignored; it's the same as "translate -r 10 0 10 bowl.c", so bowl.c
is at 110,100,110 |
| 05:40.36 |
brlcad |
presuming you
meant 90,100,110 ;) |
| 05:40.47 |
bhinesley |
yes |
| 05:40.56 |
bhinesley |
I have these
fonts really small |
| 05:41.09 |
bhinesley |
missed the
'-' |
| 05:41.20 |
brlcad |
that seems to
defeat the meaning of a keypoint to me |
| 05:42.03 |
bhinesley |
I agree, that
was just my understanding |
| 05:42.10 |
bhinesley |
I like what
you said before |
| 05:42.21 |
bhinesley |
it's just a
bit hard to understand |
| 05:42.44 |
brlcad |
translate -k
bowl.c -r -10 0 10 bowl.c == translate -r -10 0 10
bowl.c |
| 05:42.54 |
bhinesley |
-r moves us
to an absolute point, which is a relative distance away from the
keypoint |
| 05:44.23 |
brlcad |
from that
approach: translate -k bowl.c == translate -k 100 100 100, so
tranlsate -k 100 100 100 -r -10 0 10 bowl.c => 90,100,110 make
perfect sense |
| 05:44.48 |
brlcad |
but then it
carries that translate -k 10 10 10 -r -10 0 10 bowl.c should not be
the same |
| 05:46.17 |
brlcad |
k + r is
consistent with both |
| 05:46.55 |
bhinesley |
ok |
| 05:47.02 |
bhinesley |
sounds
good |
| 05:47.02 |
brlcad |
with the
understanding that k is implicitly the object's position unless
overridden |
| 05:48.22 |
brlcad |
keeps in line
with your nice FROM TO setup |
| 05:48.37 |
brlcad |
the TO is wrt
the FROM, not the object |
| 05:48.52 |
brlcad |
unless FROM
isn't specified, then it's implicitly the object |
| 05:49.20 |
brlcad |
lesse, does
that still hold for absolute too... |
| 05:49.21 |
bhinesley |
nice |
| 05:55.20 |
brlcad |
yeah, a bit
to wrap the head around at this hour |
| 05:55.27 |
brlcad |
newpos =
oldpos + rel = keypoint + rel .. pretty clear cut |
| 05:55.31 |
bhinesley |
haha,
exactly |
| 05:56.03 |
brlcad |
my original
was newpos = abs .. which is simple, but not too
useful |
| 05:56.23 |
brlcad |
you made it
derive a vector, to be applied to oldpos |
| 05:58.34 |
brlcad |
newpos = abs
- keypoint = abs - oldpos = -10,0,10 - 100,100,100 = -110,100,110
.. that doesn't seem right |
| 05:59.47 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.195.64) |
| 05:59.47 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:59.49 |
brlcad |
translate -a
-10 0 10 bowl.c => -10,0,10 .. basically newpos =
abs |
| 06:02.24 |
brlcad |
translate -k
10 10 10 -a -10 0 10 bowl.c => 100,100,100 + -20,-10,0 =
80,90,100 |
| 06:03.13 |
bhinesley |
correct |
| 06:03.50 |
brlcad |
the problem
is consistency: translate -k 100 100 100 -a -10 0 10 bowl.c =>
??? |
| 06:04.23 |
brlcad |
or maybe just
not seeing the formulation correctly |
| 06:05.01 |
brlcad |
aha! |
| 06:05.23 |
brlcad |
100,100,100 +
-110,-100,-90 = -10,0,10 |
| 06:06.34 |
brlcad |
abs is not
just "abs" .. it's abs' = abs - oldpos |
| 06:07.04 |
brlcad |
okay, cool ..
that works |
| 06:07.49 |
brlcad |
the only
other detail in the synopsis is the whole -c -o
hullabaloo |
| 06:08.43 |
bhinesley |
well -o can
go away, as you've shown |
| 06:08.55 |
bhinesley |
-k obj || -k
-10 0 10 |
| 06:09.02 |
brlcad |
nods |
| 06:11.09 |
brlcad |
actually it's
-c that disappeared |
| 06:11.38 |
brlcad |
or that
could |
| 06:11.51 |
bhinesley |
the center of
a primitive is 0,0,0? |
| 06:12.02 |
brlcad |
at least for
arbitrary non-primitive obj, their "V" position is their bounding
box center |
| 06:12.11 |
bhinesley |
oh. |
| 06:12.12 |
brlcad |
I
wish |
| 06:12.32 |
brlcad |
each
primitive defines their own "natural" origin |
| 06:12.44 |
brlcad |
for a box,
it's one of the corners |
| 06:12.56 |
brlcad |
for a
cylinder, it's the center of the bottom disc |
| 06:13.05 |
brlcad |
for a torus,
it's the center |
| 06:13.10 |
brlcad |
etc |
| 06:13.30 |
brlcad |
it's
undefined for combinations |
| 06:13.41 |
brlcad |
that's why
OED makes you specify a path/to/primitive |
| 06:13.48 |
bhinesley |
right |
| 06:14.52 |
brlcad |
so we can
define it to be the bb center for all combination
objects |
| 06:15.08 |
brlcad |
that makes -k
obj work for any object |
| 06:15.20 |
brlcad |
it's just
whether to use that same center even for primitives or whether to
use their V |
| 06:15.36 |
brlcad |
as a default
at least |
| 06:15.45 |
brlcad |
and then an
option to specify the other |
| 06:16.18 |
brlcad |
my
inclination is default to center for everything |
| 06:17.51 |
brlcad |
translate
[-n] [-k] [object | 3dpos] [-a | -r] 3dpos object(s) |
| 06:18.50 |
brlcad |
where 3dpos
:= [-x] {#|.} [-y] {#|.} [-z] {#|.} |
| 06:18.56 |
bhinesley |
yeah, I'd say
that defaulting to center is more useful |
| 06:19.43 |
brlcad |
more
precisely... |
| 06:22.06 |
brlcad |
translate
[[-n] [-k {object | [-x] {#|.} [-y] {#|.} [-z] {#|.}}]] [-a|-r]
[-x] {#|.} [-y] {#|.} [-z] {#|.} object(s) |
| 06:22.09 |
brlcad |
:) |
| 06:22.39 |
bhinesley |
don't we need
another object in there somewhere |
| 06:23.14 |
brlcad |
oh that's
right, you allowed the TO to be objects as well |
| 06:23.17 |
brlcad |
that's new to
me ;) |
| 06:23.42 |
bhinesley |
very nice
once you get the hang of it |
| 06:24.18 |
bhinesley |
say you have
3 wheels on a vehicle; you can copy one in place, and easily move
it into position |
| 06:24.31 |
bhinesley |
ignoring
z-axis |
| 06:24.41 |
brlcad |
translate
[-n] [[-k] [object|3dpos]] [[-a|-r] [object|3dpos]]
object(s) |
| 06:25.12 |
bhinesley |
great, that
actually works ok for parsing too |
| 06:26.03 |
bhinesley |
I was worried
about "translate -k obj -a obj2 obj3 obj4 obj5 at first |
| 06:26.04 |
brlcad |
probably
actually end up needing [-n|-c] |
| 06:26.36 |
bhinesley |
how
so |
| 06:26.36 |
brlcad |
and allowing
it independently on the TO and the FROM |
| 06:26.49 |
bhinesley |
right |
| 06:27.17 |
bhinesley |
translate -c
-k obj -n -a obj2 obj3 obj4 obj5 |
| 06:27.28 |
brlcad |
or at least
need to respecify -n twice |
| 06:27.40 |
bhinesley |
even
better |
| 06:28.07 |
brlcad |
so that it
binds to the k|a|r options |
| 06:30.20 |
brlcad |
translate
[[-n] [-k {object|3dpos}]] [[-n] -a|-r {object|3dpos}]
object(s) |
| 06:30.41 |
brlcad |
not exact or
useful synopsis syntax in that form... |
| 06:31.50 |
brlcad |
either way,
really nice work there .. good brainstorming |
| 06:32.19 |
bhinesley |
thanks; it
was a pleasure working with you |
| 06:33.18 |
bhinesley |
I should
probably ask you: is it alright if I focus on just this oed stuff
for my second milestone? |
| 06:33.30 |
bhinesley |
I have a
feeling it will not all be done + another command |
| 06:33.50 |
brlcad |
absolutely |
| 06:33.58 |
bhinesley |
right
on |
| 06:34.13 |
brlcad |
the
milestones are completely insignificant if progress like this is
being made ;) |
| 06:34.23 |
bhinesley |
excellent |
| 06:34.52 |
bhinesley |
sorry it's
taken me like 3 weeks to do anything significant with this. I ran
out of talent. |
| 06:35.10 |
brlcad |
was to be
expected |
| 06:35.25 |
brlcad |
not a simple
problem or we would have done it already |
| 06:37.07 |
brlcad |
easier to
create yet another command that does some specific subset syntax
and relies on a stupid oed selection state that is based around
implementation detail keypoints insignificant to the
modeler |
| 06:37.31 |
brlcad |
that's why
this consolidates about a dozen commands into just
three |
| 06:38.39 |
brlcad |
if you can
recharacterize your writeup (which should be committed, btw, even
as you work on it) after our talking, I'd jump over to scale and
rotate to make sure the same syntax structure will work for them
and make sense |
| 06:38.57 |
brlcad |
with angles
and distances, rotate might be especially interesting |
| 06:39.22 |
brlcad |
degrees,
radians |
| 06:39.30 |
bhinesley |
nods |
| 06:39.41 |
bhinesley |
I have it in
translate.c right now, is that alright? |
| 06:39.51 |
brlcad |
oh sure, I
missed it there |
| 06:40.00 |
bhinesley |
no, not
commited |
| 06:40.10 |
bhinesley |
(yet) |
| 06:40.14 |
brlcad |
ah,
okay |
| 06:40.24 |
brlcad |
was gonna
say, it's not in my copy :) |
| 06:40.43 |
bhinesley |
hehe you need
to do a 'svn up -r brandon's' |
| 06:41.55 |
brlcad |
if you get
the urge to convert to actual docs, they live in
doc/docbook/system/mann/en/ |
| 06:42.23 |
brlcad |
translate.xml
would get added for the manpage, docbook xml format, lots of
examples to follow |
| 06:42.48 |
brlcad |
goes walkabout |
| 06:43.02 |
bhinesley |
great, I was
wondering how those were generated |
| 06:52.31 |
CIA-62 |
BRL-CAD:
03bhinesley * r45359 10/brlcad/trunk/src/libged/translate.c: Laid
out a brand spankin new syntax for translate. It is already
obsolete, per irc conversation with Sean. Many
ged_translate/translate things are broken, but I'm too tired to go
on, so it's commented out for now. |
| 07:15.43 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.195.64) |
| 07:15.43 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:00.54 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 08:25.20 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.195.64) |
| 08:25.20 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:34.49 |
*** part/#brlcad kunigami1
(~kunigami@loco-gw.ic.unicamp.br) |
| 10:36.45 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 11:07.15 |
CIA-62 |
BRL-CAD:
03kunigami * r45360 10/brlcad/trunk/src/liboptical/ (liboslrend.h
osl_rt.cpp): removing unused variables |
| 11:21.32 |
kunigami |
May I add an
option to rt that reads the number of samples that will be made for
each pixel? |
| 11:22.23 |
kunigami |
If yes, it's
better to do it through rt script language, right? |
| 11:26.14 |
kunigami |
It would also
be great if I could implement that kind of framebuffer that begins
noisy and gains shape as more and more samples are done (but this
would require to change the way rays are shot by rt) |
| 11:44.06 |
starseeker |
epileg: is
that produced with the make package command? |
| 11:44.32 |
epileg |
yes,
both |
| 11:45.19 |
epileg |
starseeker:
mmmm, do You mean the binary or the shared libs list? |
| 11:50.58 |
starseeker |
epileg: well,
basically that list looks like it's from untarring one of the
tarballs (binary) built by make package |
| 11:51.23 |
starseeker |
which would
be really annoying - I thought I had all that path stuff
straightened out |
| 11:52.46 |
epileg |
starseeker:
yes, htey are |
| 11:53.08 |
starseeker |
there will be
a few things present in a CMake build that aren't in an autotools
build, since the CMake build has some new stuff |
| 11:53.27 |
starseeker |
more
disturbing is the
/home/jordi/svn/brlcad_7.20.1-0_amd64-2/usr/brlcad/bin
path |
| 11:54.15 |
starseeker |
I'm trying a
make package here |
| 11:54.15 |
epileg |
starseeker:
no no, forget this. I just created two deb packages and uncompress
them |
| 11:54.23 |
starseeker |
Oh! |
| 11:54.37 |
starseeker |
the CMake
package build for debs is completely untested |
| 11:54.42 |
epileg |
one with
autotools and another with cmake |
| 11:55.13 |
starseeker |
well, for one
thing the CMake build turns on OpenGL by default, while the
autotools still has it off by default |
| 11:55.22 |
epileg |
well, I have
done the autotools deb packages script |
| 11:55.25 |
starseeker |
that's
probably where the libGLU is coming from |
| 11:55.56 |
epileg |
aha |
| 11:56.08 |
starseeker |
epileg: I
need to look over the logic you've done for that and make sure the
CMake build incorporates what is needed to reproduce it |
| 11:56.22 |
epileg |
ok |
| 11:56.27 |
starseeker |
I can't test
deb except on a virtual machine though, so I'm not set up for it
yet |
| 11:56.37 |
epileg |
I'll give You
exactly what I've done |
| 11:57.02 |
starseeker |
for the
tcl/tk stuff... at a glance it looks like the CMake build had
enabled all local libs and the autotools build didn't |
| 11:57.41 |
starseeker |
libpoints is
just how CMake is building the MGED points logic, so that's not
surprising |
| 11:57.43 |
epileg |
but there are
more libs in autotools packages than in cmake one |
| 11:58.09 |
starseeker |
wait - is the
list I'm looking at autotools things that hte CMake build Doesn't
have? |
| 11:58.40 |
epileg |
ok |
| 11:59.13 |
epileg |
about
testing, don't worry, I've ready many virtual machines to test
them |
| 12:00.20 |
starseeker |
bhinesley:
getting this error: src/libged/translate.c:49: error:
‘translate’ defined but not used |
| 12:01.28 |
starseeker |
no worries,
but may want to #if it out in the repository until you progress to
the point where it's used by something |
| 12:02.00 |
epileg |
starseeker:
in the autotools package, there are 747 elements, 69,9 MB, and in
cmake package 671 elements, 46,3 MB |
| 12:02.13 |
starseeker |
erm. |
| 12:02.14 |
epileg |
in lib
folder |
| 12:03.26 |
epileg |
in came i
used: |
| 12:03.26 |
epileg |
cmake
-DBRLCAD-ENABLE_OPTIMIZED_BUILD=ON \ |
| 12:03.26 |
epileg |
-DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON
\ |
| 12:03.26 |
epileg |
-DBRLCAD-ENABLE_STRICT=OFF \ |
| 12:03.26 |
epileg |
-DCMAKE_BUILD_TYPE=Release \ |
| 12:03.27 |
epileg |
-DCMAKE_INSTALL_PREFIX=/usr/brlcad
\ |
| 12:03.27 |
epileg |
-DDATA_DIR=share \ |
| 12:03.28 |
epileg |
-DMAN_DIR=share/man |
| 12:04.04 |
epileg |
cmake* |
| 12:05.15 |
starseeker |
ok |
| 12:05.49 |
starseeker |
epileg: for
each of the two package directories (autotools and cmake) can you
do the following? |
| 12:06.12 |
epileg |
and in
autotools: |
| 12:06.12 |
epileg |
./configure
--enable-optimized --enable-almost-everything --with-ogl
--disable-debug -disable-strict -prefix=/usr/brlcad |
| 12:06.25 |
epileg |
yes, tell
me |
| 12:06.28 |
starseeker |
find . -type
f |grep -v .svn|xargs stat --format='%n' >
autotools.list |
| 12:06.34 |
starseeker |
find . -type
f |grep -v .svn|xargs stat --format='%n%s' >
autotools_size.list |
| 12:06.40 |
starseeker |
and the same
for cmake |
| 12:06.46 |
epileg |
ok |
| 12:06.59 |
starseeker |
those four
files will provide a way to compare what is ending up in the two
package dirs |
| 12:07.11 |
epileg |
in the root
package folder, right? |
| 12:07.15 |
starseeker |
yes |
| 12:07.21 |
epileg |
just a
secont |
| 12:11.21 |
epileg |
starseeker:
some email to send or paste on a web page? |
| 12:13.24 |
starseeker |
http://paste.debian.net should
work |
| 12:13.29 |
epileg |
ok |
| 12:14.24 |
epileg |
...Length of
code is not allowed to exceed 90kb... |
| 12:14.30 |
starseeker |
phooey |
| 12:14.45 |
starseeker |
i'll pm you
an email addy |
| 12:17.51 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 12:35.35 |
epileg |
starseeker:
did You receive it? |
| 12:37.44 |
epileg |
starseeker:
just one thing. as You can see, at the end of cmake.list and
cmake_size.list, there is ./autotools_size.list and
./autotools.list instead of the cmake... filenames |
| 12:38.15 |
epileg |
this is
because i've changed the filenames after run the command,
sorry |
| 12:52.51 |
starseeker |
epileg: I'll
check in a bit - dealing with multiple things at the
moment |
| 12:52.59 |
starseeker |
(shredder
broke, vacuum broke...) |
| 12:53.05 |
epileg |
ok, no
problem |
| 12:53.31 |
starseeker |
np - I can
spot the autotools.list filesw |
| 12:58.58 |
CIA-62 |
BRL-CAD:
03kunigami * r45361 10/brlcad/trunk/src/liboptical/ (osl_rt.cpp
sh_osl.cpp): Still having problems rendering glass material. I've
tried even calling OSL QueryColor directly (without mfuncs), but
still no success |
| 14:10.52 |
brlcad |
kunigami: rt
has a -H hypersample option already |
| 14:41.09 |
brlcad |
that used in
conjunction with -s oversizing then downsampling are a common
best-practice for producing smoothly anti-aliased
images |
| 14:42.01 |
brlcad |
on that same
note, there is a -j jitter flag that will modify the starting ray
hit point in various ways depending on the jitter value |
| 15:05.39 |
CIA-62 |
BRL-CAD:
03starseeker * r45362 10/brlcad/trunk/doc/html/CMakeLists.txt: fix
target directory for animmate |
| 15:09.14 |
CIA-62 |
BRL-CAD:
03starseeker * r45363 10/brlcad/trunk/src/util/CMakeLists.txt:
pc_test isn't supposed to be installed. |
| 15:12.19 |
starseeker |
epileg: the
CMake zlib build isn't installing the private zlib headers, while
the autotools build is - unless we need to install them, I'm
inclined to go with the CMake behavior |
| 15:13.14 |
starseeker |
epileg: the
CMake build won't have the .la files that the autotools build has -
that's expected |
| 15:13.41 |
starseeker |
some
differences with library naming for itcl/itk, looks like... that
shouldn't matter |
| 15:15.01 |
epileg |
starseeker:
I'll be agree with any decision You take |
| 15:15.27 |
starseeker |
tcl/tkConfig.sh scripts aren't there yet
for the CMake build of Tcl/Tk |
| 15:15.41 |
starseeker |
epileg: do
the packages generated actually work when installed? |
| 15:15.55 |
epileg |
yes |
| 15:16.40 |
epileg |
just the
rtwizard do not properly render, both cmake and autotools
builds |
| 15:17.29 |
starseeker |
what's the
issue with rtwizard? |
| 15:17.50 |
starseeker |
epileg: hmm,
looks like I haven't gotten around to doing the man pages for
iwidgets yet... |
| 15:19.07 |
epileg |
starseeker:
do You remember the difference between cmake and autotools about
text rendering? it's still there |
| 15:20.36 |
epileg |
error message
from rtwizard |
| 15:20.39 |
epileg |
http://paste.debian.net/121606/ |
| 15:22.06 |
starseeker |
oh, I see -
autotools build prefixed all of hte man pages before installing
them |
| 15:22.35 |
starseeker |
epileg: is rt
in your path? |
| 15:23.03 |
epileg |
nop |
| 15:23.33 |
epileg |
but rt is not
provided by brlcad? |
| 15:26.31 |
epileg |
sorry,
something wrong in my system |
| 15:32.33 |
CIA-62 |
BRL-CAD:
03starseeker * r45364 10/brlcad/trunk/src/other/iwidgets/
(CMakeLists.txt doc/CMakeLists.txt): Take care of iwidgets man
pages. |
| 15:33.02 |
starseeker |
other major
difference I see is CMake is installing Tcl/Tk man pages, where it
looks like autotools isn't |
| 15:33.15 |
epileg |
aha |
| 15:34.34 |
starseeker |
somewhat
surprisingly, autotools didn't build step-g? |
| 15:43.41 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 15:44.21 |
epileg |
starseeker:
so sorry, rtwizard properly works. It was a problem on my
environment variables |
| 15:45.13 |
starseeker |
np |
| 15:45.29 |
starseeker |
just glad it
wasn't busted yet again :-P |
| 15:46.06 |
epileg |
:-) |
| 16:42.38 |
*** join/#brlcad Elrohir
(~kvirc@pD95EDF28.dip.t-dialin.net) |
| 17:00.40 |
CIA-62 |
BRL-CAD:
03bhinesley * r45365 10/brlcad/trunk/src/libged/translate.c: don't
leave private translate function definition enabled if it's not
used |
| 17:00.42 |
bhinesley |
starseeker:
hah, yeah, I was lying in bed last night thinking "really should
have just commented out that whole private function" |
| 17:17.28 |
bhinesley |
heh
*laying |
| 18:37.22 |
brlcad |
prefixed the
man pages? |
| 18:38.53 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD
has applied to participate in the ESA Summer of Code in
Space! |
| 18:42.36 |
CIA-62 |
BRL-CAD:
03brlcad * r45366 10/brlcad/trunk/bench/Makefile.am: try without
defining DISTCLEANFILES |
| 18:42.54 |
brlcad |
I see why the
distcheck was still failing, missed committing a file a few days
ago |
| 18:44.57 |
CIA-62 |
BRL-CAD:
03starseeker * r45367
10/brlcad/trunk/src/other/iwidgets/doc/Makefile.am: Add
CMakeLists.txt file. |
| 18:59.50 |
CIA-62 |
BRL-CAD:
03kunigami * r45368
10/brlcad/trunk/src/liboptical/sh_osl.cpp: |
| 18:59.50 |
CIA-62 |
BRL-CAD:
solved the glass shader. the problem was that the next application
was set by |
| 18:59.50 |
CIA-62 |
BRL-CAD:
next.a_hit = prev.a_hit, but if prev.a_hit was the refraction
callback, |
| 18:59.50 |
CIA-62 |
BRL-CAD:
next.a_hit would be also refraction. the expected behavior is to
set mext.a_hit |
| 18:59.50 |
CIA-62 |
BRL-CAD: as
the first callback (the one that was used by the first
ray |
| 19:05.17 |
CIA-62 |
BRL-CAD:
03Kunigami 07http://brlcad.org *
r2978 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 6 */ Reports
updated |
| 19:10.23 |
CIA-62 |
BRL-CAD:
03starseeker * r45369 10/brlcad/trunk/NEWS: Richard improved
facetization by updating routines to merge coplanar
faces. |
| 19:11.58 |
CIA-62 |
BRL-CAD:
03starseeker * r45370 10/brlcad/trunk/include/conf/PATCH: Bump
patch version number. |
| 19:14.53 |
CIA-62 |
BRL-CAD:
03starseeker * r45371 10/brlcad/trunk/ChangeLog: Update
ChangeLog |
| 19:23.52 |
*** join/#brlcad merzo
(~merzo@94-20-133-95.pool.ukrtel.net) |
| 19:34.06 |
CIA-62 |
BRL-CAD:
03Kunigami 07http://brlcad.org *
r2979 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 6
*/ |
| 19:49.53 |
CIA-62 |
BRL-CAD:
03kunigami * r45372 10/brlcad/trunk/src/liboptical/sh_osl.cpp:
instead of calling OSLQueryColor directly (with the hardcoded name
glass), call mf_render. this is better because the refracted ray
may not be inside a shader named glass |
| 19:52.53 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:04.12 |
brlcad |
kunigami: so
lets see it! |
| 20:05.34 |
brlcad |
aha,
http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-Refraction-Corrected-2011-06-30.png |
| 20:06.34 |
brlcad |
kunigami:
what glass parameters are you using? refraction index, specular
and diffuse params, etc |
| 20:06.55 |
CIA-62 |
BRL-CAD:
03starseeker * r45373 10/brlcad/branches/STABLE/ (2197 files in 194
dirs): Sync STABLE to trunk r45358 |
| 20:08.49 |
starseeker |
woot |
| 20:10.57 |
CIA-62 |
BRL-CAD:
03starseeker * r45374 10/brlcad/branches/STABLE/ (17 files in 12
dirs): Sync STABLE to trunk r45373 |
| 20:11.28 |
brlcad |
thinks you meant trunk TO stable |
| 20:11.57 |
brlcad |
:) |
| 20:14.32 |
starseeker |
er,
yeah |
| 20:14.44 |
bhinesley |
either way is
good ;-) |
| 20:14.58 |
starseeker |
prepares to tag... drumroll please... |
| 20:15.34 |
starseeker |
double checks the release numbers this
time... |
| 20:15.57 |
brlcad |
and mged
acutally runs along with archer :) |
| 20:30.29 |
starseeker |
yep, they
run |
| 20:30.40 |
starseeker |
here we
go |
| 20:31.18 |
CIA-62 |
BRL-CAD:
03starseeker * r45375 10/brlcad/tags/rel-7-20-2/: Tag release
7.20.2 |
| 20:37.08 |
kunigami |
brlcad:
reading the osl glass shader, it seems that the index of refraction
is 1.5 |
| 20:39.14 |
kunigami |
I don't know
the specular and diffuse parameters. would have to take a look at
implementation |
| 20:40.08 |
kunigami |
The shader
description: http://pastebin.mozilla.org/1262389 |
| 20:43.54 |
kunigami |
Scene with a
BRLCAD shader (checkers) and a OSL shader (mirror). The way it is
implemented, BRLCAD shaders will act as lights. |
| 20:43.57 |
kunigami |
http://dl.dropbox.com/u/1399996/GSoC/OSL-BRLCAD-Shader-Integration.png |
| 20:52.04 |
brlcad |
awesome
starseeker |
| 20:57.14 |
starseeker |
tarballs
up |
| 20:58.57 |
CIA-62 |
BRL-CAD:
03starseeker * r45376 10/brlcad/trunk/ (NEWS README
include/conf/PATCH): Bump revision numbers. |
| 21:14.46 |
brlcad |
hm, rt inside
mged is blocking |
| 21:23.58 |
brlcad |
here's what
that scene looks like with rt: http://tinypic.com/view.php?pic=9kufk1&s=7 |
| 21:24.31 |
brlcad |
and as
checker: http://tinypic.com/view.php?pic=i3hzjk&s=7 |
| 21:36.17 |
CIA-62 |
BRL-CAD:
03brlcad * r45377
10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: gah, post-ta
build failure! code is used unitialized. remove it... |
| 21:51.15 |
CIA-62 |
BRL-CAD:
03brlcad * r45378
10/brlcad/branches/STABLE/src/librt/primitives/nmg/nmg_fuse.c:
merge r45377 from trunk to stable |
| 22:15.23 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2980
10/wiki/Main_Page: link to socis |
| 22:33.35 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 22:57.43 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2981
10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: eliminate some
ideas only loosely relevant to space work |
| 22:59.00 |
CIA-62 |
BRL-CAD:
03brlcad * r45379
10/brlcad/tags/rel-7-20-2/src/librt/primitives/nmg/nmg_fuse.c:
source tarballs were posted but not announced, so merge r45377 from
trunk to stable so we can regenerate them |
| 23:18.26 |
starseeker |
brlcad: O.o
Sorry - what happened? |
| 23:20.23 |
starseeker |
bites back cuss words - how in the *bleep* did I get all
those successful builds and then have a build
failure?? |
| 23:21.16 |
starseeker |
the tarballs
came out of a tagged distcheck build |
| 23:23.39 |
starseeker |
deletes source tarballs, regens |
| 23:44.14 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2982
10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: |
| 23:46.17 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r2983
10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas:
reorder |
| 23:54.05 |
brlcad |
starseeker:
did you compile optimized? |
| 23:54.14 |
brlcad |
optimized
often enables even more warnings |
| 23:55.37 |
brlcad |
that's part
of my compile script -- all+warn, all+opt+warn, all+32bit+warn,
default+warn, default+opt+warn, .... etc etc :) |
| 23:55.55 |
starseeker |
hrm. No, I
think I used the line in HACKING |
| 23:56.34 |
brlcad |
yeah, you did
it right .. just slipped through |
| 23:57.11 |
brlcad |
release
binaries aren't supposed to be optimized anyways (so they can be
debugged) |
| 23:57.58 |
brlcad |
and some
platforms don't behave well with optimized, so several reasons why
it isn't in HACKING |
| 23:58.53 |
brlcad |
looks like my
build script tests 13 build configurations testing make, make
distcheck, and make test for all 13 ... :) |
| 23:59.36 |
CIA-62 |
BRL-CAD:
03bhinesley * r45380 10/brlcad/trunk/ (6 files in 4
dirs): |
| 23:59.36 |
CIA-62 |
BRL-CAD:
Started rearranging things, to put translate/rotate/scale syntax
handling in one |
| 23:59.36 |
CIA-62 |
BRL-CAD:
place. Re-wrote proposed 'translate' manual per conversation with
Sean. There |
| 23:59.36 |
CIA-62 |
BRL-CAD: were
a couple more issues resolved and ideas added along the way. Next
step is |
| 23:59.36 |
CIA-62 |
BRL-CAD: to
ensure that rotate/scale will work alright with the same
syntax. |
| 00:33.27 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 00:42.09 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 03:34.32 |
``Erik |
the / is a
relatively safe token for splitting and we use it elsewhere to
denote tokens, the comma is used in some locales as a decimal
point... if we ever go gettext, could cause issue |
| 03:36.59 |
bhinesley |
what comma
are you referring to? |
| 03:37.17 |
``Erik |
(but I'm no
usability expert and make it a point to avoid gui work, so'z
*shrug*) |
| 03:37.28 |
``Erik |
(1,4,5) as a
listing of coordinate |
| 03:38.04 |
bhinesley |
oh, I was
just interpreting the syntax in human readable form |
| 03:38.09 |
bhinesley |
there are no
commas :) |
| 03:38.26 |
``Erik |
just noting
that the glyph is risky :) people who haven't done
internationalization can easily miss that gotcha :) |
| 03:38.37 |
bhinesley |
nods |
| 03:38.40 |
bhinesley |
thanks |
| 03:41.24 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 03:47.15 |
``Erik |
(and vi, not
vim?) |
| 03:52.36 |
``Erik |
brlcad: dlo
found issues in the solar system scale stuff when mocking up a
ringworld as a pre-procdb issue, prolly fp fuzz around 1.5e14mm,
so'z the claims in the au page may be a bit... optimistic
:) |
| 03:54.07 |
``Erik |
for the
physics shtuff, my vote is for bullet, my research indicates that
it started whupping ode a few years back |
| 04:01.18 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3006 10/wiki/User:Bhinesley: /* Who I am */ vim, not vi
:) |
| 04:01.32 |
bhinesley |
``Erik:
^ |
| 04:01.36 |
bhinesley |
:) |
| 04:02.27 |
``Erik |
:D I'm a fbsd
weenie and the 'default' editor is nvi, very different from
vim |
| 04:03.07 |
``Erik |
(default
editor is a bsh, not bash, also confusing to linux
folk) |
| 04:03.41 |
bhinesley |
I was a fbsd
admin for a couple years, but that was a long time ago |
| 04:03.52 |
bhinesley |
(small
company) |
| 04:04.47 |
``Erik |
cool
beans |
| 04:05.17 |
``Erik |
which
major? |
| 04:05.23 |
bhinesley |
computer
science |
| 04:05.25 |
bhinesley |
BS |
| 04:05.36 |
``Erik |
I meant fbsd
major release number :) |
| 04:05.44 |
bhinesley |
oh
jeez |
| 04:05.55 |
``Erik |
I went fbsd
with a 3, really embraced it at 4 |
| 04:06.21 |
``Erik |
late 90's,
yo |
| 04:07.04 |
bhinesley |
based on the
release dates on wikipedia it must have been 5 for me |
| 04:07.38 |
bhinesley |
I was running
'stable' about 2004 or 2005 |
| 04:07.47 |
``Erik |
brlcad.org is
still running one of the 5 series |
| 04:08.36 |
``Erik |
it's a good
os, can be a bit tricky to maintain if you're not used to the *nix
world |
| 04:09.34 |
bhinesley |
nods |
| 04:09.35 |
bhinesley |
I learned on
it |
| 04:09.52 |
``Erik |
<-- is a
port maintainer for a couple dozen, has a few hundred pr's, friends
with several core folk, good stuff :) |
| 04:10.11 |
bhinesley |
awesome |
| 04:10.29 |
``Erik |
openbsd is
nice, too, theo can be a dick, though |
| 04:10.36 |
bhinesley |
haha |
| 04:10.51 |
bhinesley |
never used
it, myself |
| 04:11.25 |
``Erik |
I've only
used open in a vm, the X upgrade was a royal pain |
| 04:11.50 |
``Erik |
dragonfly has
some interesting ideas, that was a weird period |
| 04:12.40 |
``Erik |
was around
'02 I think, major philosophical differences on concurrency and
smp |
| 04:13.10 |
``Erik |
smelled like
both sides weren't listening, just saying that the other side was
wrong... was almost like congress *cough* O:-) |
| 04:13.32 |
brlcad |
``Erik: how
is "untested support for astronomical units and lots of room for
there to be computational issues" being optimistic? |
| 04:13.35 |
bhinesley |
"they need to
compromise!" |
| 04:14.54 |
brlcad |
bhinesley:
not too worried about supporting FACTOR || X Y || X Y Z .. FACTOR
|| X Y Z are the two main use cases |
| 04:15.18 |
``Erik |
brlcad: the
statement that we can do it at a full sol system level, we have
known issues at 2% of that |
| 04:15.31 |
brlcad |
or even
FACTOR | [-x X] [-y Y] [-z Z] |
| 04:16.15 |
brlcad |
``Erik: er,
where do you see that statement? |
| 04:17.04 |
bhinesley |
alright. I
won't worry about it, unless it's simpler to just include
it. |
| 04:17.14 |
brlcad |
the only
claim it makes is that objects at that scale can be created .. and
then it caveats saying it's all untested and probably has
issues |
| 04:17.34 |
``Erik |
um, the
celestial mechanics page says, srry |
| 04:18.41 |
brlcad |
even there,
it just says you can accurately model the solar system to scale ..
which is true, you just can't render that model |
| 04:19.15 |
brlcad |
and even then
-- I don't know if simple ellipsoids at that scale would have an
issue |
| 04:19.20 |
``Erik |
dlo's
experiment was a 30m thick strip at 1au and had display issues
similar to ogl zbuffer fighting, *shrug* |
| 04:19.59 |
brlcad |
that's
already changing the numbers involved substantially |
| 04:20.07 |
brlcad |
small detail
at a massive scale, I'd expect a problem |
| 04:20.26 |
brlcad |
modeling the
solar system is effectively no detail at a massive
scale |
| 04:20.38 |
``Erik |
yeah, he was
trying to hand-build a niven ringworld, to preview the proc-db I
started |
| 04:21.05 |
brlcad |
I don't see
why a super massive sph wouldn't render just fine as an AU
scale |
| 04:21.11 |
brlcad |
s/as/at/ |
| 04:21.39 |
``Erik |
an ell
should, I'd think |
| 04:21.45 |
brlcad |
the only
issue might be the transformation it attempts to perform during
raytracing so that the primitive is in a normal unitized position
during eval |
| 04:21.55 |
brlcad |
that might
bork the floating |
| 04:22.23 |
brlcad |
I've created
a planet-sized ell before, no problems |
| 04:22.34 |
brlcad |
but only at
the origina |
| 04:22.40 |
``Erik |
it might be
an op ordering issue that he was seeing, too *shrug* |
| 04:22.53 |
``Erik |
planet sizes
run quite a wide gambit |
| 04:23.08 |
``Erik |
we have the
earth sized planet with the star trek stuff in orbit, that works
well |
| 04:23.24 |
``Erik |
but a planet
and local orbit is tiny compared to a solar system |
| 04:24.04 |
brlcad |
bhinesley:
note that some objects can only be scaled uniformly, so there will
have to be error checking if attempting to only scale 1 or 2
axes |
| 04:24.40 |
bhinesley |
I figured as
much; such as a sphere |
| 04:26.03 |
``Erik |
measuring in
meters, I think a 64b ieee854 is around ~10 meter accuract at a
pluto orbit (~50au), so mm would be 10km accuracy |
| 04:26.07 |
brlcad |
sphere is
fine, they become ellipsoids |
| 04:26.20 |
bhinesley |
oh,
hah |
| 04:26.24 |
``Erik |
and that's
straight measure, no math to increase inacuracy |
| 04:26.25 |
brlcad |
torus is the
typical error case |
| 04:27.00 |
``Erik |
tgc's can
also be touchy, iirc |
| 04:27.22 |
brlcad |
``Erik: which
implies simulating our solar system to scale would be just fine ..
10km would be sub-sub-pixel |
| 04:28.37 |
``Erik |
means I can't
put a toy jeep on neptune, though :D |
| 04:29.28 |
brlcad |
heh |
| 04:30.22 |
``Erik |
now my frame
of reference... back in the late 90's, I was trying to make an
xwing type game and was looking for ways to have a small craft be
accurate anywhere in a solar system |
| 04:30.24 |
brlcad |
yeah, that'd
be about *45M* km per pixel for a basic "overhead"
render |
| 04:31.24 |
brlcad |
means earth
is sub-pixel to scale too |
| 04:31.53 |
brlcad |
so you'd have
to scale the bodies up several orders of magnitude, which might be
neat in itself |
| 04:31.54 |
``Erik |
for most
displays, the only thing that MIGHT get a pixel for a solar system
scale render ist he sun... |
| 04:32.41 |
brlcad |
yeah, sun is
sub-pixel 1.39M km diameter |
| 04:33.12 |
brlcad |
three orders
of magnitude would make them visible |
| 04:33.15 |
``Erik |
but a 10,000
km 'tile' eliminates any surface detail in the outer
bits |
| 04:35.36 |
``Erik |
*shrug* at
solar scales, we lose a lot of accuracy, 'sall :) |
| 04:36.18 |
``Erik |
nerds who
want to make ringworlds, dyson spheres, etc might be a bit upset
when it doesn't quite work right |
| 04:37.29 |
``Erik |
imma catch
some z's, hasta manana :) |
| 04:38.52 |
brlcad |
nods |
| 04:38.55 |
bhinesley |
see
ya |
| 04:39.10 |
brlcad |
the first
units project aims to help fix the units issue better |
| 04:39.59 |
brlcad |
making sure
the math is stable for existing prims, then maybe working on
scaling zones |
| 04:41.21 |
brlcad |
bhinesley:
curious choice of 'alter' for the command name |
| 04:41.35 |
brlcad |
any reason
that over 'edit'? |
| 04:41.55 |
bhinesley |
nope, edit
would be fine |
| 04:42.14 |
bhinesley |
alter just
came to mind, and it's easy enough to change, so I went with
it |
| 04:43.01 |
brlcad |
it's fine,
just wondering if there was some underlying motivation |
| 04:43.15 |
brlcad |
both edit and
alter are a little vague |
| 04:43.56 |
brlcad |
ambiguous
even, since I can't edit/alter some object parameters |
| 04:45.31 |
brlcad |
those three
subcommands are all transformations, so 'xform' would be pretty
fitting too |
| 04:46.47 |
bhinesley |
whatever name
it is, it will be "extern thename" in ged_private.h |
| 04:47.03 |
bhinesley |
and also,
"extern thename_translate", etc |
| 04:47.30 |
bhinesley |
the idea is,
thename_translate will be as primitive of a translate as
possible |
| 04:48.01 |
brlcad |
you mean only
as private api, not a new parent command? |
| 04:48.26 |
bhinesley |
if I
understand you correctly: there will be both |
| 04:48.43 |
brlcad |
then what do
you mean by "extern thename" in ged_private.h ? |
| 04:49.01 |
brlcad |
ged_private
is for declaring non-public API (functions) |
| 04:49.28 |
bhinesley |
ged_thename
will be public |
| 04:49.47 |
brlcad |
so then it
goes in ged.h :) |
| 04:49.56 |
bhinesley |
correct |
| 04:50.21 |
brlcad |
okay, just
confused by your prior statement |
| 04:50.21 |
brlcad |
00:46 <
bhinesley> whatever name it is, it will be "extern thename" in
ged_private.h |
| 04:50.26 |
bhinesley |
there is a
separate function, "thename", which is for calling internally
without using argv |
| 04:50.52 |
brlcad |
ah, I think I
might get what you're saying |
| 04:50.57 |
bhinesley |
ged_thename
simply parses command line arguments and passes it to
thename |
| 04:51.01 |
brlcad |
nods |
| 04:51.03 |
brlcad |
got
it |
| 04:51.16 |
bhinesley |
yeah, excuse
me... I'm not very good at expressing these things |
| 04:51.23 |
bhinesley |
(yet) |
| 04:52.14 |
brlcad |
funcs still
only need to be declared extern in ged_private.h if they're going
to be used by more than one file |
| 04:52.29 |
brlcad |
so if it all
lives in alter.c, you're fine with simple function
ordering |
| 04:53.37 |
bhinesley |
A command
that needs to do a simple translate could call thename_translate.
If it needed to do a batch translate using '.', or if it needed to
use objects/distances to calculate coordinates, then it could call
thename. |
| 04:53.52 |
brlcad |
it'd only be
if you broke it out into alter.c, translate.c, rotate.c, scale.c
with the latter three ged_[cmd]() funcs calling
ged_alter() |
| 04:55.05 |
bhinesley |
okay, I'm a
little confused. |
| 04:55.20 |
brlcad |
no worries,
carry on :) |
| 04:55.44 |
bhinesley |
ged.h is for
sharing with commands outside of libged, while ged_private.h is for
sharing internally to libged only? |
| 04:56.01 |
brlcad |
almost |
| 04:56.37 |
brlcad |
ged.h is
public declaration for use anywhere (inside/outside) |
| 04:57.06 |
brlcad |
ged_private.h
is private declaration where there is internal reuse |
| 04:57.47 |
brlcad |
so funcs are
added to ged.h when they're "published" but should only ged added
to ged_private.h when they're actually used in more than one
file |
| 04:57.55 |
brlcad |
even if
they're ripe for reuse |
| 04:58.35 |
bhinesley |
okay |
| 04:58.50 |
brlcad |
not a big
issue if they're declared in ged_private.h and not used in multiple
places, but the decls might get removed/cleaned up down the road to
keep files simple |
| 04:59.41 |
bhinesley |
sounds like
ged_thename goes in ged.h for now, and eventually
thename/thename_translate/etc may go in ged_private.h |
| 04:59.48 |
brlcad |
there are
400+ commands which means there could easily be 3x that many
"private yet potentially reusable" internal funcs .. which wouldn't
be too useful to browse through |
| 05:00.11 |
brlcad |
right, that's
the intention at least |
| 05:00.58 |
brlcad |
my guy
feeling is that any function prime for libged reuse probably
doesn't even belong in libged |
| 05:01.07 |
brlcad |
begs
refactoring down into librt |
| 05:01.33 |
bhinesley |
why does so
much end up in librt? I thought it was just raytracing? |
| 05:01.37 |
brlcad |
aside from
commands calling other commands at the libged API level |
| 05:01.47 |
brlcad |
librt isn't
just raytracing |
| 05:02.00 |
brlcad |
it's the
underlying geometry management |
| 05:02.09 |
bhinesley |
I mean, I
have seen that... I just didn't understand the
reasoning |
| 05:02.49 |
brlcad |
geometry
representation, disk I/O, serialization, and ray
tracing |
| 05:03.24 |
brlcad |
it would
probably be more appropriately named "libg", except that the main
reason for its existence is to shoot rays |
| 05:03.56 |
bhinesley |
alright, that
makes sense |
| 05:04.15 |
brlcad |
and there is
a very close relationship between the on-disk representation and
the in-memory format used for ray-tracing |
| 05:04.44 |
brlcad |
the two are
tightly coupled for performance reasons, why we can raytrace
massive multi GB scenes in mere seconds |
| 05:04.53 |
bhinesley |
ahh |
| 05:05.42 |
brlcad |
we've talked
about separating the two into different libraries, but it would be
tricky to do cleanly API-wise |
| 05:05.53 |
bhinesley |
so, as you
were saying: should uhh... 'thename' live in librt? |
| 05:06.28 |
brlcad |
if it's
argc/argv style, then it still belongs in libged |
| 05:07.06 |
bhinesley |
well, only
ged_thename is argc/argv style |
| 05:12.21 |
brlcad |
it depends
what the command ends up looking like parameter-wise |
| 05:12.39 |
brlcad |
keep an eye
on rt_matrix_transform() since that is the current closest-fit API
call already in librt that comes to mind |
| 05:12.50 |
brlcad |
it's how mged
applies most matrix edits now |
| 05:13.00 |
brlcad |
s/matrix/primitive/ |
| 05:13.37 |
brlcad |
through
transformation matrices (with scaling, translation, and rotation
components) |
| 05:18.20 |
bhinesley |
interesting |
| 08:10.00 |
*** join/#brlcad mafm
(~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net) |
| 08:36.36 |
brlcad |
calls it done for now |
| 08:38.56 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.195.64) |
| 08:38.56 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 09:34.51 |
CIA-62 |
BRL-CAD:
03bhinesley * r45426 10/brlcad/trunk/src/libged/alter.c: Set up the
struct and flags for ged_alter and alter command argument handling.
Other small cleanup/setup stuff. |
| 11:18.17 |
CIA-62 |
BRL-CAD:
03indianlarry * r45427 10/brlcad/trunk/include/dm.h: externalize
display manager interfaces |
| 13:42.28 |
*** join/#brlcad mafm
(~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net) |
| 13:56.33 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 16:30.28 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 17:30.54 |
CIA-62 |
BRL-CAD:
03starseeker * r45428 10/brlcad/trunk/CMakeLists.txt: If we don't
have a defined CMAKE_SIZEOF_VOID_P, assume 32 bit to be
safe. |
| 17:59.24 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45429 10/brlcad/trunk/CMakeLists.txt: match the
endif to the if |
| 18:13.20 |
CIA-62 |
BRL-CAD:
03r_weiss * r45430 10/brlcad/trunk/ (6 files in 3 dirs): (log
message trimmed) |
| 18:13.20 |
CIA-62 |
BRL-CAD:
Changed function nmg_model_edge_g_fuse by renaming it to
nmg_edge_g_fuse and |
| 18:13.20 |
CIA-62 |
BRL-CAD:
allowing the magic of a nmg object to be passed in instead of a
pointer to a nmg |
| 18:13.20 |
CIA-62 |
BRL-CAD:
model structure. This change allows the function to fuse edge
geometry in other |
| 18:13.20 |
CIA-62 |
BRL-CAD:
smaller nmg objects such as an nmg shell or nmg faceuse. The
following files |
| 18:13.20 |
CIA-62 |
BRL-CAD: were
changed raytrace.h nmg_simplify.c wdb_obj.c nmg_tri.c
nmg_fuse.c |
| 18:13.21 |
CIA-62 |
BRL-CAD:
nmg_bool.c. The purpose of this change is to improve performance of
nmg boolean |
| 18:38.16 |
*** join/#brlcad nsd
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 18:43.31 |
*** join/#brlcad nsd
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 18:44.53 |
*** join/#brlcad nsd
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 19:23.54 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 19:51.40 |
CIA-62 |
BRL-CAD:
03r_weiss * r45431
10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 19:51.40 |
CIA-62 |
BRL-CAD:
Updated function nmg_bool within file nmg_bool.c. This change
removes |
| 19:51.40 |
CIA-62 |
BRL-CAD:
unnecessary operations to improve the speed of nmg boolean
operations. This |
| 19:51.40 |
CIA-62 |
BRL-CAD:
change will increase the speed of functions such as the mged 'ev'
and 'facetize' |
| 19:51.40 |
CIA-62 |
BRL-CAD:
commands. |
| 20:29.39 |
CIA-62 |
BRL-CAD:
03r_weiss * r45432 10/brlcad/trunk/ (include/raytrace.h
src/librt/primitives/nmg/nmg_ck.c): |
| 20:29.39 |
CIA-62 |
BRL-CAD:
Added a new function nmg_vsshell which validates the pointer
structures within a |
| 20:29.39 |
CIA-62 |
BRL-CAD:
single nmg shell structure and all structures within. The function
nmg_vshell |
| 20:29.39 |
CIA-62 |
BRL-CAD: was
changed to call the nmg_vsshell function. The function nmg_vshell
is passed |
| 20:29.39 |
CIA-62 |
BRL-CAD: a
list of shells to validate instead of a single shell. The purpose
of this |
| 20:29.39 |
CIA-62 |
BRL-CAD:
change is to allow a single nmg shell to be validated instead of
all shells |
| 20:29.40 |
CIA-62 |
BRL-CAD:
within an nmg model. The files raytrace.h and nmg_ck.c were
changed. |
| 20:36.28 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 21:16.57 |
CIA-62 |
BRL-CAD:
03r_weiss * r45433
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 21:16.58 |
CIA-62 |
BRL-CAD:
Updated functions nmg_triangulate_model and nmg_triangulate_shell
within file |
| 21:16.58 |
CIA-62 |
BRL-CAD:
nmg_tri.c. These changes make the operations of these functions
consistent so |
| 21:16.58 |
CIA-62 |
BRL-CAD: that
the difference is only one triangulates an nmg shell and the
other |
| 21:16.58 |
CIA-62 |
BRL-CAD:
triangulates all the nmg shells within an nmg model. |
| 21:18.31 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 21:20.56 |
CIA-62 |
BRL-CAD:
03bhinesley * r45434 10/brlcad/trunk/src/libged/alter.c: Added a
union to store distinct command argument groupings for each
command. This obsoleted some of the command-specific #define flags;
I'll fix that later. Started on helper functions for building
args. |
| 21:31.30 |
CIA-62 |
BRL-CAD:
03r_weiss * r45435
10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: |
| 21:31.30 |
CIA-62 |
BRL-CAD:
Fixed a bug in function class_eu_vs_s within file nmg_class.c. The
mid point of |
| 21:31.30 |
CIA-62 |
BRL-CAD: the
edge was not computed correctly. I also used points near the
vertices but |
| 21:31.30 |
CIA-62 |
BRL-CAD:
still on the edge for the fallback if the mid point can not be
classified. This |
| 21:31.30 |
CIA-62 |
BRL-CAD:
change improves the success of nmg boolean operations and can be
seen when |
| 21:31.30 |
CIA-62 |
BRL-CAD:
running, for example, the mged 'facetize' and 'ev'
commands. |
| 22:14.50 |
CIA-62 |
BRL-CAD:
03r_weiss * r45436
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 22:14.50 |
CIA-62 |
BRL-CAD:
Updated the prototype version of the function cut_unimonotone
within file |
| 22:14.50 |
CIA-62 |
BRL-CAD:
nmg_tri.c. This is a work in progress and this change is disabled
by default. |
| 22:14.50 |
CIA-62 |
BRL-CAD: Some
code cleanup was done and the ability to reverse the direction of
loopuse |
| 22:14.50 |
CIA-62 |
BRL-CAD: was
added to correct situations after a loop cut that the direction
reverses |
| 22:14.51 |
CIA-62 |
BRL-CAD: i.e.
is cw and should be ccw. This change supports the prototype version
of the |
| 22:14.52 |
CIA-62 |
BRL-CAD:
function nmg_triangulate_fu. |
| 22:30.37 |
CIA-62 |
BRL-CAD:
03brlcad * r45437 10/brlcad/trunk/src/libged/ (CMakeLists.txt
Makefile.am zoom/ zoom/zoom.c zoom.c): zoom becomes the guinea
piggie. move it into a subdir in preparation for sorting out fully
self-contained modular commands. |
| 22:31.19 |
CIA-62 |
BRL-CAD:
03brlcad * r45438 10/brlcad/trunk/src/libged/zoom/zoom.c: remove
unnecessary headers and useless doxy file comment |
| 22:32.36 |
CIA-62 |
BRL-CAD:
03brlcad * r45439 10/brlcad/trunk/src/libged/zoom/zoom.c:
technically, ged_private.h is no longer in this dir |
| 22:40.28 |
CIA-62 |
BRL-CAD:
03brlcad * r45440 10/brlcad/trunk/src/libged/ (ged_private.h
vutil.c zoom/zoom.c): move _ged_do_zoom() out of vutil into zoom.c
since that's the only place it's used, no longer needing private
decl. rename to zoom(). |
| 22:44.03 |
CIA-62 |
BRL-CAD:
03brlcad * r45441 10/brlcad/trunk/src/libged/zoom/zoom.c: reduce
and simplify |
| 22:44.51 |
CIA-62 |
BRL-CAD:
03brlcad * r45442 10/brlcad/trunk/src/libged/zoom/zoom.c: don't
need a db to scale the view |
| 22:58.13 |
CIA-62 |
BRL-CAD:
03brlcad * r45443 10/brlcad/trunk/src/libged/zoom/zoom.c: make sure
we set sf before testing its value, simplify validity to the two
boundaries while treating the edge case as inside. |
| 22:59.44 |
CIA-62 |
BRL-CAD:
03brlcad * r45444 10/brlcad/trunk/include/vmath.h: ws |
| 23:51.16 |
*** join/#brlcad mafm
(~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net) |
| 00:36.49 |
*** join/#brlcad crux000
(~dan@66.110.178.234) |
| 00:37.50 |
*** part/#brlcad crux000
(~dan@66.110.178.234) |
| 00:45.53 |
CIA-62 |
BRL-CAD:
03kunigami * r45470
10/brlcad/trunk/src/liboptical/sh_osl.cpp: |
| 00:45.53 |
CIA-62 |
BRL-CAD:
Instead of copying only a_rtip, a_hit and a_miss from the previous
application, |
| 00:45.53 |
CIA-62 |
BRL-CAD: I'm
now copying the whole structure before calling rt_shootray at
osl_render. I |
| 00:45.53 |
CIA-62 |
BRL-CAD: have
no idea why it worked for single threads but not for multiple
threads. |
| 00:47.29 |
CIA-62 |
BRL-CAD:
03brlcad * r45471 10/brlcad/trunk/ (7 files in 5 dirs): replace
BU_LIST_MAGIC_OK() and BU_LIST_MAGIC_WRONG() with
BU_LIST_MAGIC_EQUAL() in order for the API to be more consistent
with convention already established in libbn. |
| 00:48.00 |
brlcad |
kunigami_:
aha, so that fixed it? |
| 00:49.23 |
brlcad |
didn't
realize you were doing a partial copy there .. there are
cpu-specific resource structures in an application struct, so when
you weren't copying them it would have been in some peculiar
uninitialized state (not suitable for threaded use) |
| 00:51.37 |
CIA-62 |
BRL-CAD:
03brlcad * r45472 10/brlcad/trunk/include/bu.h: remove
BU_LIST_CLOSE() since it appears to not be in use any where and
it's use is rather limited with the embedded return; there's also
no corresponding 'open' so it was just bad API to begin
with |
| 00:55.33 |
CIA-62 |
BRL-CAD:
03bhinesley * r45473 10/brlcad/trunk/src/ (3 files in 3
dirs): |
| 00:55.33 |
CIA-62 |
BRL-CAD: Add
edit and translate/rotate/scale to Archer. Edit command aliases
are |
| 00:55.33 |
CIA-62 |
BRL-CAD:
intentionally only available to Archer, to keep existing mged
commands intact |
| 00:55.33 |
CIA-62 |
BRL-CAD: for
the time being. Once everything is working, translate/rotate/scale
will be |
| 00:55.33 |
CIA-62 |
BRL-CAD:
mapped directly to ged_edit. |
| 00:56.18 |
brlcad |
basically,
your new application struct wasn't being initialized
properly |
| 00:57.07 |
brlcad |
anytime you
do a full struct copy, you should denote it with a /* struct copy
*/ comment or similar |
| 01:02.42 |
brlcad |
starseeker:
is nirt building on windows? |
| 01:03.56 |
brlcad |
ah, I see you
just disabled those files .. never mind |
| 01:04.28 |
CIA-62 |
BRL-CAD:
03brlcad * r45474 10/brlcad/trunk/src/nirt/dist_def.c: use FMAX()
instead of fmax() since the latter is C99 |
| 01:32.51 |
kunigami_ |
brlcad: it
seems to have been solved :) I'll add that comment |
| 02:13.29 |
*** join/#brlcad merzo
(~merzo@252-7-132-95.pool.ukrtel.net) |
| 02:29.32 |
*** join/#brlcad mafm
(~mafm@90.Red-83-42-153.dynamicIP.rima-tde.net) |
| 02:49.41 |
*** join/#brlcad IriX64
(~root@bas2-sudbury98-1177871903.dsl.bell.ca) |
| 02:55.50 |
*** join/#brlcad IriX64_
(~root@bas2-sudbury98-1177872273.dsl.bell.ca) |
| 03:00.56 |
*** join/#brlcad IriX64
(~root@bas2-sudbury98-1096601331.dsl.bell.ca) |
| 03:05.59 |
*** join/#brlcad IriX64_
(~root@bas2-sudbury98-1128564768.dsl.bell.ca) |
| 03:35.14 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 04:18.25 |
CIA-62 |
BRL-CAD:
03brlcad * r45475 10/brlcad/trunk/src/nirt/ (CMakeLists.txt
Makefile.am dist_def.c): |
| 04:18.25 |
CIA-62 |
BRL-CAD:
remove dist_def.c which was disabled from compilation, but appears
to have been |
| 04:18.25 |
CIA-62 |
BRL-CAD:
related to an earlier implementation of nirt's backout command.
since that code |
| 04:18.25 |
CIA-62 |
BRL-CAD: has
since changed and been improved, just kill this old
bit. |
| 04:21.53 |
CIA-62 |
BRL-CAD:
03brlcad * r45476 10/brlcad/trunk/ (3 files in 3 dirs): remove
nurb's MIN/MAX macros since we already rely on FMIN/FMAX
elsewhere. |
| 04:28.06 |
CIA-62 |
BRL-CAD:
03brlcad * r45477 10/brlcad/trunk/src/burst/grid.c: remove the
min()/max() functions since there don't seem to be any uses that
will have side-effects, use FMIN()/FMAX() instead like already
being used. |
| 04:28.52 |
CIA-62 |
BRL-CAD:
03brlcad * r45478 10/brlcad/trunk/src/proc-db/masonry.c: get rid of
the min/max macros in favor of the FMIN/FMAX decls from
common.h |
| 04:30.58 |
CIA-62 |
BRL-CAD:
03brlcad * r45479 10/brlcad/trunk/src/fb/pl-fb.c: remove unused
min() macro |
| 04:36.12 |
CIA-62 |
BRL-CAD:
03brlcad * r45480
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: call
NEAR_EQUAL() instead of BN_APPROXEQUAL() since they do the same
thing and the latter is unnecessary api. |
| 04:41.03 |
CIA-62 |
BRL-CAD:
03brlcad * r45481 10/brlcad/trunk/include/bn.h: remove
BN_APPROXEQUAL since NEAR_EQUAL is practically equivalent just
without requiring a bn_tol. looks like the only use was isolated to
brep.cpp, so yank it. |
| 04:48.35 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 04:58.48 |
CIA-62 |
BRL-CAD:
03brlcad * r45482 10/brlcad/trunk/src/irprep/ (CMakeLists.txt
Makefile.am ir-sgi.1 ir-sgi.c): remove the antiquated ir-sgi tool
since IRIX is no longer a supported platform |
| 05:03.04 |
CIA-62 |
BRL-CAD:
03brlcad * r45483 10/brlcad/trunk/src/irprep/ (CMakeLists.txt
Makefile.am irdisp.c pictsgi.1 pictsgi.c): same for pictsgi and
irdisp tools, which called ir-sgi. remove pictsgi since it's no
longer functional without ir-sgi. |
| 05:10.11 |
CIA-62 |
BRL-CAD:
03brlcad * r45484 10/brlcad/trunk/include/ (bu.h raytrace.h):
remove sgi/mips references, platform no longer relevant |
| 05:16.58 |
CIA-62 |
BRL-CAD:
03brlcad * r45485 10/brlcad/trunk/src/lgt/ (6 files): remove all
references to sgi since the platform is no longer
maintainable |
| 05:37.28 |
CIA-62 |
BRL-CAD:
03brlcad * r45486 10/brlcad/trunk/src/canon/ (Makefile.am
canonlib.c): more sgi/irix/mips removal. no longer need libds
too. |
| 05:45.48 |
CIA-62 |
BRL-CAD:
03brlcad * r45487 10/brlcad/trunk/src/libfb/if_X.c: we still need
this with Xorg, not SGI-specific |
| 05:46.02 |
CIA-62 |
BRL-CAD:
03brlcad * r45488 10/brlcad/trunk/src/libfb/ (fbserv_obj.c
if_ogl.c): remove sgi from comments |
| 05:50.50 |
CIA-62 |
BRL-CAD:
03brlcad * r45489 10/brlcad/trunk/src/libfb/if_X.c: actually, it
looks like peeking at the fd is the only internal we look for so
call ConnectionNumber() to get it so we can unset
XLIB_ILLEGAL_ACCESS. |
| 05:52.53 |
CIA-62 |
BRL-CAD:
03brlcad * r45490 10/brlcad/trunk/src/ (bwish/Makefile.am
conv/Makefile.am): LINK_STATIC_REQUIRED was needed for irix,
simplify |
| 05:58.36 |
CIA-62 |
BRL-CAD:
03brlcad * r45491 10/brlcad/trunk/ (16 files in 9 dirs): the
sgi/irix/mips platform is no more and has been that way for many
years now. reduce maintenance cost, remove and refactor
accordingly. |
| 06:17.26 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.195.64) |
| 06:17.26 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:12.43 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 08:05.59 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 09:34.51 |
*** join/#brlcad mafm
(~mafm@247.Red-83-38-35.dynamicIP.rima-tde.net) |
| 11:49.25 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-187-000.wlan.tudelft.nl) |
| 12:01.57 |
CIA-62 |
BRL-CAD:
03starseeker * r45492 10/brlcad/trunk/CMakeLists.txt: |
| 12:01.57 |
CIA-62 |
BRL-CAD: Ah
hah. Per http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix,
the |
| 12:01.57 |
CIA-62 |
BRL-CAD:
*IGNORE_PATH variables weren't around until 2.8.3 - that's probably
why the new |
| 12:01.57 |
CIA-62 |
BRL-CAD:
mechanism for ignoring install paths wasn't working in some tests.
Bump our |
| 12:01.57 |
CIA-62 |
BRL-CAD:
required version, as we need to avoid finding old installed BRL-CAD
libraries. |
| 12:22.20 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 12:33.34 |
brlcad |
moin |
| 13:18.35 |
CIA-62 |
BRL-CAD:
03brlcad * r45493 10/brlcad/trunk/src/ (5 files in 4 dirs): more
irix reference removals. |
| 13:29.51 |
``Erik |
yargh |
| 13:30.34 |
``Erik |
hm, broken
stuff, but vaccuum lady is here :/ |
| 13:43.37 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.195.64) |
| 13:43.37 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:07.56 |
*** join/#brlcad kunigami__
(~kunigami@201.53.206.27) |
| 14:18.16 |
*** join/#brlcad dli
(~dli@dsl-67-204-13-217.acanac.net) |
| 14:40.48 |
*** join/#brlcad dli (~dli@66.49.171.226) |
| 16:34.50 |
CIA-62 |
BRL-CAD:
03r_weiss * r45494 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
(log message trimmed) |
| 16:34.51 |
CIA-62 |
BRL-CAD:
Updated the rt_ars_tess function within file ars.c. I disabled the
functions |
| 16:34.51 |
CIA-62 |
BRL-CAD:
nmg_shell_coplanar_face_merge and nmg_simplify_shell unless the
prototype |
| 16:34.51 |
CIA-62 |
BRL-CAD:
triangulation is enabled. The problem is these functions simplify
the ars which |
| 16:34.51 |
CIA-62 |
BRL-CAD:
causes more work for later triangulating the ars. The original
triangulation |
| 16:34.51 |
CIA-62 |
BRL-CAD: code
is unable to triangulate the resulting ars after being simplifed.
In order |
| 16:34.52 |
CIA-62 |
BRL-CAD: to
raytrace an ars, it is first converted to a bot primitive which
requires |
| 16:36.08 |
*** join/#brlcad dli (~dli@173.248.249.148) |
| 16:56.49 |
*** join/#brlcad dli (~dli@66.49.131.81) |
| 17:03.28 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 17:04.31 |
starseeker |
whoops |
| 17:04.52 |
starseeker |
make makes a
note that quit != part in issi |
| 17:04.55 |
starseeker |
irssi
even |
| 17:19.20 |
``Erik |
heh, nope,
not equal :) |
| 17:30.03 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 17:42.42 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 18:04.02 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:18.20 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.195.64) |
| 19:18.20 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:38.17 |
CIA-62 |
BRL-CAD:
03bhinesley * r45495 10/brlcad/trunk/src/libged/edit.c: remove
trailing ws |
| 19:54.56 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1096601243.dsl.bell.ca) |
| 19:55.44 |
IriX64 |
brlcad/regress is missing
CMakeLists.txt |
| 19:57.49 |
IriX64 |
btw i run
el6Workstation now, cygwin is retired :) ill ask my self to leave
now. |
| 20:02.11 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1096600661.dsl.bell.ca) |
| 20:02.50 |
IriX64 |
shouldn't do
this so soon but cmake generates man/html, configure generates
man/html/pdf if anybody cares |
| 20:03.19 |
IriX64 |
i hear me
asking myself to leave again, wont be back today |
| 20:25.33 |
kunigami_ |
13min to
render a scene with one processor. 14min to run with 2 :) The
problem is that I'm blocking the OSLRender every time I query a
color, which is probably where most all the time is spent. I'm
currently looking for multi-threaded examples using OSL system to
block less parts of code. |
| 20:56.14 |
dli |
cmake
trouble: [ 17%] make[2]: *** No rule to make target
`usr/brlcad/share/tclscripts/archer/tclIndex', needed by
`src/tclscripts/archer/CMakeFiles/archer_tclIndex' |
| 20:58.54 |
bhinesley |
hmm.. . it's
working for me |
| 21:03.14 |
bhinesley |
dli: are you
working on a recent svn checkout, a tarball, or what? |
| 21:03.25 |
dli |
bhinesley,
7.20.2 |
| 21:03.36 |
bhinesley |
windows? |
| 21:03.43 |
dli |
bhinesley,
linux |
| 21:05.11 |
bhinesley |
unless
someone else has an idea, I will take a look but it will take me a
bit to download/compile |
| 21:05.49 |
dli |
bhinesley,
this is my cmake line: http://pastebin.com/hrXWMCZn |
| 21:08.52 |
bhinesley |
hmm...
starseeker may have to take a look at that one |
| 21:09.24 |
bhinesley |
is just a student |
| 21:09.30 |
dli |
bhinesley, I
know he started the cmake branch |
| 21:09.55 |
bhinesley |
yep, he's
your man |
| 21:10.54 |
dli |
bhinesley,
also, I have to tweak CMakefile.txt a little bit: http://paste.pocoo.org/show/438902/ |
| 21:11.47 |
bhinesley |
odd |
| 21:13.33 |
bhinesley |
what is there
currently: http://pastebin.mozilla.org/1272356 |
| 21:13.48 |
*** join/#brlcad mafm
(~mafm@247.Red-83-38-35.dynamicIP.rima-tde.net) |
| 21:14.12 |
dli |
bhinesley,
current some ${${path_label}_LABEL} contain space
within |
| 21:15.11 |
dli |
bhinesley,
therefore, sending more than two arguments to LENGTH, and break
cmake |
| 21:15.57 |
bhinesley |
yeah, I
misread, your original is identical to the current
revision |
| 21:17.35 |
bhinesley |
I won't waste
your time: I wouldn't know how to fix it. |
| 21:18.03 |
dli |
bhinesley,
don't worry :) |
| 21:34.56 |
dli |
bhinesley,
seems to be something wrong with make configure line, it builds
now |
| 21:39.11 |
bhinesley |
can you show
me what you changed it to? |
| 21:42.32 |
dli |
bhinesley,
sure |
| 21:44.52 |
dli |
bhinesley,
http://paste.pocoo.org/show/438926/ |
| 21:45.10 |
dli |
bhinesley, I
guess the incorrect PREFIX broke it |
| 21:53.20 |
bhinesley |
dli: yeah I
see that there there is no DCMAKE_PREFIX in your correct version,
but there are two DCMAKE_INSTALL_PREFIX's |
| 21:53.28 |
bhinesley |
er, working
version |
| 21:53.46 |
bhinesley |
er
DBRLCAD_PREFIX I mean |
| 21:55.27 |
dli |
bhinesley,
it's okay, one instance is always added by the gentoo script, the
second one overrides it |
| 21:56.55 |
bhinesley |
nods |
| 21:59.28 |
dli |
^[[0m[ 98%]
Built target step-g |
| 21:59.28 |
dli |
make: ***
[all] Error 2 |
| 21:59.32 |
dli |
no luck
:( |
| 21:59.45 |
bhinesley |
:-/ |
| 22:00.04 |
dli |
bhinesley,
can I disable step-g ? |
| 22:00.33 |
dli |
bhinesley, it
says 'built', so it's not step-g |
| 22:11.40 |
brlcad |
make
VERBOSE=1 |
| 22:11.55 |
dli |
brlcad, doing
that now |
| 22:16.07 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 23:30.57 |
``Erik |
notes that --no-undefined is not a recognized option on some
of his compilers O.o (like the mac) |
| 23:54.34 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 23:56.29 |
*** join/#brlcad kunigami__
(~kunigami@201.53.206.27) |
| 23:57.00 |
starseeker |
``Erik: yeah,
need to test for that somehow or other |
| 23:59.36 |
starseeker |
dli: "usr" is
still a really bad value for CMAKE_INSTALL_PREFIX |
| 23:59.53 |
starseeker |
also, you
don't need to set BRLCAD_PREFIX any more - it's just an interal
thing now |
| 00:00.14 |
dli |
starseeker,
yes, I figured it out by trying brutal force :( |
| 00:00.33 |
starseeker |
sorry - been
busy |
| 00:00.48 |
dli |
starseeker,
how do I add LDFLAGS for itcl and itk? still broken after 98%
built |
| 00:01.24 |
starseeker |
growl.
pastebin? |
| 00:02.03 |
dli |
usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/../../../../x86_64-pc-linux-gnu/bin/ld:
cannot find -litcl |
| 00:02.35 |
starseeker |
um - are you
using system itcl or the local one? |
| 00:02.46 |
dli |
starseeker,
and itcl is at: /usr/lib64/itcl3.4/libitcl3.4.so , using system
one |
| 00:03.54 |
starseeker |
what does
your CMakeCache.txt say for ITCL_LIBRARY? |
| 00:03.57 |
dli |
starseeker,
do I need CMAKE_LINK_FLAGS or could it auto detect system
itcl/itk |
| 00:04.16 |
starseeker |
I thought I
had set up detection for Itcl/Itk |
| 00:04.43 |
dli |
starseeker,
grep ITCL_LIBRARY CMakeCache.txt found nothing |
| 00:04.47 |
starseeker |
I seldom
build with system libs, so it's possible the Find* logic for
Itcl/Itk isn't functioning quite right |
| 00:05.09 |
starseeker |
hmm - you do
have a CMakeCache.txt file? |
| 00:05.18 |
dli |
starseeker,
grep ITCL found something: http://paste.pocoo.org/show/439032/ |
| 00:06.17 |
starseeker |
hmm - so the
question is what the find routines are doing |
| 00:08.05 |
dli |
starseeker,
for the time being, I will try CMAKE_LINK_FLAGS |
| 00:09.19 |
starseeker |
If the find
routines were working, you wouldn't be getting itcl |
| 00:10.04 |
dli |
starseeker,
do you mean be getting itcl/itk trouble? |
| 00:10.17 |
CIA-62 |
BRL-CAD:
03starseeker * r45496 10/brlcad/trunk/CMakeLists.txt: Quote some
path strings for robustness - need more testing of the logic with
spaces and other unfriendly characters paths |
| 00:10.31 |
starseeker |
dli: I'm
assuming your using system Tcl/Tk? |
| 00:10.40 |
dli |
starseeker,
yes |
| 00:11.04 |
starseeker |
dli: what
happens if you just run cmake without forcing off
libraries? |
| 00:11.18 |
starseeker |
(i.e what
does the summary report at the end?) |
| 00:11.28 |
starseeker |
it will try
to use system libraries if it can find them by default |
| 00:11.53 |
dli |
starseeker, I
will try that later, it's building with CMAKE_LINK_FLAGS now :(
slow core2duo |
| 00:12.12 |
starseeker |
k - if it's
not using system Tcl/Tk, there's probably a reason |
| 00:12.34 |
starseeker |
forcing
system lib usage when the cmake logic doesn't select them by
default is problematic |
| 00:12.49 |
starseeker |
if the cmake
logic is doing its job, it is rejecting them for a
reason |
| 00:13.31 |
dli |
starseeker,
summary of report: http://pastebin.com/AkxGVSdZ |
| 00:14.07 |
starseeker |
and your
CMakeCache.txt file still doesn't have ITCL_LIBRARY? |
| 00:15.10 |
dli |
starseeker,
no, still no ITCL_LIBRARY |
| 00:17.04 |
starseeker |
OH. I know
what's going on |
| 00:17.14 |
starseeker |
this is a
consequence of switching back to using the Itcl/Itk C
API |
| 00:17.45 |
dli |
starseeker,
so, I probably need a patch for 7.20.2 |
| 00:17.59 |
starseeker |
I had changed
things so that we were simply doing package require Itcl where
needed - brlcad got a report of some breakage somewhere |
| 00:18.07 |
starseeker |
I never could
reproduce it |
| 00:18.24 |
starseeker |
dli: you
might try the autotools build - that should still work |
| 00:18.40 |
dli |
starseeker,
already tested, it works |
| 00:19.13 |
dli |
starseeker,
I'm trying to make a gentoo ebuild for cmake building |
| 00:19.14 |
starseeker |
brlcad: do
you recall what the problem was with using package require and what
the conditions were to reproduce the bug? If it's a choice between
fixing that bug and reworking the Itcl/Itk detection logic to find
the C API I'd vote for fixing the bug |
| 00:20.53 |
starseeker |
dli: this
isn't all that simple - the Itcl/Itk C headers require internal
headers we can't count on from an installed system
version |
| 00:21.27 |
dli |
starseeker,
but autotools still build it properly |
| 00:21.43 |
starseeker |
dli: yes,
because all the necessary scary logic is already in
there |
| 00:22.09 |
starseeker |
we shouldn't
actually need the Itcl/Itk C api at all - I yanked it out once, but
there was a report of a bug |
| 00:22.23 |
starseeker |
something
about loading iwidgets twice IIRC, but I couldn't duplicate
it |
| 00:22.47 |
dli |
starseeker, I
would love to see itcl/itk removed. :( |
| 00:22.58 |
starseeker |
dli: we can't
remove it - it's used extensively |
| 00:23.13 |
starseeker |
once we can
just do "package require Itcl" it gets a lot easier |
| 00:23.52 |
starseeker |
The Tcl/Tk
headers are horrible about API separation - lots of extensions need
access to "internal" headers just to build |
| 00:24.06 |
dli |
starseeker,
for the time being I can force local building of itcl/itk, seems to
be a workaround |
| 00:24.14 |
starseeker |
dli: yeah,
that should work |
| 00:24.29 |
starseeker |
although if
you're doing a gentoo ebuild they'll never go for it |
| 00:25.12 |
dli |
starseeker,
let me try ;( |
| 00:28.26 |
dli |
starseeker, I
have to enable tcl/tk local building, not simply itcl/itk,
right? |
| 00:28.40 |
starseeker |
um. You can
try just itcl/itk |
| 00:28.58 |
starseeker |
not sure if
that'll fly without the tcl/tk internal headers, but you can give
it a shot |
| 00:29.28 |
dli |
starseeker,
no such flag ITCL/ITK in CMakeLists.txt |
| 00:29.44 |
starseeker |
-DBRLCAD_BUILD_LOCAL_ITCL=ON |
| 00:29.55 |
starseeker |
-DBRLCAD_BUILD_LOCAL_ITK=ON |
| 00:29.57 |
starseeker |
try
those |
| 00:32.24 |
kunigami__ |
Is there any
way I can get the identifier of a thread in a sh_xyz
code? |
| 00:33.14 |
dli |
starseeker,
no, no effect, cmake still found system itcl/itk |
| 00:33.25 |
starseeker |
one
sec... |
| 00:34.12 |
starseeker |
crud - yeah,
you may need to enable tcl/tk then |
| 00:34.37 |
starseeker |
I was
probably thinking a "sane" Itcl/Itk build couldn't depend on a
system tcl/tk install having what it needed anyway |
| 00:37.07 |
kunigami__ |
This
identifier should be passed along application and probably set at
do_pixel |
| 00:37.28 |
starseeker |
kunigami__:
sorry, that's a little outside my expertice |
| 00:40.09 |
starseeker |
dli: the only
reason we can even "mix" system Tcl/Tk and local package builds in
the old autotools setup is due to our logic supplying our own local
include directories in src/other to the builds of those extensions
that need them |
| 00:40.11 |
dli |
starseeker,
still no luck, cmake still found system tcl/tk/itcl/itk |
| 00:40.36 |
kunigami__ |
starseeker:
no problem :) I'm just thinking aloud to see if I can get some
feedback |
| 00:40.36 |
kunigami__ |
] |
| 00:40.48 |
starseeker |
-DBRLCAD_BUILD_LOCAL_TCL_FORCE=ON |
| 00:41.11 |
starseeker |
or rather
-DBRLCAD_BUILD_LOCAL_TCL_FORCE_ON=ON |
| 00:44.02 |
dli |
starseeker,
yes, FORCE_ON does the trick |
| 00:54.41 |
kunigami__ |
<PROTECTED> |
| 00:59.19 |
CIA-62 |
BRL-CAD:
03starseeker * r45497 10/brlcad/trunk/CMakeLists.txt: Comment out
the --no-undefined linker option until I figure out how to test
it. |
| 01:17.15 |
kunigami__ |
thanks
:) |
| 01:18.09 |
dli |
starseeker,
yes, with FORCE_ON, it builds properly. Thanks |
| 01:19.28 |
starseeker |
dli: no
problem |
| 01:23.44 |
CIA-62 |
BRL-CAD:
03kunigami * r45498 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp
liboslrend.h sh_osl.cpp): changing OSLRender methods to static. I
think this will be necessary to increase parallelism |
| 02:28.22 |
bhinesley |
When I have
argc > 1 and my command returns GED_HELP, Archer prints the
error "No ledger entry found for help." What am I
missing? |
| 02:28.48 |
bhinesley |
in that case,
argv[2] was help |
| 02:29.41 |
bhinesley |
excuse me,
argv[1] was help |
| 02:37.16 |
CIA-62 |
BRL-CAD:
03bhinesley * r45499 10/brlcad/trunk/include/ged.h: moved ged_edit
to more appropriate place |
| 02:43.55 |
CIA-62 |
BRL-CAD:
03bhinesley * r45500 10/brlcad/trunk/src/ (8 files in 3 dirs):
Validate subcommand names, add ged_edit stuff to a few places I
missed before, cleanup. |
| 02:45.58 |
CIA-62 |
BRL-CAD:
03bhinesley * r45501 10/brlcad/trunk/src/libged/edit.c: quiet
compiler warning about unused variable |
| 02:52.13 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 03:12.36 |
brlcad |
kunigami__:
libbu's parallelism passes the cpu/thread id to the worker
callback |
| 03:12.54 |
brlcad |
for rt,
that's the worker() function in src/rt/worker.c, which in turn
calls do_pixel() with the cpu |
| 03:13.44 |
brlcad |
the
application struct's a_resource is then set to a cpu-specific
resource structure safe for that thread to use without
blocking |
| 03:14.18 |
brlcad |
why you'd
need to know that is a bit of a mystery, though ... :) |
| 03:15.28 |
brlcad |
bhinesley:
I'm not sure what archer was set up to use, but it may be pulling
help from src/tclscripts/helplib.tcl and/or src/tclscripts/help.tcl
... old help interface |
| 03:15.59 |
brlcad |
the modular
command refactoring that I started is the beginnings of making
those obsolete |
| 03:16.57 |
bhinesley |
brlcad: that
was sort of a bad example. It prints "No ledger entry found for
<whatever argv[1] is>" |
| 03:17.42 |
bhinesley |
assuming that
I return GED_HELP |
| 03:18.09 |
brlcad |
both mged and
archer tell you that or just archer? |
| 03:18.13 |
bhinesley |
just
archer |
| 03:19.36 |
bhinesley |
you weren't
kidding... there really are a lot of places to make changes when
you add a command |
| 03:19.52 |
*** join/#brlcad dli
(~dli@dsl-69-172-83-119.acanac.net) |
| 03:21.46 |
brlcad |
yeah, it's
really terrible |
| 03:22.23 |
brlcad |
15 years of a
very active dev not doing hardly any proper refactoring, at least
not for the DRY principle |
| 03:24.17 |
brlcad |
part of the
problem is that even with a clean refactoring towards libged, a
silly route was taken to make it fit the existing archer interface
.. once again needing to repeat all commands |
| 03:24.43 |
brlcad |
all of the
*_obj.c files should be killed, but that's a refactoring task in
itself -- feel free to tackle any and all of them |
| 03:25.46 |
bhinesley |
nods |
| 03:25.55 |
bhinesley |
definitely no
lack of things to do |
| 03:31.53 |
brlcad |
he's also
like the 3rd or 4th most experienced tcl dev on the planet (at
least as measured by ohloh), so (for him) he's very adept wandering
around the bowels of mged and archer |
| 03:32.14 |
brlcad |
sort of has
his own perspective on maintainability |
| 03:34.02 |
bhinesley |
is he ever in
here? |
| 03:34.12 |
bhinesley |
or lists
only? |
| 03:37.52 |
brlcad |
mostly
mailing list |
| 03:38.08 |
brlcad |
so that
ledger issue, more replication crap |
| 03:38.36 |
brlcad |
and it's not
code I really understand, so can't be of much help -- might make a
good mailing list question if you have any |
| 03:38.42 |
bhinesley |
alright,
well, it's not inhibiting the functionality of the command, so I
won't worry about it right now |
| 03:39.00 |
brlcad |
tclscripts/archer/Archer.tcl AND
tclscripts/archer/ArcherCore.tcl .. both list commands for some
reason |
| 03:39.19 |
brlcad |
I presume if
you don't list the command that it's calling some generic wrapper,
and pulling the wrong argv for your command or
something |
| 03:39.54 |
bhinesley |
looks into this |
| 03:40.07 |
bhinesley |
hey, ohloh is
pretty neat |
| 03:40.10 |
bhinesley |
just now
checking it out |
| 03:40.17 |
brlcad |
really?
:) |
| 03:40.33 |
brlcad |
http://www.ohloh.net/p/brlcad |
| 03:41.37 |
bhinesley |
first thing I
did was search for brlcad ;-) |
| 03:51.20 |
bhinesley |
96 commits...
hm... I'd better step it up a notch |
| 03:59.40 |
brlcad |
add two
orders of magnitude and you'll be in the #3 spot ;) |
| 03:59.59 |
brlcad |
that's like
two years |
| 04:11.19 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r3008
10/wiki/Non-vacuum_gravity_simulator: missing paren |
| 04:20.37 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r3009
10/wiki/Celestial_mechanics_particle_system: link to some 3rd party
libs |
| 04:21.08 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r3010
10/wiki/Non-vacuum_gravity_simulator: |
| 04:41.35 |
*** join/#brlcad dli (~dli@67.55.33.66) |
| 07:09.17 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 07:10.29 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 07:12.14 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 07:12.56 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 07:16.23 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 08:02.47 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 09:10.01 |
*** join/#brlcad mafm
(~mafm@120.Red-83-42-153.dynamicIP.rima-tde.net) |
| 09:18.18 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 09:56.23 |
kunigami__ |
brlcad: it
seems I need to set different vars for each thread when first
calling OSLRender and I dont know how to do that without an
identifier for each thread. |
| 10:08.14 |
kunigami__ |
unless I
initialize OSLRender right in do_pixel |
| 11:02.51 |
*** join/#brlcad dli (~dli@67.55.33.66) |
| 11:20.07 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 11:39.20 |
*** join/#brlcad __name__
(~name@sburn/devel/name) |
| 11:47.31 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 12:13.20 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 14:05.29 |
*** join/#brlcad dli (~dli@66.49.183.65) |
| 14:50.42 |
brlcad |
kunigami__:
you could use the address of the struct resource in the application
struct -- that is unique per process/thread |
| 15:12.05 |
*** join/#brlcad mafm_
(~mafm@120.Red-83-42-153.dynamicIP.rima-tde.net) |
| 16:47.47 |
*** join/#brlcad __name__
(~name@chello080108038152.1.11.vie.surfer.at) |
| 16:47.47 |
*** join/#brlcad __name__
(~name@sburn/devel/name) |
| 17:11.42 |
__name__ |
Hello! I've
been reading your SOCIS projects and would be interested whether
there are any tools of preference for the web applications
(language, DB, whether it's supposed the be ajaxy,
etc.) |
| 17:21.48 |
CIA-62 |
BRL-CAD:
03r_weiss * r45502
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 17:21.48 |
CIA-62 |
BRL-CAD:
Updated the prototype version of function cut_unimonotone within
file nmg_tri.c. |
| 17:21.48 |
CIA-62 |
BRL-CAD: This
function supports the prototype version of function
nmg_triangulate_fu. |
| 17:21.48 |
CIA-62 |
BRL-CAD:
These prototype functions are disabled by default. This is a work
is progress. |
| 17:21.48 |
CIA-62 |
BRL-CAD:
Changed the test for an infinite loop and added more error
checking. Also did |
| 17:21.49 |
CIA-62 |
BRL-CAD: code
cleanup. |
| 18:11.18 |
*** join/#brlcad name
(~name@sburn/devel/name) |
| 18:34.55 |
brlcad |
hello
__name__ |
| 18:35.45 |
brlcad |
__name__:
there isn't a strong preference, but something that works for most
users, is easy to install and maintain, and does the job
best |
| 18:36.16 |
brlcad |
current
website is a drupal+mediawiki combo |
| 18:46.45 |
*** join/#brlcad DarkCalff
(DC@173.231.40.98) |
| 18:48.44 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45503 10/brlcad/trunk/src/libged/edit.c: Clean
up C90 warning on some compilers. |
| 19:12.08 |
CIA-62 |
BRL-CAD:
03r_weiss * r45504 10/brlcad/trunk/src/irprep/ (Compile.sgi
Makefile.am): sgi files are gone in irprep - let the Makefile.am
know about it. |
| 19:34.37 |
*** join/#brlcad epileg
(~epileg@188.119.210.222.dynamic.eurona.net) |
| 19:34.41 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 19:40.22 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
| 19:50.42 |
brlcad |
wootness |
| 20:35.14 |
starseeker |
brlcad:
hmm? |
| 20:35.30 |
__name__ |
brlcad: Well
you cannot really base a benchmark web-UI on either of
those. |
| 21:08.37 |
CIA-62 |
BRL-CAD:
03r_weiss * r45505
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 21:08.37 |
CIA-62 |
BRL-CAD:
Updated the prototype version of the function nmg_triangulate_fu
within file |
| 21:08.37 |
CIA-62 |
BRL-CAD:
nmg_tri.c. This function is disabled by default. This is a work is
process. The |
| 21:08.37 |
CIA-62 |
BRL-CAD:
majority of the changes were code cleanup. Added logic to prevent
unnecessary |
| 21:08.37 |
CIA-62 |
BRL-CAD:
processing of already triangulated faceuse. |
| 21:09.19 |
CIA-62 |
BRL-CAD:
03starseeker * r45506
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Clang likes to
complain about unused command line arguments, and we don't really
care. |
| 21:19.19 |
starseeker |
first crack
at building BRL-CAD with clang/clang++ in XCode 4: http://pastebin.mozilla.org/1272704 |
| 21:19.45 |
brlcad |
__name__:
sure you could -- I could make plain html work too |
| 21:19.50 |
brlcad |
all in the
design |
| 21:20.02 |
brlcad |
doesn't mean
you're constrained to those, just saying what's already
handy |
| 21:20.08 |
starseeker |
doesn't know enough about why those externs are there to know
if they are still needed... |
| 21:20.09 |
__name__ |
brlcad:
Doesn't sound like a good idea though. |
| 21:20.21 |
brlcad |
that's a
different statement ;) |
| 21:20.31 |
__name__ |
(Generating
pure HTML.) |
| 21:21.05 |
brlcad |
big
difference between "cannot" and "not a good idea" ;) |
| 21:21.15 |
__name__ |
brlcad: Fair
point. |
| 21:21.20 |
brlcad |
you have a
windows build handy? |
| 21:21.29 |
brlcad |
sry,
starseeker: http://pastebin.mozilla.org/1272704 |
| 21:21.38 |
brlcad |
bah ..
starseeker: you have a windows build handy? |
| 21:23.13 |
__name__ |
brlcad:
Anyway. I'd be happy to do the web-application (or any other
not-too-physics-heavy task). |
| 21:24.12 |
starseeker |
brlcad: not
at the moment - problem? |
| 21:24.13 |
brlcad |
starseeker:
huh, interesting warnings .. apparently llvm thinks that
declarations can shadow declarations |
| 21:24.34 |
starseeker |
liboptical
isn't happy either: http://pastebin.mozilla.org/1272706 |
| 21:25.16 |
brlcad |
starseeker:
the good news is that those are just duplicate decls and llvm can
help weed them out |
| 21:25.49 |
brlcad |
just remove
the redundant duplicate |
| 21:26.32 |
brlcad |
starseeker:
and no, not a problem -- I just have an implementation of fchmod()
for Windows that will likely break the Windows build, need someone
to test |
| 21:26.51 |
starseeker |
ah |
| 21:27.25 |
starseeker |
yeah,
probably would take me at least an hour or so to kick my Windows
build back into gear |
| 21:28.47 |
CIA-62 |
BRL-CAD:
03starseeker * r45507 10/brlcad/trunk/src/ (libfb/fb_generic.c
librt/tcl.c): remove duplicate decls (XCode 4 clang no
likie) |
| 21:28.54 |
starseeker |
bounces over to the Windows box... |
| 21:29.09 |
starseeker |
brlcad: whats
the MFUNCS thing all about? |
| 21:29.31 |
brlcad |
hold a sec,
looking |
| 21:31.26 |
CIA-62 |
BRL-CAD:
03brlcad * r45508 10/brlcad/trunk/src/libbu/fchmod.c: |
| 21:31.26 |
CIA-62 |
BRL-CAD:
implement fchmod() for Windows. this will likely break the Windows
build, but |
| 21:31.26 |
CIA-62 |
BRL-CAD:
committing it since the only issue should be minor header and
preprocessor |
| 21:31.26 |
CIA-62 |
BRL-CAD:
symbolage. in order to implement fchmod on Windows, we rely on
chmod() instead |
| 21:31.26 |
CIA-62 |
BRL-CAD:
which is available but requires a filename. this is normally not
knowable, but |
| 21:31.27 |
CIA-62 |
BRL-CAD:
windows provides a roundabout way to get it, so run with
it. |
| 21:42.57 |
CIA-62 |
BRL-CAD:
03starseeker * r45509 10/brlcad/trunk/src/liboptical/sh_wood.c:
duplicate declarations in sh_wood.c |
| 21:47.28 |
CIA-62 |
BRL-CAD:
03r_weiss * r45510
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 21:47.28 |
CIA-62 |
BRL-CAD:
Updated the prototype function nmg_plot_fu within file nmg_tri.c.
This function |
| 21:47.28 |
CIA-62 |
BRL-CAD:
supports the prototype function nmg_triangulate_fu. These functions
are disabled |
| 21:47.28 |
CIA-62 |
BRL-CAD: by
default. This is a work in process. The changes were code
cleanup. |
| 21:55.05 |
CIA-62 |
BRL-CAD:
03starseeker * r45511 10/brlcad/trunk/src/ (14 files in 10 dirs):
Remove all non-liboptical shadowing warnings. |
| 22:00.01 |
starseeker |
ah right, the
optical/multispectral thing |
| 22:02.06 |
CIA-62 |
BRL-CAD:
03starseeker * r45512
10/brlcad/trunk/src/liboptical/init.c: |
| 22:02.06 |
CIA-62 |
BRL-CAD: Some
of these MFUNCS are declared in the header for libmultispectral -
for |
| 22:02.06 |
CIA-62 |
BRL-CAD:
those, don't do the extern struct part of the original MFUNCS
macro. Add a |
| 22:02.06 |
CIA-62 |
BRL-CAD:
DMFUNCS macro for both the extern and the mlib_add shader call, and
make MFUNCS |
| 22:02.06 |
CIA-62 |
BRL-CAD: just
do the mlib_add_shader bit. |
| 22:04.04 |
CIA-62 |
BRL-CAD:
03starseeker * r45513 10/brlcad/trunk/src/fbed/fbed.c: f_Stop
doesn't take any arguments |
| 22:07.46 |
CIA-62 |
BRL-CAD:
03starseeker * r45514 10/brlcad/trunk/src/libmultispectral/init.c:
Same trick for libmultispectral as for liboptical. |
| 22:09.08 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 22:10.57 |
CIA-62 |
BRL-CAD:
03starseeker * r45515
10/brlcad/trunk/src/gtools/beset/population.c: resp was unused
here? Not really sure what the intent of that statement
was. |
| 22:11.47 |
CIA-62 |
BRL-CAD:
03starseeker * r45516 10/brlcad/trunk/src/rt/ (viewarea.c
viewfrac.c viewpp.c): Some more duplicate declarations. |
| 22:13.38 |
brlcad |
starseeker:
MFUNCS is how each shader is registered with liboptical |
| 22:13.53 |
CIA-62 |
BRL-CAD:
03starseeker * r45517 10/brlcad/trunk/src/lgt/do_options.c: More
functions that don't take any arguments. |
| 22:14.26 |
brlcad |
the problem
is that a few shaders might have to be declared for
libmultispectral, so some are declared in optical.h |
| 22:14.56 |
starseeker |
brlcad: right
- I had forgotten about that, something I think from the Windows
build |
| 22:14.59 |
starseeker |
I got is
straight |
| 22:15.17 |
brlcad |
they
shouldn't need to be declared in optical.h |
| 22:15.21 |
starseeker |
Woot! clang
build with XCode 4 finished |
| 22:15.30 |
brlcad |
sort of
breaks the whole modularity DRY principle |
| 22:17.42 |
brlcad |
pretty cool,
yay for portability |
| 22:18.08 |
starseeker |
brlcad: what
was the intent of that bset/population.c line I wonder? |
| 22:29.50 |
brlcad |
I don't see a
beset line |
| 22:34.05 |
starseeker |
r45515 |
| 22:34.32 |
starseeker |
svn diff
-r45514:45515 |
| 22:40.52 |
starseeker |
Ouch |
| 22:40.59 |
starseeker |
benchmark
results: |
| 22:41.07 |
starseeker |
clang vgr:
13540 |
| 22:41.21 |
starseeker |
gcc vgr:
14944 |
| 22:41.30 |
starseeker |
(debug builds
in both cases) |
| 22:47.05 |
``Erik |
optimized? |
| 22:47.12 |
starseeker |
``Erik:
working on it now |
| 22:49.14 |
starseeker |
brlcad:
fchmod.c Windows build failures: http://pastebin.mozilla.org/1272750 |
| 23:03.53 |
CIA-62 |
BRL-CAD:
03starseeker * r45518 10/brlcad/trunk/src/mged/utility1.c: clang is
reporting these as unused. Looks like this is part of the stuff
that has moved to libged - nuke. |
| 23:16.46 |
starseeker |
gcc vgr
(optimized): 33425 |
| 23:18.01 |
starseeker |
can already tell the clang results will be
slower |
| 23:20.45 |
*** join/#brlcad webmaster
(~webmaster@93-152-34-168.xln.managedbroadband.co.uk) |
| 23:30.26 |
starseeker |
clang vgr
(optimized): 30409 |
| 23:30.56 |
starseeker |
sigh. Oh,
well - at least it's a useful tool for debugging - I like the error
messages |
| 01:44.54 |
CIA-62 |
BRL-CAD:
03kunigami * r45535 10/brlcad/trunk/src/other/ (4 files in 3 dirs):
Added cmakefile to compile the .osl shaders into .oso ones. This is
done only if the OSL flag is enabled |
| 02:03.23 |
CIA-62 |
BRL-CAD:
03kunigami * r45536 10/brlcad/trunk/src/liboptical/sh_osl.cpp:
changed sh_osl to read shaders from ../shaders instead of
./ |
| 02:17.17 |
CIA-62 |
BRL-CAD:
03bhinesley * r45537 10/brlcad/trunk/src/libged/edit.c: adding
generic subargument handling to ged_edit; it's a work in progress.
incomplete sections are disabled |
| 02:30.37 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3012 10/wiki/User:Bhinesley: /* Log */ wrong month on a few
dates |
| 02:33.00 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3013 10/wiki/User:Bhinesley: /* Log */ overwrote a couple dates
last change |
| 02:53.22 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3014 10/wiki/User:Bhinesley: /* Log */ catching up |
| 03:04.46 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3015 10/wiki/User:Bhinesley: /* Log */ cross out completed
items |
| 03:57.06 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 04:38.51 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 05:53.12 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
| 07:14.06 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 07:57.17 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:34.05 |
*** join/#brlcad yAdam
(~chatzilla@188.147.179.132.nat.umts.dynamic.t-mobile.pl) |
| 10:09.28 |
*** join/#brlcad yAdam
(~chatzilla@188.147.201.90.nat.umts.dynamic.t-mobile.pl) |
| 10:15.46 |
*** join/#brlcad yAdam
(~chatzilla@188.147.201.90.nat.umts.dynamic.t-mobile.pl) |
| 12:52.35 |
*** join/#brlcad yAdam
(~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl) |
| 13:03.29 |
*** part/#brlcad yAdam
(~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl) |
| 13:20.35 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45538 10/brlcad/trunk/src/libged/edit.c: #if0
some unused funcs marked HIDDEN, causes compile failure when
debugging is disabled |
| 13:41.09 |
CIA-62 |
BRL-CAD:
03brlcad * r45539 10/brlcad/trunk/ (include/bu.h
src/libbu/file.c): |
| 13:41.09 |
CIA-62 |
BRL-CAD:
initial implementation of bu_file_delete() for removing files.
performs a |
| 13:41.09 |
CIA-62 |
BRL-CAD:
simple remove() but then will try harder by relaxing the file
permissions on a |
| 13:41.09 |
CIA-62 |
BRL-CAD:
second pass attempt if the first fails. untested on windows but
remove() is c90 |
| 13:41.09 |
CIA-62 |
BRL-CAD: so
we should be able to rely on it. callers will just have to make
sure the |
| 13:41.10 |
CIA-62 |
BRL-CAD: file
isn't opened. |
| 13:49.45 |
*** join/#brlcad yAdam
(~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl) |
| 13:49.58 |
*** part/#brlcad yAdam
(~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl) |
| 14:16.51 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701)
|| |
| 14:16.58 |
brlcad |
bah |
| 14:17.34 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 14:17.58 |
brlcad |
all orgs get
just one slot |
| 14:18.48 |
__name__ |
shouldn't
this have been announced yesterday? |
| 14:19.56 |
brlcad |
they were a
little late due to more submissions than they
anticipated |
| 14:20.17 |
brlcad |
it was just
announced a little bit ago |
| 14:22.09 |
__name__ |
Their FAQ
still are not complete either. |
| 14:24.37 |
brlcad |
is a faq ever
complete? |
| 14:24.52 |
__name__ |
They have
questions without answers isted. |
| 14:24.55 |
brlcad |
unless you
define the frequency, there will always be someone with a
question |
| 14:24.55 |
__name__ |
*listed
even |
| 14:25.01 |
brlcad |
ah,
meh |
| 14:25.03 |
brlcad |
not really
concerning -- they're pretty closely mirrored after
gsoc |
| 14:25.21 |
brlcad |
limited time
and resources, building it up as they go .. it is a pilot program
after all |
| 14:25.40 |
brlcad |
any info is a
plus, the whole thing could be done over private e-mail
exchanges |
| 14:25.41 |
__name__ |
Yeah. |
| 14:25.54 |
brlcad |
or (shudder)
phone calls |
| 14:26.34 |
brlcad |
I'm impressed
they got 20 slots funded by their management |
| 14:27.02 |
brlcad |
roughly
100-200k pilot |
| 14:28.00 |
``Erik |
heh, a faq
with no answers would be awesome "look, it's a faq, not an atfaq!
just the questions!" :D |
| 14:29.16 |
__name__ |
Hah |
| 14:33.33 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 15:10.02 |
bhinesley |
``Erik: I
wonder why it doesn't fail for me when there are unused
functions... I have debugging enabled |
| 15:10.37 |
bhinesley |
I don't even
get a warning |
| 15:11.41 |
bhinesley |
smacks self awake |
| 15:12.22 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:05.21 |
brlcad |
bhinesley:
different versions of the same compiler will report different
warnings, plus other compilation settings (such as optimized) can
affect warnings |
| 16:07.46 |
bhinesley |
do you always
build with strict on? It never works for me |
| 16:07.58 |
``Erik |
with
debugging OFF, the NDEBUG flag gets set, which turns HIDDEN into
"static", otherwise it's defined as /* */ |
| 16:08.24 |
``Erik |
that's where
that issue came from |
| 16:08.52 |
bhinesley |
hmm |
| 16:11.09 |
bhinesley |
the question
I really mean to ask is: what should I be doing differently, so
that you guys don't have to follow me around to clean up my mess?
:) |
| 16:11.27 |
``Erik |
stop making a
mess? :D |
| 16:11.51 |
bhinesley |
I have to
figure out how to identify a mess first |
| 16:11.54 |
``Erik |
I like to
have a 'build' directory with several subdirs for different
configurations to spot those |
| 16:12.47 |
bhinesley |
okay, so you
build with various options as a matter of course |
| 16:13.37 |
``Erik |
yeah, and a
variety of os/arch's, to boot |
| 16:14.35 |
bhinesley |
ok |
| 16:21.27 |
brlcad |
bhinesley:
strict should always work -- if it doesn't, that's something that
needs to be addressed |
| 16:21.48 |
brlcad |
should be
building with strict enabled |
| 16:22.20 |
brlcad |
debug enabled
and strict enabled -- optimized can be on or off |
| 16:23.22 |
bhinesley |
there are
thousands upon thousands of warnings... I'm guessing that only
certain types are treated as errors |
| 16:23.26 |
bhinesley |
? |
| 16:24.13 |
bhinesley |
I will take a
look at what is stopping me from building strict |
| 16:35.24 |
brlcad |
what are the
first few? |
| 16:35.48 |
brlcad |
i'm guessing
that it's something like printf specifier conversions |
| 16:38.04 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.157.143) |
| 16:38.04 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:54.02 |
*** join/#brlcad alex_jon1
(~alex_joni@81.196.65.201) |
| 16:59.28 |
bhinesley |
brlcad: lots
of printf specifier conversions, yes. Also, a lot of variables not
set or not used (these are stopping me from building
strict). |
| 16:59.43 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 17:01.57 |
brlcad |
bhinesley:
what os and version of gcc? |
| 17:02.03 |
brlcad |
and cmake or
autotools build? |
| 17:02.35 |
brlcad |
if you can
produce a full build log, I can look into whether there is a
categoric fix |
| 17:03.03 |
bhinesley |
Fedora 15,
gcc 4.6.0 20110530, cmake |
| 17:03.08 |
brlcad |
I suspect
you're just using a version of gcc newer than everyone else or on a
curious platform with odd 32-bit/64-bit size mixtures |
| 17:03.17 |
bhinesley |
64-bit |
| 17:03.23 |
brlcad |
definitely a
pretty new gcc |
| 17:04.21 |
brlcad |
make -k
2>&1 | tee build.log |
| 17:05.01 |
``Erik |
installs gcc47 on crit O.o |
| 17:05.19 |
bhinesley |
Okay, I'm
running that. It seems that the unused variables are primarily what
is preventing build, so I'll see how far the rabbit hole goes in
the meantime. |
| 17:06.59 |
bhinesley |
a lot of
"{int ret; ret = somefunction();}" ->
"{(void)somefunction();}" |
| 17:13.33 |
bhinesley |
http://db.tt/rITDTCH |
| 17:13.54 |
bhinesley |
brlcad ^
build log |
| 17:18.31 |
CIA-62 |
BRL-CAD:
03bhinesley * r45540 10/brlcad/trunk/src/libbu/ (bomb.c
crashreport.c): removed unused variables and quiet
compiler |
| 17:20.23 |
bhinesley |
more complex
to fix: http://pastebin.mozilla.org/1276121 |
| 17:21.11 |
bhinesley |
I'm assuming
we want to keep BU_LIST_APPEND's BU_ASSERT's |
| 17:27.52 |
CIA-62 |
BRL-CAD:
03bhinesley * r45541 10/brlcad/trunk/src/libbu/vlb.c: remove unused
variable missed last commit |
| 17:32.20 |
bhinesley |
very quietly disables strict and goes back to work for
now |
| 17:50.20 |
brlcad |
bhinesley:
don't go too far down that route |
| 17:50.56 |
brlcad |
functions
like read()/write() will thrown warnings with different versions of
the compiler if you cast the return to (void) |
| 17:51.10 |
bhinesley |
ah |
| 17:51.35 |
brlcad |
the fact that
the return value is being stashed in a var was to quiet earlier
warnings |
| 17:51.46 |
bhinesley |
alright, I'll
revert |
| 17:52.30 |
brlcad |
note that
r45540 unveils two issues |
| 17:53.07 |
brlcad |
fwrite
doesn't return an int, it returns a size_t |
| 17:54.43 |
bhinesley |
okay, so I'll
fix it |
| 17:54.45 |
brlcad |
write and
fwrite return values are compared against the number of values
written, write is an int, fwrite a size_t, both if (ret != nvals)
perror("fwrite/write failed"); |
| 17:55.14 |
brlcad |
just calling
perror() preserves current behavior, just printing the
issue |
| 17:55.51 |
brlcad |
(as a
two-liner, not one-liner) |
| 17:57.15 |
*** join/#brlcad merzo
(~merzo@48-81-132-95.pool.ukrtel.net) |
| 18:06.42 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.157.143) |
| 18:06.42 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:33.35 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 19:23.15 |
CIA-62 |
BRL-CAD:
03bhinesley * r45542 10/brlcad/trunk/src/libbu/ (bomb.c
crashreport.c vlb.c): resolved issues regarding fwrite/write return
value validation, unveiled by r45540/r45541 per conversation with
Sean |
| 19:42.26 |
*** join/#brlcad KimK_afk
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 19:46.08 |
brlcad |
bhinesley:
thought you said there were thousands? |
| 19:46.29 |
brlcad |
only see a
dozen or so files in your log |
| 19:56.57 |
bhinesley |
I must have
different options set. I did a `wc` of lines containing "error" a
couple weeks ago, and there were thousands. |
| 19:57.07 |
bhinesley |
er
"warning" |
| 19:59.31 |
bhinesley |
that's how I
found the 511 warnings that I fixed with r45238 |
| 20:00.02 |
bhinesley |
(all
regarding printf specifiers) |
| 20:03.15 |
bhinesley |
anyways, it
seems that I misunderstood the meaning of strict; I thought that
*all* warnings were treated as errors. When I saw so many warnings,
I assumed that compiling w/ strict was a goal, not a reality. Then
I noticed that people were finding problems with my code a little
too fast >.< |
| 20:06.22 |
brlcad |
yeah, nope ..
you're just ahead of us with your fancy new compilerness
;) |
| 20:06.33 |
bhinesley |
hah |
| 20:06.45 |
brlcad |
suprised
starseeker hadn't hit the issues on gentoo |
| 20:09.06 |
CIA-62 |
BRL-CAD:
03brlcad * r45543 10/brlcad/trunk/src/libbu/crashreport.c: quell
warning on || && logic, wrap latter in parens |
| 20:15.08 |
CIA-62 |
BRL-CAD:
03128.63.32.74 07http://brlcad.org
* r3016 10/wiki/Community_Publication_Portal: stub in ESA SOCIS
announcement |
| 20:19.56 |
CIA-62 |
BRL-CAD:
03brlcad * r45544 10/brlcad/trunk/ (NEWS src/mged/mged.c
src/mged/setup.c): now that the ged struct is fully initialized
during ged_init(), it exposed a bug where code wasn't initializing
the output handler properly after opening a database. this restores
rt command output. |
| 20:47.30 |
brlcad |
starseeker:
the csgbrep bomb is valid -- the arbn block creates an nmgmodel and
tries to pass it forward as an rt_arbn_internal, so it
bombs |
| 20:47.54 |
brlcad |
the magic
check was probably what changed, no idea how it ever would have
worked as it is now |
| 20:48.28 |
brlcad |
csgbrep.cpp:261 is where it goes
wrong |
| 20:52.41 |
CIA-62 |
BRL-CAD:
03brlcad * r45545
10/brlcad/trunk/src/proc-db/csgbrep.cpp: |
| 20:52.41 |
CIA-62 |
BRL-CAD:
looks like this is calling the wrong function table entry. it's
setting an NMG |
| 20:52.41 |
CIA-62 |
BRL-CAD: as
the object pointer, but was trying to call the ARBN functab.
tripped a bomb |
| 20:52.41 |
CIA-62 |
BRL-CAD:
magic detection. calling the NMG converter seems to work in a
better non-crashy |
| 20:52.41 |
CIA-62 |
BRL-CAD:
way. |
| 21:08.42 |
starseeker |
brlcad: ah,
cool - thanks |
| 21:31.14 |
*** join/#brlcad merzo
(~merzo@48-81-132-95.pool.ukrtel.net) |
| 21:31.56 |
CIA-62 |
BRL-CAD:
03kunigami * r45546 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp
liboslrend.h sh_osl.cpp): Added support for setting string
parameters to OSL shaders |
| 21:41.03 |
CIA-62 |
BRL-CAD:
03Intmiti 07http://brlcad.org *
r3017 10/wiki/Videopoker_is_definately_the_best_casino_games: New
page: look for for online casinos on [http://www.google.com
Google] |
| 21:41.55 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 22:03.48 |
CIA-62 |
BRL-CAD:
03bhinesley * r45547 10/brlcad/trunk/src/libged/edit.c: change a
labeled block to a private function |
| 22:27.16 |
*** join/#brlcad merzo
(~merzo@48-81-132-95.pool.ukrtel.net) |
| 22:48.17 |
CIA-62 |
BRL-CAD:
03Antlipi 07http://www.solidgeometry.org *
r3018
10/wiki/Blackjack_is_without_any_doubts_the_best_casino_games: New
page: look for for ambling on [http://www.google.com
Google] |
| 23:14.21 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Antlipi]] with an expiry
time of infinite (account creation disabled, e-mail blocked):
Spamming links to external sites |
| 23:14.24 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Blackjack is without any
doubts the best casino games]]": content was: 'look for for ambling
on [http://www.google.com
Google]' (and the only contributor was
'[[Special:Contributions/Antlipi|Antlipi]]') |
| 23:14.28 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Intmiti]] with an expiry
time of infinite (account creation disabled, e-mail blocked):
Spamming links to external sites |
| 23:14.33 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Videopoker is definately the
best casino games]]": content was: 'look for for online casinos on
[http://www.google.com Google]'
(and the only contributor was
'[[Special:Contributions/Intmiti|Intmiti]]') |
| 23:24.26 |
CIA-62 |
BRL-CAD:
03kunigami * r45548 10/brlcad/trunk/src/other/osl/shaders/
(converter.osl sh_texture.osl): texture shader. this one was pretty
straightforward since there's already an implemented internal
function |
| 23:25.09 |
kunigami_ |
Testing the
texture shader: http://dl.dropbox.com/u/1399996/GSoC/osl_texture.png |
| 23:39.04 |
brlcad |
heh,
nifty |
| 23:39.22 |
brlcad |
what happened
to the light source, though? |
| 23:40.26 |
brlcad |
illuminating
the left corner but not the right just from the reflective box? if
so, seems like there's some energy loss (I'd expect it to be
brighter given previous images) |
| 23:51.14 |
kunigami_ |
brlcad: in
previous images I was multiplying the colors by a factor of 2 or 3
because the scene was too dark. Now I'm just using a very very
bright light. I'm not sure if that's the cause of
difference |
| 23:51.30 |
brlcad |
kunigami_: so
you mentioned earlier that you have to hypersample 1000 times ..
that just sounds wrong for many reasons.. how is hypersampling
being used? |
| 23:53.01 |
kunigami_ |
the image
above was hypersamples 1000 times too. I'm just using -H 1000
-J3 |
| 23:53.13 |
brlcad |
should work
without any hypersampling, just perhaps not as well converged
global light (e.g., corners not quite as dark as they should
be) |
| 23:53.25 |
brlcad |
right, but ..
why? :) |
| 23:53.38 |
brlcad |
what does non
-H1000 look like? |
| 23:55.22 |
kunigami_ |
brlcad:
http://dl.dropbox.com/u/1399996/GSoC/no-hypersampling.png |
| 23:55.55 |
brlcad |
so can you
explain that? |
| 23:56.43 |
brlcad |
every pixel
has a ray being fired, so why wouldn't they all return a color for
a primary hit? |
| 23:57.07 |
kunigami_ |
the osl
system returns a random reflection direction everytime I make a
query (biased depending on the shader), so it's
necessary |
| 23:57.19 |
``Erik |
-H only
effects the primary ray, didn't the path tracer and photon mapper
twingy did get a HUGE benefit by multiplying secondaries instead of
primaries? |
| 23:57.24 |
kunigami_ |
a large
number of samples so the color converges |
| 23:58.58 |
brlcad |
kunigami_:
returning a random reflection direction sounds like a controllable
parameter though, no? |
| 23:59.41 |
brlcad |
it's the
shader's job to determine whether there is reflection in the first
place |
| 23:59.50 |
kunigami_ |
hm not sure.
I'd have to find out |
| 00:00.23 |
brlcad |
unless you
just happen to be using an osl shader that returns random
reflections |
| 00:00.50 |
brlcad |
otherwise, it
sounds like something they's just default to .. but isn't actually
necessary -- should be able to converge much faster |
| 00:01.16 |
brlcad |
otherwise it
sounds like it basically acting like a generalized path
tracer |
| 00:01.28 |
brlcad |
otherwise
;) |
| 00:01.42 |
kunigami_ |
I think it's
a path tracer |
| 00:01.53 |
brlcad |
it is and it
isn't ;) |
| 00:02.02 |
brlcad |
isn't
supposed to be a generalized shader system |
| 00:02.22 |
brlcad |
meaning you
could use it as a path tracer or not |
| 00:02.42 |
kunigami_ |
hmm makes
sense |
| 00:02.42 |
brlcad |
perhaps it
just defaults to path tracing |
| 00:02.55 |
``Erik |
accidental
negative? it IS supposed to be generalized, no? so'z it can be path
trace, radiosity, phong, etc |
| 00:03.26 |
brlcad |
"isn't it
supposed to be" |
| 00:04.06 |
brlcad |
or
s/isn't/it's/ :) |
| 00:04.06 |
``Erik |
ah, s/t/ t
it/;s/$/?/ |
| 00:04.34 |
kunigami_ |
the thing is
that I based my code in a example and maybe there it was
implementing a path tracer |
| 00:05.00 |
kunigami_ |
I wasn't
aware that this could be just a "mode" |
| 00:05.07 |
``Erik |
kunigami:
sounds so, is there a basic phong OSL script you can slap in there?
that'd be a lot quicker on the tests and be a pretty close relative
to the current 'default' of rt |
| 00:05.13 |
brlcad |
so then we
(you) have some homework to figure out ;) |
| 00:06.04 |
``Erik |
would think pixdiffs of the current C phong/plastic vs the
OSL phong would be interesting |
| 00:06.23 |
brlcad |
for starters,
making sure you're working with rt from here forward, not a
standalone so we make sure the integration migrations towards
something production usable, even if it's the path
tracer |
| 00:06.40 |
brlcad |
I don't think
OSL ships phong by default |
| 00:07.22 |
``Erik |
any guess on
how difficult it'd be to write? I'd hope trivial... |
| 00:08.01 |
brlcad |
hm, mildly
related discussion:
http://groups.google.com/group/osl-dev/browse_thread/thread/3350532577b3f8b7/657b1956e545b5ba?lnk=raot |
| 00:08.30 |
kunigami_ |
I think
there's a implementation of a phong shader, but if I remember well,
it wasn't much different from the diffuse |
| 00:08.39 |
kunigami_ |
let me try
here |
| 00:09.52 |
brlcad |
hates it when he searches for some topic like this and the
top hits are our own irc log discussions |
| 00:10.35 |
brlcad |
so phong() is
an OSL function |
| 00:10.45 |
brlcad |
along with
cooktorrance() |
| 00:10.52 |
brlcad |
and a few
others |
| 00:11.23 |
``Erik |
ok, so we do
have the theoretical opportunity for a 1:1 comparison of our own
shader system vs osl |
| 00:11.57 |
brlcad |
still unclear
how you drive the phong reflectance/specular rays |
| 00:13.10 |
``Erik |
if push comes
to shove, we SHOULD be able to re-implement our interpretation in
osl, I'd hope? |
| 00:13.30 |
brlcad |
it's not
that |
| 00:13.39 |
brlcad |
librt is
still the one shooting rays and managing geometry |
| 00:13.55 |
brlcad |
so librt
fires, hits an osl surface, calls into osl to figure out what to
do |
| 00:14.01 |
``Erik |
*shrug*
either way, hasta luego, see ya'll tomorrie :) |
| 00:14.15 |
brlcad |
then it needs
to fire more rays .. how it does that isn't clear to me |
| 00:15.41 |
brlcad |
this should
be like a "chapter 1" or intro-to-osl detail spelled out
somewhere |
| 00:18.28 |
brlcad |
aha, language
spec talks about it somem |
| 00:19.04 |
brlcad |
"Effects that
would ordinarily require explicit ray tracing, such as reflection
and refraction, are simply part of the radiance closure and look
like any other BSDF |
| 00:21.07 |
brlcad |
mm, getting
the gist |
| 00:21.11 |
brlcad |
kunigami_: so
I'll have to read through this some more tonight, but I think the
first step is to not gang off the -H option since that fires
multiple primary rays ... |
| 00:23.21 |
brlcad |
very
expensive |
| 00:23.28 |
brlcad |
do something
trivial like getenv(LIBRT_OSL_SAMPLES) instead of a command line
option and use that parameter to toggle how many internal osl
samples it needs to acquire per ray |
| 00:24.27 |
brlcad |
should shave
massive amounts of time since it doesn't need to rewalk the spatial
partitioning, and still give the same resulting picture |
| 00:25.17 |
kunigami_ |
ah I was just
asking that. ok, so going back to my first implemented
hypersampling |
| 00:25.34 |
brlcad |
we can tie it
to command-line options later if it all gets working
cleanly |
| 00:25.52 |
brlcad |
it
*shouldn't* need to re-call rt_shootray() |
| 00:26.08 |
brlcad |
the ray hit
is the same for 1 sample as it was for 1 million |
| 00:56.40 |
CIA-62 |
BRL-CAD:
03kunigami * r45549
10/brlcad/trunk/src/liboptical/sh_osl.cpp: |
| 00:56.40 |
CIA-62 |
BRL-CAD:
added back hypersampling right on sh_osl instead of using the -H
parameter. It's |
| 00:56.40 |
CIA-62 |
BRL-CAD: much
less expensive since we dont need to re-calculate the hit point
which, in |
| 00:56.40 |
CIA-62 |
BRL-CAD: the
end, will be the same for all samples. It reads the number of
samples from |
| 00:56.40 |
CIA-62 |
BRL-CAD: an
environment variable, which is better than having a hardcoded
value |
| 01:31.05 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.132.140) |
| 01:37.19 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 01:42.45 |
brlcad |
kunigami_:
there are several items in your nsamples loop there that do not
change across loop iterations -- should pull them out so they're
only computed once |
| 02:01.29 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.152.125) |
| 02:06.32 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 02:11.35 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.148.37) |
| 03:03.39 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.149.58) |
| 03:03.39 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 03:07.41 |
CIA-62 |
BRL-CAD:
03bhinesley * r45550 10/brlcad/trunk/src/libged/edit.c: |
| 03:07.41 |
CIA-62 |
BRL-CAD: Cut
down on a lot of duplication. Fixed a few issues with subcmd arg
helper |
| 03:07.41 |
CIA-62 |
BRL-CAD:
functions (and most are enabled/used now). ged_edit() generic
subcommand |
| 03:07.41 |
CIA-62 |
BRL-CAD:
argument parsing is nearly done. Still a WIP. Some option
combinations are |
| 03:07.41 |
CIA-62 |
BRL-CAD:
accepted that shouldn't be. It is crashing right now, too. That is
to be |
| 03:07.42 |
CIA-62 |
BRL-CAD:
expected, as it needs edit_str_to_arg() to work properly, and that
is |
| 03:07.43 |
CIA-62 |
BRL-CAD:
incomplete/needs some modifications. |
| 03:18.01 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.193) |
| 03:18.01 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 03:34.20 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.157.12) |
| 03:55.43 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.18.126) |
| 03:55.43 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 04:00.42 |
*** join/#brlcad Stattrav_
(~Stattrav@117.202.16.214) |
| 04:05.44 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 04:25.44 |
*** join/#brlcad Stattrav_
(~Stattrav@117.202.23.44) |
| 04:37.55 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.24.28) |
| 04:37.55 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 04:55.29 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.156.5) |
| 04:55.29 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:00.28 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.146.128) |
| 05:05.26 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.28.81) |
| 05:05.27 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:16.45 |
*** join/#brlcad Stattrav_
(~Stattrav@117.202.22.242) |
| 05:24.24 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded a new version of
"[[Image:Industry Diagram.pdf]]": Fifth revision of the BRL-CAD
Industry Diagram. |
| 05:27.32 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.159.51) |
| 05:27.33 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 05:29.15 |
brlcad |
starseeker:
care to try another attempt at converting the diagram to an open
format? :) |
| 05:30.05 |
brlcad |
been a few
years, better fonts, hopefully better rendering |
| 05:31.10 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 05:31.18 |
yukonbob |
hello,
#brlcad :) |
| 05:33.12 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.154.48) |
| 05:43.41 |
brlcad |
howdy |
| 05:52.57 |
yukonbob |
hai |
| 05:53.22 |
yukonbob |
how're
things? |
| 06:47.55 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.128.91) |
| 06:47.55 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:00.39 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 07:28.52 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 08:11.31 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 10:23.10 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 10:51.49 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.195.64) |
| 10:51.49 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:33.04 |
*** join/#brlcad SCD101
(~sam@109.77.120.154) |
| 12:33.19 |
SCD101 |
Hey there
:) |
| 12:37.35 |
SCD101 |
Many people
enquired about the ESA SoC? |
| 12:48.06 |
CIA-62 |
BRL-CAD:
03kunigami * r45551 10/brlcad/trunk/src/liboptical/sh_osl.cpp:
moving constant parts out of the loop |
| 12:56.40 |
brlcad |
SCD101: I
think we're up to approximately 482 |
| 12:57.06 |
SCD101 |
482 for just
your projects? Wow |
| 12:58.04 |
brlcad |
SCD101: heh,
if you believe that, I have a bridge to sell you |
| 12:58.36 |
SCD101 |
Well
considering there are 20 places in total over all of the
organisations :P |
| 12:58.47 |
SCD101 |
How many
really? :L |
| 12:59.10 |
SCD101 |
Also, how big
is the bridge? |
| 12:59.15 |
SCD101 |
:P |
| 12:59.16 |
brlcad |
it's a
wonderful bridge, connecting reality with Mr. Roger's
Neighborhood |
| 12:59.32 |
brlcad |
just a
couple |
| 13:00.24 |
brlcad |
20 orgs, but
the program isn't exceptionally well known, only affects EU
students, and is for students with an interest in a niche domain
(space) |
| 13:00.30 |
SCD101 |
Ah cool. I
only know C and am doing GSoC atm. Would I need experience with
BRL-CAD or is it only needed for some of the projects? |
| 13:18.02 |
brlcad |
shouldn't
matter for most projects, you's learn what you need as you
go |
| 13:18.50 |
brlcad |
you don't
need experience with BRL-CAD, but you should be able to read and
comprehend existing source code quickly so anything you work on is
properly integrated |
| 13:19.26 |
brlcad |
none of the
projects are stand alone, work-off-in-a-corner tasks |
| 13:19.54 |
brlcad |
they're all
intended to be fully integrated so that when you're done, you've
improved BRL-CAD in some fashion |
| 13:33.21 |
SCD101 |
brlcad, I'm
currently working on dpkg for Debian. So I've gotten some good
experience with large codebases. However I do hope our codebase has
more comments than dpkg :P |
| 13:36.12 |
brlcad |
at more than
1M lines, you'll find some parts are extensively commented,
beautiful lush examples, along with entire continents of code
without comments |
| 13:36.34 |
brlcad |
so it depends
where you're working, but there are plenty of devs to help you
along |
| 13:36.58 |
SCD101 |
Ok that's
good :) |
| 13:37.21 |
SCD101 |
And all of
the projects are open for submission? I only ask because there can
only be one can't there? :P |
| 13:38.46 |
brlcad |
not sure what
you mean |
| 13:39.02 |
brlcad |
you propose
the project |
| 13:39.05 |
brlcad |
we just
suggest ideas |
| 13:39.37 |
SCD101 |
Nvm got
confused :L |
| 13:41.04 |
SCD101 |
I'm liking
the look of this bending light idea :P |
| 13:41.39 |
SCD101 |
AH you use
svn |
| 13:47.51 |
SCD101 |
Ok I really
like the code layout. Looks nice to work with |
| 15:55.38 |
*** join/#brlcad SCD101
(~sam@109.77.120.154) |
| 16:04.49 |
brlcad |
if you have
any questions, this is usually the place (or the mailing
list) |
| 17:00.04 |
kunigami_ |
it seems osl
shaders have functions named eval_reflect and eval_transmit which
must be fed with the view direction and the lighting direction and
they return the color |
| 17:05.50 |
kunigami_ |
hmm so we
need to consider the contribution of each light source and get a
color? |
| 17:07.21 |
kunigami_ |
then, if
there's reflection/refraction to be done, we compute the
directions? |
| 17:45.11 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 18:15.10 |
*** join/#brlcad merzo
(~merzo@142-55-132-95.pool.ukrtel.net) |
| 18:30.17 |
CIA-62 |
BRL-CAD:
03bhinesley * r45552 10/brlcad/trunk/src/libged/edit.c: oops;
db_free_full_path() doesn't free bu_malloc'd space for the
db_full_path struct itself, so it must be done
manually. |
| 18:39.26 |
CIA-62 |
BRL-CAD:
03bob1961 * r45553 10/brlcad/trunk/src/tclscripts/mged/openw.tcl:
This fixes the failed browser launch on windows. |
| 18:56.40 |
CIA-62 |
BRL-CAD:
03brlcad * r45554 10/brlcad/trunk/NEWS: bob fixed a bug in mged
where the browser wasn't getting set properly so the browser
wouldn't launch. needed to set mged_browser var but was only
setting (web_browser) |
| 19:05.57 |
brlcad |
kunigami_: so
my reading through the osl intro last night, it does change a few
notions I had of their system |
| 19:06.40 |
brlcad |
they are
geared towards solving global illumination, which doesn't
necessarily mean path tracing, but it does mean that they're not
set up for traditional phong-style ray tracing |
| 19:07.33 |
kunigami_ |
does global
illumination imples multiple samples? |
| 19:07.37 |
brlcad |
actually,
their docs seemed a little self-contradicting saying they didn't
implement phong-style semantics for a shader but then continue to
list a phong function as a possible shader evaluation
routine |
| 19:07.37 |
kunigami_ |
implies* |
| 19:07.51 |
brlcad |
yes and
no |
| 19:08.06 |
brlcad |
osl evaluates
closures |
| 19:08.27 |
brlcad |
so you can
think of every pixel as representing a complex polynomial
equation |
| 19:08.57 |
brlcad |
if solves the
equation as far as it can parametrically, then uses the starting
view/ray information to solve the remainder |
| 19:09.08 |
brlcad |
so in theory,
they precompute a lot more than you would otherwise |
| 19:10.28 |
brlcad |
e.g., if you
had a lot of reflective shiny surfaces, bright lights but then had
a "black-hole sphere" in that scene, then the closure for the
pixels of the sphere reduce to .. nothing, black, and there is no
need to sample, reshoot, etc |
| 19:10.51 |
brlcad |
it's not just
"absorbed", it figured out that the equation reduced |
| 19:13.16 |
kunigami_ |
I made two
renders using their phong function. one using exponent = 0 and the
other exponent = 1. |
| 19:13.18 |
brlcad |
so not
calling -Hbig_number and having any OSL-samples happen internally
was a better direction |
| 19:15.13 |
kunigami_ |
exp = 0
http://dl.dropbox.com/u/1399996/GSoC/green-phong-e0.png |
| 19:15.24 |
kunigami_ |
exp = 1
http://dl.dropbox.com/u/1399996/GSoC/green-phong-e1.png |
| 19:17.27 |
brlcad |
mm, too noisy
to tell what is going on there |
| 19:20.23 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 19:20.30 |
*** part/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 19:20.34 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 19:26.14 |
brlcad |
kunigami_:
did you see a performance difference between shooting with -H and
since you refactored out the common code from the loop you
readded? |
| 19:27.03 |
kunigami_ |
didn't
measured. Let me do some tests |
| 19:27.27 |
brlcad |
would have
expected it to be noticeable |
| 19:32.47 |
kunigami_ |
I was
wondering if it's desirable to have another incremental mode view
for such shaders. At each sample the framebuffer is updated so the
image begins noisy and converges to a noise-free one |
| 20:20.08 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45555 10/brlcad/trunk/ (include/bu.h
src/libbu/simd.c): add support for SSE3, SSE4_1 and SSE4_2. Add a
bu_simd_supported function. Minor cleanup and clobberage
fixes |
| 20:25.19 |
CIA-62 |
BRL-CAD:
03r_weiss * r45556
10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: (log message
trimmed) |
| 20:25.19 |
CIA-62 |
BRL-CAD:
Updated function nmg_class_pt_s within file nmg_class.c. This
change supports |
| 20:25.19 |
CIA-62 |
BRL-CAD: the
prototype version of the nmg_triangulate_fu function. Within
function |
| 20:25.19 |
CIA-62 |
BRL-CAD:
nmg_class_pt_s it uses the raytracer to classify if a point is in,
out or on a |
| 20:25.19 |
CIA-62 |
BRL-CAD:
shell. During the computations of determining this, line
intersection functions |
| 20:25.20 |
CIA-62 |
BRL-CAD: are
used where some require finite line segments. To help resolve some
of the |
| 20:25.21 |
CIA-62 |
BRL-CAD:
computation problems I added a magnitude to the ray direction
vector instead of |
| 20:52.34 |
*** join/#brlcad tharis20
(~tharis@bl21-44-216.dsl.telepac.pt) |
| 21:21.23 |
tharis20 |
hi, I'm
Francisco from Portugal and I'm applying to SOCIS |
| 21:21.56 |
tharis20 |
I don't know
what else I should mention, for now I'm just reading and following
the checklist |
| 21:23.32 |
kunigami_ |
brlcad:
running with -H 100 and 1 sample per pixel, took 910s. with -H 1
and 100 samples per pixel, took 713s. |
| 21:29.51 |
CIA-62 |
BRL-CAD:
03Kunigami 07http://brlcad.org *
r3020 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ added
reports for week 9 |
| 21:31.33 |
CIA-62 |
BRL-CAD:
03Kunigami 07http://brlcad.org *
r3021 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 9 (July 18th
to July 25) */ added more info to week 9 |
| 21:50.20 |
brlcad |
tharis20:
welcome and thanks! |
| 21:50.26 |
brlcad |
kunigami_:
iiiinteresting |
| 21:50.49 |
brlcad |
I would have
expected more of an increase frankly, but maybe osl is just
dominating more than I thought |
| 21:51.32 |
tharis20 |
brlcad: to
run archer do I need to compile brlcad with opengl? |
| 21:52.18 |
brlcad |
kunigami_: so
now is oslr->QueryColor() deterministic? does it return the
same color every time for a given info? |
| 21:52.25 |
brlcad |
tharis20:
yep |
| 21:52.36 |
brlcad |
otherwise,
you can use 'mged' |
| 21:52.54 |
tharis20 |
I know, but I
wanted to run archer to see the differences |
| 21:53.11 |
kunigami_ |
brlcad: no, I
still don't know how to use eval_reflect / transmit
correcly. |
| 21:53.43 |
tharis20 |
OpenGL is
supposed to be shipped with OSX, but I'm getting an error compiling
brlcad with it... I'll see if I can fix it, otherwise, I'll ask
someone for help |
| 21:54.16 |
brlcad |
tharis20: it
is shipped with osx -- how are you compiling? |
| 21:54.30 |
brlcad |
tharis20:
give the cmake build a try, you'll need to install
cmake |
| 21:55.19 |
tharis20 |
I have cmake
installed, but I was using autotools |
| 21:55.27 |
tharis20 |
I'll give it
a shot then |
| 21:56.27 |
brlcad |
otherwise,
you can paste an error snippet and usually someone will respond
within a while |
| 21:56.40 |
tharis20 |
sure ;) thank
you |
| 22:13.26 |
*** join/#brlcad dtidrow_desk
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 22:14.06 |
*** join/#brlcad SCD101
(~sam@109.77.120.154) |
| 22:14.07 |
tharis20 |
... |
| 22:52.22 |
tharis20 |
woot 37
minutes, 8 seconds |
| 22:57.59 |
``Erik |
for the
compile? single core slower machine? o.O nfs over 14.4k modem?
:D |
| 22:59.27 |
bhinesley |
waits about that long for a clean build on a Core 2 6600 @
2.4Ghz |
| 23:00.34 |
*** join/#brlcad SCD101
(~sam@109.77.120.154) |
| 23:13.13 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 23:13.20 |
abhi2011 |
hi |
| 23:15.09 |
abhi2011 |
I am trying
to write a basic plugin for BRLCAD |
| 23:15.30 |
abhi2011 |
Is there any
tutorial similar to http://brlcad.org/wiki/Developing_applications
for plugins ? |
| 23:17.10 |
tharis20 |
``Erik: yes,
for the compile |
| 23:30.08 |
CIA-62 |
BRL-CAD:
03r_weiss * r45557
10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: (log
message trimmed) |
| 23:30.08 |
CIA-62 |
BRL-CAD:
Updated functions vertex_neighborhood,
get_pole_dist_to_face, |
| 23:30.08 |
CIA-62 |
BRL-CAD:
guess_class_from_hitlist_min,
guess_class_from_hitlist_max, |
| 23:30.08 |
CIA-62 |
BRL-CAD:
isect_ray_snurb_face, record_face_hit, edge_hit_ray_state,
ray_hit_vertex, |
| 23:30.08 |
CIA-62 |
BRL-CAD:
nmg_class_ray_vs_shell within file nmg_rt_isect.c. Many changes are
to support |
| 23:30.09 |
CIA-62 |
BRL-CAD: the
prototype version of nmg_triangulate_fu. The changes associated
with this |
| 23:30.10 |
CIA-62 |
BRL-CAD:
prototype are disabled by default. The prototype related changes
create a |
| 23:37.15 |
kunigami_ |
To evaluate
the contribution of light sources, I'll have to find the light
directions for every query point and also if this light is visible
or not. For now, I'll just use BRL-CAD lights because this
information is already computed |
| 23:58.28 |
kunigami_ |
Seems there's
a bug on sh_toon shader. Currently it is : cosi =
VDOT(swp->sw_hit.hit_normal, swp->sw_tolight); |
| 23:58.30 |
CIA-62 |
BRL-CAD:
03r_weiss * r45558 10/brlcad/trunk/src/libbn/plane.c: |
| 23:58.30 |
CIA-62 |
BRL-CAD:
Updated the protoype function bn_isect_line3_line3_new within file
plane.c which |
| 23:58.30 |
CIA-62 |
BRL-CAD:
supports the prototype function nmg_triangulate_fu. These changed
are disabled |
| 23:58.30 |
CIA-62 |
BRL-CAD: by
default. Performed code cleanup and improved some of the logic.
More cleanup |
| 23:58.30 |
CIA-62 |
BRL-CAD: is
needed. This is a work in progress. |
| 23:59.41 |
kunigami_ |
but since
we're iterating on lights, I think it should be: cosi =
VDOT(swp->sw_hit.hit_normal, &sh_swp->sw_tolight +
3*i); |
| 00:01.09 |
kunigami_ |
If anyone
confirm that I'll change it |
| 00:03.16 |
kunigami_ |
oops ignore
the operator & there |
| 00:22.42 |
brlcad |
abhi2011:
wanting to "write a basic plugin" can mean many many things to a
package as large as brl-cad |
| 00:23.06 |
abhi2011 |
ok |
| 00:23.29 |
brlcad |
could be new
object type, new shaders, new commands, new tools, ... |
| 00:23.31 |
abhi2011 |
so I am
trying to learn how to compile plugins |
| 00:23.41 |
abhi2011 |
i just want
to print something |
| 00:23.48 |
abhi2011 |
on the
console and exit |
| 00:23.55 |
brlcad |
from
what? |
| 00:24.13 |
abhi2011 |
from inside
the plugin |
| 00:24.19 |
abhi2011 |
this is for
the physics engine |
| 00:24.22 |
brlcad |
still, a
plugin to *what* :) |
| 00:24.33 |
abhi2011 |
we were
discussing in the mailing list |
| 00:24.35 |
brlcad |
brl-cad is a
suite of applications |
| 00:24.49 |
brlcad |
okay, so
probably a new command |
| 00:24.54 |
abhi2011 |
yes |
| 00:24.58 |
brlcad |
commands go
into libged |
| 00:25.06 |
abhi2011 |
so something
like ged_physics() |
| 00:25.46 |
bhinesley |
src/libged/zap.c is a small
example |
| 00:26.57 |
abhi2011 |
1 sec i ll
ok |
| 00:27.05 |
bhinesley |
or
version.c |
| 00:27.10 |
abhi2011 |
ok |
| 00:27.14 |
brlcad |
yeah, there
are about 400 examples in there |
| 00:27.30 |
abhi2011 |
ok....is
there any doc which discusses how to compile the plugin |
| 00:27.39 |
abhi2011 |
that is after
i have setup the tcl code and c code |
| 00:27.48 |
brlcad |
add them to
src/mged/setup.c and you'll have it available in mged |
| 00:27.59 |
abhi2011 |
ah
ok |
| 00:28.08 |
abhi2011 |
well i
actually wanted to make a plugin for archer |
| 00:28.47 |
abhi2011 |
the plugin
will allow simple physics ultmately |
| 00:28.48 |
brlcad |
adding to
archer is a bit more involved, save that for later |
| 00:28.57 |
abhi2011 |
ok |
| 00:29.11 |
brlcad |
it's easy,
but that's code that's in flux, so no need to waste
time |
| 00:29.37 |
abhi2011 |
so to compile
the code I guess something like : cc -I/usr/brlcad/include/brlcad
-L/usr/brlcad/lib -o rtexample rtexample.c -lbu -lrt
-lm |
| 00:29.42 |
brlcad |
if a new
physics command does what you're proposing it will do, then can
look into archer hooks |
| 00:29.43 |
abhi2011 |
should do
? |
| 00:30.06 |
brlcad |
you could do
that, assumes a brl-cad install but better would be to add it to
the build logic |
| 00:30.23 |
abhi2011 |
ok |
| 00:30.34 |
brlcad |
if you're
doing an autotools compile, you edit the Makefile.am; or if you're
doing a cmake compile, it's the CMakeLists.txt file |
| 00:30.37 |
brlcad |
then just
make |
| 00:30.48 |
abhi2011 |
ok |
| 00:30.59 |
brlcad |
(after
running autogen.sh or cmake or configure, depends on which build
system you use and your platform) |
| 00:31.08 |
brlcad |
INSTALL and
INSTALL.cmake have details |
| 00:31.16 |
abhi2011 |
ok |
| 00:31.54 |
abhi2011 |
by the way I
was trying out the example from http://brlcad.org/w/images/3/3d/Application_Development.pdf |
| 00:32.04 |
abhi2011 |
the
rtexample.c file |
| 00:32.06 |
brlcad |
kunigami_:
good find if it is the bug, but I'm not familiar with that shader
-- ``Erik wrote it |
| 00:32.15 |
abhi2011 |
if i compile
using cc -I/usr/brlcad/include/brlcad -L/usr/brlcad/lib -o
rtexample rtexample.c -lbu -lrt -lm |
| 00:32.16 |
brlcad |
abhi2011:
yes? |
| 00:32.20 |
abhi2011 |
then i
get |
| 00:32.37 |
abhi2011 |
no bio.h
file |
| 00:32.57 |
brlcad |
need to also
include /usr/brlcad/include |
| 00:33.00 |
abhi2011 |
and this
header is indeed not present in /usr/include/brlcad |
| 00:33.33 |
abhi2011 |
ah
ok |
| 00:33.43 |
brlcad |
actually,
you're right |
| 00:33.50 |
brlcad |
bio.h is
considered a private header |
| 00:34.06 |
abhi2011 |
yah |
| 00:34.11 |
abhi2011 |
i dont c it
there either |
| 00:34.26 |
abhi2011 |
in
/usr/brlcad/include i mean |
| 00:34.46 |
abhi2011 |
there is a
file called fbio.h |
| 00:35.01 |
abhi2011 |
in
/usr/brlcad/include/brlcad |
| 00:35.19 |
abhi2011 |
i popped that
in instead :P |
| 00:35.51 |
CIA-62 |
BRL-CAD:
03brlcad * r45559 10/brlcad/trunk/src/rt/rtexample.c: doesn't seem
to be a real need for bio.h here. remove it since this is an
example application meant to compile outside brl-cad's build
system. thx abhi2011 for the catch. |
| 00:36.15 |
abhi2011 |
ok |
| 00:36.18 |
abhi2011 |
np |
| 00:36.40 |
brlcad |
technically,
http://brlcad.org/w/images/3/3d/Application_Development.pdf
doesn't reference bio.h ;) |
| 00:36.57 |
abhi2011 |
ah
ok |
| 00:37.09 |
abhi2011 |
well no tcl.h
now |
| 00:37.21 |
abhi2011 |
[abhi@abhi
rt]$ cc -I/usr/brlcad/include/brlcad -L/usr/brlcad/lib -o rtexample
rtexample.c -lbu -lrt -lm |
| 00:37.22 |
abhi2011 |
In file
included from /usr/brlcad/include/brlcad/vmath.h:85:0, |
| 00:37.24 |
abhi2011 |
<PROTECTED> |
| 00:37.25 |
abhi2011 |
/usr/brlcad/include/brlcad/bu.h:216:58:
fatal error: tcl.h: No such file or directory |
| 00:37.27 |
abhi2011 |
compilation
terminated. |
| 00:37.51 |
brlcad |
that's system
dependent |
| 00:37.58 |
abhi2011 |
ah ok got
it |
| 00:38.00 |
brlcad |
either in
/usr/brlcad/include or somewhere else on your system |
| 00:38.06 |
abhi2011 |
yes
right |
| 00:38.09 |
abhi2011 |
will put it
in |
| 00:38.11 |
brlcad |
that compile
line is just supposed to be notional, no way to make it work for
everyone |
| 00:38.20 |
abhi2011 |
right |
| 00:49.20 |
abhi2011 |
ok got
rtexample.c compiled with cc -I/usr/brlcad/include/brlcad
-I/usr/brlcad/include-L/usr/brlcad/lib -o rtexample rtexample.c
-lbu -lrt -lm |
| 00:49.58 |
abhi2011 |
now there is
a shared library error with brlcad utility library |
| 00:50.01 |
abhi2011 |
[abhi@abhi
rt]$ ./rtexample sphere.g sph1.s |
| 00:50.03 |
abhi2011 |
./rtexample:
error while loading shared libraries: libbu.so.19: cannot open
shared object file: No such file or directory |
| 00:51.03 |
abhi2011 |
perhaps its
not looking in /usr/brlcad/lib |
| 00:51.17 |
abhi2011 |
where i can
see the library is present |
| 00:52.29 |
abhi2011 |
hmm....I have
given the lib path correctly during compiling though |
| 00:59.35 |
abhi2011 |
probably load
library path |
| 00:59.51 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.137.87) |
| 00:59.51 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 01:03.02 |
kunigami_ |
abhi2011:
which OS? |
| 01:03.11 |
abhi2011 |
right finally
got rtexample working |
| 01:03.16 |
brlcad |
your example
line has a typo, before the -L |
| 01:03.18 |
abhi2011 |
fedora
15 |
| 01:03.26 |
brlcad |
(no
space) |
| 01:03.48 |
abhi2011 |
yes i
corrected that |
| 01:04.25 |
abhi2011 |
the
$LD_LIBRARY_PATH was not pointing to /usr/brlcad/lib |
| 01:04.36 |
abhi2011 |
i put that in
, now it runs |
| 01:04.53 |
brlcad |
not
particularly relevant for implementing a physics engine command,
but here's a similar example that shows one of the interfaces for
creating procedural geometry:
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/proc-db/wdb_example.c?revision=45559&view=markup |
| 01:05.07 |
brlcad |
LD_LIBRARY_PATH shouldn't need to point to
/usr/brlcad/lib |
| 01:05.13 |
brlcad |
unless you
already had is set |
| 01:05.49 |
brlcad |
LD_LIBRARY_PATH overrides whatever the
binary was compiled to look in, if it was set then the solution was
probably to just unset it |
| 01:06.03 |
brlcad |
unless you
have it set due to other apps or something like that |
| 01:06.07 |
abhi2011 |
well ok i ll
try unsetting it |
| 01:06.13 |
abhi2011 |
it was blank
before |
| 01:06.23 |
brlcad |
set or
blank? |
| 01:06.31 |
brlcad |
er, unset or
blank? |
| 01:06.41 |
brlcad |
empty is not
the same as unset |
| 01:06.49 |
abhi2011 |
it was
blank...but the program was complaining when it was
blank |
| 01:07.12 |
abhi2011 |
hmm....it was
printing a blank line when i echoed it |
| 01:07.45 |
brlcad |
so what are
you studying? |
| 01:08.06 |
abhi2011 |
i am doing
computer engineering |
| 01:08.17 |
brlcad |
undergrad or
grad? |
| 01:08.22 |
abhi2011 |
grad |
| 01:08.39 |
abhi2011 |
you are
studying as well ? |
| 01:08.52 |
brlcad |
always
;) |
| 01:08.58 |
abhi2011 |
hehe |
| 01:09.00 |
brlcad |
but not in a
university setting any more |
| 01:09.07 |
abhi2011 |
ok |
| 01:09.17 |
abhi2011 |
hmm..same
error again |
| 01:09.29 |
abhi2011 |
./rtexample:
error while loading shared libraries: libbu.so.19: cannot open
shared object file: No such file or directory |
| 01:10.00 |
abhi2011 |
but i think
the gcc linker will link it in as a static library |
| 01:10.16 |
brlcad |
ldd
rtexample |
| 01:10.26 |
abhi2011 |
yep abt to do
tht |
| 01:10.47 |
abhi2011 |
hmm |
| 01:10.52 |
abhi2011 |
[abhi@abhi
rt]$ ldd rtexample |
| 01:10.52 |
brlcad |
there's no
reason it shouldn't work non-static and without LD_LIBRARY_PATH
set |
| 01:10.53 |
abhi2011 |
linux-gate.so.1 =>
(0x00339000) |
| 01:10.56 |
abhi2011 |
libbu.so.19
=> not found |
| 01:10.57 |
abhi2011 |
librt.so.19
=> not found |
| 01:10.58 |
abhi2011 |
libm.so.6
=> /lib/libm.so.6 (0x4d18c000) |
| 01:11.00 |
abhi2011 |
libc.so.6
=> /lib/libc.so.6 (0x4cfd1000) |
| 01:11.02 |
abhi2011 |
/lib/ld-linux.so.2
(0x4cfb0000) |
| 01:11.54 |
brlcad |
what does it
report if you just run this: cc -I/usr/brlcad/include/brlcad
-I/usr/brlcad/include -L/usr/brlcad/lib -o rtexample
rtexample.c |
| 01:12.51 |
abhi2011 |
lots of
undefined references |
| 01:13.08 |
abhi2011 |
[abhi@abhi
rt]$ cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include
-L/usr/brlcad/lib -o rtexample rtexample.c |
| 01:13.10 |
abhi2011 |
/tmp/cchQUtho.o: In function
`hit': |
| 01:13.12 |
abhi2011 |
rtexample.c:(.text+0x58): undefined
reference to `bu_log' |
| 01:13.13 |
abhi2011 |
rtexample.c:(.text+0x133): undefined
reference to `bu_badmagic' |
| 01:13.15 |
abhi2011 |
rtexample.c:(.text+0x1a8): undefined
reference to `bu_badmagic' |
| 01:13.17 |
abhi2011 |
rtexample.c:(.text+0x226): undefined
reference to `bu_badmagic' |
| 01:13.18 |
abhi2011 |
..... |
| 01:14.04 |
abhi2011 |
hmm the -L
flag should be enough to specify the library path |
| 01:14.06 |
brlcad |
so then: cc
-I/usr/brlcad/include/brlcad -I/usr/brlcad/include
-L/usr/brlcad/lib -o rtexample rtexample.c -lrt -lbu
-lm |
| 01:15.04 |
abhi2011 |
that command
compiles successfully |
| 01:15.22 |
brlcad |
but then ldd
still says not found? |
| 01:15.31 |
abhi2011 |
yep |
| 01:15.33 |
abhi2011 |
[abhi@abhi
rt]$ cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include
-L/usr/brlcad/lib -o rtexample rtexample.c -lrt -lbu
-lm |
| 01:15.35 |
abhi2011 |
[abhi@abhi
rt]$ ldd rtexample |
| 01:15.37 |
abhi2011 |
linux-gate.so.1 =>
(0x00b43000) |
| 01:15.38 |
abhi2011 |
librt.so.19
=> not found |
| 01:15.40 |
abhi2011 |
libbu.so.19
=> not found |
| 01:15.41 |
abhi2011 |
libm.so.6
=> /lib/libm.so.6 (0x4d18c000) |
| 01:15.43 |
abhi2011 |
libc.so.6
=> /lib/libc.so.6 (0x4cfd1000) |
| 01:15.44 |
abhi2011 |
/lib/ld-linux.so.2
(0x4cfb0000) |
| 01:15.46 |
abhi2011 |
[abhi@abhi
rt]$ |
| 01:15.52 |
brlcad |
then
something with your ld setup doesn't seem standard |
| 01:16.19 |
abhi2011 |
hmm..its a
fresh fedora install |
| 01:16.44 |
brlcad |
set >
file |
| 01:16.50 |
brlcad |
pastebin the
file |
| 01:16.56 |
abhi2011 |
ok |
| 01:17.15 |
brlcad |
cc
--version |
| 01:17.43 |
brlcad |
fwiw, it
doesn't really matter (at least in terms of getting work
done) |
| 01:18.06 |
brlcad |
it's
something particular to either your setup and system or fedora in
general |
| 01:18.16 |
brlcad |
usual
integration is to mod the build system |
| 01:18.26 |
abhi2011 |
ok |
| 01:18.39 |
abhi2011 |
by the
way...what do you mean by paste binning the file |
| 01:18.45 |
abhi2011 |
i ll just
paste it here ? |
| 01:18.48 |
brlcad |
~pastebin |
| 01:18.48 |
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. |
| 01:18.57 |
brlcad |
don't use the
first one |
| 01:19.36 |
abhi2011 |
ok |
| 01:20.33 |
abhi2011 |
http://bin.cakephp.org/view/1242653996 |
| 01:23.12 |
abhi2011 |
[abhi@abhi
rt]$ cc --version |
| 01:23.14 |
abhi2011 |
cc (GCC)
4.6.0 20110530 (Red Hat 4.6.0-9) |
| 01:23.16 |
abhi2011 |
Copyright (C)
2011 Free Software Foundation, Inc. |
| 01:25.27 |
abhi2011 |
dont try to
hack my system :P |
| 01:32.49 |
brlcad |
why would I
bother with that? :P |
| 01:33.07 |
brlcad |
so you DO
have LD_LIBRARY_PATH set to empty |
| 01:33.14 |
brlcad |
try: unset
LD_LIBRARY_PATH |
| 01:33.19 |
brlcad |
then
./rtexample |
| 01:36.14 |
abhi2011 |
haha just
kidding :) |
| 01:36.27 |
abhi2011 |
ok yah i ll
try that |
| 01:38.45 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 01:42.06 |
abhi2011 |
[abhi@abhi
rt]$ unset LD_LIBRARY_PATH |
| 01:42.08 |
abhi2011 |
[abhi@abhi
rt]$ ./rtexample |
| 01:42.10 |
abhi2011 |
./rtexample:
error while loading shared libraries: librt.so.19: cannot open
shared object file: No such file or directory |
| 01:42.12 |
abhi2011 |
[abhi@abhi
rt]$ echo $LD_LIBRARY_PATH |
| 01:42.52 |
abhi2011 |
seems that
its unable to find the library without the library path being
set |
| 01:47.46 |
kunigami_ |
Did you try:
export LD_LIBRARY_PATH=/usr/brlcad/lib ? |
| 01:50.31 |
abhi2011 |
yes that does
work of course |
| 01:50.57 |
abhi2011 |
ok so I am
trying to add a command to Mged |
| 01:51.28 |
abhi2011 |
i copied
src/libged/zap.c to test.c |
| 01:51.37 |
abhi2011 |
and i have
modified it to : |
| 01:52.06 |
abhi2011 |
http://bin.cakephp.org/view/118439282 |
| 01:52.36 |
abhi2011 |
then in
setup.c i added a cmd below the zap command |
| 01:52.47 |
abhi2011 |
<PROTECTED> |
| 01:52.49 |
abhi2011 |
<PROTECTED> |
| 01:52.50 |
abhi2011 |
{"T",
cmd_test, GED_FUNC_PTR_NULL}, |
| 01:52.52 |
abhi2011 |
<PROTECTED> |
| 01:52.55 |
abhi2011 |
the T command
for testing |
| 01:53.17 |
abhi2011 |
now I guess i
need to compile these 2 files |
| 01:53.33 |
abhi2011 |
so do I
compile like I did for rtexample.c ? |
| 01:54.00 |
CIA-62 |
BRL-CAD:
03bhinesley * r45560
10/brlcad/trunk/src/librt/db_fullpath.c: |
| 01:54.00 |
CIA-62 |
BRL-CAD:
db_string_to_path() will trim all leading slashes, but only one
trailing slash; |
| 01:54.00 |
CIA-62 |
BRL-CAD: then
it fails when more than one trailing slash is given. I can think of
no |
| 01:54.00 |
CIA-62 |
BRL-CAD:
reason why it shouldn't remove all trailing slashes, so now it
does. |
| 01:55.11 |
abhi2011 |
i think the
cmd_test still needs to be defined though |
| 01:59.25 |
bhinesley |
abhi2011:
actually, mged isn't using libged for that one... |
| 02:00.18 |
bhinesley |
you need a
better example :) |
| 02:01.36 |
bhinesley |
archer is
using ged_zap, while mged is using cmd_zap |
| 02:04.24 |
bhinesley |
ged_cat in
cat.c is another short one |
| 02:05.14 |
bhinesley |
what you'll
need is something like {"T", cmd_ged_plain_wrapper,
ged_test} |
| 02:13.55 |
brlcad |
abhi2011: the
thing is, the library path is supposed to be set in the binary
(unless ld or gcc are configured otherwise) |
| 02:14.35 |
brlcad |
like I said,
might be a fedora-specific setting or something different with gcc
4.6 |
| 02:15.03 |
brlcad |
either way,
really doesn't matter -- that's not the usual compile method -- we
use a build system |
| 02:15.27 |
brlcad |
so first step
is to compile and install all of brl-cad -- there is a checklist on
the wiki of things to do |
| 02:15.47 |
brlcad |
as for the
command, everything bhinesley is saying is spot on :) |
| 02:55.58 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 04:26.07 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.21.215) |
| 04:26.07 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 04:31.06 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.23.74) |
| 04:31.06 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 04:58.47 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.23.74) |
| 04:58.47 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:39.46 |
CIA-62 |
BRL-CAD:
03bhinesley * r45561 10/brlcad/trunk/src/libged/edit.c: Fixed a
bunch of logic bugs. Implemented 'quiet' flagging for
edit_str_to_arg, and allowed for conversions to be silently
attempted whenever a string *might* contain an arg. |
| 06:54.21 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 07:08.41 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:17.12 |
CIA-62 |
BRL-CAD:
03bhinesley * r45562 10/brlcad/trunk/src/libbu/bomb.c: "not
validating 'write' return value; missed this in r45542" |
| 07:24.37 |
*** join/#brlcad Stattrav
(~Stattrav@117.213.184.187) |
| 07:24.40 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 07:39.31 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 10:25.26 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 10:28.32 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 10:55.19 |
tharis20 |
brlcad: does
fixing a broken link on your wiki count as a useful patch?
:p |
| 11:07.40 |
abhi2011 |
brlcad: well
i have installed all of brlcad |
| 11:08.44 |
abhi2011 |
and I have
setup a new file in src\libged |
| 11:08.54 |
abhi2011 |
src\libged\test.c |
| 11:09.57 |
abhi2011 |
so I want it
to be a new command to mged |
| 11:10.29 |
abhi2011 |
i inserted a
new command into setup.c |
| 11:10.59 |
abhi2011 |
{"T",
cmd_ged_plain_wrapper, ged_test}, |
| 11:12.01 |
abhi2011 |
my question
is how do I now compile both the files : setup.c and test.c, so
that they become available in mged |
| 11:18.59 |
kunigami_ |
add test.c to
LIBGED_SOURCES at libged/CMakeLists.txt |
| 11:19.37 |
CIA-62 |
BRL-CAD:
03brlcad * r45563 10/brlcad/trunk/src/libbu/bomb.c: write() returns
an ssize_t, simplify test |
| 11:22.55 |
brlcad |
tharis20: can
I apply the fix with the patch command? |
| 11:23.27 |
brlcad |
abhi2011: did
you compile/install using cmake? |
| 11:24.02 |
brlcad |
if so, then
what kunigami_ said, recompile, and test.c should get
built |
| 11:24.14 |
brlcad |
if you used
autotool, edit src/libged/Makefile.am, then recompile |
| 11:32.16 |
abhi2011 |
umm no i
nstalled brlcad from the rpm |
| 11:32.32 |
abhi2011 |
so should i
build brlcad from source ? |
| 11:32.51 |
abhi2011 |
is there no
way to compile plugins without compiling all of brlcad
? |
| 11:39.30 |
tharis20 |
in the
features request tracker there are some marked open which are
already solved |
| 11:41.41 |
brlcad |
abhi2011:
have you ever worked with open source (development)
before? |
| 11:42.00 |
brlcad |
tharis20:
yeah, they've not been reviewed in a little while, couple months
out of sync |
| 11:42.33 |
brlcad |
better are
the BUGS and TODO files in the source code, or run the tools until
you encounter an issue |
| 11:44.00 |
tharis20 |
I was reading
them so that I could choose one to try to implement and I was
always "Ok, I don't understand this... isn't this already
implemented? No, otherwise it would be closed. It's probably me not
understading..." |
| 11:44.01 |
brlcad |
abhi2011: you
can compile plugins without compiling all of brlcad but if it's not
obvious how to do that, then you should build the package from
source |
| 11:44.12 |
abhi2011 |
well i have
installed open source software before and I know how to compile
softwares from source |
| 11:44.27 |
abhi2011 |
but no i
havent actually worked on an open source project |
| 11:45.27 |
brlcad |
we make
compiling brl-cad about as simple as it gets, especially for a
package this big, including adding additions -- but yes, you could
set up your own build module outside our build system if you wanted
using whatever tools you like |
| 11:45.55 |
brlcad |
it's just a
lot easier to explain the integrated approach and socis will be
entirely focused on an integrated approach anyways |
| 11:46.16 |
abhi2011 |
ok yes, I am
fine with that |
| 11:46.32 |
abhi2011 |
so by the
integrated approach you mean using cmake right ? |
| 11:46.40 |
brlcad |
fwiw,
stand-alone development is highly frowned upon around here, we all
work together so there should be no hesitation to add to the
core |
| 11:46.41 |
abhi2011 |
using cmake
to build brlcad from source ? |
| 11:46.51 |
brlcad |
cmake or
autotools |
| 11:46.55 |
brlcad |
we have two
major build systems |
| 11:47.10 |
brlcad |
autotools is
the older more established, but we're in the process (right now)
replacing it with a cmake build |
| 11:47.45 |
abhi2011 |
yes of
course..I do not want to do stand-alone development, i want to do
this with the community :) |
| 11:47.47 |
brlcad |
every major
feature we remove, though, goes through a proper deprecation
removal process so it's not just yanked out from under our
users |
| 11:48.09 |
brlcad |
so autotools
is now considered deprecated, and in a few months there will be
only cmake |
| 11:48.16 |
abhi2011 |
ok |
| 11:48.30 |
abhi2011 |
all I want to
do is learn how to make plugins in brlcad |
| 11:48.41 |
brlcad |
but in the
time being, either/both work (and if you make it into socis, you'd
be expected to update both) |
| 11:48.42 |
abhi2011 |
so I can move
on to real development of the physics |
| 11:48.58 |
abhi2011 |
ok yes i
understand |
| 11:49.53 |
brlcad |
like I said
yesterday, we have at least a dozen different concepts of a plugin
and they all get hooked in differently -- for libged commands, it's
(not necessary, but) easiest to just add to the existing
build |
| 11:50.07 |
brlcad |
tharis20:
which feature? |
| 11:50.38 |
brlcad |
abhi2011:
have you looked over http://brlcad.org/wiki/Summer_of_Code/Checklist
? |
| 11:50.49 |
tharis20 |
brlcad:
fbclear, for example |
| 11:51.11 |
brlcad |
link? |
| 11:51.38 |
abhi2011 |
ah no not
yet. right I ll have a look |
| 11:52.09 |
tharis20 |
http://sourceforge.net/tracker/?func=detail&aid=3238193&group_id=105292&atid=640805 |
| 11:52.27 |
tharis20 |
this one also
http://sourceforge.net/tracker/?func=detail&aid=3279756&group_id=105292&atid=640805 |
| 11:52.41 |
brlcad |
tharis20: as
far as I know, mged doesn't sport an fbclear command
still |
| 11:53.27 |
brlcad |
the latter
for the mater command was a bug and is fixed |
| 11:53.49 |
tharis20 |
I thought it
did, in the Introduction to MGED, it mentions this
command |
| 11:53.53 |
tharis20 |
let me check
again |
| 11:54.27 |
brlcad |
theres a gui
fbclear button |
| 11:54.29 |
brlcad |
but no
command |
| 11:56.07 |
tharis20 |
is the
function of the wanted command the same of the button? |
| 11:57.14 |
abhi2011 |
ok I have a
question about the Application requirements for SOCIS |
| 11:57.39 |
abhi2011 |
so is
submitting a patch required for being accepted |
| 12:05.00 |
abhi2011 |
right I have
read through the requirements |
| 12:07.33 |
abhi2011 |
To write a
successful propsal, I am trying to compile brlcad from source and
write a basic plugin |
| 12:09.54 |
abhi2011 |
given the
tight timeline for SOCIS, how strictly will the acceptance
requirements be followed ? |
| 12:10.24 |
abhi2011 |
especially
submitting a patch within the short timeframe would be really
tight |
| 12:11.25 |
``Erik |
the patch is
just to prove that you can compile the code, follow the coding
guidelines in the HACKING file and interface with subversion, it
doesn't have to be a major change |
| 12:18.29 |
abhi2011 |
ok I
understand...right I ll get on it |
| 12:29.33 |
tharis20 |
if there's an
app doing something and I just want to make a command that uses
that app, what's the best approach? |
| 12:30.46 |
tharis20 |
system call
to that app (I don't think that's a good idea), although the GUI
uses it or copying and pasting that part that matters of the code
of the original app, or ? |
| 12:37.52 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-187-000.wlan.tudelft.nl) |
| 13:12.56 |
tharis20 |
besides
adding a line in setup.c, editing src/libged/Makefile.am, what else
do I need to do to compile with a new command? is there anything
else I need to update? |
| 13:16.33 |
kunigami_ |
tharis20: I
think it's enough. Have you tried compiling with these
changes? |
| 13:17.03 |
tharis20 |
yes, and I
always get that the function is undeclared |
| 13:19.55 |
kunigami_ |
paste the
error in a patebin, http://paste.ubuntu.com/, for
example |
| 13:22.15 |
tharis20 |
http://pastebin.com/7pBuvvhJ |
| 13:23.28 |
tharis20 |
I've also
noticed that in libged there's no fbclear.o or
fbclear.lo |
| 13:53.01 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 13:56.08 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45564 10/brlcad/trunk/src/libbu/bomb.c: fix
signed/unsigned warning |
| 14:06.33 |
*** join/#brlcad tharis20_
(~tharis@bl21-60-39.dsl.telepac.pt) |
| 14:06.57 |
tharis20_ |
brlcad: can
you help me? ^ |
| 14:48.43 |
brlcad |
tharis20: if
it were, there wouldn't be the need for an fbclear command
;) |
| 14:48.56 |
brlcad |
it calls
through some private api to clear the framebuffer |
| 14:49.46 |
brlcad |
abhi2011: the
patch doesn't have to be related to your project proposal, it can
be anything -- the point as ``Erik mentioned is to show
competency |
| 14:50.36 |
abhi2011 |
ok yes. I am
compiling the brlcad source now from the instructions in
INSTALL.cmake file |
| 14:51.18 |
brlcad |
so the better
your patch, the better your proposal, but even a one-line patch
that fixes a hard bug can be as amazing or more than a 1000 line
patch that implements some new feature |
| 14:51.28 |
tharis20 |
brlcad: so,
the button fbclear doesn't do the same as the command of the
feature request |
| 14:51.46 |
brlcad |
tharis20: it
does the desired operation |
| 14:52.00 |
brlcad |
but you can't
use the api that the button uses for the command |
| 14:52.14 |
brlcad |
they're in
different sections of code |
| 14:52.23 |
tharis20 |
but the
command calls the application fbclear through a system
call |
| 14:52.38 |
brlcad |
yes, it
eventually gets to that |
| 14:52.39 |
tharis20 |
*the
button |
| 14:52.54 |
brlcad |
that's kinda
lame for a command |
| 14:53.05 |
abhi2011 |
right i
understand, thanks brlcad |
| 14:53.37 |
brlcad |
it's just as
much logic to set up a connection to fork/exec the fbclear binary
as it is to open a connection to the framebuffer and issue a clear
command |
| 14:53.53 |
tharis20 |
exactly,
that's why I asked what's the best way, trying to avoid the system
call |
| 14:53.53 |
brlcad |
probably <
20 lines of code |
| 14:54.13 |
brlcad |
basically,
the guts to the fbclear command, with some
simplification |
| 14:54.21 |
brlcad |
s/command/tool/ |
| 14:54.54 |
tharis20 |
ok, I created
a fbclear.c in src/libged |
| 14:55.06 |
tharis20 |
and added it
to Makefile.am |
| 14:55.29 |
brlcad |
the issue in
terms of encapsulation is that there "shouldn't" be a direct call
into libfb from libged |
| 14:55.44 |
tharis20 |
what else do
I need to do so that when I compile, mged will recognize the
command? |
| 14:55.49 |
brlcad |
so you
shouldn't just call fb_clear() .. it should get passed in through
the struct ged |
| 14:56.10 |
brlcad |
you'll need
to add a binding for the function in src/mged/setup.c |
| 14:56.22 |
tharis20 |
yes, I also
did that |
| 14:58.32 |
brlcad |
fwiw, calling
the binary would be better than calling the libfb api directly if
you can't figure out how to get to the framebuffer through the
struct ged |
| 14:59.17 |
brlcad |
(ged_fbsp) |
| 15:00.02 |
brlcad |
tharis20:
pastebin.com is the worst pastebin service out there and
inaccessible to many of us (network blocked) |
| 15:00.06 |
tharis20 |
I'm calling
the binary src/fb/fbclear |
| 15:00.20 |
brlcad |
if you have a
declaration problem, that means what? |
| 15:00.41 |
tharis20 |
http://pastebin.ubuntu.com/649203/ |
| 15:01.10 |
tharis20 |
that means
I'm not including something, I guess |
| 15:01.12 |
brlcad |
so what does
that error mean? |
| 15:01.21 |
brlcad |
not
exactly |
| 15:01.28 |
brlcad |
it means
something isn't declared |
| 15:01.47 |
brlcad |
and it tells
you exactly what's not declared |
| 15:01.56 |
brlcad |
so you just
need to find where declarations go |
| 15:05.46 |
tharis20 |
ok, so now
it's the linker giving an error |
| 15:05.56 |
tharis20 |
since
fbclear.c was not compiled |
| 15:06.58 |
CIA-62 |
BRL-CAD:
03brlcad * r45565 10/brlcad/trunk/src/libbu/bomb.c: strlen()
returns and write() takes a size_t, so keep the higher precision as
far as we can even through write() requires the stupid return
type |
| 16:32.15 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 17:16.52 |
brlcad |
``Erik: |
| 17:16.53 |
brlcad |
simd.c:29:
error: can't find a register in class 'BREG' while reloading
'asm' |
| 17:47.34 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.147.252) |
| 17:47.34 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:31.32 |
kunigami_ |
question on
calculating the visibility of the light: if the normal of the
surface points in the same "direction" of the light, then that
light is not visible. In this case the function light_obs returns
early without setting sw_visible to NULL |
| 18:32.18 |
kunigami_ |
I made a
test. In the following image, whenever there's a visible light in
the given point, I shade it white. look the result |
| 18:32.53 |
kunigami_ |
http://dl.dropbox.com/u/1399996/GSoC/light_obs.png |
| 18:35.21 |
kunigami_ |
this also
seem to be the cause of the strange behavior of the toon shader:
http://dl.dropbox.com/u/1399996/GSoC/toon_result.png |
| 18:36.00 |
kunigami_ |
look how the
blue light seems to be casting a shadow in the portion that should
be illuminated by the yellow one |
| 18:36.51 |
kunigami_ |
without the
blue light: http://dl.dropbox.com/u/1399996/GSoC/toon_result_2.png |
| 18:42.50 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.147.252) |
| 18:42.50 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 18:52.40 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.147.252) |
| 18:52.40 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:08.44 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.147.252) |
| 19:08.44 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 19:12.29 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 20:09.28 |
kunigami_ |
strange...
the result is still this image http://dl.dropbox.com/u/1399996/GSoC/toon_result.png
even when I initialize sw_visible to NULL (before calling
light_obs). |
| 20:10.03 |
kunigami_ |
the problem
is only solved when I replace sw_tolight by sw_tolight + 3*i (as
mentioned yesterday) |
| 20:10.59 |
kunigami_ |
http://dl.dropbox.com/u/1399996/GSoC/toon_result_3.png |
| 20:12.13 |
kunigami_ |
I'm not
really sure if my changes are the right ones to do. I'll send an
email to dev-list asking for a review |
| 20:32.24 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.147.252) |
| 20:32.25 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:39.51 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.147.252) |
| 20:39.51 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 21:01.03 |
CIA-62 |
BRL-CAD:
03bhinesley * r45566 10/brlcad/trunk/src/libged/edit.c: |
| 21:01.04 |
CIA-62 |
BRL-CAD:
added detection of objects without slashes, nullified
dangling |
| 21:01.04 |
CIA-62 |
BRL-CAD:
pointers, misc cleanup |
| 21:07.03 |
brlcad |
kunigami_:
the toon shader is very new, might just have some bugs |
| 21:08.21 |
brlcad |
``Erik wrote
it, best to ask him |
| 21:08.53 |
brlcad |
from your
images, looks like it is a bug, but not familiar with that shader
myself |
| 21:12.03 |
``Erik |
should probably eventually finish that
shader |
| 21:20.04 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45567 10/brlcad/trunk/src/libbu/simd.c: ia32
seems to be unhappy about trying to address ebx at all in PIC mode,
so simplify by completely duplicating the asm section to contain
all the specialisms |
| 21:22.13 |
brlcad |
build
succeeded here |
| 21:22.41 |
``Erik |
yeah, i386
PIC asm code confuses gcc |
| 21:24.58 |
CIA-62 |
BRL-CAD:
03brlcad * r45568 10/brlcad/trunk/TODO: reports of crashes. red
with multiple blank lines and illuminate+Z. |
| 21:36.55 |
*** join/#brlcad Elrohir
(~kvirc@p5B14A10B.dip.t-dialin.net) |
| 23:10.44 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.135.247) |
| 23:15.46 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.134.79) |
| 23:15.46 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 23:31.08 |
CIA-62 |
BRL-CAD:
03r_weiss * r45569 10/brlcad/trunk/src/libbn/plane.c: |
| 23:31.09 |
CIA-62 |
BRL-CAD:
Updated the prototype version of function bn_isect_line_lseg
and |
| 23:31.09 |
CIA-62 |
BRL-CAD:
bn_isect_line3_line3_new within the libbn library within file
plane.c. These |
| 23:31.09 |
CIA-62 |
BRL-CAD:
changes are disabled by default. These functions support the
prototype function |
| 23:31.09 |
CIA-62 |
BRL-CAD:
nmg_triangulate_fu. Made changes to code logic and performed code
cleanup. This |
| 23:31.09 |
CIA-62 |
BRL-CAD: is a
work in progress. |
| 23:56.23 |
CIA-62 |
BRL-CAD:
03r_weiss * r45570
10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: |
| 23:56.23 |
CIA-62 |
BRL-CAD:
Updated function nmg_radial_build_list within file nmg_fuse.c.
These changes |
| 23:56.23 |
CIA-62 |
BRL-CAD:
support the prototype version of nmg_triangulate_fu. This change
corrects a |
| 23:56.23 |
CIA-62 |
BRL-CAD:
problem when the edge radial pointers are not already sorted. These
changes are |
| 23:56.23 |
CIA-62 |
BRL-CAD:
disabled by default. This is a work in progress. |
| 00:32.04 |
abhi2011 |
hi |
| 00:32.12 |
abhi2011 |
I am trying
to compile brlcad |
| 00:32.23 |
abhi2011 |
apparently I
do not have many libraries installed |
| 00:32.37 |
abhi2011 |
here is the
output after compile |
| 00:33.45 |
abhi2011 |
http://bin.cakephp.org/view/1775318086 |
| 00:34.35 |
abhi2011 |
i am trying
to install the optimized version , the command is as given in
INSTALL.cmake |
| 00:34.53 |
abhi2011 |
cmake
../brlcad-X.Y.Z -DBRLCAD-ENABLE_OPTIMIZED=ON |
| 00:38.40 |
abhi2011 |
i am
installing the packages one by one now |
| 01:04.34 |
kunigami_ |
if you're
building from source. probably the dependencies are already there.
try using -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON parameter
too |
| 01:19.18 |
abhi2011 |
ok |
| 01:20.06 |
abhi2011 |
well i
installed and updated quite a few libraries before i saw this
:P |
| 01:20.17 |
abhi2011 |
now its
finaly succeeded |
| 01:20.25 |
abhi2011 |
will try to
make now |
| 01:23.53 |
abhi2011 |
hmm ran into
an error while building |
| 01:23.58 |
abhi2011 |
[ 3%]
Building C object
src/libbu/CMakeFiles/libbu.dir/malloc.c.o |
| 01:23.59 |
abhi2011 |
[ 3%]
Building C object
src/libbu/CMakeFiles/libbu.dir/mappedfile.c.o |
| 01:24.00 |
abhi2011 |
/home/abhi/brlcad/src/libbu/mappedfile.c:
In function ‘bu_open_mapped_file’: |
| 01:24.02 |
abhi2011 |
/home/abhi/brlcad/src/libbu/mappedfile.c:237:5:
error: the comparison will always evaluate as ‘true’ for the
address of ‘bu_mapped_file_list’ will never be NULL
[-Werror=address] |
| 01:24.04 |
abhi2011 |
cc1: all
warnings being treated as errors |
| 01:24.06 |
abhi2011 |
make[2]: ***
[src/libbu/CMakeFiles/libbu.dir/mappedfile.c.o] Error 1 |
| 01:24.07 |
abhi2011 |
make[1]: ***
[src/libbu/CMakeFiles/libbu.dir/all] Error 2 |
| 01:24.08 |
abhi2011 |
make: ***
[all] Error 2 |
| 01:24.16 |
abhi2011 |
this is from
code checked out from trunk |
| 01:25.01 |
abhi2011 |
probably have
to turn warnings as errors off ? |
| 01:31.52 |
abhi2011 |
here is the
build log |
| 01:31.54 |
abhi2011 |
http://bin.cakephp.org/view/1072403513 |
| 02:24.18 |
brlcad |
starseeker:
is the automatic detection not set up in cmake? e.g., in his build
log it fails on termlib (but that's obviously something we
provide) |
| 02:26.11 |
brlcad |
abhi2011:
that strictness failure is due to a recent code change. you
can/should turn Werror off (or fix the warning) |
| 02:29.40 |
abhi2011 |
ok |
| 02:31.44 |
brlcad |
see if this
fixes it |
| 02:32.53 |
CIA-62 |
BRL-CAD:
03brlcad * r45577 10/brlcad/trunk/include/bu.h: cast the BU_ASSERT
pointers through void* in order to hopefully get past the compiler
(correctly) warning that the comparison will always evaluate as
true. |
| 02:40.31 |
*** join/#brlcad tharis20
(~tharis@bl21-50-118.dsl.telepac.pt) |
| 02:46.56 |
abhi2011 |
ok..so I
should turn compiler warning off, or should I try to cast the
BU_ASSERT pointers through void* |
| 03:00.34 |
abhi2011 |
ok is there a
particular cmake file which has the compiler flags ? |
| 03:00.46 |
abhi2011 |
I have been
searching in the files but havent found one yet |
| 03:00.49 |
abhi2011 |
i ll try
find |
| 03:08.13 |
abhi2011 |
hmm i found
it in brlcad/misc/CMake/CompilerFlags.cmake |
| 03:08.45 |
abhi2011 |
seems like I
should turn off the BRLCAD-ENABLE_STRICT flag |
| 03:14.30 |
abhi2011 |
ok I set
brlcad/CMakeLists.txt , line 708 to OFF |
| 03:14.46 |
abhi2011 |
#
Enable/disable strict compiler settings - these are limited to
libraries that |
| 03:14.48 |
abhi2011 |
#
specifically inform the BRLCAD_ADDLIB macro they can be built with
STRICT flags. |
| 03:14.49 |
abhi2011 |
OPTION(BRLCAD-ENABLE_STRICT "Use strict
compiler settings on libraries that support them" OFF) |
| 03:15.30 |
abhi2011 |
this should
turn off the warnings as errors |
| 03:16.34 |
abhi2011 |
hmmm...thats
didnt work |
| 04:32.40 |
bhinesley |
abhi2011: he
tried to patch it, the channel just echoed his commit; you should
run `svn update` and see if your warning is gone. |
| 04:33.11 |
bhinesley |
otherwise,
just try something like `cmake -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON
-DBRLCAD-ENABLE_STRICT=OFF` |
| 04:33.15 |
bhinesley |
` |
| 04:34.22 |
bhinesley |
(er rather,
the bot CIA-62 echoed his commit) |
| 06:42.45 |
*** join/#brlcad colin_
(~colin@114-37-169-197.dynamic.hinet.net) |
| 07:23.29 |
*** part/#brlcad colin_
(~colin@114-37-169-197.dynamic.hinet.net) |
| 11:18.05 |
``Erik |
hm, fbsd is
conservative with setting __SSE__, it wants an -msse3 flag
passed... is there cmake fu to make that happen? |
| 11:28.42 |
abhi2011 |
Scanning
dependencies of target htester |
| 11:28.44 |
abhi2011 |
[ 4%]
Building C object
src/libbu/CMakeFiles/htester.dir/htester.c.o |
| 11:28.45 |
abhi2011 |
/home/abhi/brlcad/src/libbu/htester.c: In
function ‘main’: |
| 11:28.47 |
abhi2011 |
/home/abhi/brlcad/src/libbu/htester.c:68:9:
error: variable ‘ret’ set but not used
[-Werror=unused-but-set-variable] |
| 11:28.49 |
abhi2011 |
cc1: all
warnings being treated as errors |
| 11:28.50 |
abhi2011 |
make[2]: ***
[src/libbu/CMakeFiles/htester.dir/htester.c.o] Error 1 |
| 11:28.52 |
abhi2011 |
make[1]: ***
[src/libbu/CMakeFiles/htester.dir/all] Error 2 |
| 11:28.53 |
abhi2011 |
make: ***
[all] Error 2 |
| 11:28.55 |
abhi2011 |
i ll try the
-DBRLCAD-ENABLE_STRICT=OFF` |
| 11:29.15 |
*** part/#brlcad epileg
(~epileg@unaffiliated/epileg) |
| 11:58.22 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 12:03.15 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 12:03.29 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.150.58) |
| 12:03.29 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:05.35 |
CIA-62 |
BRL-CAD:
03brlcad * r45578 10/brlcad/trunk/src/libbu/htester.c: newer gcc
4.6 is smarter, have to actually use the return value. |
| 14:05.39 |
brlcad |
abhi2011:
that commit should fix htester.c |
| 14:07.07 |
brlcad |
newer
compiler just came out less than a month ago that is better and
producing/detecting more warning issues, so they're new issues that
haven't been fixed yet |
| 14:08.00 |
brlcad |
we default to
not only treating all warnings as errors but having the compiler
report almost every error that it's capable of reporting, way more
than the default used by others |
| 14:09.19 |
brlcad |
so you can
keep reporting them and someone will fix them or just turn the
strictness off with -DBRLCAD-ENABLE_STRICT=OFF |
| 14:10.12 |
brlcad |
starseeker:
those define sames are like nails on chaulkboard -- can they be all
underscores or all dashes? the mix is just asking for usability
woe |
| 14:10.26 |
brlcad |
s/sames/names/ |
| 14:22.23 |
abhi2011 |
right
ok |
| 14:23.07 |
abhi2011 |
hmm got one
more :) !! |
| 14:23.11 |
abhi2011 |
Linking C
executable ../../bin/g-var |
| 14:23.13 |
abhi2011 |
/usr/bin/ld:
CMakeFiles/g-var.dir/g-var.c.o: undefined reference to symbol
'sin@@GLIBC_2.0' |
| 14:23.15 |
abhi2011 |
/usr/bin/ld:
note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try
adding it to the linker command line |
| 14:23.16 |
abhi2011 |
/lib/libm.so.6: could not read symbols:
Invalid operation |
| 14:23.18 |
abhi2011 |
collect2: ld
returned 1 exit status |
| 14:23.20 |
abhi2011 |
make[2]: ***
[bin/g-var] Error 1 |
| 14:23.22 |
abhi2011 |
make[1]: ***
[src/conv/CMakeFiles/g-var.dir/all] Error 2 |
| 14:23.23 |
abhi2011 |
make: ***
[all] Error 2 |
| 14:24.12 |
abhi2011 |
math library
flag |
| 14:24.32 |
abhi2011 |
or something
related i think |
| 14:28.38 |
abhi2011 |
about 41% of
the build is done |
| 15:37.06 |
CIA-62 |
BRL-CAD:
03brlcad * r45579 10/brlcad/trunk/src/conv/CMakeLists.txt: add to
all of the executables that make direct calls to sin()/cos().
report of build failure from abhi2011 via irc on linux, gcc 4.6,
where the implicit attempt to add it automatically results in an ld
failure. |
| 15:37.28 |
abhi2011 |
cool! |
| 15:37.34 |
abhi2011 |
will try
now |
| 15:38.29 |
abhi2011 |
So what
exactly got added |
| 15:39.50 |
brlcad |
well, exactly
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/conv/CMakeLists.txt?r1=45069&r2=45579 |
| 15:39.56 |
brlcad |
there's now
an explicit link for -lm for those binaries |
| 15:40.34 |
brlcad |
should not be
needed as it's already prescribed elsewhere, but something appears
to be wrong on your system with ld or /lib/libm.so.6 |
| 15:41.19 |
abhi2011 |
ok |
| 15:41.28 |
brlcad |
adding it
explicit may just get past whatever that issue is and is harmless
in the build file otherwise for others |
| 15:41.38 |
abhi2011 |
right
ok |
| 15:49.54 |
abhi2011 |
Scanning
dependencies of target enf-g |
| 15:49.56 |
abhi2011 |
[ 41%]
Building C object
src/conv/CMakeFiles/enf-g.dir/enf-g.c.o |
| 15:49.57 |
abhi2011 |
Linking C
executable ../../bin/enf-g |
| 15:49.59 |
abhi2011 |
/usr/bin/ld:
CMakeFiles/enf-g.dir/enf-g.c.o: undefined reference to symbol
'sqrt@@GLIBC_2.0' |
| 15:50.00 |
abhi2011 |
/usr/bin/ld:
note: 'sqrt@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try
adding it to the linker command line |
| 15:50.02 |
abhi2011 |
/lib/libm.so.6: could not read symbols:
Invalid operation |
| 15:50.04 |
abhi2011 |
collect2: ld
returned 1 exit status |
| 15:50.05 |
abhi2011 |
make[2]: ***
[bin/enf-g] Error 1 |
| 15:50.07 |
abhi2011 |
make[1]: ***
[src/conv/CMakeFiles/enf-g.dir/all] Error 2 |
| 15:50.08 |
abhi2011 |
make: ***
[all] Error 2 |
| 15:50.10 |
abhi2011 |
same issue,
different place |
| 16:13.18 |
CIA-62 |
BRL-CAD:
03brlcad * r45580 10/brlcad/trunk/src/conv/CMakeLists.txt: more
needed for sqrt() |
| 16:36.39 |
abhi2011 |
[ 17%]
Building C object
src/rt/CMakeFiles/rtray.dir/viewray.c.o |
| 16:36.41 |
abhi2011 |
Linking C
executable ../../bin/rtray |
| 16:36.42 |
abhi2011 |
/usr/bin/ld:
CMakeFiles/rtray.dir/worker.c.o: undefined reference to symbol
'sin@@GLIBC_2.0' |
| 16:36.44 |
abhi2011 |
/usr/bin/ld:
note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try
adding it to the linker command line |
| 16:36.45 |
abhi2011 |
/lib/libm.so.6: could not read symbols:
Invalid operation |
| 16:36.47 |
abhi2011 |
collect2: ld
returned 1 exit status |
| 16:36.48 |
abhi2011 |
make[2]: ***
[bin/rtray] Error 1 |
| 16:36.50 |
abhi2011 |
make[1]: ***
[src/rt/CMakeFiles/rtray.dir/all] Error 2 |
| 16:36.52 |
abhi2011 |
make: ***
[all] Error 2 |
| 17:13.44 |
*** join/#brlcad bhinesley
(~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net) |
| 17:39.28 |
abhi2011 |
Linking C
executable ../../bin/rtray |
| 17:39.29 |
abhi2011 |
/usr/bin/ld:
CMakeFiles/rtray.dir/worker.c.o: undefined reference to symbol
'sin@@GLIBC_2.0' |
| 17:39.31 |
abhi2011 |
/usr/bin/ld:
note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try
adding it to the linker command line |
| 17:39.33 |
abhi2011 |
/lib/libm.so.6: could not read symbols:
Invalid operation |
| 17:39.35 |
abhi2011 |
collect2: ld
returned 1 exit status |
| 17:39.37 |
abhi2011 |
make[2]: ***
[bin/rtray] Error 1 |
| 17:39.38 |
abhi2011 |
make[1]: ***
[src/rt/CMakeFiles/rtray.dir/all] Error 2 |
| 17:39.40 |
abhi2011 |
make: ***
[all] Error 2 |
| 18:00.11 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 19:35.11 |
CIA-62 |
BRL-CAD:
03brlcad * r45581 10/brlcad/trunk/src/rt/CMakeLists.txt: more
${M_LIBRARY} additions to accommodate some front-end calls to
sin()/cos() |
| 19:45.23 |
abhi2011 |
cool! |
| 19:45.42 |
brlcad |
there are
undoubtedly a lot more places that will need to be
propagated |
| 19:48.41 |
abhi2011 |
ok |
| 19:49.12 |
abhi2011 |
cant this be
automated |
| 19:49.39 |
abhi2011 |
like for all
binaries like the rtray |
| 19:50.10 |
abhi2011 |
ok 42%
now |
| 19:50.13 |
abhi2011 |
Linking C
shared library ../../lib/libtclcad.so |
| 19:50.15 |
abhi2011 |
[ 42%] Built
target libtclcad |
| 19:50.16 |
abhi2011 |
Linking C
executable ../../bin/asc2g |
| 19:50.18 |
abhi2011 |
/usr/bin/ld:
CMakeFiles/asc2g.dir/asc/asc2g.c.o: undefined reference to symbol
'sqrt@@GLIBC_2.0' |
| 19:50.20 |
abhi2011 |
/usr/bin/ld:
note: 'sqrt@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try
adding it to the linker command line |
| 19:50.21 |
abhi2011 |
/lib/libm.so.6: could not read symbols:
Invalid operation |
| 19:50.23 |
abhi2011 |
collect2: ld
returned 1 exit status |
| 19:50.25 |
abhi2011 |
make[2]: ***
[bin/asc2g] Error 1 |
| 19:50.26 |
abhi2011 |
make[1]: ***
[src/conv/CMakeFiles/asc2g.dir/all] Error 2 |
| 19:50.27 |
abhi2011 |
make: ***
[all] Error 2 |
| 19:50.36 |
brlcad |
only thing I
can think of is you're using some older version of cmake or there
is something wrong with your ld setup |
| 19:51.08 |
abhi2011 |
hmm
ok |
| 19:51.09 |
brlcad |
otherwise,
there's no way to automate the fix for sure |
| 19:51.28 |
abhi2011 |
its a
straight fedora 15 install |
| 19:51.43 |
abhi2011 |
no changes to
ld etc |
| 19:51.59 |
brlcad |
right, but it
gets back to the earlier ld fishyness too |
| 19:52.09 |
abhi2011 |
yeah |
| 19:52.14 |
brlcad |
something is
still different, whether intentional or not |
| 19:53.12 |
brlcad |
there are 400
binaries in brl-cad, so at least that many opportunities to hit
this issue |
| 19:53.41 |
brlcad |
one thing you
could do would be to compile with "make -k 2>&1 | tee
build.log" |
| 19:54.09 |
brlcad |
then you can
post that build log up some place, it should get further than one
at a time |
| 19:54.58 |
abhi2011 |
ok right I ll
do that |
| 19:57.40 |
CIA-62 |
BRL-CAD:
03brlcad * r45582 10/brlcad/trunk/src/conv/ (CMakeLists.txt
iges/CMakeLists.txt): more -lm propagation |
| 20:08.36 |
*** join/#brlcad tharis20_
(~tharis@2.82.61.33) |
| 20:43.11 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.137.215) |
| 20:43.11 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:48.11 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.138.138) |
| 20:51.12 |
abhi2011 |
right the
build is done |
| 20:53.20 |
abhi2011 |
i ll post the
build log in the mailing list |
| 20:53.57 |
brlcad |
Nuuuo |
| 20:54.09 |
brlcad |
just post it
to some file sharing service |
| 20:54.13 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 20:54.25 |
brlcad |
how long is
it? |
| 21:01.44 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.138.89) |
| 21:01.44 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 21:01.48 |
abhi2011 |
10.6
mb |
| 21:02.00 |
abhi2011 |
when
compressed just 400 kb |
| 21:02.54 |
abhi2011 |
sent on the
mailing list |
| 21:03.07 |
abhi2011 |
may I know
what is the preferred platform for building brlcad |
| 21:03.46 |
abhi2011 |
i would like
to finish building brlcad soon and move on development as the ESA
SOCIS deadline is coming up fast :) |
| 21:08.06 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 21:14.30 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.138.89) |
| 21:14.41 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 21:24.02 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.138.89) |
| 21:24.03 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 21:31.21 |
brlcad |
abhi2011:
there isn't really a preferred platform, we continuously build on a
variety of platforms including linux (rh, gentoo, ubuntu, ...),
freebsd, mac os x, windows, and occasionally even on haiku,
solaris, openbsd, ... |
| 21:31.37 |
brlcad |
the issues
you're running into are not common, to say the least |
| 21:32.04 |
brlcad |
the only
other suggestion I could make would be to try the autotools build
instead of the cmake build (from a fresh checkout) to see if it
works better for you |
| 21:32.23 |
brlcad |
./autogen.sh
&& ./configure --enable-all && make |
| 21:33.10 |
abhi2011 |
right
ok |
| 21:37.02 |
brlcad |
mm, 95% of
that build log is just src/conv/step blathering warnings for
autogenerated code (which we don't care about, won't
fix) |
| 21:37.55 |
brlcad |
that's more
reasonable, 1mb |
| 21:39.33 |
brlcad |
er, not even
.. 300k, just 5k lines |
| 21:40.07 |
abhi2011 |
<PROTECTED> |
| 21:40.17 |
abhi2011 |
79372
lines |
| 21:41.03 |
brlcad |
of which
about 74300 are completely irrelevant |
| 21:41.42 |
abhi2011 |
ok I ll try
the autotools build, see if that resolves the issue |
| 21:41.58 |
brlcad |
if that log
needs to get generated again (say after someone goes through and
addresses the warnings), use: cat build.log | grep -v src/conv/step
|grep -v src/other/step > build2.log |
| 21:42.51 |
brlcad |
autotools
isn't going to fix the strictness warnings, so need to disable
strict there too |
| 21:42.59 |
brlcad |
./autogen.sh
&& ./configure --enable-all --disable-strict &&
make |
| 21:43.37 |
brlcad |
it detects
and links libraries in a very different way, though, so might get
past the math library issues |
| 21:44.27 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.131.139) |
| 21:54.34 |
abhi2011 |
right
ok |
| 21:55.31 |
abhi2011 |
and as
backup...does brlcad have a smooth build on fedora 10 ? |
| 21:55.57 |
abhi2011 |
like I am
looking for any other platform in which brlcad is known to have a
smooth build |
| 21:57.03 |
brlcad |
what are your
options? |
| 21:57.14 |
abhi2011 |
i can try
opensuse various versions |
| 21:57.19 |
abhi2011 |
or fedora 10
to 14 |
| 21:57.40 |
abhi2011 |
well any free
distro really :) |
| 21:58.10 |
brlcad |
well we've
certainly built on fedora and opensuse before |
| 21:58.33 |
brlcad |
the
compilation warnings are a non-issue, because they can be disabled
-- and are specific to gcc 4.6 |
| 21:58.45 |
abhi2011 |
ok |
| 21:58.57 |
abhi2011 |
yes i am
trying with autotools now |
| 21:59.41 |
brlcad |
the linker
problem is the first I've seen of that so hopefully the autotools
build will get past it |
| 22:01.05 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 22:11.29 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.131.139) |
| 22:11.30 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 22:21.32 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.131.139) |
| 22:21.33 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 22:45.41 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 22:56.45 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.143.63) |
| 22:56.45 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 23:01.43 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.138.30) |
| 23:10.17 |
abhi2011 |
well the
autotools build is still running, i hope there is a way to just
build plugins for mged separately rather than have to build all of
brlcad to test them |
| 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 |
| 00:46.55 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 01:39.59 |
LainIwakuraX |
starseeker: I
can build BRL-CAD as a whole, if you check my patch it's the
environment |
| 01:40.28 |
starseeker |
LainIwakuraX:
what behavior do you see if you try the above? |
| 01:40.43 |
LainIwakuraX |
1
sec |
| 01:41.00 |
LainIwakuraX |
yeah I get
that too |
| 01:41.19 |
starseeker |
hrm |
| 01:42.12 |
LainIwakuraX |
how do I
track down that sort of thing? =/ |
| 01:42.26 |
starseeker |
LainIwakuraX:
gdb to start with |
| 01:42.52 |
starseeker |
figure out
which call is producing the error, examine the data being fed in
and why it's wiping out |
| 01:43.41 |
LainIwakuraX |
ah
okay..first time working with gdb, I'll try to get this
sorted |
| 01:43.56 |
starseeker |
it's a good
skill to have :-) |
| 01:44.05 |
starseeker |
bt
(backtrace) is quite useful |
| 01:44.44 |
LainIwakuraX |
ah I think I
know what may be causing this bug, I can go fix it in
source |
| 01:59.29 |
LainIwakuraX |
It looks like
somewhere a std::string is being assigned to NULL when it probably
should be "" |
| 01:59.43 |
LainIwakuraX |
this might
take a few minutes to hunt down |
| 02:00.00 |
starseeker |
yeah, I
thought it might be something like this:
http://stackoverflow.com/questions/2407711/avoiding-improper-stdstring-initialization-with-null-const-char-using-g |
| 02:00.15 |
starseeker |
possibly
SCLstring tolerated NULL as an initialization input... |
| 02:01.13 |
LainIwakuraX |
mhm. I found
a few spots where I said "new std::string" and I changed those to
initialize with "" for sure...but that didn't fix it |
| 02:01.29 |
LainIwakuraX |
I'll look
around |
| 02:01.33 |
starseeker |
LainIwakuraX:
I probably added a few of those myself... |
| 02:01.45 |
LainIwakuraX |
=x |
| 02:06.12 |
CIA-62 |
BRL-CAD:
03bhinesley * r45628 10/brlcad/trunk/src/libged/edit.c: |
| 02:06.12 |
CIA-62 |
BRL-CAD:
Tracked down an issue where the last object wasn't being added, and
the last |
| 02:06.12 |
CIA-62 |
BRL-CAD: node
in the linked list was empty. Added support for numeric args (as
abs coord, |
| 02:06.12 |
CIA-62 |
BRL-CAD: rel
pos, or obj offset). Added/renamed constants for specifying
coordinates, so |
| 02:06.12 |
CIA-62 |
BRL-CAD: that
significance goes from left to right: |
| 02:06.13 |
CIA-62 |
BRL-CAD:
'%s/EDIT\([[:upper:]]\)_COORD/EDIT_COORD_\1/g'. Several
smaller, |
| 02:06.14 |
CIA-62 |
BRL-CAD:
formatting/comment corrections. |
| 02:20.07 |
LainIwakuraX |
starseeker:
If you find the spot where it's being initialized to null let me
know, I haven't found it yet =( |
| 02:21.08 |
starseeker |
LainIwakuraX:
it might even be a function of what it's parsing... my C++ foo is a
bit weak, unfortunately |
| 02:21.38 |
starseeker |
probably very
simple once we figure it out |
| 02:22.43 |
LainIwakuraX |
yeah, I know
that when I see it I'll know it lol it's just finding
it |
| 02:23.04 |
LainIwakuraX |
gdb gives me
some info.. |
| 02:23.14 |
LainIwakuraX |
STEPWrapper::load(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&)
() |
| 02:23.28 |
LainIwakuraX |
I can't find
STEPWrapper::load anywhere though |
| 02:24.42 |
starseeker |
wonders if ddd might be helpful... |
| 02:25.51 |
bhinesley |
spent about a hour wrestling ddd crashes
today |
| 02:26.57 |
bhinesley |
LainIwakuraX:
when in doubt: `find . -name "*.cpp" -exec grep "STEPWrapper::load"
--with-filename {} \;` |
| 02:28.26 |
bhinesley |
or use ctags
(even better) |
| 02:31.00 |
LainIwakuraX |
doesn't bring
up anything =( |
| 02:31.22 |
LainIwakuraX |
I usually
use: grep -H -r "<thing to search for>" . | grep -v svn |
less |
| 02:32.42 |
LainIwakuraX |
oho...may
have found it |
| 02:33.17 |
LainIwakuraX |
ugh it was in
a different directory! I forgot two were involved in my editing
process...this should be easier now |
| 02:43.36 |
LainIwakuraX |
starseeker:
I've found the offending code I'm in the process of debugging
it |
| 02:45.27 |
starseeker |
Registry::AddType,
clstepcore/Registry.inline.cc:221 ? |
| 02:45.33 |
LainIwakuraX |
No |
| 02:45.44 |
starseeker |
nmm |
| 02:45.53 |
LainIwakuraX |
conv/step/STEPWrapper.cpp |
| 02:45.56 |
LainIwakuraX |
the load
function |
| 02:45.57 |
starseeker |
ah |
| 03:15.06 |
LainIwakuraX |
okay the
"offending" code was sort of offending, after travelling to 4
different functions I found the real offending code =P working on
it.. |
| 03:36.04 |
LainIwakuraX |
starseeker: I
fixed that bug, but now we get a segfault |
| 03:36.13 |
LainIwakuraX |
Reading Data
from ../brlcad/src/other/step/data/ap203/cube1.p21... |
| 03:36.16 |
LainIwakuraX |
segfault |
| 03:38.20 |
brlcad |
starseeker,
probably a little premature on the cross-post, no? :) |
| 03:39.00 |
brlcad |
best when
collaborating to announce after we've fully vetted/tested
ourselves |
| 03:41.04 |
brlcad |
interesting
that I didn't run into a failure on my test |
| 03:41.27 |
brlcad |
tests that particular p21 file |
| 03:41.31 |
LainIwakuraX |
yes, it is
curious but the bug I found would have indeed failed on something
eventually =P |
| 03:41.35 |
LainIwakuraX |
the line
said |
| 03:41.43 |
LainIwakuraX |
std::string
schmn = NULL |
| 03:41.53 |
LainIwakuraX |
that won't
work |
| 03:44.16 |
brlcad |
nods |
| 03:44.22 |
brlcad |
hm, BAD cmake
rebuild |
| 03:48.55 |
LainIwakuraX |
Uhh |
| 03:49.05 |
LainIwakuraX |
I got it to
work without a segfault |
| 03:49.20 |
LainIwakuraX |
it says
Reading Data from
../brlcad/src/other/step/data/ap203/cube1.p21... |
| 03:49.33 |
LainIwakuraX |
Then it says
basic_string::_S_construct null not valid |
| 03:49.38 |
LainIwakuraX |
then the
program exits normally... |
| 03:49.45 |
LainIwakuraX |
(according to
gdb) |
| 03:53.34 |
bhinesley |
brlcad: what
gcc do most devs use? |
| 03:53.51 |
brlcad |
yeah, my test
of the patch was quite flawed, two build systems got in the way of
each other |
| 03:53.54 |
bhinesley |
I figured I'd
install a lower version so I can use strict |
| 03:54.12 |
brlcad |
bhinesley: a
pretty wide variety, actually |
| 03:54.20 |
brlcad |
just nobody
on gcc 4.6 yet (except you ;) |
| 03:54.26 |
bhinesley |
heh |
| 03:54.35 |
``Erik |
uses 4.2 (fbsd standard) and 4.1 (apple standard)
mostly |
| 03:54.36 |
brlcad |
it's been out
for about a month |
| 03:54.54 |
brlcad |
bhinesley:
have you rebuilt lately? |
| 03:55.15 |
bhinesley |
doing so now,
but strict is off |
| 03:55.20 |
brlcad |
I fixed a
slew of the ones abhit reported over the weekend, about a thousand
issues |
| 03:55.27 |
bhinesley |
nice |
| 03:55.28 |
brlcad |
save a full
build log |
| 03:55.46 |
brlcad |
make
2>&1 | tee build.log |
| 03:56.02 |
bhinesley |
okay, in just
a bit |
| 03:56.29 |
bhinesley |
I just did a
svn update... you guys were busy over the weekend :) |
| 03:56.38 |
brlcad |
I'm sure I
didn't get everything since I don't have the compiler warning if I
missed anything, but it should be far better |
| 03:56.51 |
bhinesley |
nods |
| 03:56.57 |
``Erik |
brlcad: I put
gcc4.7 on crit if you get the urge to play |
| 03:56.59 |
bhinesley |
I saw the
logs |
| 03:57.09 |
brlcad |
most oft he
things it's warning about are really trivial to fix |
| 03:57.26 |
brlcad |
vars not
being used, print specifier consistency |
| 03:57.37 |
brlcad |
``Erik: good
to know, thanks |
| 03:57.51 |
brlcad |
reproduces the step-g failure |
| 03:58.23 |
LainIwakuraX |
brlcad: I
have that fixed to not crash, cleaning up some things and
submitting a patch |
| 04:01.44 |
brlcad |
LainIwakuraX:
okay, great .. so I shouldn't go debugging |
| 04:08.36 |
LainIwakuraX |
brlcad: Patch
is submitted...like I said in the notes though even though there
isn't a crash I still don't know if it "works" |
| 04:08.54 |
LainIwakuraX |
If you could
test that it'd be great =) I haven't used this program before, I
don't know what to expect from it |
| 04:11.32 |
brlcad |
LainIwakuraX:
what was the issue with STEPWrapper::load() ? |
| 04:12.06 |
brlcad |
changing from
a std::string& to a std::string merely makes it make a copy
(alloc) |
| 04:12.27 |
brlcad |
if that fixes
a crash, some further investigating is probably
warranted |
| 04:12.35 |
LainIwakuraX |
brlcad: Uh,
that shouldn't have been changed- that was a test |
| 04:12.46 |
brlcad |
starseeker:
debugging is not enabled by default? |
| 04:13.30 |
brlcad |
patch files
are text, you should review them before posting .. just like you
should review the diff before a commit too |
| 04:13.42 |
brlcad |
svn revert
will restore a file to an unedited state |
| 04:14.09 |
brlcad |
"svn diff |
less" and you can manually inspect what changes are getting
included |
| 04:14.41 |
LainIwakuraX |
brlcad: if
you give me two seconds I'll upload a better patch file |
| 04:14.45 |
brlcad |
k |
| 04:15.20 |
brlcad |
also make
sure you're up-to-date (svn up) so the line offsets are
correct |
| 04:17.20 |
LainIwakuraX |
hm |
| 04:17.36 |
LainIwakuraX |
I put my
&'s on string, not the variable name.. |
| 04:18.05 |
LainIwakuraX |
it was string
&step_file but now it's string& step_file..that's fine
though |
| 04:18.20 |
brlcad |
they are
equivalent |
| 04:18.24 |
LainIwakuraX |
I
know |
| 04:18.31 |
LainIwakuraX |
that's why I
said it's fine =P |
| 04:18.36 |
brlcad |
heh |
| 04:19.22 |
brlcad |
convention is
usually to bind the type together with c++ but separate them for
c |
| 04:19.34 |
brlcad |
so
string& is peachy for scl |
| 04:19.39 |
LainIwakuraX |
ah |
| 04:19.48 |
LainIwakuraX |
k the better
patch is up there |
| 04:20.06 |
brlcad |
gets |
| 04:21.54 |
LainIwakuraX |
I'll brb in
~10 mins, let me know how it goes |
| 04:22.25 |
brlcad |
testing
now |
| 04:23.18 |
brlcad |
so it no
longer hard-crashes, but it still exits due to a NULL
string |
| 04:24.06 |
brlcad |
looks like
it's maybe on a static |
| 04:25.46 |
brlcad |
will have to
debug more tomorrow.. because *somebody* thought defaulting to no
debug symbol compilation was a good idea *ahem* :) |
| 04:26.41 |
brlcad |
basically,
every place a std::string is instantiated, it needs to be
initialized to be compatible with what it was assuming |
| 04:32.02 |
CIA-62 |
BRL-CAD:
03brlcad * r45629 10/brlcad/trunk/src/other/step/src/ (5 files in 2
dirs): |
| 04:32.02 |
CIA-62 |
BRL-CAD:
apply sf patch 3377904 (fixed a bug with step-g and null strings)
from Zach |
| 04:32.02 |
CIA-62 |
BRL-CAD:
Easterbrook ( lainiwakurax ) which indeed fixes the step-g crash,
but still |
| 04:32.02 |
CIA-62 |
BRL-CAD:
doesn't restore it to a functional status. aborts with a message
about a NULL |
| 04:32.02 |
CIA-62 |
BRL-CAD:
std::string. |
| 04:32.23 |
LainIwakuraX |
I'm
back |
| 04:32.59 |
LainIwakuraX |
brlcad: How
can we test this if it's failing without...uh, any
issues? |
| 04:33.09 |
LainIwakuraX |
I can't do a
backtrace in gdb |
| 04:33.51 |
brlcad |
for one,
step-g produces a ton of output when it's working correctly
;) |
| 04:34.31 |
brlcad |
you can put a
breakpoint on main (b main) and step forward ('n' command for "next
instruction") |
| 04:34.51 |
brlcad |
or "b
whatever" to break on any arbitrary function |
| 04:35.08 |
brlcad |
it'll take me
a while to get a rebuild with debugging enabled myself |
| 04:36.43 |
LainIwakuraX |
brlcad: Is it
cool if we tackle this tomorrow then? It's 12:30a.m here and I have
a few more things to do before bed =x |
| 04:37.55 |
brlcad |
we're
apparently on the same coast, sounds good to me |
| 04:38.50 |
LainIwakuraX |
k, see you
then. I'm usually awake in the afternoon lol |
| 04:42.03 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 04:55.02 |
bhinesley |
brlcad:
build.log http://paste.pocoo.org/show/446487/ |
| 04:56.03 |
bhinesley |
er, you
probably wanted me to use 'make -k' |
| 05:00.42 |
bhinesley |
'make -k'
build log: http://paste.pocoo.org/show/446495/ |
| 05:34.01 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:26.18 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 07:10.26 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 08:47.51 |
CIA-62 |
BRL-CAD:
03Abby Moss 07http://brlcad.org *
r3037 10/wiki/Main_Page: |
| 08:47.59 |
CIA-62 |
BRL-CAD:
03d_rossberg * r45630 10/brlcad/trunk/src/libbu/CMakeLists.txt:
Windows MSVC: because of GetMappedFileName() in fchmod.c link with
psapi.lib |
| 08:50.13 |
*** join/#brlcad Stattrav
(~Stattrav@122.167.229.132) |
| 08:50.13 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 09:33.19 |
*** join/#brlcad DarkCalf
(DC@173.231.40.98) |
| 11:42.12 |
starseeker |
brlcad: yeah,
premature. Was going on your initial report that it
worked |
| 11:47.55 |
starseeker |
starseeker:
I'll hold off until we have it working next time |
| 11:47.59 |
starseeker |
er brlcad
rather |
| 11:48.05 |
starseeker |
is talking to himself |
| 11:58.57 |
brlcad |
mm, you sent
the message before I'd even started testing :) |
| 12:01.07 |
brlcad |
2pm, didn't
test and commit till 5pm .. but even if if it was golden, I'd
suggest we send them revision numbers at stepping
points |
| 12:01.17 |
brlcad |
bhinesley:
thanks |
| 12:20.58 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r3038
10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Abby
Moss|Abby Moss]] ([[User talk:Abby Moss|Talk]]); changed back to
last version by [[User:Sean|Sean]] |
| 12:21.20 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Abby Moss]] with an
expiry time of infinite (account creation disabled, e-mail
blocked) |
| 12:27.48 |
CIA-62 |
BRL-CAD:
03brlcad * r45631 10/brlcad/trunk/src/ (CMakeLists.txt
libbu/CMakeLists.txt): set PSAPI_LIB variable so we can consolidate
into the same since MSVC block |
| 12:30.28 |
d_rossberg |
brlcad:
setting of the MSVC libraries isn't very consistent in the cmake
files, see e.g. librt |
| 12:34.54 |
brlcad |
nods |
| 12:35.57 |
CIA-62 |
BRL-CAD:
03brlcad * r45632 10/brlcad/trunk/src/other/step/src/ (62 files in
7 dirs): |
| 12:35.57 |
CIA-62 |
BRL-CAD:
eliminate all of the __OSTORE__ sections. considered dead code
because there |
| 12:35.57 |
CIA-62 |
BRL-CAD: was
no managed way to enable those code sections. appears to be a
binding to a |
| 12:35.57 |
CIA-62 |
BRL-CAD:
commercial API (Progress Software Corp's ObjectStore product), so
remove in |
| 12:35.57 |
CIA-62 |
BRL-CAD:
favor of simplified code maintenance and reduced complexity.
removes almost 3k |
| 12:35.58 |
CIA-62 |
BRL-CAD:
lines of code. |
| 12:36.08 |
brlcad |
d_rossberg: I
know, the evils of letting a "platform" identifier in for a few
things makes it really easy to abuse/reuse in more places than it
should |
| 12:36.51 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 12:41.00 |
CIA-62 |
BRL-CAD:
03brlcad * r45633 10/brlcad/trunk/src/ (CMakeLists.txt
librt/CMakeLists.txt): similar to libbu, consolidate the msvc
library settings into the same place where winsock gets set,
consistently just use library names in ADDLIB |
| 12:49.09 |
brlcad |
I'm sure the
intention was to go back one day, some day, and fix them proper
when they were first written... ;) |
| 12:53.18 |
CIA-62 |
BRL-CAD:
03brlcad * r45634 10/brlcad/trunk/CMakeLists.txt: typo? |
| 12:54.10 |
d_rossberg |
OK |
| 13:00.31 |
CIA-62 |
BRL-CAD:
03brlcad * r45635 10/brlcad/trunk/CMakeLists.txt: |
| 13:00.31 |
CIA-62 |
BRL-CAD:
consistently default all builds (particularly fresh svn checkouts)
to a system |
| 13:00.32 |
CIA-62 |
BRL-CAD:
install into /usr/brlcad using rel- for releases and dev- for
developer builds. |
| 13:00.32 |
CIA-62 |
BRL-CAD:
could probably even just key off of the patch number but leave
as-is for now. |
| 13:00.32 |
CIA-62 |
BRL-CAD: this
will probably require windows to set the install prefix given there
usually |
| 13:00.32 |
CIA-62 |
BRL-CAD: is
no /usr path but that is needed for windows anyways for release
builds. |
| 13:01.29 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 13:01.46 |
CIA-62 |
BRL-CAD:
03brlcad * r45636 10/brlcad/trunk/TODO: remove all of the MSVC
platform sections in the CMakeLists.txt files |
| 13:01.49 |
brlcad |
abhi2011:
application received! |
| 13:08.44 |
CIA-62 |
BRL-CAD:
03brlcad * r45637 10/brlcad/trunk/TODO: demote a lot of tasks that
won't likely be completed by next month. leave most of the
build-related tasks since we're moving towards eventual autotools
removal. |
| 13:09.37 |
CIA-62 |
BRL-CAD:
03brlcad * r45638 10/brlcad/trunk/TODO: cp command now redraws once
again, along with a slew of other ged commands. if one of the argv
parameters is displayed, it gets redrawn. |
| 13:14.57 |
CIA-62 |
BRL-CAD:
03brlcad * r45639 10/brlcad/trunk/BUGS: rt displays output once
again, button bindings should be fixed, and rt after cd in mged on
windows should work once again |
| 13:34.45 |
CIA-62 |
BRL-CAD:
03brlcad * r45640 10/brlcad/trunk/src/conv/step/step-g.cpp: ws
style |
| 13:39.02 |
CIA-62 |
BRL-CAD:
03brlcad * r45641 10/brlcad/trunk/src/conv/step/ (6
files): |
| 13:39.02 |
CIA-62 |
BRL-CAD: got
step-g to crash with a couple input test files, one crashing on
Surface.h:48 |
| 13:39.02 |
CIA-62 |
BRL-CAD:
implying some stack corruption or memory issue. so add protections
all the way |
| 13:39.02 |
CIA-62 |
BRL-CAD: up
the stack to make sure we didn't run out of memory or dereference a
null |
| 13:39.02 |
CIA-62 |
BRL-CAD:
pointer at some point. probably doesn't get to the heart of the
crash, but |
| 13:39.02 |
CIA-62 |
BRL-CAD:
should help isolate it and help halt sooner (and hopefully more
gracefully than |
| 13:39.03 |
CIA-62 |
BRL-CAD: a
crash). |
| 13:40.34 |
CIA-62 |
BRL-CAD:
03brlcad * r45642 10/brlcad/trunk/src/other/libpng/depcomp: depcomp
is generated, remove from checkin |
| 13:42.35 |
CIA-62 |
BRL-CAD:
03brlcad * r45643 10/brlcad/trunk/src/other/libpng/config.h.in:
autoheader made config.h.in, also remove |
| 13:42.44 |
abhi2011 |
thanks brlcad
:) |
| 13:50.51 |
CIA-62 |
BRL-CAD:
03brlcad * r45644 10/brlcad/trunk/TODO: libpng needs backported
fixes for autotools |
| 14:30.38 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:35.28 |
starseeker |
brlcad: ah,
right - I thought they might want to play with the patch at that
point. Was hoping they might do some of the work for us
:-P |
| 14:36.48 |
starseeker |
brlcad: you
really want to go into /usr/brlcad for dev builds by
default? |
| 14:36.57 |
starseeker |
was very intentionally staying out of system
dirs |
| 14:47.00 |
CIA-62 |
BRL-CAD:
03starseeker * r45645 10/brlcad/trunk/CMakeLists.txt: Wasn't a typo
- to do what that previous edit looked like it wanted to do, ELSEIF
(I think) is what is needed. Instead of that, just turn on
DEBUG_BUILD for everything except Release |
| 14:47.26 |
starseeker |
isn't even sure how to test for Microsoft system
libraries... |
| 14:49.16 |
CIA-62 |
BRL-CAD:
03starseeker * r45646 10/brlcad/trunk/misc/enigma/enigma.c: clang
didn't like argc not having a type |
| 14:52.13 |
starseeker |
isn't sure he agrees with making the MSVC specific stuff into
tests - that'll just lengthen the configure process even further,
and the probability is very high that those options will be useless
everywhere else (or even worse, might mean something altogether
different, given how foreign MSVC is to other
environments) |
| 14:58.22 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 15:04.02 |
CIA-62 |
BRL-CAD:
03starseeker * r45647
10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Add the new,
improved libpng CMakeLists.txt macros from our 1.4.x build - this
is what should go back to libpng as a proposed patch. |
| 15:21.22 |
CIA-62 |
BRL-CAD:
03starseeker * r45648 10/brlcad/trunk/src/other/ (3 files in 2
dirs): OK, I think we've gotten rid of 'em now - try again to
remove scl_string |
| 15:33.24 |
brlcad |
starseeker:
having a default checkout that doesn't perform a system install
breaks convention in itself, /usr/local is usually the default
which is where our /usr/brlcad becomes preferred so we're
protected |
| 15:35.50 |
brlcad |
there's also
a portability issue for some platforms (like aix, hpux, some linux,
and few others) where binaries are not relocatable by default, so
if you installed into your home directory, you can't just copy that
(e.g., into /usr/brlcad) and have it work, have to set library
paths and our brlcad root/data paths in the environment |
| 15:36.57 |
starseeker |
right, but I
had figured when doing a debug (e.g. development) build installing
in /usr/brlcad was less likely to be important (I personally never
install there while doing development) |
| 15:36.59 |
brlcad |
plus it
matches our project history, we consistently install into
/usr/brlcad by default -- others can set a prefix |
| 15:37.40 |
brlcad |
to a user
checking out from svn, there is a surprise that I just did a
checkout, compile, install ... and it's not installed |
| 15:37.57 |
brlcad |
at least not
where I'd expect it, not in a system location |
| 15:38.26 |
starseeker |
well... I
suppose I could go back to defaulting to /usr/brlcad if
CMAKE_BUILD_TYPE is not set... |
| 15:38.38 |
brlcad |
and you
should be installing into /usr/brlcad ... else we end up with
mysterious path problems when mged is attempting to load
:) |
| 15:39.11 |
starseeker |
<snort>
I would have thought installing somewhere other than /usr/brlcad
would be MORE likely to highlight path problems, not
less |
| 15:39.31 |
brlcad |
release going
to /usr/brlcad/rel-VERSION and non-release going to
/usr/brlcad/dev-VERSION is actually a nice consistency |
| 15:40.10 |
brlcad |
it did
highlight problems.. the /usr/brlcad one didn't work :) |
| 15:40.16 |
starseeker |
nods - I can live with it, I just liked the idea of doing a
checkout/build/install for development purposes without having to
worry about system permissions |
| 15:41.39 |
brlcad |
end-user
convenience should always take priority over developer
convenience |
| 15:41.48 |
brlcad |
i'm a stout
believer in that stance |
| 15:42.03 |
starseeker |
end users use
RPMs or package managers :-P |
| 15:42.05 |
brlcad |
users get the
shaft WAY too often in open source |
| 15:42.14 |
brlcad |
end users
include anyone that's not a developer |
| 15:43.57 |
brlcad |
which
includes users that checkout from the repository, or that would
pick up a nightly source tarball... |
| 15:44.47 |
brlcad |
still, it's
more just about not *intentionally* making things more difficult or
compilicated when it's just a matter of convention or a few
keystrokes more or a few more lines in build files to help make it
easier |
| 15:48.34 |
starseeker |
shrugs. OK, I can live with dev-VERSION. |
| 15:49.29 |
brlcad |
so next
topic? :) |
| 15:49.41 |
brlcad |
I'd expect
microsoft system libs are tested for like any other library,
no? |
| 15:49.49 |
starseeker |
hmm... idea.
If I look for a BRL-CAD_build_settings.cmake file early in the
CMakeLists.txt and load it if found, that would provide a way for a
developer to customize things without disturbing end-users - would
that be OK? |
| 15:50.35 |
starseeker |
brlcad: I
suppose there might be a way to test for Microsoft librarys - I
have no idea if the standard CMake mechanisms will do it
though. |
| 15:51.12 |
starseeker |
Maybe we can
wrap that set of tests in in MSVC conditional in the toplevel so we
don't waste time with them on Mac/Linux at least? |
| 15:51.28 |
brlcad |
the issue is
really what happens to a default user -- if someone actively sets
up their config, that's akin to setting -Dvar=val or --prefix
options and it's peachy keen |
| 15:51.54 |
starseeker |
awesome - I
mainly want a way to minimize the number of config options/flags I
have to pass over and over |
| 15:52.01 |
brlcad |
nods |
| 15:52.06 |
brlcad |
perfectly
reasonable |
| 15:52.18 |
brlcad |
when was the
last time you built the linux kernel (by hand)? |
| 15:52.24 |
starseeker |
the configure
wrapper helps some there, but not really enough |
| 15:52.46 |
brlcad |
they had a
pretty neat setup |
| 15:52.46 |
starseeker |
brlcad:
define by hand - using their grapical config tool, or
item-by-item? |
| 15:52.55 |
brlcad |
either
really |
| 15:53.00 |
brlcad |
so you config
the kernel, right? |
| 15:53.07 |
brlcad |
it ends up
with a config file with all your settings |
| 15:53.16 |
starseeker |
yeah -
usually whenever I get a new machine, so the gentoo kernel has the
right modules |
| 15:53.20 |
starseeker |
right |
| 15:53.23 |
brlcad |
so even after
config is done, you can go in, edit it, and run with those new
settings |
| 15:53.37 |
brlcad |
something
like that would be awesome |
| 15:53.58 |
starseeker |
nods - CMakeCache.txt does some of that, but not "up front"
before a configure is run |
| 15:54.13 |
brlcad |
"cmake path"
resulting in a .GLOBAL would be fun :) |
| 15:54.43 |
starseeker |
brlcad: in
case I haven't mentioned it - you can hand edit the CMakeCache.txt
file in the toplevel build to change options |
| 15:54.44 |
brlcad |
I think linux
uses .CONFIG? |
| 15:55.20 |
brlcad |
it's
configurable iirc, but defaults to something like that |
| 15:55.23 |
starseeker |
for post
configure settings caching, CMakeCache.txt should have everything
you could want |
| 15:56.03 |
brlcad |
so common use
case that comes to mind .. we have all these tests for
opengl |
| 15:56.12 |
brlcad |
user runs
cmake, it fails the test |
| 15:56.16 |
brlcad |
but they know
they have it |
| 15:56.58 |
brlcad |
sure enough,
"make" just skips our ogl code; so they go in and edit the build
config file, turn ogl on, re-run make .. and it builds |
| 15:57.04 |
brlcad |
something
like that doable? |
| 15:57.21 |
starseeker |
yeah - that's
what I usually do if I forget to turn something on |
| 15:57.44 |
brlcad |
so maybe just
a better name than CMakeCache.txt :) |
| 15:58.01 |
brlcad |
or is that
literally every function/header/feature test? |
| 15:58.37 |
starseeker |
brlcad: heh -
hardwired, I think. But my point wasn't that I want that ability
AFTER running cmake - I want to always pass (say)
BRLCAD-ENABLE_ALL_LOCAL_LIBS=ON without having to type it every
time, and without having to edit the cache file |
| 15:59.01 |
brlcad |
blocking the
MSVC-only tests would be fine -- that's what I was thinking -- it's
more that they should still be tested for like any other feature
since they're just as ephemeral as any of the other
libs |
| 15:59.25 |
brlcad |
winsock2, for
example, is one of several incarnations of the windows networking
interface |
| 16:00.41 |
brlcad |
starseeker:
right, I got that -- but I figured that should just be a matter of
(re-)loading it during cmake for defaults as well as during make to
drive compilation |
| 16:01.08 |
brlcad |
so if
CMakeCache.txt is hardwired, maybe we could output just the
high-level options we care about to a different config
file |
| 16:01.15 |
starseeker |
nods |
| 16:01.16 |
brlcad |
basically,
the summary items |
| 16:01.21 |
starseeker |
let me
experiment a bit |
| 16:01.59 |
brlcad |
likes the .GLOBAL/_GLOBAL inside "joke" |
| 16:02.02 |
starseeker |
this is over
and above anything autotools ever provided (unless you count
storing a configure line in a .sh file) so it's probably not a high
priority - I'm just lazy about typing options :-P |
| 16:02.18 |
brlcad |
it is above
it |
| 16:02.27 |
brlcad |
something I
thought about adding a few times, though |
| 16:02.29 |
starseeker |
winces a little - maybe
BRL-CAD_CONFIG.GLOBAL |
| 16:03.15 |
brlcad |
users already
know they're in a brl-cad checkout, no need to remind them in all
the file names :) |
| 16:03.38 |
brlcad |
even just
CONFIG would probably be fine |
| 16:03.59 |
starseeker |
hadn't envisioned putting it in the checkout or even the
build dir - this would be something that could be stored
(optionally) in the parent directory |
| 16:04.28 |
brlcad |
I didn't mean
put it in checkout |
| 16:04.40 |
brlcad |
file
generated by cmake, reused by cmake and make |
| 16:05.00 |
starseeker |
shakes his head - I want to be able to use this to set
options before I ever run CMake at all |
| 16:05.36 |
brlcad |
nothing I've
said precludes that ??? |
| 16:06.00 |
starseeker |
cmake can't
generate a file in the parent directory - oh, wait |
| 16:06.08 |
starseeker |
hmm.
|
| 16:06.30 |
brlcad |
I presume by
parent you mean user's home dir or something? |
| 16:06.35 |
starseeker |
basically |
| 16:06.49 |
starseeker |
one config
file to rule them all :-P |
| 16:07.14 |
starseeker |
I guess we
can check for and read that in, then generate something in the
build directory for subsequent use in that run |
| 16:07.23 |
brlcad |
hm, that's a
little odd |
| 16:07.45 |
starseeker |
brlcad: might
be odd, but it would be completely harmless unless someone
specifically sought it out and set it up |
| 16:08.08 |
brlcad |
sure, but it
can be turned into a proper feature and achieve the same
result |
| 16:08.48 |
starseeker |
uh... I guess
I'm not following |
| 16:09.13 |
brlcad |
still
thinking to the linux kernel as a model to follow |
| 16:09.44 |
brlcad |
I can craft
up my own CONFIG file and specify it to the build (from wherever
really) |
| 16:10.01 |
brlcad |
or I can run
the interactive build (cmake .) and it'll dump out a CONFIG file
for me |
| 16:10.15 |
brlcad |
which I can
subsequently reuse if I wanted (from anywhere) |
| 16:10.21 |
brlcad |
edit to
heart's content |
| 16:10.32 |
brlcad |
or ignore and
the build just uses it for settings |
| 16:11.12 |
brlcad |
familiar,
time tested, pretty simple |
| 16:16.42 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:26.45 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:34.55 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.146.20) |
| 17:09.59 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 17:34.55 |
CIA-62 |
BRL-CAD:
03starseeker * r45649 10/brlcad/trunk/CMakeLists.txt: |
| 17:34.55 |
CIA-62 |
BRL-CAD: Add
a dirt-simple way to allow developers to inject their own default
settings |
| 17:34.55 |
CIA-62 |
BRL-CAD: into
the CMake process - eventually we may want to do something
more |
| 17:34.55 |
CIA-62 |
BRL-CAD:
sophisticated, but this is a simple way to do things like enable
all local |
| 17:34.55 |
CIA-62 |
BRL-CAD:
libraries by default. |
| 18:34.40 |
brlcad |
starseeker:
what does it mean to be a release build? |
| 18:35.03 |
brlcad |
is that
merely synonymous with non-debug? .. or what if I wanted a
debuggable release build? |
| 19:30.47 |
brlcad |
starseeker:
so unexpected behavior .. cd brlcad ; mkdir .cmake ; cd .cmake ;
cmake .. ; echo "why aren't there any build files output
here?" |
| 19:56.43 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
| 20:08.40 |
*** join/#brlcad tharis20_
(~tharis@2.83.244.20) |
| 21:10.19 |
starseeker |
starseeker:
right now it's mostly /usr/brlcad/rel* paths and turning on
optimization by default |
| 21:11.20 |
starseeker |
formally acknowledges not outputing build files in expected
directory if there is a CMakeCache.txt file in the source dir is
Not Good |
| 21:11.33 |
starseeker |
brlcad: right
now it's mostly /usr/brlcad/rel* paths and turning on optimization
by default |
| 21:11.38 |
starseeker |
is talking to himself again |
| 23:29.45 |
*** join/#brlcad LainIwakuraX
(~yuki@d24-57-80-191.home.cgocable.net) |
| 23:32.42 |
LainIwakuraX |
brlcad: I see
a lot of updates to step stuff in the latest rev. sorry I wasn't
here in the afternoon to help =( |
| 23:46.28 |
tharis20 |
brlcad: in
the expectations it is said that it is expected students to work 40
hours a week, the same as a full-time job |
| 23:46.50 |
tharis20 |
but SOCIS
extends until the end of October and classes begin in
mid-September |
| 00:00.00 |
LainIwakuraX |
lol |
| 00:11.21 |
CIA-62 |
BRL-CAD:
03brlcad * r45668 10/brlcad/trunk/src/conv/step/step-g.cpp: always
tear down the factory |
| 00:13.42 |
CIA-62 |
BRL-CAD:
03brlcad * r45669 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp:
dotg != dot_g |
| 00:49.48 |
*** join/#brlcad tharis20
(~tharis@dyn896-219.eduroam.ic.ac.uk) |
| 00:50.57 |
LainIwakuraX |
Out for the
night |
| 00:57.55 |
*** join/#brlcad tharis20
(~tharis@dyn896-219.eduroam.ic.ac.uk) |
| 01:54.26 |
CIA-62 |
BRL-CAD:
03kunigami * r45670 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp
liboslrend.h sh_osl.cpp): added support for vector/normal/point and
matrix shader parameters |
| 03:07.52 |
CIA-62 |
BRL-CAD:
03brlcad * r45671 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp:
sanity, abort if we encounter a null |
| 03:08.07 |
CIA-62 |
BRL-CAD:
03brlcad * r45672 10/brlcad/trunk/src/conv/step/ (5 files):
ws |
| 04:22.17 |
CIA-62 |
BRL-CAD:
03brlcad * r45673 10/brlcad/trunk/configure.ac: PNG libtool library
is now libpng15.la |
| 04:27.20 |
CIA-62 |
BRL-CAD:
03brlcad * r45674 10/brlcad/trunk/src/libbn/plane.c: parallel is
set but unused, kill it |
| 04:34.05 |
CIA-62 |
BRL-CAD:
03brlcad * r45675 10/brlcad/trunk/src/libbn/plot3.c: more variable
set-but-unused warnings from gcc 4.7 (prerelease), but these are
actually needed. check the ret value and perror if we didn't write
all that was expected. |
| 04:38.20 |
*** join/#brlcad DarkCalf
(DC@173.231.40.98) |
| 04:40.45 |
CIA-62 |
BRL-CAD:
03brlcad * r45676 10/brlcad/trunk/src/librt/bundle.c: status is
unused, remove |
| 04:52.42 |
CIA-62 |
BRL-CAD:
03brlcad * r45677 10/brlcad/trunk/src/conv/step/ (STEPWrapper.cpp
STEPWrapper.h): convert InstMgr from an embedded class to a pointer
with allocation on the heap |
| 05:15.31 |
CIA-62 |
BRL-CAD:
03brlcad * r45678 10/brlcad/trunk/src/librt/prep.c: yet another
example why strict compilation is a "good thing" (tm). quell
warning about old_max being set but unused. turns out this was a
bug introduced several years ago in r36723 after a simple
refactoring. |
| 05:17.46 |
CIA-62 |
BRL-CAD:
03brlcad * r45679
10/brlcad/trunk/src/other/step/src/cleditor/instmgr.cc: plug a
memory leak accounting for almost a half MB. delete the InstMgr
master and sorted master manager node arrays. |
| 05:34.37 |
CIA-62 |
BRL-CAD:
03brlcad * r45680 10/brlcad/trunk/src/librt/primitives/ (bot/btgf.c
dsp/dsp.c): remove unused var |
| 05:36.15 |
CIA-62 |
BRL-CAD:
03brlcad * r45681
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: and
again, strictness catches a bug -- this one affects being able to
dbupgrade/dbopen incompatible v4 files. it basically was reading in
old bpline objects without applying a properly byte-flipped
matrix. |
| 05:38.13 |
CIA-62 |
BRL-CAD:
03brlcad * r45682
10/brlcad/trunk/src/other/step/src/cleditor/STEPfile.inline.cc:
delete the instances before deleting the container, don't just
clear them. plugs memory leak (though there is still lots to go for
scl) |
| 05:41.30 |
CIA-62 |
BRL-CAD:
03brlcad * r45683 10/brlcad/trunk/src/other/step/TODO: leaking
something nasty |
| 06:50.59 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 07:00.34 |
CIA-62 |
BRL-CAD:
03brlcad * r45684 10/brlcad/trunk/src/librt/ (13 files in 9 dirs):
quell a slew of gcc 4.7 detections of variables being set but
weren't being used. one of the nmg routines,
nmg_eval_linear_trim_to_tol(), is a little suspect but the rest
were mostly benign. |
| 09:59.59 |
CIA-62 |
BRL-CAD:
03bhinesley * r45685 10/brlcad/trunk/src/libged/edit.c: (log
message trimmed) |
| 09:59.59 |
CIA-62 |
BRL-CAD:
Renamed stupid "*_concise" functions to "*_wrapper". Added
functions to get the |
| 09:59.59 |
CIA-62 |
BRL-CAD: next
argument "head" in the union edit_cmd. Not too happy about adding
yet |
| 09:59.59 |
CIA-62 |
BRL-CAD:
another command-specific function; but it seems necessary to keep
separation, |
| 09:59.59 |
CIA-62 |
BRL-CAD:
while still having an intuitive way to build arguments (id est
union edit_cmd). |
| 10:00.00 |
CIA-62 |
BRL-CAD: With
these functions, we'll be able to pass over all of a command's
arguments, |
| 10:00.01 |
CIA-62 |
BRL-CAD:
without being aware of the union edit_cmd layout. The new plan is
to keep edit() |
| 11:00.10 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.209.201) |
| 11:00.10 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 11:04.06 |
*** join/#brlcad Stattrav_
(~Stattrav@111.93.134.142) |
| 11:12.08 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 11:12.08 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 12:10.46 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
| 12:10.46 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 13:08.16 |
CIA-62 |
BRL-CAD:
03brlcad * r45686 10/brlcad/trunk/src/libfb/ (if_X.c if_X24.c):
quell set-but-unused warnings |
| 13:11.30 |
CIA-62 |
BRL-CAD:
03brlcad * r45687 10/brlcad/trunk/src/libgcv/bottess.c: dir
unused |
| 13:14.02 |
CIA-62 |
BRL-CAD:
03brlcad * r45688 10/brlcad/trunk/src/libgcv/bottess.c: actually,
build just wasn't up to date -- dir is used now, but i is not.
quellage. |
| 13:17.41 |
CIA-62 |
BRL-CAD:
03brlcad * r45689 10/brlcad/trunk/src/libged/ (bo.c bot_dump.c):
remove slew of set-yet-unused vars |
| 13:22.29 |
CIA-62 |
BRL-CAD:
03brlcad * r45690 10/brlcad/trunk/src/libged/edit.c: gcc 4.7 no
longer considers these constant/computable at compile-time. so,
meh, set them at runtime. |
| 13:26.55 |
CIA-62 |
BRL-CAD:
03brlcad * r45691 10/brlcad/trunk/src/libged/ (glob.c human.c):
more set-and-unused var elimination |
| 13:30.22 |
CIA-62 |
BRL-CAD:
03brlcad * r45692 10/brlcad/trunk/src/libpc/pcVariable.h: j
unused |
| 13:31.59 |
CIA-62 |
BRL-CAD:
03brlcad * r45693 10/brlcad/trunk/src/librt/opennurbs_ext.cpp:
points a and b are unused, remove |
| 13:32.46 |
brlcad |
i'm liking
this new version of the compiler .. the warnings have actually
caught a slew of bugs, some minor, some not-so-minor |
| 13:40.31 |
CIA-62 |
BRL-CAD:
03brlcad * r45694 10/brlcad/trunk/include/bu.h: the pointer!=NULL
comparison is always true for variables on the stack. cast through
void so the compiler will shut it. |
| 13:42.25 |
CIA-62 |
BRL-CAD:
03brlcad * r45695 10/brlcad/trunk/src/libged/ (png.c ps.c red.c
screengrab.c tire.c): remainder of libged set-and-unused
warnings |
| 13:51.54 |
CIA-62 |
BRL-CAD:
03brlcad * r45696 10/brlcad/trunk/src/liboptical/photonmap.c:
unused due to commented code |
| 13:52.56 |
CIA-62 |
BRL-CAD:
03brlcad * r45697 10/brlcad/trunk/src/libdm/labels.c: we dont' do
anything with id, so don't bother saving it from
rt_db_get_internal() |
| 13:54.42 |
CIA-62 |
BRL-CAD:
03brlcad * r45698 10/brlcad/trunk/src/conv/ (3dm/3dm-g.cpp
dxf/dxf-g.c step/OpenNurbsInterfaces.cpp): set-and-unused
quellage |
| 13:56.17 |
CIA-62 |
BRL-CAD:
03brlcad * r45699 10/brlcad/trunk/src/librtserver/rtserver.c: idx
and los are unused, so get rid of them |
| 13:58.53 |
CIA-62 |
BRL-CAD:
03brlcad * r45700 10/brlcad/trunk/NEWS: |
| 13:58.53 |
CIA-62 |
BRL-CAD:
preliminary testing of the conversion from SCLstring to std::string
is showing a |
| 13:58.53 |
CIA-62 |
BRL-CAD:
consistent speed improvement in step-g for relatively small models.
Models |
| 13:58.53 |
CIA-62 |
BRL-CAD:
taking less than a few minutes to convert are now taking
approximately 10-30% |
| 13:58.53 |
CIA-62 |
BRL-CAD: less
time. Unfortunately, models that take more than 10-20 minutes still
take |
| 13:58.53 |
CIA-62 |
BRL-CAD:
10-20 minutes implying that some other processing dominates as the
files get |
| 13:58.53 |
CIA-62 |
BRL-CAD:
bigger. |
| 14:10.19 |
CIA-62 |
BRL-CAD:
03brlcad * r45701 10/brlcad/trunk/src/lgt/ (do_options.c
screen.h): |
| 14:10.19 |
CIA-62 |
BRL-CAD: let
TEMPLATE_COLS represent the number of chars not including null, so
we're |
| 14:10.19 |
CIA-62 |
BRL-CAD:
protected on both ends of printing. more tricky, gcc detected that
the |
| 14:10.19 |
CIA-62 |
BRL-CAD:
snprintf() range provided was too much since IR_AUTO_MAP_PTR
already indexes far |
| 14:10.19 |
CIA-62 |
BRL-CAD: into
template. |
| 14:12.47 |
brlcad |
and with
that, we have our first clean strict pass on 4.7 |
| 14:13.43 |
brlcad |
still have to
test optimized and 32-bit |
| 14:14.05 |
brlcad |
hits the road |
| 14:15.31 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45702 10/brlcad/trunk/src/libgcv/bottess.c: put
the i's back, they're necessary for the next step |
| 14:23.05 |
brlcad |
``Erik: I
figured that was a work-in-progress .. but the newer compiler
builds now halt on incomplete code that's enabled |
| 14:24.18 |
brlcad |
we'll have to
#if-wrap works in progress that get committed (that i var is
actually the only one that was active code,
surprisingly) |
| 14:24.54 |
brlcad |
rather like
it actually, encourages coding complete (and committing complete)
instead of stubbed functionality |
| 14:38.42 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:39.00 |
``Erik |
<PROTECTED> |
| 14:39.34 |
``Erik |
would rather not do a 2000 line commit O.o |
| 14:45.21 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 15:28.23 |
brlcad |
``Erik: I
think it's smart enough to recognize that's a no-op and the var is
still unused now |
| 15:32.38 |
brlcad |
starseeker:
so there are just two or three files that keep getting edited in
the source directory |
| 15:32.42 |
brlcad |
cmake is
building built in a separate build dir |
| 15:32.50 |
CIA-62 |
BRL-CAD:
03r_weiss * r45703
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 15:32.51 |
CIA-62 |
BRL-CAD:
Added two new functions to support the prototype version of
nmg_triangulate_fu. |
| 15:32.51 |
CIA-62 |
BRL-CAD:
These functions are 'nmg_tri_kill_accordions' and 'validate_tbl2d'.
The first |
| 15:32.51 |
CIA-62 |
BRL-CAD:
function is a specialized version of the 'nmg_kill_accordions'
function which |
| 15:32.51 |
CIA-62 |
BRL-CAD:
allows killed vertexuse to be removed (nulled out) from the tbl2d
table. The |
| 15:32.51 |
CIA-62 |
BRL-CAD:
second function verifies that all vertexuse within a faceuse is
stored in the |
| 15:32.52 |
CIA-62 |
BRL-CAD:
tbl2d table. These functions are a work in progress and are
disabled by default. |
| 15:32.52 |
brlcad |
zconf.h |
| 15:33.41 |
brlcad |
cssprop.tcl,
tokenlist.txt |
| 15:34.00 |
``Erik |
commits and runs O.O |
| 15:34.00 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45704 10/brlcad/trunk/src/libgcv/bottess.c: gut
stuff and use straight moller97, modified for BRL-CAD
types |
| 15:48.13 |
CIA-62 |
BRL-CAD:
03r_weiss * r45705
10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: Rewrote the
'nmg_kill_accordions' function within file 'nmg_mod.c'. The new
version has cleaner logic and will continue to remove all
accordions from a loopuse. |
| 15:54.33 |
*** join/#brlcad b0ef
(~b0ef@226.27.202.84.customer.cdi.no) |
| 15:59.31 |
CIA-62 |
BRL-CAD:
03r_weiss * r45706
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 15:59.31 |
CIA-62 |
BRL-CAD:
Updated function 'find_pt2d' within file 'nmg_tri.c'. This change
allows this |
| 15:59.31 |
CIA-62 |
BRL-CAD:
function to receive a null vertexuse pointer without crashing. In
addition, when |
| 15:59.31 |
CIA-62 |
BRL-CAD:
passed a null vertexuse pointer, this function will return the
first entry in |
| 15:59.31 |
CIA-62 |
BRL-CAD: the
table which contains a null vertexuse pointer. This is useful for
finding |
| 15:59.32 |
CIA-62 |
BRL-CAD:
entries in the table which can be reused instead of allocating a
new table |
| 15:59.33 |
CIA-62 |
BRL-CAD:
entry. |
| 16:16.07 |
brlcad |
bhinesley:
looks like a strict 4.6 build should work just fine now |
| 16:46.28 |
CIA-62 |
BRL-CAD:
03r_weiss * r45707
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 16:46.29 |
CIA-62 |
BRL-CAD:
Updated function 'join_mapped_loops' within file 'nmg_tri.c'. Added
more error |
| 16:46.29 |
CIA-62 |
BRL-CAD:
checking and did some code cleanup and improved the existing error
messages. |
| 16:46.29 |
CIA-62 |
BRL-CAD:
Changed some of the logic to support the prototype version of
the |
| 16:46.29 |
CIA-62 |
BRL-CAD:
'nmg_triangulate_fu' function. Under certain conditions a new
vertexuse can be |
| 16:46.29 |
CIA-62 |
BRL-CAD:
created and it was not adding this to the tbl2d table. The logic
changes are a |
| 16:46.30 |
CIA-62 |
BRL-CAD: work
in progress and are disabled by default. |
| 17:41.31 |
CIA-62 |
BRL-CAD:
03brlcad * r45708 10/brlcad/trunk/src/conv/step/BRLCADWrapper.cpp:
close the database on destruction, null out the pointer just in
case |
| 17:43.52 |
bhinesley |
brlcad,
sorry, there are still some issues: http://paste.pocoo.org/show/448279/ |
| 17:44.23 |
CIA-62 |
BRL-CAD:
03brlcad * r45709 10/brlcad/trunk/src/conv/step/step-g.cpp: so
there is definitely some funky stack corruption going on. deleting
the step wrapper crashes, investigating. |
| 17:44.55 |
bhinesley |
I cut out the
middle of the file around 337, because it was too big to upload.
The lines I cut out were similar to the ones directly before
it. |
| 17:45.26 |
brlcad |
bhinesley: no
need to be sorry, that's good |
| 17:45.54 |
brlcad |
strictness
almost always requires multi-platform compilation to get all the
issues ironed out |
| 17:49.59 |
CIA-62 |
BRL-CAD:
03brlcad * r45710 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: my
bad, STEPWrapper doesn't get to own the dotg instance, they're
stashing it for future use. was causing double-delete
badness. |
| 17:50.50 |
CIA-62 |
BRL-CAD:
03brlcad * r45711 10/brlcad/trunk/src/conv/step/step-g.cpp: safe to
delete stepwrapper again |
| 17:54.08 |
bhinesley |
brlcad: that
trimmed it down enough so that I can upload the whole file now:
http://paste.pocoo.org/show/448285/ |
| 17:54.18 |
brlcad |
cool,
thx |
| 17:54.28 |
bhinesley |
np |
| 17:54.43 |
bhinesley |
oops, wait...
that was the old one |
| 17:54.58 |
brlcad |
so in
actuality, only a dozen or so issues remaining |
| 17:55.17 |
brlcad |
all the
SdaiCONFIG_CONTROL_DESIGN ones aren't fatal (that's auto-generated
code) |
| 17:56.33 |
bhinesley |
nods |
| 17:57.01 |
bhinesley |
wgetpaste is
playing tricks on me... uploading the old version of a file that
has been overwritten (!) |
| 17:59.40 |
bhinesley |
ahh, n/m,
it's a problem with my primary selection/clipboard. The link in
here is good, the link getting pasted into my browser is
old. |
| 18:03.32 |
bhinesley |
counts about 50 errors, probably only a dozen or so unique as
brlcad mentioned |
| 18:45.51 |
CIA-62 |
BRL-CAD:
03r_weiss * r45712
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 18:45.51 |
CIA-62 |
BRL-CAD:
Changed the function 'join_mapped_loops' within file 'nmg_tri.c'. I
disabled one |
| 18:45.51 |
CIA-62 |
BRL-CAD: of
the error checks which was causing some problems. The error check
is now only |
| 18:45.51 |
CIA-62 |
BRL-CAD:
enabled when the prototype version of function 'nmg_triangulate_fu'
is enabled. |
| 18:46.30 |
CIA-62 |
BRL-CAD:
03brlcad * r45713
10/brlcad/trunk/src/conv/step/SdaiCONFIG_CONTROL_DESIGN.cc: delete
debug code |
| 18:47.29 |
abhi2011 |
hi |
| 18:47.43 |
abhi2011 |
I am trying
to add a command to mged |
| 18:48.03 |
abhi2011 |
its to learn
how to add commands basically |
| 18:48.21 |
abhi2011 |
so I have
copied out the tire.c file to a new file physics.c |
| 18:48.28 |
abhi2011 |
and made some
changes |
| 18:49.04 |
abhi2011 |
the command
will be simply called runphysics and has no parameters |
| 18:49.19 |
abhi2011 |
so apart from
making a new source file, are there any other changes
needed |
| 18:49.33 |
abhi2011 |
to compile it
as part of libged |
| 18:53.25 |
brlcad |
of course
:) |
| 18:53.46 |
abhi2011 |
in the
CMakeLists.txt i guess |
| 18:53.47 |
brlcad |
otherwise how
would libged know your new file from thesis.doc |
| 18:54.09 |
abhi2011 |
haha |
| 18:54.12 |
abhi2011 |
:) |
| 18:54.12 |
brlcad |
CMakeLists.txt and Makefile.am |
| 18:54.17 |
abhi2011 |
ok |
| 18:54.26 |
brlcad |
we have two
build systems being maintained at the moment |
| 18:54.29 |
brlcad |
so two
files |
| 18:54.45 |
abhi2011 |
ok, and the
specific CMakeLists.txt to be edited is the top level one in the
brlcad directory i guess |
| 18:54.49 |
brlcad |
once added,
that will compile the file |
| 18:55.13 |
brlcad |
then you'll
either want to add a command binding to mged or create a
stand-alone application wrapper |
| 18:55.30 |
abhi2011 |
ah yes the
command binding |
| 18:55.34 |
brlcad |
mged bindings
are in src/mged/setup.c |
| 18:55.37 |
abhi2011 |
there wqa a
specific c file for that |
| 18:55.38 |
abhi2011 |
right |
| 18:55.53 |
brlcad |
stand-alone
wrapper would be writing a small binary like
src/shapes/tire.c |
| 18:56.05 |
abhi2011 |
ok |
| 18:56.18 |
abhi2011 |
yah i ll try
with the command binding first |
| 18:56.24 |
abhi2011 |
though it
makes more sense |
| 18:56.31 |
abhi2011 |
to have it as
a binary wrapper |
| 18:56.53 |
abhi2011 |
I have an
interesting question though |
| 18:56.55 |
brlcad |
makes more
sense as an mged command, but a binary wrapper will be easier for
initial testing |
| 18:57.03 |
abhi2011 |
yes
exactly |
| 18:57.21 |
abhi2011 |
and most
physics engines |
| 18:57.28 |
abhi2011 |
can launch an
opengl render window |
| 18:57.38 |
abhi2011 |
and show
whats happening in the physics world |
| 18:57.55 |
abhi2011 |
which can
help at times |
| 18:58.11 |
brlcad |
well, that
would be mged |
| 18:58.34 |
abhi2011 |
yes right,
mged already shows an opengl windows |
| 18:58.37 |
brlcad |
writing
opengl or windowing code for a standalone binary would be
undesirable, waste of time frankly |
| 18:58.39 |
abhi2011 |
*window |
| 18:58.47 |
abhi2011 |
yes
right |
| 18:59.11 |
brlcad |
standalone
binary would be just to run the simulation, console debug printing,
simplified testing |
| 18:59.46 |
abhi2011 |
yes |
| 19:00.31 |
abhi2011 |
I understand
your point of course. Bullet already comes with accurate rendering
code though :) so there is no need to write it :) |
| 19:01.01 |
brlcad |
BRL-CAD
already comes with rendering code too, so there's no need to bind
to a new 3rd party interface |
| 19:01.11 |
abhi2011 |
hehe :) yes
true |
| 19:03.40 |
CIA-62 |
BRL-CAD:
03brlcad * r45714 10/brlcad/trunk/src/libdm/dm-ogl.c: quellage,
remove set-but-not-used variables |
| 19:06.45 |
brlcad |
bhinesley:
grep -E '(CURSES|TERM|TINFO)' include/brlcad_config.h |
| 19:06.49 |
brlcad |
(in your
build dir) |
| 19:07.00 |
brlcad |
/home/bhinesley/brlcad-trunk/src/libcursor/cursor.c
looks like a cmake detection failure |
| 19:07.17 |
brlcad |
not testing
for termcap or curses correctly |
| 19:07.42 |
brlcad |
same thing
with the burst too (Sc.c) |
| 19:08.43 |
brlcad |
so those look
like the only three problems, dm-ogl.c which I just fixed and those
two files (cursor.c and Sc.c) which have the same termcap detection
problem |
| 19:10.51 |
abhi2011 |
so I have
added a new command just after rtweight |
| 19:10.58 |
abhi2011 |
{"rtweight",
cmd_rt, GED_FUNC_PTR_NULL}, |
| 19:10.59 |
CIA-62 |
BRL-CAD:
03brlcad * r45715
10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: debug code
tracing down stack corruption accidentally got committed. re-enable
advanced brep entity loading. |
| 19:10.59 |
abhi2011 |
{"runphysics", cmd_rt,
GED_FUNC_PTR_NULL}, |
| 19:12.39 |
brlcad |
doesn't look
right |
| 19:12.54 |
brlcad |
you were
following the tire command, that's your example -- not
rtweight |
| 19:13.11 |
brlcad |
at least in
terms of what that line should look like, doesn't matter where it's
at |
| 19:17.29 |
abhi2011 |
ok yah the
tire command is a wrapper ...right i ll change it |
| 19:18.51 |
abhi2011 |
right this
should be ok |
| 19:18.54 |
abhi2011 |
<PROTECTED> |
| 19:18.56 |
abhi2011 |
<PROTECTED> |
| 19:18.57 |
abhi2011 |
<PROTECTED> |
| 19:19.16 |
abhi2011 |
i changed the
c function name of course in the .c file |
| 19:24.10 |
brlcad |
kunigami_:
just to be sure, you have seen http://code.google.com/p/openshadinglanguage/w/list
y es? |
| 19:24.54 |
bhinesley |
brlcad:
#define HAVE_TERMIO_H 1\n#define HAVE_TERMIOS_H 1 |
| 19:26.52 |
kunigami |
brlcad: yup.
I didn't read the light path expression because I thought that was
not a feature that would be useful for brlcad, or am I
wrong? |
| 19:29.28 |
abhi2011 |
brlcad: hmm I
went through the CMakeLists.txt file in the brlcad top level
directory, there does not appear to be a place to add a mged
command there |
| 19:29.38 |
abhi2011 |
for example I
dont see tire anywhere |
| 19:29.58 |
abhi2011 |
*mged
application wrapper i mean, not a command |
| 19:36.29 |
brlcad |
abhi2011: not
following |
| 19:36.35 |
brlcad |
you add it to
libged's file |
| 19:36.35 |
CIA-62 |
BRL-CAD:
03brlcad * r45716 10/brlcad/trunk/src/other/ (CMakeLists.txt
libz/CMakeLists.txt): test to see what breaks. leave the zconf.h
file alone, don't abort if it exists. |
| 19:37.43 |
bhinesley |
abhi2011: I
think you're looking for libged/CMakeList.txt |
| 19:38.46 |
abhi2011 |
ah
yes, |
| 19:38.57 |
brlcad |
starseeker:
I'll give that a go with some testing, but that should be a pretty
safe/easy change |
| 19:39.07 |
abhi2011 |
I have added
it to setup.c in src/mged/ |
| 19:39.17 |
abhi2011 |
and now I
want to add it to the build logic |
| 19:39.27 |
brlcad |
because
zconf.h isn't "actually" autogenerated .. at least zconf.h.in
doesn't have any substitution patterns, so it's just a
copy |
| 19:39.49 |
brlcad |
which means
there could be a million copies in a million include dirs and it
won't affect build in the least |
| 19:40.01 |
brlcad |
testing now
though |
| 19:40.31 |
abhi2011 |
so I guess
the right place to add the the new c file that implements
runphysics (i.e. src/libged/runphysics.c), to the build logic is
libged/CMakeList.txt |
| 19:42.06 |
CIA-62 |
BRL-CAD:
03brlcad * r45717 10/brlcad/trunk/src/other/libz/zconf.h.cmakein:
remove the _LARGEFILE64_SOURCE hack from the cmake template too.
causes build problems with system headers that also define
it. |
| 19:46.30 |
abhi2011 |
ok thats
done, now the autotools build has to know about the new c file as
well |
| 19:46.50 |
abhi2011 |
So I guess
the new filename should go into Makefile.am |
| 19:46.58 |
abhi2011 |
in the top
level directory |
| 19:47.11 |
bhinesley |
nope, in
libged/Makefile.am |
| 19:47.30 |
abhi2011 |
ah yes there
is one there too...right of course |
| 19:47.37 |
bhinesley |
haha |
| 19:47.44 |
abhi2011 |
:P |
| 19:48.20 |
abhi2011 |
these make
files and cmake files are all over the place ! |
| 19:49.13 |
``Erik |
hm, cmake
seems to do everything in it's power to prevent a profiling
build |
| 20:00.09 |
starseeker |
brlcad: yeah,
I actually have added the two define options in the cmakein file in
the CMakeLists.txt file as definitons, which means we don't need
that file at all. |
| 20:00.56 |
CIA-62 |
BRL-CAD:
03starseeker * r45718 10/brlcad/trunk/src/other/
(libz/CMakeLists.txt libz/zconf.h.cmakein libz.dist): Eliminate the
need for a separate zconf.h.cmakein file by simply adding the
definitions at the CMakeLists.txt level if they are
needed. |
| 20:03.53 |
starseeker |
looks at cssprop.tcl, tokenlist.txt to see if he can get them
to change |
| 20:11.12 |
CIA-62 |
BRL-CAD:
03r_weiss * r45719
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 20:11.12 |
CIA-62 |
BRL-CAD:
Updated the prototype version of function 'cut_unimonotone' within
file |
| 20:11.12 |
CIA-62 |
BRL-CAD:
'nmg_tri.c'. This function supports the prototype version of
function |
| 20:11.12 |
CIA-62 |
BRL-CAD:
'nmg_triangulate_fu'. Improved the error checking and the logic to
cleanup |
| 20:11.12 |
CIA-62 |
BRL-CAD:
problem loopuse. Also did some code cleanup. This change is
disabled by default. |
| 20:11.12 |
CIA-62 |
BRL-CAD: This
is a work in progress. |
| 20:19.07 |
starseeker |
``Erik:
here's a good quote for you: |
| 20:19.11 |
starseeker |
"You don't
make a good language by smashing a bunch of "projects" together. If
you do that, you end up with C++." |
| 20:21.36 |
CIA-62 |
BRL-CAD:
03bhinesley * r45720 10/brlcad/trunk/src/libged/edit.c: Changed all
union edit_cmd args to pointers. Kinda liked the idea of them being
automatic, as it would simplify building commands, but we need to
be able to shuffle them around easily for the *_add_arg
functions. |
| 20:22.57 |
CIA-62 |
BRL-CAD:
03bhinesley * r45721 10/brlcad/trunk/src/ (libdm/dm-ogl.c
libtclcad/tclcad_obj.c): Quiet some compiler warnings about unused
variables. |
| 21:04.42 |
CIA-62 |
BRL-CAD:
03starseeker * r45722
10/brlcad/trunk/src/other/libpng/configure.ac: autogen failed - add
back in what seem to be the related differences from the previous
libpng configure.ac |
| 21:06.33 |
starseeker |
in case
anyone else wants profiling w/cmake, it's
BRLCAD-ENABLE_PROFILING |
| 21:09.00 |
``Erik |
yeh, srry,
found that var earlier, only mentioned it to starseeker in
person |
| 21:17.32 |
CIA-62 |
BRL-CAD:
03starseeker * r45723
10/brlcad/trunk/src/other/libpng/configure.ac: whoops,
typo |
| 21:21.41 |
starseeker |
cool - with
that zconf.h change, in principle the CMake build should now leave
behind a pristine source tree |
| 21:33.23 |
CIA-62 |
BRL-CAD:
03starseeker * r45724 10/brlcad/trunk/configure.ac: need both
source and build dirs as includes now for libpng |
| 21:35.44 |
CIA-62 |
BRL-CAD:
03starseeker * r45725 10/brlcad/trunk/NEWS: Upgraded libpng to
1.5.4 |
| 21:36.53 |
starseeker |
brlcad: yeah,
I'm not seeing any changes to the tkhtml files here doing both an
autotools and cmake out of dir build... |
| 21:37.14 |
starseeker |
guess the
next thing to try is in dir... |
| 21:50.59 |
``Erik |
starseeker:
the slashdot comments on java7 release? |
| 21:53.08 |
starseeker |
heh -
yeah |
| 21:54.50 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45726 10/brlcad/trunk/src/libgcv/bottess.c:
cleanup, more style normalization, removal of some dead
code |
| 21:55.38 |
starseeker |
that should
take care of libpng, unless another platform exposes some issue -
working on Linux now |
| 22:01.44 |
CIA-62 |
BRL-CAD:
03starseeker * r45727
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Don't add
omit-frame-pointer if we're profiling - things are Not
Happy. |
| 22:53.28 |
CIA-62 |
BRL-CAD:
03r_weiss * r45728
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: Updated the
prototype version of function 'nmg_triangulate_fu' within file
'nmg_tri.c'. The logic was simplified and code cleanup was done.
This change is disabled by default. This is a work in
progress. |
| 23:41.10 |
*** join/#brlcad LainIwakuraX
(~yuki@d24-57-80-191.home.cgocable.net) |
| 06:18.08 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 06:18.08 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 06:58.40 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 07:03.34 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 09:35.41 |
d_rossberg |
starseeker:
the STRICT_FLAGS is a little bit disturbing to MSVC |
| 09:54.36 |
*** join/#brlcad Stattrav
(~Stattrav@122.178.209.201) |
| 09:54.42 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 10:12.24 |
abhi2011 |
ok thanks
bhinesly and brlcad |
| 10:41.07 |
abhi2011 |
bhinesley:
db_lookup(dbip, argv[2], 1) is correct then as db_lookup works on
objects inside the database, and sph1.s is an object inside the
sphere.g database |
| 10:41.54 |
abhi2011 |
however it
seems that ged_bb() treats the command line differently from what I
expect |
| 10:42.32 |
abhi2011 |
so I give the
db name first and the object name 2nd which is argv[1] and argv[2]
respectively |
| 10:43.35 |
abhi2011 |
but it treats
argv[1] also as an object name in the currently open db, so I
modified the code to pass argv+1 instead and argc =1, so that only
1 object name (sph1.s) gets passed |
| 10:44.13 |
abhi2011 |
like this :
if ( ged_bb(gedp, 1, argv+1) == GED_OK){.... |
| 10:45.26 |
abhi2011 |
ged_bb()
still doesnt return GED_OK though, so I am checking if something
else is going wrong |
| 11:08.43 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:19.11 |
abhi2011 |
ok I got the
bb now ! |
| 12:19.27 |
abhi2011 |
but it seems
I cant print the bound by just printing the gedp result
string |
| 12:19.53 |
abhi2011 |
so if i try
printf("%s\n", gedp->ged_result_str); |
| 12:20.09 |
abhi2011 |
then i get
�;3� !! |
| 12:20.44 |
abhi2011 |
I ll check if
its actually a char* |
| 12:37.46 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 12:49.35 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:08.57 |
abhi2011 |
ah ok its a
variable length string to save memory |
| 13:13.12 |
abhi2011 |
YES!!!...finally got the bb printed
:P |
| 13:13.20 |
abhi2011 |
printf("%s\n", (
((gedp->ged_result_str)->vls_str) +
((gedp->ged_result_str)->vls_offset) ) ); |
| 13:13.38 |
abhi2011 |
output is
same as in archer for a unit sphere centred at the
origin |
| 13:15.39 |
abhi2011 |
perhaps not
the most efficient but works : http://bin.cakephp.org/view/1085618267 |
| 13:46.31 |
starseeker |
d_rossberg:
"disturbing?" |
| 13:52.21 |
d_rossberg |
MSVC does not
know how to handle a "STRICT_FLAGS" compiler switch, so it tries to
open a file with this name |
| 13:53.24 |
d_rossberg |
probable a
problem in cmake: not STRICT_FLAGS is meant but its
value |
| 13:55.44 |
*** join/#brlcad DarkCalff
(DC@173.231.40.98) |
| 14:56.59 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 15:12.18 |
brlcad |
abhi2011: so
this is going to be a learning experience, but good work figuring
out how to print the bb |
| 15:13.21 |
brlcad |
your end
result uses the libged API, which is a very high-level
interface |
| 15:13.32 |
brlcad |
a few
"mistakes", one being what you did with ged_result_str |
| 15:13.57 |
brlcad |
it's a struct
bu_vls ... and accessing the internal vls_str and vls_offset is a
no-no |
| 15:14.16 |
brlcad |
there are
printing routines for that |
| 15:14.32 |
brlcad |
you'd either
use bu_log() instead of printf() where you can use %V to print
them |
| 15:15.11 |
brlcad |
or you'd call
printf() with bu_vls_addr(dedp->ged_result_str) to get the
underlying char * |
| 15:16.22 |
brlcad |
abhi2011: so
then the next useful step is to compute the bounding box without
calling ged_open() or ged_bb(), using the lower level librt API
that libged is using |
| 15:24.05 |
CIA-62 |
BRL-CAD:
03kunigami * r45767 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp
liboslrend.h sh_osl.cpp): changed the field reflection by ray_type
so that it can also represent transmission rays. I hope this way
the logic gets clearer |
| 15:40.28 |
abhi2011 |
brlcad :
right will try that |
| 15:43.44 |
brlcad |
so,
db_open(), and other db_*() and rt_*() api calls, no ged_*()
functions |
| 15:44.03 |
brlcad |
that will be
what your physics command will need to do |
| 15:44.10 |
abhi2011 |
yes, that was
my other option if libged were not to work, but chose the easy way
out first :P |
| 15:44.23 |
abhi2011 |
yes
right |
| 15:44.47 |
brlcad |
nothing wrong
with that approach |
| 15:45.08 |
brlcad |
and in most
other contexts, calling libged would be fine too |
| 15:45.26 |
abhi2011 |
umm so why
not in this case too |
| 15:45.33 |
brlcad |
if anything,
you can read the source for ged_bb() and follow the functions to
see how it computes the bb |
| 15:45.42 |
abhi2011 |
yes i did
that |
| 15:45.52 |
abhi2011 |
i know how to
use the librt functions now |
| 15:46.01 |
brlcad |
so then it
should be very clear and trivial to convert ;) |
| 15:46.09 |
abhi2011 |
yep
:) |
| 15:46.25 |
brlcad |
this case is
different because you're also implementing a libged
function |
| 15:46.49 |
abhi2011 |
so we cannot
use other libged functions ? |
| 15:47.04 |
abhi2011 |
that are
exported...just curious |
| 15:47.04 |
brlcad |
ged functions
shouldn't be built on other ged functions when the common
functionality has already been refactored into librt |
| 15:47.10 |
brlcad |
it just adds
layered complexity |
| 15:47.11 |
abhi2011 |
ah
ok |
| 15:47.22 |
abhi2011 |
and will
introduce delays |
| 15:47.23 |
brlcad |
as well as
slows things down |
| 15:47.25 |
brlcad |
nods |
| 15:47.27 |
abhi2011 |
yep |
| 15:47.55 |
brlcad |
the slow down
in negligible for interactive use, but is significant for
programmatic use |
| 15:48.14 |
abhi2011 |
yah...we want
real time motion..yay ! |
| 15:48.18 |
abhi2011 |
:) |
| 15:49.16 |
abhi2011 |
by the way I
was wondering, brl cad was used before my usmil right |
| 15:49.35 |
abhi2011 |
so they moved
on to other software and open sourced this ? |
| 15:50.40 |
abhi2011 |
I was looking
for some of the full forms of the primitives like tgc in google and
I came across this :
http://www.digitaldogma.org/archive/MikeMuuss/papers/brlcad5.0/html/mged/tableofcontents2_1.html |
| 16:16.49 |
*** join/#brlcad survery
(~thomas@dslb-178-007-120-202.pools.arcor-ip.net) |
| 16:17.05 |
*** part/#brlcad survery
(~thomas@dslb-178-007-120-202.pools.arcor-ip.net) |
| 16:21.16 |
bhinesley |
abhi2011:
that makes sense. I was looking for calls directly to db_lookup in
your pastbin; I didn't catch that. Glad you got it
working. |
| 16:24.39 |
abhi2011 |
bhinesley:
yep, converting to use only rt now |
| 17:22.49 |
CIA-62 |
BRL-CAD:
03starseeker * r45768
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Was getting too
clever for my own good. If ADD_NEW_FLAG comes in empty, don't do
anything - should avoid the error on Windows |
| 17:28.03 |
CIA-62 |
BRL-CAD:
03r_weiss * r45769 10/brlcad/trunk/include/raytrace.h: |
| 17:28.03 |
CIA-62 |
BRL-CAD:
Added an entry into the 'raytrace.h' header for a new function
'nmg_keu_zl' |
| 17:28.03 |
CIA-62 |
BRL-CAD:
which removes all zero length edgeuse from an nmg shell. This
function is |
| 17:28.03 |
CIA-62 |
BRL-CAD:
disabled by default and is a work in progress. This function
supports the |
| 17:28.03 |
CIA-62 |
BRL-CAD:
prototype version of 'nmg_triangulate_fu'. |
| 17:31.08 |
CIA-62 |
BRL-CAD:
03r_weiss * r45770
10/brlcad/trunk/src/librt/primitives/nmg/nmg_mk.c: |
| 17:31.08 |
CIA-62 |
BRL-CAD:
Added a new function 'nmg_keu_zl' which removes all zero length
edgeuse from an |
| 17:31.08 |
CIA-62 |
BRL-CAD: nmg
shell. This was added into file 'nmg_mk.c'. This function is
disabled by |
| 17:31.08 |
CIA-62 |
BRL-CAD:
default and supports the prototype version of 'nmg_triangulate_fu'.
This is a |
| 17:31.08 |
CIA-62 |
BRL-CAD: work
in progress. |
| 17:42.59 |
CIA-62 |
BRL-CAD:
03r_weiss * r45771 10/brlcad/trunk/src/librt/primitives/tor/tor.c:
(log message trimmed) |
| 17:42.59 |
CIA-62 |
BRL-CAD:
Updated function 'rt_tor_tess' within file
'src/librt/primitives/tor/tor.c' by |
| 17:42.59 |
CIA-62 |
BRL-CAD:
adding a call to function 'nmg_keu_zl' which removes all zero
length edgeuse. |
| 17:42.59 |
CIA-62 |
BRL-CAD:
Under certain conditions the function 'rt_tor_tess' will create a
tessellated |
| 17:42.59 |
CIA-62 |
BRL-CAD:
torus which contains zero length edgeuse which is invalid and
causes a crash in |
| 17:43.00 |
CIA-62 |
BRL-CAD:
later functions. An example of a torus which causes a crash during
'facetize' is |
| 17:43.00 |
CIA-62 |
BRL-CAD:
object 'old.s82' within the 'm35.g' sample model. This change is
disabled by |
| 18:18.57 |
CIA-62 |
BRL-CAD:
03kunigami * r45772 10/brlcad/trunk/src/rt/view.c: added a
dedicated buffer to keep partial sums on multi-sample
modes |
| 18:24.54 |
CIA-62 |
BRL-CAD:
03kunigami * r45773 10/brlcad/trunk/src/rt/view.c: had left behind
a debug message |
| 18:27.20 |
``Erik |
mysql removed
from osX.7, nice |
| 19:04.33 |
CIA-62 |
BRL-CAD:
03brlcad * r45774 10/brlcad/trunk/include/vmath.h: add missing zero
macros, HNEAR_ZERO(), VZERO(), V2ZERO(), & HZERO() |
| 19:04.43 |
CIA-62 |
BRL-CAD:
03r_weiss * r45775
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message
trimmed) |
| 19:04.43 |
CIA-62 |
BRL-CAD:
Added new functions 'print_loopuse_tree',
'nmg_classify_pt_loop_new', |
| 19:04.43 |
CIA-62 |
BRL-CAD:
'nmg_classify_lu_lu_new', 'insert_above', 'insert_node'
and |
| 19:04.43 |
CIA-62 |
BRL-CAD:
'nmg_build_loopuse_tree' to file 'nmg_tri.c'. These function are
prototype |
| 19:04.44 |
CIA-62 |
BRL-CAD:
functions which support the prototype version of
'nmg_triangulate_fu'. Some of |
| 19:04.44 |
CIA-62 |
BRL-CAD:
these functions may have their names changed or moved to a more
appropriate |
| 19:04.45 |
CIA-62 |
BRL-CAD:
location within the code. These functions are the beginning of code
which |
| 19:05.34 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:20.56 |
brlcad |
kunigami: it
might be beneficial in the long run to use a long or floating point
accumulation buffer |
| 19:21.31 |
kunigami |
yup I'm using
long |
| 19:21.47 |
brlcad |
awesome,
missed that ;) |
| 19:24.41 |
brlcad |
that means
we'll be able to accumulate about 16M passes before the buffer is
"full" (at 32-bit) .. that's a lot of hypersampling ;) |
| 19:25.59 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 19:27.04 |
kunigami |
when adding
inside sh_osl, I could have values greater than 1.0, but with
averages bellow 1.0. Thus, it was not "clamped". now, if I have any
component greater than 1.0, it will be clamped and the average will
be near 0 if the other components are 0. I have a test Scenesthat
relies on strong brightnes. It was rendered nicely before, but now
it is too dark. Would be wrong if I avoid clamping the components
of the sum, but only the sum itself? |
| 19:38.58 |
brlcad |
kunigami: if
I understand you correctly (and I'm not 100% sure that I do), then
yes.. you can use the buffer as an accumulation buffer and
clamp/average/downsample at some later processing stage |
| 19:42.24 |
brlcad |
for
hypersampling, for example, instead of accumulating "value/#rays"
for each hypersample ray (i.e. val/#rays * #rays =>
final_value), it would accumulate "value" as-is (resulting in
"value * #rays" in the buffer), then divide by the #rays at the end
or scale to 255 or whatever |
| 19:45.46 |
CIA-62 |
BRL-CAD:
03brlcad * r45776 10/brlcad/trunk/BUGS: a torus with a zero sized
inner diameter results in zero-length edges during tessellation.
nmg_keu_zl() could remove them, but it implies there is a flaw in
the rt_tor_tess() logic not accounting for the edge
case. |
| 19:46.43 |
brlcad |
kunigami: did
my response make sense about the two different options? |
| 19:50.42 |
kunigami |
brlcad: yes,
that makes sense. I'll do the same way as hypersampling,
thanks |
| 20:40.49 |
*** join/#brlcad merzo
(~merzo@59-47-132-95.pool.ukrtel.net) |
| 21:26.36 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 21:46.33 |
CIA-62 |
BRL-CAD:
03kunigami * r45777 10/brlcad/trunk/src/rt/ (do.c view.c): changed
the accumulator buffer to float so that it saves the raw components
of ap.a_color before theyre clamped. We only expand and clamp it
when moving the partial sums to scanline |
| 22:01.47 |
*** join/#brlcad Yoshi477
(~jan@d72-39-60-53.home1.cgocable.net) |
| 22:14.43 |
abhi2011 |
so I am
trying to get the bb now using librt only |
| 22:14.52 |
abhi2011 |
here is the
code so far : http://bin.cakephp.org/view/570066725 |
| 22:15.12 |
abhi2011 |
I run it as
./a.out dome.g sph2.s rcc2.s |
| 22:15.34 |
abhi2011 |
the objects
are present in the dome.g database file as I can see them in
archer |
| 22:15.58 |
abhi2011 |
yet :
db_lookup(sph2.s) failed: sph2.s does not exist |
| 22:16.07 |
abhi2011 |
so I am
debugging with gdb now |
| 22:16.53 |
abhi2011 |
and I saw
that inside db_lookup there is a line that tries to hash the name
'sph2.s' (when its being looked up) |
| 22:17.56 |
abhi2011 |
line 230 : dp
= dbip->dbi_Head[db_dirhash(name)]; |
| 22:18.38 |
abhi2011 |
the hash for
'sph2.s' is 747 which is why dbip->dbi_Head[db_dirhash(name)];
returns null and consequently the lookup fails |
| 22:23.15 |
abhi2011 |
probably the
hash value can be anything, but perhaps its out of range in this
case of the array dbi_Head[] |
| 22:31.29 |
abhi2011 |
perhaps its
because the objects sph2.s and rcc2.s are leaves, that is they are
not children of higher levels groups |
| 23:01.48 |
abhi2011 |
probaly the
directory is not built up already as in the rtexample.c |
| 23:13.24 |
abhi2011 |
ok easier to
use rtip = rt_dirbuild(argv[1], title, sizeof(title)); |
| 23:13.47 |
abhi2011 |
and
rt_gettree(rtip, argv[2]) with bb calculated using
rt_prep_parallel(rtip, 1); |
| 23:24.19 |
``Erik |
*reads he
pastebin* yeah, you do need an rt_prep somewhere in there, that's
where the bb gets set |
| 23:25.28 |
abhi2011 |
well yes, but
I did not reach that far in that code, the db_lookup() called from
db_string_to_path() in line 50, barfed well before that
! |
| 23:25.40 |
abhi2011 |
I guess cause
there was no directory built up |
| 23:26.14 |
abhi2011 |
this command
would normally get called from inside mged when rtip would have a
valid directory setup containing the structure of the
model |
| 23:26.44 |
abhi2011 |
but for the
command line program its probably not so, so I have to start by
calling rt_dirbuild() |
| 23:27.36 |
``Erik |
hm, yeah (not
too familiar with the very early stages of opening/parsing a .g,
myself), I think you're right |
| 23:28.23 |
``Erik |
some of the
src/conv/ programs use prepared geometry and are quite a bit
simpler than the src/rt stuff... might be worth poking around in
there for examples |
| 23:28.49 |
CIA-62 |
BRL-CAD:
03bhinesley * r45778 10/brlcad/trunk/src/libged/edit.c: |
| 23:28.49 |
CIA-62 |
BRL-CAD:
Started on functions that convert db_full_path objects to points
(natural |
| 23:28.49 |
CIA-62 |
BRL-CAD:
origin/bounding box center); WIP. edit() was getting a bit
difficult to read, |
| 23:28.49 |
CIA-62 |
BRL-CAD:
which has led to several bugs, so I broke out batch expansion code
into |
| 23:28.49 |
CIA-62 |
BRL-CAD:
edit_arg_expand(). There are still some problems preventing this
from working, |
| 23:28.50 |
CIA-62 |
BRL-CAD: but
I haven't commited in a while and need to. Several changes to
struct |
| 23:28.51 |
CIA-62 |
BRL-CAD:
edit_arg helper functions; needed more versatility |
| 23:29.07 |
abhi2011 |
ah ok, umm
why the 'conv' are they converted from some other library or
something ? |
| 23:30.05 |
``Erik |
converting
between formats |
| 23:30.38 |
bhinesley |
abhi2011, the
HACKING file tells you what the major directories are
for |
| 23:31.05 |
``Erik |
g-shell-rect.c fires rays to solve new
geometry |
| 23:31.35 |
``Erik |
um, also; the
rtcmp toplevel project has an rt directory with a VERY minimal and
simple example of how to get rt firing rays at geometry |
| 23:33.09 |
abhi2011 |
ah yes right
thanks Erik and bhinesley |
| 23:33.13 |
``Erik |
which is
rt_dirbuild(); rt_gettree(); rt_prep_parallel(); |
| 23:34.45 |
abhi2011 |
the rtcmp
sounds interesting, will have a look |
| 23:36.01 |
``Erik |
it's minimal
and hackish, was to compare performance/correctness between 3
raytracing engines |
| 23:36.14 |
``Erik |
not
"production" code :) |
| 23:36.57 |
abhi2011 |
ok, yah I
just need a quick intro to raytracing using brlcad |
| 23:40.13 |
``Erik |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/rtcmp/trunk/rt/rt.c?revision=34030&view=markup |
| 23:40.52 |
``Erik |
that's about
as simple as it gets... the hit() function is a bit more than you
might need, but the rest... :) |
| 23:47.00 |
abhi2011 |
hmm I
understand most of it except the hit function |
| 23:47.22 |
abhi2011 |
seems its
partitioning the 3d space around the point where the ray hit some
geometry |
| 23:47.46 |
abhi2011 |
and
calculating the outward pointing normal at that point on its
surface....wild guess |
| 23:48.45 |
``Erik |
yeah,
rt_shootray() needs hit and miss callbacks set in the application
structure and calls one of them depending on what
happened |
| 23:49.00 |
``Erik |
the hit
function gets fed a boolean evaluated "partition list" |
| 23:49.28 |
``Erik |
my hit()
function there is solving normals and repacking the results into a
different partition list format (for comparison) |
| 23:50.00 |
``Erik |
if a_onehit
is set, it'll only fill the first partition, useful for visual
raytracing |
| 23:50.36 |
abhi2011 |
ok so these
partitions represent cubiodal regions in 3d space ? |
| 23:51.29 |
abhi2011 |
i am thinking
in terms of partitioning of the 3d space into 8 different regions
around a point |
| 23:51.47 |
abhi2011 |
around the 3
axes |
| 23:52.06 |
``Erik |
no, they're
segments along the ray where it intersects geometry |
| 23:52.26 |
abhi2011 |
ah
ok |
| 23:52.41 |
abhi2011 |
so some
segments will be inside the geomtry and some outside |
| 23:53.06 |
abhi2011 |
which can be
decided using the equation of a sphere for example if a sphere is
the geometry |
| 23:53.28 |
``Erik |
it does
boolean evaluation before generating the partition list (using the
boolweave() function in rt), so that's actual solid geometry in
those partitions |
| 23:54.02 |
abhi2011 |
ok |
| 23:54.36 |
``Erik |
if you have a
1 radius sphere at the origin and subtract an arb8 that's across an
origin plane and shoot perpendicular to that plane, you'll see a
partition that says "I hit a sphere from 1,0,0 to
0,0,0" |
| 23:54.47 |
``Erik |
is that
confusing enough? :D |
| 23:56.02 |
abhi2011 |
no I am
getting it slowly :P, but I am familiar with all the short forms of
the primitves yet, so arb8 is a rectangle or a plane ? |
| 23:56.19 |
abhi2011 |
*not
familiar |
| 23:56.19 |
``Erik |
arb8 is a
box |
| 23:56.22 |
abhi2011 |
ok |
| 23:57.04 |
abhi2011 |
right i get
it |
| 23:57.32 |
abhi2011 |
but wait we
have subtracted an arb8 |
| 23:57.36 |
``Erik |
http://brlcad.org/gallery/d/170-2/primitives.png |
| 23:57.48 |
abhi2011 |
so there is a
hollow region inside the sphere |
| 23:57.56 |
``Erik |
well, a
sphere cut in half |
| 23:58.04 |
abhi2011 |
ah yes
right |
| 23:58.42 |
abhi2011 |
ah cool thats
handy |
| 00:29.01 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 01:42.57 |
*** join/#brlcad merzo
(~merzo@9-227-132-95.pool.ukrtel.net) |
| 02:05.14 |
CIA-62 |
BRL-CAD:
03starseeker * r45788 10/brlcad/trunk/src/other/ (6 files in 4
dirs): More Tcl/Tk build logic changes, again backported from 8.6
experiments. |
| 02:06.35 |
CIA-62 |
BRL-CAD:
03starseeker * r45789 10/brlcad/trunk/misc/CMake/FindX11.cmake:
FindX11 changes from tk - really need to put together some svn foo
to have all these multiple copies of files come from one source
file. |
| 02:10.24 |
starseeker |
brlcad: I
don't suppose we could skip straight to svn 1.6?
http://stackoverflow.com/questions/1355956/can-we-set-single-file-as-external-in-subversion |
| 02:18.20 |
brlcad |
starseeker:
er, how does that affect us? |
| 02:18.36 |
brlcad |
they're
talking about svn:external |
| 02:20.32 |
brlcad |
like, I want
to set up MagicSpecialSauce.cmake with my awesome macro definitions
as an svn external embedded into every cmake-using svn repos around
the world |
| 02:22.01 |
brlcad |
for checking
out a single file, 1.5 added a hackish manual workaround way to do
it |
| 02:23.24 |
brlcad |
the hack
might be useful for gs, but not strictly necessary |
| 02:23.55 |
brlcad |
kunigami: you
can run "fbhelp" and it'll list your available framebuffer
devices |
| 02:24.14 |
brlcad |
/dev/X or
/dev/wgl or /dev/ogl are the usual suspects |
| 02:25.35 |
brlcad |
bhinesley:
db_non_union_push() |
| 02:27.07 |
brlcad |
bhinesley:
er, never mind .. misread |
| 02:27.41 |
brlcad |
if you call
db_walk_tree(), there is a callback that will have the composite
matrix accumulated |
| 02:27.56 |
brlcad |
see
src/libged/push.c or src/libged/xpush.c |
| 02:28.23 |
brlcad |
(which are
two ged commands that should be refactored into one
...) |
| 03:11.32 |
starseeker |
gah this is
weird - I can successfully compile tcl/tk 8.6 and run it, but when
I try 8.5 wish doesn't work - it segfaults immediately on Tk_Main,
and I can't even tell why in the debugger |
| 03:16.55 |
brlcad |
sounds
familiar :) |
| 03:17.05 |
brlcad |
maybe you can
finally reproduce that bug I mentioned |
| 03:17.15 |
starseeker |
you mean the
iwidgets bug? |
| 03:17.27 |
brlcad |
no, different
init bug |
| 03:17.39 |
brlcad |
iwidgets was
yet another |
| 03:17.57 |
starseeker |
gets curious and tries 8.6 with BRL-CAD... |
| 03:21.50 |
starseeker |
oh, right -
would need the new itcl/itk too |
| 03:22.25 |
starseeker |
alright...
how the heck do I debug this? |
| 03:22.37 |
starseeker |
braces himself for a long day tomorrow... |
| 03:25.52 |
brlcad |
why does it
crash |
| 03:26.00 |
starseeker |
segmentation
fault |
| 03:31.23 |
brlcad |
more specific
than that |
| 03:31.51 |
brlcad |
presumably
dereferencing some variable that is not a valid pointer |
| 03:31.53 |
starseeker |
http://pastebin.mozilla.org/1290015 |
| 03:32.36 |
starseeker |
http://bzflag.bz/~starseeker/tcltk85-cmake.tar.gz
is what I'm working with |
| 03:34.11 |
starseeker |
cd tcltk85
&& mkdir build && cd build && cmake ..
&& make -j4 && gdb ./bin/wish |
| 03:35.11 |
starseeker |
in a way it
actually reminds me of the wish.exe failure we get on
Windows |
| 03:35.49 |
starseeker |
8.6 actually
working is a temptation... wonder how we would do with the next-gen
itcl/itk |
| 03:41.55 |
starseeker |
decides tomorrow is the time to test that and heads
home |
| 03:45.59 |
*** join/#brlcad nsd_
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 04:00.21 |
brlcad |
starseeker:
ah, making more sense .. so then since it's actually crashing *on*
the call to Tk_main() .. my guess is that it's probably getting the
wrong libtk |
| 04:02.27 |
brlcad |
make sure
you've installed and it's pulling the right libs at runtime (force
the (DY)LD_LIBRARY_PATH setting) |
| 04:43.29 |
starseeker |
brlcad: it
should be pulling the right lib |
| 04:51.59 |
brlcad |
of course it
should |
| 04:52.05 |
brlcad |
but is it
really |
| 04:54.56 |
brlcad |
the crash
would indicate 'maybe not' or there's some static initializer
causing havoc or lib incompat with binary, etc |
| 05:43.12 |
bhinesley |
brlcad: looks
good, thanks |
| 07:33.15 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 08:51.21 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 10:53.31 |
abhi2011 |
Hi |
| 10:53.42 |
abhi2011 |
I am playing
with the nirt program now |
| 10:54.18 |
abhi2011 |
so I was
looking at the example in page 5 of the Interactive Ray Tracing_The
nirt command.pdf file |
| 10:55.03 |
abhi2011 |
there are
these 2 lines in the example : |
| 10:55.06 |
abhi2011 |
nirt>
s |
| 10:55.07 |
abhi2011 |
Origin (x y
z) = (6.63324958 0.00000000 0.80000000) (h v d) = (0.0000 0.8000
0.0000) |
| 10:55.50 |
abhi2011 |
this was got
after automatically backing out the origin point from which the ray
was shot by setting backout as 1 |
| 10:56.11 |
abhi2011 |
what I dont
get is the h v d reported for the vew co-ordinates |
| 10:57.18 |
abhi2011 |
I am guessing
h v d is horizontal distance which is distance along x, vertical
distance along z, depth along y |
| 10:58.01 |
abhi2011 |
so in this
case since the origin of the ray has been auto backed out to
(6.63324958 0.00000000 0.80000000), hvd should be =(6.63324958
0.8000 0.0000) |
| 10:58.38 |
abhi2011 |
because the h
represent horizontal distance along x and the x value of the origin
of the ray is 6.6332 |
| 11:47.36 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 11:53.31 |
abhi2011 |
wow the nirt
in mged visualization is amazing !! |
| 14:17.36 |
starseeker |
brlcad: ldd
thinks it's pulling the right one: http://pastebin.mozilla.org/1290563 |
| 14:22.14 |
starseeker |
can
LD_LIBRARY_PATH override what ldd is reporting? |
| 14:25.02 |
starseeker |
hmm, ok... so
the old build did work and the new one doesn't - what did I
change... |
| 15:33.01 |
brlcad |
no, ldd takes
ld-library-path into account |
| 15:56.05 |
CIA-62 |
BRL-CAD:
03brlcad * r45790 10/brlcad/trunk/include/ (bu.h fbio.h): move
RED/GRN/BLU from fbio to bu given how fundamental the need for
indexing into an rgb[3] array is. |
| 16:03.31 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 16:04.19 |
CIA-62 |
BRL-CAD:
03brlcad * r45791 10/brlcad/trunk/src/proc-db/sphflake.c: eek,
wasn't using libbu memory management. call libbu and free
dynamically allocated memory. |
| 17:39.26 |
*** join/#brlcad emagdalena
(~emagdalen@129.Red-88-4-185.dynamicIP.rima-tde.net) |
| 18:33.33 |
CIA-62 |
BRL-CAD:
03brlcad * r45792 10/brlcad/trunk/src/proc-db/ (CMakeLists.txt
Makefile.am menger.c): (log message trimmed) |
| 18:33.33 |
CIA-62 |
BRL-CAD:
initial implementation of a new procedural geometry generator that
makes menger |
| 18:33.33 |
CIA-62 |
BRL-CAD:
sponges. menger sponges are sierpinski carpet patterns in 3d.
this |
| 18:33.33 |
CIA-62 |
BRL-CAD:
implementation supports creating the normal 'inside' subtraction
patterns as |
| 18:33.33 |
CIA-62 |
BRL-CAD: well
as inverted 'outside' subtraction patterns. there are also options
to only |
| 18:33.34 |
CIA-62 |
BRL-CAD:
perform the patterns along specified xyz axes. this test case was
written as a |
| 18:33.35 |
CIA-62 |
BRL-CAD:
means to test/compare performance of arb8+csg evaluation against
evaluated bot |
| 18:48.59 |
*** join/#brlcad emagdalenag
(~emagdalen@129.Red-88-4-185.dynamicIP.rima-tde.net) |
| 18:49.55 |
*** join/#brlcad emagdalena
(~emagdalen@129.Red-88-4-185.dynamicIP.rima-tde.net) |
| 18:50.12 |
*** join/#brlcad emagdalenag
(~splineman@129.Red-88-4-185.dynamicIP.rima-tde.net) |
| 20:10.23 |
*** join/#brlcad merzo
(~merzo@66-250-132-95.pool.ukrtel.net) |
| 20:39.37 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45793 10/brlcad/trunk/src/proc-db/menger.c: free
light1 instead of double-freeing light0 |
| 20:56.25 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 21:06.59 |
brlcad |
oops |
| 21:07.19 |
brlcad |
fyi, still
working on that proc |
| 21:07.34 |
brlcad |
going to
change the way it creates the layers to make better csg |
| 21:07.44 |
``Erik |
it blows up
pretty quick with -r values :) |
| 21:07.47 |
brlcad |
right now, it
blows the stack after four levels |
| 21:08.03 |
brlcad |
er, after *3*
levels |
| 21:08.10 |
``Erik |
at -r3,
there're some insane length names, too |
| 21:08.49 |
brlcad |
yeah, you can
e up each level individually, though |
| 21:09.12 |
brlcad |
e
level1.c |
| 21:09.17 |
brlcad |
should look
sane |
| 21:09.42 |
brlcad |
each level is
also presently independent, so they overlap space |
| 21:09.49 |
``Erik |
rt level2.c
seems to hang, or take a really really long time |
| 21:10.03 |
brlcad |
it's just a
really long time |
| 21:10.15 |
brlcad |
prep is
insane |
| 21:10.33 |
brlcad |
about a half
hour iirc |
| 21:11.08 |
brlcad |
it evaluates
all the individual pushed matrices and ends up recursing several
thousand times |
| 21:16.20 |
abhi2011 |
Erik: I have
a question about nirt |
| 21:16.48 |
``Erik |
sooooo, ask
it? :D |
| 21:17.16 |
bhinesley |
hey... what
do you think this is, a public forum?! |
| 21:17.36 |
abhi2011 |
So I am in
page 5 of the nirt interactive ray tracing pdf :P |
| 21:17.57 |
abhi2011 |
and there is
the view co ordinates shown in 1 of the examples |
| 21:18.06 |
abhi2011 |
(h v d) =
(0.0000 0.8000 0.0000) |
| 21:18.27 |
abhi2011 |
the complete
line is : Origin (x y z) = (6.63324958 0.00000000 0.80000000) (h v
d) = (0.0000 0.8000 0.0000) |
| 21:18.46 |
abhi2011 |
so the ray
was short from x = 6.633, 0, 0.8 |
| 21:19.00 |
abhi2011 |
thus hvd
should be = 6.633, 0.8 , 0 |
| 21:19.06 |
abhi2011 |
not as
shown |
| 21:19.27 |
abhi2011 |
because h
represent "Horizontal" distance right ? |
| 21:19.34 |
abhi2011 |
and v is
vertical |
| 21:20.18 |
abhi2011 |
hvd is the
co-ordinates of the ray origin in view co-ordinates |
| 21:22.17 |
starseeker |
abhi2011: no,
xyz is the origin |
| 21:22.22 |
starseeker |
hvd is the
view plain, iirc |
| 21:23.29 |
starseeker |
was never terribly comfortable conceptually with
hvd |
| 21:24.29 |
abhi2011 |
oh ok, so no
matter where i move the ray origin through the dir command, as long
as I dont change my view(say keep looking at it from the front),
hvd shoudnt change |
| 21:24.49 |
abhi2011 |
*the xyz
command i mean, not dir |
| 21:31.07 |
abhi2011 |
but the
example in the pdf and when I run nirt on the given model, does not
show that |
| 21:31.39 |
abhi2011 |
so first the
origin and hvd is : Origin (x y z) = (0.00000000 0.00000000
0.50000000) (h v d) = (0.0000 0.5000 0.0000) |
| 21:32.13 |
abhi2011 |
then xyz
alone is changed with backout enabled |
| 21:32.27 |
abhi2011 |
and after
shooting we get : Origin (x y z) = (6.63324958 0.00000000
0.80000000) (h v d) = (0.0000 0.8000 0.0000) |
| 21:33.05 |
abhi2011 |
hmm, maybe in
the example the view was changed |
| 21:36.22 |
abhi2011 |
hmm , no it
couldnt have been changed, seems hvd is connected to xyz
somehow |
| 21:37.15 |
abhi2011 |
probably the
view is changed to look towards the direction from which the ray
will be shot |
| 21:37.22 |
abhi2011 |
that seems to
be the relation |
| 21:52.24 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 22:06.09 |
bhinesley |
am I correct
in assuming that bombing macros are disabled for a release
build? |
| 22:07.53 |
bhinesley |
I've been
sticking BU_ASSERT's all over the place |
| 22:55.49 |
abhi2011 |
the command
wrappers defined in mged/cmd.c like cmd_ged_edit_wrapper seems to
be all designed to send data back to a tcl procedure |
| 22:56.17 |
abhi2011 |
I guess this
is the tcl proc thats invoked when the user types the command in
the gui |
| 22:59.27 |
CIA-62 |
BRL-CAD:
03starseeker * r45794 10/brlcad/trunk/src/other/tk/CMakeLists.txt:
Ah HAH! Need to be more selective about when we define
USE_TCL_STUBS - wish no likie. |
| 23:00.01 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 23:07.39 |
abhi2011 |
I was looking
into how tcl/tk is integrated with C as thats what appears to be
used to add command to the mged tcl/tk user interface |
| 23:08.26 |
CIA-62 |
BRL-CAD:
03brlcad * r45795 10/brlcad/trunk/src/proc-db/csgbrep.cpp: working
towards writing out both brep and implicit forms for each entity
type. consolidate writing out the objects to a common function,
reducing 60+ lines |
| 23:08.48 |
abhi2011 |
So I am
guessing the commands are written as an extension with an entry
point like int DLLEXPORT Entry_point_func(Tcl_Interp *interp)
? |
| 23:09.05 |
brlcad |
bhinesley: in
general, they're left enabled |
| 23:09.40 |
brlcad |
it's only for
specific production environments that need to squeeze out another
10-20% performance on inputs that are known to be good |
| 23:10.18 |
brlcad |
abhi2011: not
really |
| 23:10.46 |
brlcad |
abhi2011:
there is a simple mapping table in src/mged/setup.c that sets up
the libged function name |
| 23:11.12 |
brlcad |
when a
command is called, it walks the mapping table until it finds a
match and simply calls that function |
| 23:12.06 |
brlcad |
in that
sense, the ged_*() functions are "entry points" but that term seems
ill/undefined |
| 23:13.07 |
bhinesley |
brlcad (on
tcl): that's what I thought... I never found any TCL c headers
being used. |
| 23:13.11 |
abhi2011 |
ok the entry
point is defined in tclcad.c |
| 23:14.45 |
*** join/#brlcad juan_man
(~quassel@unaffiliated/juanman) |
| 23:15.12 |
starseeker |
sings a chorus of "ding dong the witch is
dead..." |
| 23:15.25 |
bhinesley |
brlcad (on
bombing macros): so, I supposed I should limit the use of my
asserts, or at least #if 0 them out |
| 23:15.40 |
bhinesley |
starseeker:
congrats :) |
| 23:16.33 |
brlcad |
bhinesley:
nah, assert overhead is nominal |
| 23:16.56 |
brlcad |
you shouldn't
assert for the heck of it -- since the result of a failed assert is
to abort an application |
| 23:17.39 |
brlcad |
if you
validate your inputs and they fail, you return an error |
| 23:19.23 |
bhinesley |
brlcad: I'm
only using them to confirm that other functions are operating
correctly; where just assuming that they are would probably cause a
crash anyways |
| 23:19.36 |
brlcad |
then it's all
good |
| 23:19.58 |
CIA-62 |
BRL-CAD:
03starseeker * r45796 10/brlcad/trunk/src/other/tcl/ (4 files in 4
dirs): Let's see if we can do without the tcl_cfg.h hack
altogether. |
| 23:20.26 |
brlcad |
that's
exactly how they're intended to be used, to detect memory/logic
bugs and abort early instead of crashing |
| 23:20.35 |
brlcad |
or (worse)
corrupting user data |
| 23:20.48 |
bhinesley |
ok,
cool |
| 23:21.21 |
CIA-62 |
BRL-CAD:
03brlcad * r45797 10/brlcad/trunk/src/proc-db/csgbrep.cpp: reduce
about 20 more lines -- don't need separate arrays for arb
data |
| 23:23.47 |
CIA-62 |
BRL-CAD:
03starseeker * r45798 10/brlcad/trunk/src/other/tcl/CMakeLists.txt:
Whoops - don't forget windows. |
| 23:29.25 |
abhi2011 |
brlcad :
right, I get it |
| 23:35.16 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 00:49.06 |
abhi2011 |
ok so I am
trying to add a new .cpp file to src/libged where all the c++ code
to access bullet physics will go |
| 00:49.40 |
abhi2011 |
the cpp file
has a header which I include in the mged command implementation
file |
| 00:50.43 |
abhi2011 |
So my c++
test file is simphysics.cpp with some test code |
| 00:51.45 |
abhi2011 |
http://bin.cakephp.org/view/1739302378 |
| 00:53.23 |
abhi2011 |
I have a
header for it and this is included in simulate.c which has the
libged implementation of the simulate command : http://bin.cakephp.org/view/1706385166 |
| 00:54.24 |
abhi2011 |
the cpp file
has the definition of a single function single_step_sim() which
uses the cout object to print out some test message |
| 00:55.19 |
abhi2011 |
I get a
linking error when I compile which says single_step_sim() is an
undefined reference |
| 00:56.39 |
abhi2011 |
However since
I have included the header (which declares single_step_sim() )
in simulate.c the compiler should be able to see the
declaration |
| 00:57.14 |
abhi2011 |
Perhaps it
has to be exported using GED_EXPORT, but its not called from
outside the library so it shouldnt be required to export
it |
| 01:06.51 |
abhi2011 |
this is the
linking error : http://bin.cakephp.org/view/1997617995 |
| 05:15.44 |
*** join/#brlcad Stattrav
(~Stattrav@203.196.190.162) |
| 05:15.44 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 06:04.43 |
*** join/#brlcad emagdalenag
(~emagdalen@109.Red-88-4-184.dynamicIP.rima-tde.net) |
| 10:23.01 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 11:32.54 |
CIA-62 |
BRL-CAD:
03Kunigami 07http://brlcad.org *
r3056 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 11 (August
1st to August 8th) */ log for past week |
| 12:30.41 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 12:36.39 |
abhi2011 |
has anyone
tried to add c++ files to existing code, that is mixing c with
c++ |
| 12:38.07 |
brlcad |
abhi2011:
adding c++ to c files would make them c++ files |
| 12:40.40 |
brlcad |
you'll want
to write a bridge, i.e., one or more C functions that wrap all of
your C++ logic |
| 12:40.42 |
abhi2011 |
ok I am
trying to integrate bullet c++ code into brlcad |
| 12:40.48 |
brlcad |
I
know |
| 12:40.49 |
abhi2011 |
right |
| 12:41.08 |
brlcad |
those
bridging functions will need to be marked extern "C" since they're
in c++ files |
| 12:41.16 |
brlcad |
so that
they're not name-mangled |
| 12:42.52 |
abhi2011 |
yes I have
written a separate function in a cpp file simphysics.cpp that has
all the c++ code, I have declared this function in a header
simphysics.h |
| 12:42.54 |
*** join/#brlcad emagdalenag
(~emagdalen@179.Red-88-4-185.dynamicIP.rima-tde.net) |
| 12:43.10 |
abhi2011 |
i include
this header in simulate.c which is the libged simulate command
implementation |
| 12:43.41 |
abhi2011 |
in the header
where i declare the c++ function, I can declare it as
extern |
| 12:43.55 |
brlcad |
it's not just
extern |
| 12:43.58 |
brlcad |
it's extern
"C" |
| 12:44.05 |
abhi2011 |
ah
ok |
| 12:44.20 |
brlcad |
search for
that in existing include/*.h headers |
| 12:44.21 |
abhi2011 |
i get
it |
| 12:44.27 |
abhi2011 |
right |
| 12:44.39 |
brlcad |
stop saying
right :) |
| 12:45.05 |
abhi2011 |
:P,
yes |
| 12:51.46 |
brlcad |
heh, http://www.sbir.gov/sbirsearch/detail/93829 |
| 12:52.06 |
brlcad |
apparently
ARA got half a million back in the mid-90's to develop that ..
interesting, never saw it |
| 12:52.35 |
brlcad |
(assuming
they got phase 2 funding, maybe only phase 1) |
| 13:40.55 |
abhi2011 |
interestng |
| 14:19.10 |
*** join/#brlcad emagdalenag
(~emagdalen@41.Red-88-21-190.staticIP.rima-tde.net) |
| 14:52.47 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-187-155.wlan.tudelft.nl) |
| 15:25.29 |
CIA-62 |
BRL-CAD:
03brlcad * r45808 10/brlcad/trunk/src/libwdb/skt.c: there already
exists a copy function for deep copying, so use it. |
| 15:27.33 |
CIA-62 |
BRL-CAD:
03brlcad * r45809 10/brlcad/trunk/src/libwdb/ (CMakeLists.txt
Makefile.am sketch.c skt.c): rename from skt.c to sketch.c because
it's easier to find the file if the filename matches the
primitive's canonical short name. |
| 15:35.56 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 15:49.05 |
*** join/#brlcad fosburg
(~steve@or-67-238-17-118.dhcp.embarqhsd.net) |
| 15:49.59 |
fosburg |
anyone
here |
| 16:04.54 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 16:07.57 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 16:11.46 |
*** join/#brlcad fosburg
(~steve@or-67-238-17-118.dhcp.embarqhsd.net) |
| 16:16.06 |
kunigami |
rt is running
out of single letter options :) shouldn't we allow more for more
mnemonic options? |
| 16:16.46 |
kunigami |
I'd like to
add a framebuffer mode. Bothb,B, f and F are already taken, but -fb
would be better anyway |
| 16:23.47 |
brlcad |
kunigami: we
don't (yet) have proper infrastructure in place for
--long-options |
| 16:25.02 |
brlcad |
with getopt,
-fb is equivalent to "-f -b", so at best you'd need something like
--fb |
| 16:25.12 |
brlcad |
that said,
what do you mean by framebuffer mode? |
| 16:27.20 |
CIA-62 |
BRL-CAD:
03brlcad * r45810 10/brlcad/trunk/include/wdb.h: meant to commit
this with r45808, made the passed parameter const now that it's
properly copied before export. |
| 16:28.36 |
CIA-62 |
BRL-CAD:
03brlcad * r45811 10/brlcad/trunk/include/raytrace.h: add a new
type, rt_curve, for use by sketch and extrude
definitions. |
| 16:38.40 |
abhi2011 |
does anyone
else get warnings about the version infomation being missing from
libz : /usr/bin/cmake: /usr/brlcad/dev-7.20.3/lib/libz.so.1: no
version information available (required by
/usr/bin/cmake) |
| 16:38.58 |
abhi2011 |
I get this
during cmake and during make install as well |
| 16:39.38 |
abhi2011 |
maybe the
libz version info needs to be patched |
| 17:03.11 |
*** join/#brlcad fosburg
(~steve@or-67-238-17-118.dhcp.embarqhsd.net) |
| 17:05.32 |
kunigami |
brlcad:
something like we discussed on email: the frequency on which the
framebuffer is updated and how rays are shot. this would form two
options. I want to add an option for the "how rays are shot". fb
was just an example for a long letter example. Which name would
better describe this parameter? tr? |
| 17:08.05 |
brlcad |
that rabbit
hole runs a little deep :) |
| 17:09.25 |
brlcad |
my point
wasn't specific to -fb, -abc == -a -b -c to getopt (which is highly
desireable in some contexts) |
| 17:09.42 |
brlcad |
the feature
missing is long-opts support, which would let you specify longer
name options in addition to one-letter optiosn |
| 17:10.15 |
brlcad |
half of rt's
short options would be better as long-only options for some form of
advanced control |
| 17:11.38 |
brlcad |
but like I
said, the infrastructure for long options isn't implemented, so
better to just pick one of the few remaining one-letter options for
now unless you want to tackle implementing long options properly
(new libbu api) |
| 17:12.12 |
kunigami |
hehe ok. Will
choose one of the remaining :) |
| 17:12.19 |
brlcad |
:) |
| 17:13.01 |
brlcad |
looks like -m
-y -z -L -Y -Z plus some punctuation are all that
remain |
| 17:15.39 |
brlcad |
given -l is
lighting model, -L for firing pattern might work well |
| 17:18.36 |
brlcad |
another
option might be to overload the -Q option or -B option |
| 17:18.51 |
brlcad |
looks like -b
might be fair game too.. |
| 17:22.08 |
brlcad |
definitely
fair game, it's the same as -j |
| 17:22.54 |
brlcad |
so I suggest
-L, -Q, or -b |
| 17:23.40 |
brlcad |
the latter
two require a little refactoring, but seem most
appropriate |
| 17:25.43 |
brlcad |
kunigami:
suggest writing up the proposed usage change like what bhinesley
did for edit, either as a comment or wiki dev page would be
sufficient |
| 17:26.05 |
brlcad |
to make sure
the usage is clean and impact minimal before you run down a
path |
| 17:27.14 |
brlcad |
rt is a
critical path, so should make sure there's extra thought put into
how the new options will get used |
| 17:33.31 |
CIA-62 |
BRL-CAD:
03brlcad * r45812 10/brlcad/trunk/src/libwdb/ (CMakeLists.txt
Makefile.am extr.c extrude.c): rename extr.c to extrude.c so that
the filename matches the primitiv'es canonical short name. makes it
easier to identify what this file contains. |
| 17:35.33 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 17:44.47 |
kunigami |
brlcad:
comment right on the code? like rt/main.c or rt/opt.c? |
| 17:45.40 |
brlcad |
anywhere,
just some place we can collectively see it |
| 17:45.52 |
kunigami |
ok! |
| 17:58.49 |
*** join/#brlcad fosburg
(~steve@or-67-238-17-118.dhcp.embarqhsd.net) |
| 18:12.14 |
brlcad |
excellent |
| 18:12.35 |
brlcad |
couple usage
examples would be helpful too in addition to more formalized usage
syntax |
| 18:23.00 |
CIA-62 |
BRL-CAD:
03brlcad * r45813
10/brlcad/trunk/src/tclscripts/menu_override.tcl: |
| 18:23.00 |
CIA-62 |
BRL-CAD:
example of why it's useful to see the tclsh warnings.. remove a
handful of |
| 18:23.00 |
CIA-62 |
BRL-CAD:
::tk:: functions that curiously are living in our sources, yet they
don't appear |
| 18:23.00 |
CIA-62 |
BRL-CAD: to
have any overridden behavior. menus in mged tested fine without, so
let the |
| 18:23.01 |
CIA-62 |
BRL-CAD: tk
guys manage their own code. remove our fork. |
| 18:25.58 |
``Erik |
starseeker:
tclUnixInit.c:367 or so, #include <sys/utsname.h> for
uname(3) on line 471 or so |
| 18:26.22 |
CIA-62 |
BRL-CAD:
03brlcad * r45814 10/brlcad/trunk/misc/Doxyfile: output to
'doxygen_output' in whatever our current directory is, no point
putting it into misc |
| 18:28.06 |
CIA-62 |
BRL-CAD:
03Kunigami 07http://brlcad.org *
r3057 10/wiki/User:Kunigami/GSoc2011/RT_Parameters_Proposal: draft
to present the new options to be added RT application. Waiting for
review before implementing |
| 18:28.28 |
CIA-62 |
BRL-CAD:
03Kunigami 07http://brlcad.org *
r3058 10/wiki/User:Kunigami/GSoc2011/RT_Parameters_Proposal: /*
Examples */ correct formatting |
| 18:29.28 |
*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) |
| 18:29.38 |
kunigami |
may I already
add osl and oiio code to the svn? |
| 18:30.03 |
tofu |
how big are
they? |
| 18:30.48 |
*** mode/#brlcad [+o brlcad] by ChanServ |
| 18:31.01 |
kunigami |
osl is
5MB |
| 18:31.24 |
kunigami |
oiio is
9.4MB |
| 18:31.50 |
kunigami |
or we'll let
them be optional external code? |
| 18:31.56 |
brlcad |
do they have
any dependencies of their own? |
| 18:32.09 |
brlcad |
it depends
just how complex they are |
| 18:32.20 |
kunigami |
yes, a quite
long one by the way |
| 18:33.35 |
brlcad |
do you have
the build documented somewhere? |
| 18:33.48 |
kunigami |
http://brlcad.org/wiki/User:Kunigami/GSoc2011/OSL_Tutorial |
| 18:33.59 |
brlcad |
excellent,
thought you had |
| 18:34.58 |
starseeker |
as i recall,
OSL has quite the nasty dependency list |
| 18:35.02 |
kunigami |
but I didn't
mentioned all the dependencies. Most of them are aviable like in
mac ports or ubuntu synaptic |
| 18:35.08 |
starseeker |
llvm |
| 18:35.10 |
kunigami |
starseeker:
yup |
| 18:36.24 |
brlcad |
ah, right,
llvm .. that's certainly a pickle |
| 18:37.14 |
brlcad |
pretty much
guarantees it'll be disabled on release configurations unless we do
some heavy lifting to make it easier |
| 18:37.16 |
starseeker |
boost, imath,
openimageio |
| 18:38.25 |
starseeker |
(imath looks
like it may be part of openexr) |
| 18:38.45 |
kunigami |
yes, I had to
install openexr |
| 18:38.53 |
brlcad |
kunigami: how
about checking all of the deps into a separate module |
| 18:39.24 |
starseeker |
not surpring,
openexr really has taken off in the movie industry and that's
sony's target use case for this... |
| 18:39.31 |
brlcad |
we can hook
those in later as an svn external if we want, or extra download
step |
| 18:39.41 |
starseeker |
votes for that appraoch |
| 18:39.41 |
brlcad |
but that way,
the N deps are all in one place |
| 18:39.43 |
starseeker |
approach
even |
| 18:40.51 |
brlcad |
then their
compilation can be wrapped up with even a simple Makefile that will
compile/install all in the proper order |
| 18:41.01 |
brlcad |
<PROTECTED> |
| 18:41.17 |
brlcad |
kunigami: do
you know how to create a new module? |
| 18:41.18 |
starseeker |
osl itself
uses cmake |
| 18:41.29 |
kunigami |
kunigami:
nope |
| 18:41.34 |
kunigami |
ops |
| 18:41.37 |
kunigami |
brlcad:
nope |
| 18:41.38 |
brlcad |
sure, but
it's just one of about a half-dozen or so |
| 18:42.08 |
starseeker |
openimagio
has one, it looks like |
| 18:42.13 |
starseeker |
pretty sure
llvm does |
| 18:42.39 |
kunigami |
you mean
cmake module? like FindXYZ.cmake? |
| 18:43.00 |
starseeker |
no,
CMakeLists.txt file |
| 18:43.08 |
brlcad |
kunigami:
basically, you'll checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad
(perhaps with max-depth set to 0 so it doesn't check out the whole
repo) and add an 'osl' dir with three subdirs, 'trunk', 'branches',
'tags' |
| 18:43.56 |
brlcad |
then add the
various OSL packages as subdirs under
/svnroot/brlcad/osl/trunk/. |
| 18:44.30 |
brlcad |
one dir for
each dep, openexr, llmbase, boost, etc |
| 18:44.52 |
brlcad |
can skip any
external deps that are in /svnroot/brlcad/brlcad/trunk/src/other
(like libpng, libz, etc) |
| 18:45.43 |
starseeker |
hmm...
openexr doesn't have one |
| 18:45.52 |
starseeker |
wonder if
they'd accept one |
| 18:46.16 |
brlcad |
unless we
plan on fully managing them, wouldn't bother |
| 18:46.55 |
brlcad |
only reason
to add them is to have them in revision control so they can be
conveniently downloaded if we want to push out binaries with osl
enabled |
| 18:47.57 |
brlcad |
exr-pix would
be cool, that'd be a reason :) |
| 18:49.10 |
starseeker |
isn't quite sure how exr would integrate with our tools - we
might have to make rt and friends output straight to exr if we
wanted to take full advantage of it... |
| 19:03.39 |
CIA-62 |
BRL-CAD:
03kunigami * r45815 10/osl/ (. branches/ tags/ trunk/): setting up
initial structure for osl code and dependences |
| 19:06.27 |
*** join/#brlcad fosburg
(~steve@or-67-238-17-118.dhcp.embarqhsd.net) |
| 19:12.31 |
CIA-62 |
BRL-CAD:
03starseeker * r45816 10/brlcad/trunk/src/other/tcl/CMakeLists.txt:
Add one missing file to Windows source list - this new setup, for
the first time, allows for a successful run of wish.exe |
| 19:22.44 |
*** join/#brlcad emagdalena
(~emagdalen@216.Red-88-4-184.dynamicIP.rima-tde.net) |
| 19:38.33 |
CIA-62 |
BRL-CAD:
03brlcad * r45817 10/brlcad/trunk/misc/ (CMakeLists.txt
Makefile.am): the Doxygen paths are already relative, so no need to
auto-generate the file with full-paths shoved in. write out to the
doc dir. |
| 19:56.07 |
CIA-62 |
BRL-CAD:
03Kunigami 07http://brlcad.org *
r3059 10/wiki/User:Kunigami: /* Links */ added link to my RT
parameters proposal |
| 20:01.04 |
*** join/#brlcad dli
(~dli@dsl-67-204-17-156.acanac.net) |
| 20:03.49 |
CIA-62 |
BRL-CAD:
03brlcad * r45818 10/brlcad/trunk/ (16 files in 10
dirs): |
| 20:03.50 |
CIA-62 |
BRL-CAD: fix
a FIXME, rename the struct curve definition that was embedded
into |
| 20:03.50 |
CIA-62 |
BRL-CAD:
rt_sketch_internal. this creates a new rt_curve structure and moves
the |
| 20:03.50 |
CIA-62 |
BRL-CAD:
associated segment structures into rtgeom. unfortunately requires
nmg.h for the |
| 20:03.50 |
CIA-62 |
BRL-CAD:
knot_vector and cascades a set of name changes, but improvement all
around. |
| 20:17.54 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 20:32.24 |
CIA-62 |
BRL-CAD:
03kunigami * r45819 10/osl/trunk/osl/: add just the empty dir for
mime-type testing |
| 20:35.00 |
CIA-62 |
BRL-CAD:
03kunigami * r45820 10/osl/trunk/osl/CHANGES: add just the empty
dir for mime-type testing |
| 21:54.45 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 21:54.46 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 22:05.20 |
CIA-62 |
BRL-CAD:
03brlcad * r45827 10/brlcad/trunk/ (include/raytrace.h
src/librt/primitives/sketch/sketch.c): segment magic numbers are
presently unsigned long, update pointers accordingly |
| 22:15.48 |
CIA-62 |
BRL-CAD:
03brlcad * r45828 10/brlcad/trunk/src/proc-db/sketch.c: now that
mk_sketch() releases memory, we can simplify by creating the sketch
and all segments on the stack. |
| 22:19.13 |
CIA-62 |
BRL-CAD:
03kunigami * r45829 10/osl/trunk/oiio/ (399 files in 82 dirs):
adding missing files to oiio |
| 22:21.18 |
CIA-62 |
BRL-CAD:
03brlcad * r45830 10/brlcad/trunk/src/proc-db/sketch.c: come to
think of it, we don't need ANY stinking dynamic memory allocation.
huzzah. |
| 22:25.58 |
CIA-62 |
BRL-CAD:
03brlcad * r45831 10/brlcad/trunk/src/proc-db/sketch.c: reduce some
more and document the vars |
| 23:38.46 |
CIA-62 |
BRL-CAD:
03kunigami * r45832 10/osl/trunk/ilmbase/ (245 files in 69 dirs):
adding latest stable version of ilmbase, 1.0.1 |
| 23:46.50 |
CIA-62 |
BRL-CAD:
03kunigami * r45833 10/osl/trunk/ilmbase/config/Makefile.in: added
missing file to ilmbase |
| 23:51.29 |
CIA-62 |
BRL-CAD:
03kunigami * r45834 10/osl/trunk/ilmbase/ (7 files in 7 dirs):
added missing file to ilmbase (cant understand why some files are
not being added) |
| 00:04.54 |
brlcad |
kunigami:
it's because some files are listed in your ~/.subversion/config
global-ignores directive, files that are "usually"
auto-generated |
| 00:05.25 |
brlcad |
Makefile.in
files being a byproduct of automake, though some projects choose to
be autoconf-only and use Makefile.in |
| 00:05.53 |
brlcad |
remove the
directive and should resolve itself |
| 00:06.34 |
kunigami |
that's
strange, my global-ignores only includes .o, .lo and
.la |
| 00:27.45 |
starseeker |
brlcad: we've
got something odd going on with bu_ipwd |
| 00:27.58 |
starseeker |
I'm trying to
run archer from build directory, and it's not finding the
plugins |
| 00:28.31 |
starseeker |
the problem
traces to how plugins are loaded - the current working directory is
changed to being fairly deep in the share structure |
| 00:28.43 |
starseeker |
when there,
bu_brlcad_data no longer gives useful results |
| 00:29.38 |
starseeker |
brlcad: try
running bwish from
share/brlcad/7.20.3/plugins/archer/Utility |
| 00:30.05 |
starseeker |
e.g
../../../../../../bin/bwish |
| 00:30.11 |
starseeker |
then try
bu_brlcad_data "" |
| 00:32.30 |
dli |
starseeker,
is there any known issue with building brlcad against
libpng-1.5? |
| 00:36.19 |
starseeker |
dli: trunk
can (we actually just upgraded to 1.5) |
| 00:36.44 |
dli |
starseeker,
thanks a lot! just got a bug report from gentoo |
| 00:41.29 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 00:49.44 |
CIA-62 |
BRL-CAD:
03kunigami * r45835 10/osl/trunk/openexr/ (396 files in 67 dirs):
adding latest version of openexr (v1.6.1) |
| 01:38.53 |
kunigami |
openexr
requires zlib, which is packed with brlcad. but openexr uses
autotools to build. should I modify it to automatically find the
brlcad version or may I assume that the user will take care of this
dependence? |
| 01:48.05 |
brlcad |
kunigami:
that is pretty odd then .. it's in my config (but then I added
it) |
| 01:49.18 |
brlcad |
as for zlib,
is there already a configure option for --with-zlib=/path/to/zlib
or somesuch? otherwise the top-level build file can take care of
passing it in the build flags |
| 01:49.42 |
kunigami |
brlcad: hmm,
let me check |
| 01:52.54 |
kunigami |
there's no
such option. so the idea is that one top-level file builds all osl
dependencies? |
| 01:58.16 |
brlcad |
yeah,
something very simple to assist builds on linux/bsd/mac |
| 01:59.12 |
kunigami |
hm,
ok |
| 01:59.16 |
brlcad |
either a
makefile or a script, whatever is easiest |
| 02:00.54 |
kunigami |
I'd go for
script. I'm not that fluent with makefiles |
| 02:01.49 |
brlcad |
starseeker:
data path loading requires either a) that one of the libbu path
functions is called prior to a directory change or b) that the
resources are in their install location |
| 02:03.03 |
brlcad |
if both those
are false, then there's no way for libbu to know what the initial
working directory path was (other than a hard override) |
| 02:11.14 |
CIA-62 |
BRL-CAD:
03bhinesley * r45836 10/brlcad/trunk/src/libged/edit.c: |
| 02:11.15 |
CIA-62 |
BRL-CAD:
Batch arguments were expanding, but only the first set was being
executed. |
| 02:11.15 |
CIA-62 |
BRL-CAD:
Fixing this meant writing a function to duplicate command argument
groupings, |
| 02:11.15 |
CIA-62 |
BRL-CAD:
which in turn required changing the subcommand functions for
looping through |
| 02:11.15 |
CIA-62 |
BRL-CAD:
args. The counters needed to be exposed as paramaters, and made
non-static... |
| 02:11.15 |
CIA-62 |
BRL-CAD:
which should have been done in the first place. Updated the
half-dozen or so |
| 02:11.15 |
CIA-62 |
BRL-CAD:
places that depended on the old logic. |
| 02:20.19 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 03:04.18 |
CIA-62 |
BRL-CAD:
03bhinesley * r45837 10/brlcad/trunk/src/libged/edit.c: off by one
errors introduced r45836 |
| 03:09.53 |
starseeker |
brlcad: it
can't key off the location of the bwish binary? |
| 04:00.49 |
starseeker |
hmm... may
want to re-examine the mechanism being used for plugin
loading |
| 04:02.14 |
CIA-62 |
BRL-CAD:
03bhinesley * r45838 10/brlcad/trunk/src/libged/edit.c: |
| 04:02.15 |
CIA-62 |
BRL-CAD:
Simplified/removed some things in edit(), and resolved several
unrelated issues, |
| 04:02.15 |
CIA-62 |
BRL-CAD: many
of which were recently introduced. Translate isn't quite working
yet. There |
| 04:02.15 |
CIA-62 |
BRL-CAD:
seems to be a problem getting the apparent coordinates of objects,
which I think |
| 04:02.15 |
CIA-62 |
BRL-CAD:
might all be evaluating to (0,0,0). Also, there are several
untested option/arg |
| 04:02.15 |
CIA-62 |
BRL-CAD:
combinations. |
| 04:04.31 |
starseeker |
brlcad: if
the "change to current working directory before doing things"
approach is what's causing the break, I wonder if it might be
workable to scrap that altogether |
| 04:07.30 |
starseeker |
or "change
the current working directory" rather |
| 04:07.44 |
starseeker |
doesn't quite see why that's essential |
| 04:22.16 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3060 10/wiki/User:Bhinesley: /* Log */ today, plan |
| 04:22.46 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3061 10/wiki/User:Bhinesley: /* Log */ typo |
| 04:32.21 |
brlcad |
starseeker:
why what is/isn't essential? |
| 04:32.42 |
brlcad |
archer
needing to change the cwd sounds bad |
| 04:33.49 |
brlcad |
and even if
it "needs to" for some odd reason, it should be getting the current
dir (via libbu) first so the path can be restored |
| 04:41.28 |
starseeker |
Archer::pluginLoadCWDFiles |
| 04:42.09 |
starseeker |
will try to sort it out tomorrow |
| 05:06.05 |
brlcad |
yeah, without
getting into the nitty gritty, there doesn't sound like there's any
reason it needs to load files from "cwd" .. it needs to load files
from a plugin dir, determined from bu_brlcad_data
"path/to/plugin/dir" |
| 05:46.30 |
*** join/#brlcad blindbox
(~UPPnub@60.51.60.209) |
| 06:32.52 |
*** part/#brlcad blindbox
(~UPPnub@60.51.60.209) |
| 08:33.16 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 08:58.26 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 09:56.50 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 13:32.33 |
abhi2011 |
brlcad: I am
working on a new function to be added to librt which will reside in
librt/bbox.c |
| 13:32.57 |
abhi2011 |
the function
looks like this : rt_bound_dbfullpath(const struct db_full_path
*pp, struct rt_i *rtip, fastf_t *tree_min, fastf_t
*tree_max) |
| 13:33.31 |
abhi2011 |
so it will
take a db_full_path and return the bb for the combination or
region in that path, otherwise return an error |
| 13:38.08 |
abhi2011 |
however for
finding the bb a db_full_path is not needed, generall the databse
would be opened using rt_dirbuild() which returns a struct rt_i and
not struct db_i |
| 13:38.29 |
abhi2011 |
from that
point onwards only rt_* functions would be involved |
| 13:39.59 |
abhi2011 |
so I am
currently using db_path_to_string() to convert the struct
db_full_path passed to rt_bound_dbfullpath(), to a string
representation of the path |
| 13:42.04 |
abhi2011 |
I can use
this string representation of a region/group to search the list of
regions available in the struct rt_i * trip |
| 13:42.27 |
abhi2011 |
once the
region is found then I can use rt_bound_tree() to get the
bb |
| 13:43.11 |
abhi2011 |
so my point
is that db_path_to_string() seems to be the only way to jump from
using db_* functions to rt_* functions |
| 15:33.55 |
brlcad |
abhi2011: the
function shouldn't take an rtip |
| 15:34.19 |
brlcad |
that's an
implementation detail .. needs to be a simple form of "here's an
object, get the bounding box" |
| 15:35.14 |
brlcad |
either using
db_full_patths or rt_db_internal objects, not immediately clear to
me which is better |
| 15:36.42 |
brlcad |
also, in
general, the database won't necessarily be opened with
rt_dirbuild() .. that's only for raytracing applications. they may
simply call db_open() or db_open_inmem() or wdb_dbopen() or
... |
| 15:37.19 |
brlcad |
that's one of
the points of creating this function, hiding the fact that we
create a raytrace context so we can call prep so we can get the
bounding boxes |
| 16:12.05 |
CIA-62 |
BRL-CAD:
03brlcad * r45839 10/brlcad/trunk/src/proc-db/csgbrep.cpp:
eliminate the remainder of dynamic memory allocation now that it is
no longer needed. greatly simplifies creating sketch objects
procedurally. |
| 16:31.58 |
CIA-62 |
BRL-CAD:
03brlcad * r45840
10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: help prevent
crashing if the data file cannot be found, validate before trying
to use the mapped file. this should be using dsp_get_data() instead
of replicating logic. |
| 16:53.07 |
CIA-62 |
BRL-CAD:
03brlcad * r45841 10/brlcad/trunk/TODO: sketch objects get copied
deeply now |
| 16:55.38 |
CIA-62 |
BRL-CAD:
03brlcad * r45842 10/brlcad/trunk/TODO: most of the wdb routines
now properly make a copy so wdb_export can free it. possibly a few
stragglers remaining, but not nmg and sketch previously
mentioned. |
| 16:57.12 |
CIA-62 |
BRL-CAD:
03brlcad * r45843 10/brlcad/trunk/src/proc-db/sketch.c: no more
dynamic mem |
| 16:57.43 |
abhi2011 |
brlcad: ok I
get it. |
| 16:57.52 |
CIA-62 |
BRL-CAD:
03brlcad * r45844 10/brlcad/trunk/src/proc-db/csgbrep.cpp: we
already created a db_internal, don't call mk_sketch()
directly. |
| 16:59.25 |
abhi2011 |
all the prep
functions take an rtip as input however i.e. rt_prep(struct rt_i
*rtip) & rt_prep_parallel() |
| 16:59.43 |
brlcad |
knows that :) |
| 16:59.51 |
abhi2011 |
I am guessing
these are the only 2 ways to get the bb |
| 17:00.00 |
brlcad |
you need an
rtip |
| 17:00.06 |
brlcad |
the function,
however, does not |
| 17:00.06 |
abhi2011 |
hmm so I
would need to convert the input to an rtip |
| 17:00.14 |
brlcad |
right |
| 17:01.19 |
abhi2011 |
rt_dirbuild()
would open up the database and return a rtip, but we dont want the
caller to pass the database name as well |
| 17:01.27 |
abhi2011 |
just an
object |
| 17:01.30 |
brlcad |
right |
| 17:01.50 |
brlcad |
and they
might not be a raytracing app, so all they have is a filename
and/or a dbip |
| 17:02.20 |
brlcad |
you might get
away with passing a (struct db_i *, struct rt_db_internal *, min,
max) |
| 17:02.46 |
brlcad |
or db_i,
name, min, max |
| 17:02.49 |
abhi2011 |
yes i am
looking at rt_new_rti() which has db_i |
| 17:02.57 |
abhi2011 |
as
input |
| 17:03.25 |
abhi2011 |
yah I am
guessing the user will have at a minimum the db_i |
| 17:03.33 |
abhi2011 |
else they
wont have a file open :P |
| 17:04.21 |
brlcad |
they won't
necessarily have a file open |
| 17:04.33 |
brlcad |
you can
create memory-only database instances |
| 17:04.39 |
abhi2011 |
ah yes
right |
| 17:04.48 |
brlcad |
but that's
still encapsulated in a dsip |
| 17:04.52 |
brlcad |
*dbip |
| 17:04.55 |
abhi2011 |
both ways,
the db_i would exist |
| 17:06.02 |
abhi2011 |
ok I ll
proceed assuming that a db_i can be passed by the caller , as of
now |
| 17:06.29 |
CIA-62 |
BRL-CAD:
03brlcad * r45845 10/brlcad/trunk/src/external/Unigraphics/ug-g.c:
call rt_curve_free() for consistent cleanup |
| 17:17.34 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 17:17.34 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 17:19.00 |
abhi2011 |
ok, what is
an in-mem, you mean an in memory representation of the comb, which
can be prepped ? |
| 17:19.30 |
brlcad |
db_open_inmem() |
| 17:19.39 |
brlcad |
it's a dbip
that only lives in memory |
| 17:20.52 |
brlcad |
you can
create an in-mem dbip, add the struct rt_db_internal * to it, call
rt_new_rti() to get an rtip, and finally call rt_gettree() to
evaluate the bounding boxes |
| 17:23.26 |
abhi2011 |
ok |
| 17:26.35 |
CIA-62 |
BRL-CAD:
03brlcad * r45846 10/brlcad/trunk/src/conv/dxf/dxf-g.c: free the
sketch now that mk_sketch() doesn't |
| 17:27.48 |
abhi2011 |
I see a
duplication in 1 thing though |
| 17:28.12 |
abhi2011 |
since db_*
functions already provide database manipulation capabilities on
disk and in-mem |
| 17:28.38 |
abhi2011 |
is there any
need to duplicate it in functions like rt_dir_build() |
| 17:28.40 |
CIA-62 |
BRL-CAD:
03brlcad * r45847 10/brlcad/trunk/src/conv/dxf/dxf-g.c: struct is
embedded, can't be null, and rt_curve_free() wants a
pointer. |
| 17:29.02 |
abhi2011 |
eg.
rt_dir_build() and db_open() both open a database |
| 17:30.07 |
abhi2011 |
but perhaps
its because rt_dir_build() opens a on disk database and very
conveniently returns a rt_i which can be used further down the
raytracing system |
| 17:30.13 |
brlcad |
rt_dirbuild()
calls db_open() |
| 17:30.26 |
abhi2011 |
oh
ok |
| 17:31.09 |
brlcad |
the goal of
dirbuild is to give a raytrace instance, the point of open is to
get a database instance .. different (albeit related)
purposes |
| 17:31.37 |
abhi2011 |
yes I get
understand |
| 17:33.03 |
CIA-62 |
BRL-CAD:
03brlcad * r45848 10/brlcad/trunk/src/conv/shp/shp-g.c: no longer
need to allocate dynamic memory for the sketch, keep it on the
stack and just free the minimal set of dynamic memory that was
needed for the sketch's curve segments. |
| 17:36.49 |
CIA-62 |
BRL-CAD:
03brlcad * r45849 10/brlcad/trunk/src/libged/tire.c: another
rt_sketch_internal that no longer needs to be dynamic. release the
dynamic data associated with it though, now that mk_sketch()
won't |
| 17:42.15 |
abhi2011 |
i was looking
at d b _ c r e a t e _ i n m e m() as well and I see that it add a
default _GLOBAL object as well, but what would be the point of
adding such an object |
| 17:42.54 |
brlcad |
doesn't
matter |
| 17:43.18 |
brlcad |
_GLOBAL holds
the working units for the geometry in question |
| 17:43.30 |
abhi2011 |
ok |
| 17:45.47 |
CIA-62 |
BRL-CAD:
03brlcad * r45850 10/brlcad/trunk/src/libged/make.c: enable
creation of the old/original sketch object if a LIBGED_MAKE_SKETCH
environment variable is set to 1. useful for debugging purposes and
makes the code get compiled so it doesn't fall out of sync with the
api. |
| 17:52.24 |
abhi2011 |
I was reading
about sketches at http://brlcad.org/wiki/Sketch ,
since I see a lot of code changes going on related to them, I
guess they are simply a line and curve based drawing of a model's
shape ? |
| 18:02.10 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 18:04.07 |
brlcad |
abhi2011:
they're autocad-style 2d "drawings" |
| 18:05.17 |
abhi2011 |
ok |
| 18:21.52 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: |
| 18:21.52 |
CIA-62 |
BRL-CAD:
uploaded "[[Image:Example sketch.png]]": This is an example sketch
that can be |
| 18:21.52 |
CIA-62 |
BRL-CAD:
created with the ''make'' command if the LIBGED_MAKE_SKETCH
environment variable |
| 18:21.52 |
CIA-62 |
BRL-CAD: is
set to 1. This example sketch is primarily used for demonstration
and |
| 18:21.52 |
CIA-62 |
BRL-CAD:
debugging purposes. |
| 18:28.51 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r3063
10/wiki/Sketch: link to the example sketch object image |
| 18:33.11 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r3064
10/wiki/SGI_Cube: clean up alignment with |
| 18:35.04 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r3065
10/wiki/SGI_Cube: swap images? |
| 18:47.55 |
CIA-62 |
BRL-CAD:
03brlcad * r45851 10/brlcad/trunk/ (include/raytrace.h
src/librt/htbl.c): use size_t for hit table indexing |
| 19:03.43 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 19:03.43 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 19:05.21 |
abhi2011 |
Trying to
convert the struct rt_db_internal to bu_external now as
wdb_export_external() accepts only bu_external |
| 19:06.32 |
abhi2011 |
some of the
primitives of librt do it |
| 19:06.57 |
abhi2011 |
like
rt_ell_export5() in librt/primitives/ell/ell.c |
| 19:12.03 |
abhi2011 |
specifically
the htond() and ntohd() seem to do conversions from an external db
format bu_external to an internal rt_db_internal |
| 19:21.19 |
brlcad |
abhi2011:
sounds too low-level |
| 19:22.46 |
brlcad |
wdb_put_internal() and
rt_db_put_internal() both work at a higher level |
| 19:22.55 |
abhi2011 |
well I wish
there was a wdb_export_external |
| 19:23.02 |
abhi2011 |
*wdb_export_internal |
| 19:23.04 |
abhi2011 |
ah
ok |
| 19:23.36 |
brlcad |
get/put
read/write to disk |
| 19:23.54 |
abhi2011 |
yes I need to
look through the libwdb functions more carefully :P |
| 19:23.55 |
brlcad |
import/export
convert from/to serialized (i.e., disk) format |
| 19:24.25 |
brlcad |
it's
understandably complex to fresh eyes :) |
| 19:24.58 |
abhi2011 |
yah the thing
is all the functions are there to make life easy, just need to run
doxygen once |
| 19:25.39 |
brlcad |
even with
doxygen, there are a LOT of functions .. so it takes a
while |
| 19:25.52 |
abhi2011 |
ok |
| 19:56.59 |
CIA-62 |
BRL-CAD:
03kunigami * r45852 10/osl/trunk/compile.sh: Added a script to
build ilmbase and openexr |
| 20:04.42 |
brlcad |
kunigami:
ready for testing? |
| 20:07.06 |
kunigami |
no |
| 20:07.51 |
kunigami |
I'm currently
trying to force openexr to use the local version of libz. It's
getting from system] |
| 20:10.06 |
brlcad |
unless that
causes a problem, wouldn't worry too much about it |
| 20:11.38 |
kunigami |
actually I
don't know how to tell openexr where to look if it's not installed
on the system :P |
| 20:12.04 |
brlcad |
main options
are 1) install brlcad, then osl, then reinstall brlcad; or 2) link
libz as svn external, then osl, then brlcad; or 3) copy libz, then
osl, then brlcad |
| 20:12.44 |
brlcad |
autoconf
supports setting CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS during configure,
that'd be how |
| 20:13.20 |
brlcad |
./configure
CPPFLAGS=-I/path/to/libz/include
LDFLAGS=-L/path/to/libz/libdir |
| 20:14.20 |
kunigami |
oh ok, great
then. (by the way, I didn't understand what you meant in those
three options) |
| 20:17.12 |
brlcad |
in terms of
dealing with libz |
| 20:17.18 |
brlcad |
basically
three options |
| 20:17.45 |
brlcad |
if you assume
brlcad is already compiled/installed (so you can use the libz it
compiled), then you'll have to build brl-cad twice |
| 20:18.31 |
kunigami |
true |
| 20:19.06 |
brlcad |
alternatives
are to link in libz sources (svn:external) or svn cp (i.e., fork
them in) |
| 20:34.12 |
CIA-62 |
BRL-CAD:
03starseeker * r45853 10/brlcad/trunk/src/ (6 files in 3 dirs):
Simplify loading of Archer plugins - use bu_brlcad_data and avoid
all the CWD logic. Good cleanup, and plugin loading now works in
the build directory. |
| 20:34.40 |
brlcad |
awesome |
| 20:48.34 |
*** join/#brlcad DarkCalf
(DC@173.231.40.98) |
| 21:08.04 |
CIA-62 |
BRL-CAD:
03starseeker * r45854 10/brlcad/trunk/src/libbu/basename.c:
Generalize bu_basename with the BU_DIR_SEPARATOR
variable |
| 21:09.52 |
CIA-62 |
BRL-CAD:
03starseeker * r45855 10/brlcad/trunk/src/libbu/basename.c: Fix
comments |
| 21:12.32 |
brlcad |
starseeker: i
imagine the bu_basename() change is user-visible in some
fashion |
| 21:12.41 |
brlcad |
possibly the
plugins one too |
| 21:13.11 |
starseeker |
possibly...
plugins is visible only when running from the build directory
(probably why it never got addressed sooner...) |
| 21:13.21 |
starseeker |
adds NEWS item for basename |
| 21:13.33 |
brlcad |
yeah, plugins
wouldn't be then |
| 21:16.35 |
CIA-62 |
BRL-CAD:
03starseeker * r45856 10/brlcad/trunk/NEWS: Generalized the
bu_basename function to work with Windows paths - allows libraries
and programs to capture their executable name without path
information. |
| 21:18.40 |
brlcad |
which means
what to the user? |
| 21:19.03 |
starseeker |
brlcad: not
entirely sure. |
| 21:19.09 |
brlcad |
heh |
| 21:19.25 |
brlcad |
what wasn't
working that now is working? |
| 21:19.28 |
starseeker |
brlcad:
things *might* not work because of that, but we apparently hadn't
run into anything |
| 21:23.35 |
*** join/#brlcad saltan
(~lieven@d51530284.static.telenet.be) |
| 21:25.37 |
CIA-62 |
BRL-CAD:
03brlcad * r45857 10/brlcad/trunk/NEWS: |
| 21:25.37 |
CIA-62 |
BRL-CAD: how
about this. cliff and bob improved mged/archer/bwish run-time
behavior on |
| 21:25.37 |
CIA-62 |
BRL-CAD:
windows by fixing bu_basename() to work with the windows path
separator. this |
| 21:25.37 |
CIA-62 |
BRL-CAD:
low-level interface is used for capturing the path to the running
executable, |
| 21:25.37 |
CIA-62 |
BRL-CAD: data
resources, and more; so fixing the routine should generally make
things |
| 21:25.37 |
CIA-62 |
BRL-CAD:
better, making apps more consistent for windows users. |
| 21:30.14 |
brlcad |
prepares a large whoosh commit |
| 21:30.16 |
starseeker |
that'll work
:-) |
| 21:30.22 |
starseeker |
ducks and hides |
| 21:51.12 |
CIA-62 |
BRL-CAD:
03brlcad * r45858 10/brlcad/trunk/ (88 files in 23 dirs): (log
message trimmed) |
| 21:51.12 |
CIA-62 |
BRL-CAD:
Convert all BRL-CAD magic numbers to uint32_t. This change affects
more than a |
| 21:51.12 |
CIA-62 |
BRL-CAD:
dozen structs and more than 500 usages throughout the code
including many |
| 21:51.12 |
CIA-62 |
BRL-CAD:
function signatures, but is still considered minimally impacting.
This |
| 21:51.12 |
CIA-62 |
BRL-CAD:
consolidates the slew of int, long, unsigned int, unsigned long,
etc definitions |
| 21:51.12 |
CIA-62 |
BRL-CAD: of
magic numbers that were assuming to be 4 bytes for magic number
validation. |
| 21:51.13 |
CIA-62 |
BRL-CAD: It
also exposed a curious book-keeping practice in NMG where pointers
to the |
| 21:51.42 |
starseeker |
tests the woosh |
| 21:57.56 |
starseeker |
yep, seems to
work |
| 22:03.13 |
brlcad |
argh |
| 22:21.49 |
CIA-62 |
BRL-CAD:
03bob1961 * r45859
10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: |
| 22:21.49 |
CIA-62 |
BRL-CAD: Need
to copy result of call to bu_brlcad_root() into local storage
before |
| 22:21.49 |
CIA-62 |
BRL-CAD:
calling bu_brlcad_data() because bu_brlcad_root() uses static char
array and |
| 22:21.49 |
CIA-62 |
BRL-CAD:
bu_brlcad_data() calls bu_brlcad_root() overwriting what was
previously in the |
| 22:21.49 |
CIA-62 |
BRL-CAD:
static array. |
| 22:24.28 |
abhi2011 |
rt_uniresource is often(always) specified
with rt_db_put_internal() |
| 22:24.43 |
brlcad |
it's a
global |
| 22:24.47 |
abhi2011 |
I understand
that it contains settings for uni processor machines |
| 22:24.56 |
abhi2011 |
yes |
| 22:24.57 |
brlcad |
sort
of |
| 22:25.09 |
abhi2011 |
so what
happens for multi cpu machines |
| 22:25.26 |
CIA-62 |
BRL-CAD:
03brlcad * r45860 10/brlcad/trunk/src/librt/ (4 files in 2
dirs): |
| 22:25.26 |
CIA-62 |
BRL-CAD: add
a new private header for dsp-implementation use, moving the DSP()
macro from |
| 22:25.26 |
CIA-62 |
BRL-CAD:
dsp.c to this new dsp.h header so that the brep routine can use the
same macro. |
| 22:25.26 |
CIA-62 |
BRL-CAD:
remove the dsp_val() debugging wrapper function while we're at
it. |
| 22:25.52 |
brlcad |
it's a "cpu
resource" structure used for book-keeping |
| 22:26.11 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 22:26.15 |
abhi2011 |
ok |
| 22:26.29 |
brlcad |
the
rt_uniresource can only be used by one cpu at a time, so it
effectively makes that function single-threaded |
| 22:26.51 |
abhi2011 |
oh ok, some
semaphore is present to enable that |
| 22:26.59 |
brlcad |
many
functions pass resources around, but don't actually do anything
with them |
| 22:27.13 |
brlcad |
others use
the resource structure if they're SMP-aware |
| 22:27.17 |
brlcad |
like the ray
tracer |
| 22:27.22 |
abhi2011 |
ok |
| 22:27.29 |
brlcad |
basically,
don't worry about it |
| 22:27.35 |
abhi2011 |
ok
:) |
| 22:27.43 |
brlcad |
if you were
passed a resource, then pass it forward |
| 22:27.57 |
brlcad |
otherwise if
you need to call something and don't have a resource, use the
rt_uniresource |
| 22:28.17 |
abhi2011 |
ok |
| 22:31.35 |
CIA-62 |
BRL-CAD:
03brlcad * r45861
10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: |
| 22:31.35 |
CIA-62 |
BRL-CAD: make
the dsp brep implementation use the new private dsp.h header for
the DSP() |
| 22:31.35 |
CIA-62 |
BRL-CAD:
macro instead of duplicating the code (bad, no donut for you).
similarly, there |
| 22:31.35 |
CIA-62 |
BRL-CAD:
shouldn't need to be any need to validate the dsp_ip or load it
because that |
| 22:31.35 |
CIA-62 |
BRL-CAD:
would have already happened during import. redoing that here will
just leak |
| 22:31.36 |
CIA-62 |
BRL-CAD:
memory and be not as good as what is done during
import. |
| 22:36.08 |
CIA-62 |
BRL-CAD:
03starseeker * r45862 10/brlcad/trunk/src/other/tk/CMakeLists.txt:
Make sure FREETYPE_LIBRARIES is empty if FREETYPE_FOUND is a
no-go. |
| 22:38.40 |
dli |
/var/tmp/portage/media-gfx/brlcad-7.20.2-r1/work/brlcad-7.20.2/src/libged/png.c:363:38:
error: 'Z_BEST_COMPRESSION' undeclared (first use in this
function) |
| 22:39.10 |
dli |
starseeker,
so, 7.20.2 is not compatible with libpng-1.5 |
| 22:40.14 |
dli |
starseeker,
is there a patch to make 7.20.2 build with libpng-1.5? |
| 22:41.15 |
``Erik |
that's
actually a zlib symbol, one that's been there for a long time
:/ |
| 22:43.15 |
brlcad |
dli: suspect
that's not the actual first error |
| 22:43.38 |
brlcad |
probably
preceeded with some failure to find/include zlib.h |
| 22:43.47 |
dli |
brlcad, seems
to be, I do "make" again, that's the only error |
| 22:44.11 |
brlcad |
show the
entire output from the compile line on |
| 22:44.33 |
brlcad |
make
VERBOSE=1 if you're using cmake |
| 22:44.54 |
dli |
brlcad,
http://pastebin.com/xH38anuF |
| 22:45.05 |
brlcad |
can't get to
pastebin.com |
| 22:45.26 |
brlcad |
try http://paste.ubuntu.com/ |
| 22:46.20 |
``Erik |
gnarly, that
really is the first error |
| 22:46.44 |
dli |
brlcad,
http://paste.ubuntu.com/662232/ |
| 22:48.06 |
brlcad |
so then it's
finding some zlib.h that doesn't declare
Z_BEST_COMPRESSION |
| 22:50.25 |
dli |
brlcad, let
me try to build zlib |
| 22:50.27 |
starseeker |
dli: um. I
suppose I could make a patch... |
| 22:50.36 |
brlcad |
dli: what
does your system zlib.h look like? |
| 22:50.51 |
dli |
starseeker,
if it's not too much work :( |
| 22:51.39 |
brlcad |
so far this
has little if anything to do with libpng-1.5 |
| 22:52.03 |
dli |
brlcad,
http://paste.pocoo.org/show/455636/ |
| 22:52.09 |
``Erik |
you fools
have 8 minutes until http://www.humblebundle.com is
over, if'n ya wanna show your support for linux or osX
:) |
| 22:54.53 |
brlcad |
dli: yeah,
that zlib.h definitely defines Z_BEST_COMPRESSION |
| 22:55.08 |
brlcad |
edit that
file and put a #error on the line before
Z_BEST_COMPRESSION |
| 22:55.13 |
brlcad |
see if it's
actually included |
| 22:55.19 |
dli |
brlcad, so,
it's the building scripts or configure |
| 22:55.37 |
brlcad |
either
neither? |
| 22:56.12 |
starseeker |
dli: this is
most of it: http://bzflag.bz/~starseeker/png_patch.diff |
| 22:56.30 |
starseeker |
given it's
gentoo, I'm assuming you're not using our src/other copies of zlib
or libpng? |
| 22:56.42 |
dli |
starseeker,
thanks |
| 22:57.09 |
brlcad |
the error
says it's not declared, the source includes zlib.h, zlib.h lists it
declared |
| 22:57.15 |
brlcad |
ergo, there
is no problem |
| 22:57.23 |
dli |
starseeker,
no other people, I'm the only one maintaining brlcad in
gentoo |
| 22:57.32 |
``Erik |
2.5 minutes
on humblebundle.com O.o |
| 22:58.08 |
brlcad |
nothing in
libpng-1.5 changes Z_BEST_COMPRESSION |
| 22:58.30 |
brlcad |
so it's still
an unknown problem, and libpng update is possibly a big red
herring |
| 22:58.33 |
starseeker |
knows - was just giving him changes he will likely need
later. |
| 22:58.58 |
brlcad |
OH |
| 22:59.13 |
brlcad |
I'm looking
at head .. did 7.20.2 not include zlib.h ? |
| 22:59.19 |
dli |
starseeker,
why do I still need this patch? http://paste.pocoo.org/show/455638/ |
| 22:59.21 |
brlcad |
(in
src/libged/png.c |
| 22:59.47 |
brlcad |
that would
explain it, lucy |
| 22:59.59 |
dli |
brlcad, the
svn trunk builds without issue |
| 23:00.04 |
starseeker |
dli: um...
may have something to do with spaces in paths... |
| 23:00.40 |
starseeker |
or just
spaces in general |
| 23:00.42 |
brlcad |
dli: yeah,
that explains it all -- the problem is a simple one-liner header
#include missing |
| 23:01.14 |
dli |
brlcad, add
the header to the c file itself? |
| 23:01.21 |
brlcad |
hm? |
| 23:01.29 |
starseeker |
dli: does the
patch I posted fix it? |
| 23:01.31 |
brlcad |
#include
"zlib.h" was missing from that file |
| 23:01.45 |
dli |
starseeker,
let me try |
| 23:01.54 |
brlcad |
starseeker's
patch, http://bzflag.bz/~starseeker/png_patch.diff
fixes it for the previous release |
| 23:02.13 |
brlcad |
png.h must no
longer auto-include zlib.h for you |
| 23:04.17 |
CIA-62 |
BRL-CAD:
03brlcad * r45863 10/brlcad/trunk/src/librt/primitives/dsp/dsp.h:
prevent crashing if the dsp buffer isn't set yet |
| 23:04.46 |
CIA-62 |
BRL-CAD:
03brlcad * r45864 10/brlcad/trunk/src/proc-db/csgbrep.cpp:
initialize all of the dsp fields so we don't crash on
export |
| 23:08.01 |
``Erik |
yup, 1.4 has
#include <zlib.h>, 1.5 does not |
| 23:10.22 |
``Erik |
png.h
indicates that you should pass an actual number and that they may
not correlate to the zlib values in the future |
| 23:11.08 |
``Erik |
line
1646 |
| 23:11.45 |
brlcad |
funny, their
manpage gives an example using Z_BEST_COMPRESSION :) |
| 23:13.06 |
``Erik |
(does his
best wallace shawn voice) docs that're out of date?
inconceivable! |
| 23:14.49 |
CIA-62 |
BRL-CAD:
03kunigami * r45865 10/osl/trunk/compile.sh: added oiio
compilation. there's an issue with cmake mixing TBB versions (like
it does with opengl in brlcad), so by now I just set
TBB_USE=0 |
| 23:16.43 |
CIA-62 |
BRL-CAD:
03bhinesley * r45866 10/brlcad/trunk/src/libged/edit.c: |
| 23:16.43 |
CIA-62 |
BRL-CAD:
Enabled use of bounding box centers of objects as points. Basic
object |
| 23:16.43 |
CIA-62 |
BRL-CAD:
translations are working "translate -k obj1 -a obj2 obj3",
"translate -a obj2 |
| 23:16.43 |
CIA-62 |
BRL-CAD:
obj1", etc. (redrawing is broken, the objects have to be blasted).
It turns out |
| 23:16.43 |
CIA-62 |
BRL-CAD: that
getting the natural origin is what is causing the 0,0,0
coordinates; |
| 23:16.44 |
CIA-62 |
BRL-CAD:
haven't been able to figure out why. Many things aren't working
yet. At least |
| 23:16.44 |
CIA-62 |
BRL-CAD: some
translations using reference vectors are working. |
| 23:18.21 |
CIA-62 |
BRL-CAD:
03brlcad * r45867 10/brlcad/trunk/src/librt/primitives/ (20 files
in 20 dirs): |
| 23:18.21 |
CIA-62 |
BRL-CAD: make
the caller allocate an ON_Brep object, maybe they want to avoid
dynamic |
| 23:18.21 |
CIA-62 |
BRL-CAD:
memory allocation altogether. this plugs a leak in the csgbrep
proc-db and begs |
| 23:18.21 |
CIA-62 |
BRL-CAD:
changing the *_brep() param to a simple ON_Brep * instead of a
double pointer. |
| 23:19.42 |
brlcad |
cheers on bhinesley |
| 23:19.55 |
brlcad |
progress,
:) |
| 23:20.04 |
bhinesley |
yes, finally
:) |
| 23:21.49 |
bhinesley |
still a lot
to fix/test |
| 23:22.18 |
bhinesley |
for instance
"translate 5 obj1.c" is broken |
| 23:22.20 |
bhinesley |
rolls eyes |
| 23:22.31 |
starseeker |
heh - hang in
there |
| 23:22.46 |
starseeker |
that "it's
all coming together" feeling is a lot of fun |
| 23:25.59 |
bhinesley |
starseeker:
agreed |
| 23:30.04 |
bhinesley |
if I could do
one thing differently, I would have used simple linked lists of
arguments with flags, instead of a union of subcommand structs of
args. That made so much more work and caused so many problems, that
it couldn't possibly have been worth it |
| 23:32.56 |
bhinesley |
the only
'pro' is that it should make it easier to build subcommand
arguments programatically. Create a union, attach a command name,
stuff the arguments in the correct elements and go. |
| 23:33.09 |
bhinesley |
s/Create/declare |
| 23:33.25 |
starseeker |
nods - hindsight is often like that |
| 23:49.32 |
starseeker |
makes a note to check this out later: http://dgnlib.maptools.org/ |
| 00:13.34 |
starseeker |
bhinesley:
one question - with the benefit of hindsight, would it be better
going forward to switch to a linked list approach (not right now
obviously, with gsoc winding up RSN, but in the future) |
| 00:14.43 |
bhinesley |
it probably
depends on how often we're building commands
programatically |
| 00:15.22 |
starseeker |
linked lists
can also be built programatically though, can't they? |
| 00:16.13 |
starseeker |
figures for the editing commands programmatic calling will
probably be fairly common... |
| 00:26.36 |
dli |
starseeker,
brlcad with starseeker's patch, brlcad-7.20.2 builds with
libpng-1.5, thanks |
| 00:27.52 |
starseeker |
dli: np -
good to know it fixes it for external libpng as well as our local
copy |
| 00:47.57 |
*** join/#brlcad LainIwakuraX
(~yuki@d24-57-80-191.home.cgocable.net) |
| 00:49.17 |
bhinesley |
starseeker:
yes; but it *may* be easier, and/or less error prone for edit()
callers to use the structs. (btw, callers can actually still use a
linked list if need be, and just run it through
edit_<subcmd-name>_add_cl_args() before calling edit()). I
decided on the edit_cmd union because it seemed like building args
would be more legible, and therefore easier to build:
"cmd.translate.ref_vector.from = arg;" rather than
"args |
| 00:52.12 |
bhinesley |
structs seems
more "rigid", as you have a finite number of elements (arguments)
that you can add |
| 00:54.21 |
bhinesley |
as far as
creating new edit subcommands goes, I don't think it makes much of
a difference; it requires a couple subcommand-specific functions
that would not be required if linked lists were used, but they're
~20 lines and dead simple. |
| 00:58.06 |
bhinesley |
it feels like
hacking in linked-list behavior, though |
| 01:24.14 |
bhinesley |
I can't think
of a compelling reason switch to linked lists. I'm open to
criticism, though. |
| 03:05.03 |
*** join/#brlcad dli_
(~dli@dsl-173-248-211-69.acanac.net) |
| 03:15.04 |
*** join/#brlcad yukonbob
(~bch@S010600235a187d92.ok.shawcable.net) |
| 03:15.05 |
yukonbob |
oh
hai |
| 03:27.51 |
CIA-62 |
BRL-CAD:
03brlcad * r45868 10/brlcad/trunk/src/librt/ (db_io.c dir.c): the
rt_fwrite_internal/db_fwrite_internal functions are only intended
to work with v4 geometry. |
| 03:31.23 |
*** join/#brlcad dli_
(~dli@dsl-69-171-146-13.acanac.net) |
| 03:39.11 |
CIA-62 |
BRL-CAD:
03brlcad * r45869 10/brlcad/trunk/src/proc-db/csgbrep.cpp:
relearning how to write an object from nothing |
| 03:39.38 |
CIA-62 |
BRL-CAD:
03brlcad * r45870 10/brlcad/trunk/src/proc-db/csgbrep.cpp:
ws |
| 03:40.06 |
CIA-62 |
BRL-CAD:
03brlcad * r45871 10/brlcad/trunk/src/proc-db/csgbrep.cpp:
indent |
| 03:43.30 |
CIA-62 |
BRL-CAD:
03brlcad * r45872 10/brlcad/trunk/src/proc-db/ (19 files): ws and
indent cleanup |
| 03:52.08 |
yukonbob |
before I dig
in: I'm getting a build failure on 7.20.2 (NetBSD, providing some
own utilities (ie: tcl/tk/itcl) |
| 03:53.08 |
yukonbob |
is a warning
(treated as error): bitv.c: in function
'bu_hex_to_bitv': |
| 03:53.45 |
yukonbob |
bitv.c:250:
warning: array subscript has type char |
| 03:53.48 |
yukonbob |
, same for
line 255 |
| 03:54.05 |
yukonbob |
had same
error w/ 7.20.0 |
| 03:54.20 |
yukonbob |
known
issue? |
| 03:55.16 |
yukonbob |
hrmm... macro
issue? |
| 03:55.35 |
brlcad |
yukonbob: not
a known issue, just our strict compilation behavior treating a
warning as an error |
| 03:55.53 |
yukonbob |
hey brlcad
:) |
| 03:55.54 |
brlcad |
you can
disable strict compilation and it'll succeed |
| 03:56.09 |
yukonbob |
nods. alright :) Onward! |
| 03:57.05 |
brlcad |
if you try to
compile with trunk, a full build log would be useful |
| 03:57.11 |
brlcad |
so someone
can fix the warnings |
| 03:57.43 |
yukonbob |
will work incrementally. |
| 03:58.19 |
yukonbob |
7.20.2 for
now... I've got some tcl/tk/itcl integration I'd like to work with
somebody on; then bigger fish |
| 03:59.12 |
yukonbob |
just svn updated, but has to review tree, got merge
conflicts, which is weird, considering I don't edit my local
copy. |
| 03:59.51 |
yukonbob |
re-./configure'd, make'ing. |
| 04:00.36 |
yukonbob |
brlcad:
autoconf et al still to be first class citizens for foreseeable
future? |
| 04:01.51 |
brlcad |
yukonbob: not
really |
| 04:02.01 |
brlcad |
the build
system is being replaced with the new cmake build
system |
| 04:02.05 |
yukonbob |
ok... so
cmake transition went well? |
| 04:02.11 |
brlcad |
for the most
part |
| 04:02.14 |
yukonbob |
nice. |
| 04:02.22 |
brlcad |
autotools is
going through our deprecation process now |
| 04:02.27 |
yukonbob |
I like cmake,
despite it's problems. |
| 04:02.47 |
yukonbob |
my biggest
peave is that they didn't use Tcl as the control language, but
half-baked their own, but... ;) |
| 04:02.54 |
brlcad |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/deprecation.txt?revision=HEAD |
| 04:03.09 |
brlcad |
basically a
3-month minimum to give people a head's up |
| 04:03.29 |
yukonbob |
nods. |
| 04:03.41 |
yukonbob |
well,
congratulations on the shift; not a small feat! |
| 04:03.50 |
brlcad |
starseeker
did all the hard work |
| 04:03.57 |
yukonbob |
was just going to ask... |
| 04:04.09 |
yukonbob |
I know cliff
was heads-down in it for a while. |
| 04:04.34 |
yukonbob |
[incr
starseeker] |
| 04:06.21 |
yukonbob |
dammit |
| 04:06.24 |
CIA-62 |
BRL-CAD:
03brlcad * r45873 10/brlcad/trunk/src/libged/ (dbip.c grid.c
nmg_collapse.c): quell the non-%V warnings listed in dli's build
log |
| 04:06.28 |
yukonbob |
now real
macro issues. |
| 04:07.01 |
yukonbob |
iso C does
not permit named variadic macros... |
| 04:07.43 |
yukonbob |
hrmm. Looks
to be from own X11 headers. |
| 04:08.26 |
yukonbob |
oh. nm. /me
reads on, sees, is itk. |
| 04:15.40 |
CIA-62 |
BRL-CAD:
03brlcad * r45874 10/brlcad/trunk/src/other/tcl/CMakeLists.txt:
looks like this file is not in sync with the sources.. build
failure with missing symbol and sure enough the source file isn't
being compiled. |
| 04:24.18 |
brlcad |
bhinesley:
../../../src/libged/edit.c:1226: warning: passing argument 2 of
'ged_path_validate' discards qualifiers from pointer target
type |
| 04:25.33 |
brlcad |
if you can
capture another "make -k 2>&1 | tee build.log" .. I can take
another pass at squashing any warnings that remain so you can keep
strict enabled |
| 04:26.40 |
bhinesley |
brlcad: will
do |
| 04:27.32 |
brlcad |
also, |
| 04:27.33 |
brlcad |
../../../src/libged/path.c:83: error:
conflicting types for 'ged_path_validate' |
| 04:27.33 |
brlcad |
../../../include/ged.h:1885: error:
previous declaration of 'ged_path_validate' was here |
| 04:27.42 |
brlcad |
perhaps
header not checked in |
| 04:27.56 |
bhinesley |
that's
odd |
| 04:28.13 |
brlcad |
or... maybe
I'm not up to date..... |
| 04:28.19 |
brlcad |
lemme
check |
| 04:28.41 |
bhinesley |
I did change
them in 2 seperate commits |
| 04:30.03 |
brlcad |
low and
behold, that was the problem for both issues, it's all
good |
| 04:30.09 |
brlcad |
sorry for the
bother! |
| 04:30.18 |
bhinesley |
oh
np |
| 04:39.27 |
CIA-62 |
BRL-CAD:
03brlcad * r45875 10/brlcad/trunk/src/proc-db/csgbrep.cpp: things
are way simpler than I was attempting, just call
wdb_put_internal() |
| 04:40.29 |
CIA-62 |
BRL-CAD:
03brlcad * r45876 10/brlcad/trunk/src/proc-db/csgbrep.cpp: unused
var |
| 04:43.08 |
bhinesley |
brlcad: build
log: http://paste.pocoo.org/show/455744/ |
| 04:48.11 |
CIA-62 |
BRL-CAD:
03brlcad * r45877
10/brlcad/trunk/src/proc-db/csgbrep.cpp: |
| 04:48.11 |
CIA-62 |
BRL-CAD:
turns out, wdb_put_internal() has similar delusional notions to the
mk_*() |
| 04:48.11 |
CIA-62 |
BRL-CAD:
functions assuming memory is dynamic and ready to be released.
since we have |
| 04:48.11 |
CIA-62 |
BRL-CAD:
stack objects, that's bad. fortunately, it skips the free if
idb_meth isn't |
| 04:48.11 |
CIA-62 |
BRL-CAD: set,
so try to pull a fast one. |
| 05:00.24 |
CIA-62 |
BRL-CAD:
03brlcad * r45878 10/brlcad/trunk/src/librt/ (db5_io.c wdb.c):
prevent crashing if idb_meth isn't set |
| 05:21.38 |
CIA-62 |
BRL-CAD:
03brlcad * r45879 10/brlcad/trunk/src/librt/primitives/ (5 files in
5 dirs): remove debugging print statements, noisy |
| 05:28.04 |
CIA-62 |
BRL-CAD:
03brlcad * r45880
10/brlcad/trunk/src/librt/primitives/pipe/pipe_brep.cpp:
shush |
| 05:28.25 |
CIA-62 |
BRL-CAD:
03brlcad * r45881
10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: print 5 in v5
routines, not 4 |
| 05:35.41 |
CIA-62 |
BRL-CAD:
03brlcad * r45882
10/brlcad/trunk/src/librt/primitives/ehy/ehy_brep.cpp: unused vars,
perhaps wip |
| 05:36.27 |
CIA-62 |
BRL-CAD:
03brlcad * r45883 10/brlcad/trunk/ (include/raytrace.h
src/librt/primitives/sketch/sketch.c): more uint32_t magic number
fallout |
| 05:50.36 |
CIA-62 |
BRL-CAD:
03brlcad * r45884 10/brlcad/trunk/src/librt/primitives/
(extrude/extrude.c revolve/revolve.c sketch/sketch_brep.cpp): even
more magic fallout. highlights the importance of consistently
testing magic numbers, particularly where pointers to them are
shoved into bu pointer tables and end up with signage
issues. |
| 06:02.50 |
CIA-62 |
BRL-CAD:
03brlcad * r45885
10/brlcad/trunk/src/librt/primitives/revolve/revolve_brep.cpp: yep,
more |
| 06:07.23 |
yukonbob |
yay me!
successfully built, installing; issues that I recognize from
previous installs; conflicts w/ libpng between in-tree and
other-installations, need to #include <zlib.h> (will find
file), tweak itcl/itk... |
| 06:11.29 |
CIA-62 |
BRL-CAD:
03brlcad * r45886
10/brlcad/trunk/src/librt/primitives/revolve/revolve_brep.cpp: more
shushing |
| 06:12.36 |
CIA-62 |
BRL-CAD:
03brlcad * r45887 10/brlcad/trunk/src/proc-db/csgbrep.cpp: and with
this, we should now have all primitives getting written out
identically in brep and implicit form (export needed the idb_type
to be set). dsp is hozered, so disable. |
| 06:13.09 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 06:29.32 |
brlcad |
bhinesley:
THX! |
| 06:30.22 |
bhinesley |
np |
| 06:30.46 |
*** part/#brlcad saltan
(~lieven@d51530284.static.telenet.be) |
| 06:46.06 |
CIA-62 |
BRL-CAD:
03bhinesley * r45888 10/brlcad/trunk/src/libged/edit.c: (log
message trimmed) |
| 06:46.06 |
CIA-62 |
BRL-CAD:
Wrote a function to expand arguments with partial coordinates set,
via -x/-y/-z |
| 06:46.06 |
CIA-62 |
BRL-CAD:
options (support for this was missing in edit()). Required changes
to functions |
| 06:46.06 |
CIA-62 |
BRL-CAD: for
getting object coordinates; they now write to any vector they are
passed, so |
| 06:46.06 |
CIA-62 |
BRL-CAD: that
coordinates may be obtained without modifying the edit_cmd object.
Resolved |
| 06:46.06 |
CIA-62 |
BRL-CAD:
issue in an argument string parsing function, which was incorrectly
pairing |
| 06:46.07 |
CIA-62 |
BRL-CAD:
objects with the coordinates that they followed. Had to remove
ability to |
| 07:06.27 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3066 10/wiki/User:Bhinesley: /* Log */ today |
| 07:23.16 |
*** join/#brlcad dli
(~dli@dsl-69-171-146-13.acanac.net) |
| 09:45.54 |
*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) |
| 09:46.33 |
*** join/#brlcad d_rossbe1g
(~rossberg@BZ.BZFLAG.BZ) |
| 09:47.20 |
abhi2011 |
brlcad: I
have been trying to insert a struct rt_db_internal into a
directory |
| 09:48.10 |
abhi2011 |
it goes like
this : http://bin.cakephp.org/view/73267920 |
| 09:48.30 |
abhi2011 |
so I create a
in-mem dbip |
| 09:48.58 |
abhi2011 |
and then I
create a struct directory by using dp = db_lookup(dbip,
ip->idb_meth->ft_name, LOOKUP_NOISY) |
| 09:49.19 |
abhi2011 |
the struct
directory is required when using rt_db_put_internal(dp, dbip, ip,
&rt_uniresource) |
| 09:49.59 |
abhi2011 |
the
db_lookup() is bound to fail however because the dbip it uses has
just been created, so its empty |
| 09:50.39 |
abhi2011 |
so is there
any other way to create a struct directory * that can be passed to
rt_db_put_internal() |
| 09:54.47 |
abhi2011 |
probably
db_diradd() may work |
| 10:34.47 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 11:17.49 |
d_rossberg |
abhi2011: you
have just created the in-memory database, therefore it's
empty |
| 11:18.35 |
d_rossberg |
you probably
need a rt_i* as a parameter |
| 11:19.55 |
abhi2011 |
d_rossberg:
Yes true, however I need top insert a struct rt_db_internal into
the dbip before I can make a rt_i* out of it |
| 11:20.05 |
abhi2011 |
<PROTECTED> |
| 11:20.45 |
abhi2011 |
however
before I can call rt_new_rti , i need to insert an object
(represented by rt_db_internal) into the dbip |
| 11:22.12 |
abhi2011 |
to insert a
rt_db_internal into the dbip, I call rt_db_put_internal(dp, dbip,
ip, &rt_uniresource) |
| 11:22.29 |
abhi2011 |
which
requires a struct directory * dp |
| 11:22.47 |
abhi2011 |
its while
getting the dp that I run into an issue |
| 11:23.22 |
abhi2011 |
I obviously
cannot use db_loopup() because dbip is empty |
| 11:23.32 |
abhi2011 |
yet I need dp
:P |
| 11:23.56 |
abhi2011 |
*db_lookup() |
| 11:24.06 |
d_rossberg |
i'm afraid
it's impossible to get the rtip back from a rt_db_internal
structure |
| 11:24.49 |
d_rossberg |
rt_db_internal points to the internal
representation of an object |
| 11:24.56 |
abhi2011 |
hmm, my final
aim is to calculate the bounding box for the passed
rt_db_internal |
| 11:25.07 |
d_rossberg |
it needs to
be castet to the real object type |
| 11:25.13 |
abhi2011 |
oh
ok |
| 11:25.31 |
abhi2011 |
so a switch
case to detect the object type |
| 11:25.31 |
abhi2011 |
and
convert |
| 11:25.31 |
d_rossberg |
look at
rtgeom.h for these types |
| 12:53.39 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 12:53.39 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 12:55.22 |
CIA-62 |
BRL-CAD:
03brlcad * r45889 10/brlcad/trunk/src/proc-db/csgbrep.cpp: this is
v5 geometry, need to set the major_type as well as the
minor. |
| 13:00.47 |
abhi2011 |
So I am
calling wdb_put_external() using : |
| 13:00.49 |
abhi2011 |
if
(wdb_put_internal(dbip->dbi_wdbp, ip->idb_meth->ft_name,
&ip, 1.0) < 0) |
| 13:01.05 |
abhi2011 |
I want it to
insert an object named sph2.s |
| 13:01.28 |
abhi2011 |
however
ip->idb_meth->ft_name point to the ID of the sphere geometry
ID_ELL |
| 13:01.46 |
abhi2011 |
I would need
the object name here |
| 13:02.08 |
abhi2011 |
There should
be some way to extract the object name from the struct
rt_db_internal |
| 13:02.21 |
abhi2011 |
I am looking
at the fields of idb_meth now |
| 13:03.39 |
abhi2011 |
so instead of
wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0 "ID_ELL",
ip=0x7fffffffd988, local2mm=1) |
| 13:03.52 |
abhi2011 |
I want to
call the function as wdb_put_internal (wdbp=0x634420,
name=0x7fffe98ccdb0 "sph2.s", ip=0x7fffffffd988,
local2mm=1) |
| 13:06.23 |
CIA-62 |
BRL-CAD:
03brlcad * r45890 10/brlcad/trunk/src/proc-db/csgbrep.cpp: extrude
and revolve don't actually need their own sketch objects,
reduce |
| 13:09.02 |
tofu |
abhi2011:
look at that file (csgbrep.cpp) .. in there is a little function
that shows an rt_db_internal getting added to a
database |
| 13:09.47 |
tofu |
at the
rt_db_internal layer, you don't know the name any more, but you
don't need to -- so you can just give it any dummy name |
| 13:10.25 |
tofu |
the whole
point of adding it to a dbip in the first place is just so you can
get a proper rtip so you can call dirbuild and/or prep to get the
bounding box calculated automatically |
| 13:10.49 |
tofu |
see the
write_out() function |
| 13:12.03 |
abhi2011 |
tofu: thanks!
i suspected the name wouldnt be there anymore and yes i dont need
it too |
| 13:12.04 |
tofu |
there's also
wdb_put_internal() that is even simpler and might work for you
(just write_out() couldn't use it) |
| 13:12.22 |
abhi2011 |
ok |
| 13:13.25 |
abhi2011 |
tofu: yes i
am using wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0
"ID_ELL", ip=0x7fffffffd988, local2mm=1) now |
| 13:13.38 |
abhi2011 |
which needs a
name to be pased as well |
| 13:13.53 |
abhi2011 |
i could try a
dummy of course |
| 13:18.10 |
tofu |
bhinesley:
you actually have no more compilation warnings listed in that log,
just one bonefide build failure in cursor.c |
| 13:19.41 |
tofu |
bhinesley:
something is awry with the termcap.h/term.h/curses.h header
detection, so it's not getting a header included that it needs --
if you would, work with starseeker to see what cmake isn't
detecting properly as it's not a source code issue but a build
system issue |
| 13:30.03 |
CIA-62 |
BRL-CAD:
03brlcad * r45891 10/brlcad/trunk/src/tclscripts/mged/openw.tcl:
only attempt to override tk behavior if tk is loaded |
| 13:33.13 |
starseeker |
tofu: I'll
take a look at that today - Bob's machine is having a similar
issue |
| 13:33.57 |
starseeker |
mildly
frustrating - I thought I finally had that sorted - but I'll squash
it sooner or later |
| 13:34.35 |
CIA-62 |
BRL-CAD:
03brlcad * r45892
10/brlcad/trunk/src/tclscripts/mged/helpdevel.tcl: supposed to read
helplib.tcl, but it doesn't, so simpilfy |
| 13:37.12 |
CIA-62 |
BRL-CAD:
03brlcad * r45893 10/brlcad/trunk/src/tclscripts/mged/help.tcl: try
a different way to read in the helplib.tcl file, source
it |
| 13:46.05 |
CIA-62 |
BRL-CAD:
03brlcad * r45894
10/brlcad/trunk/src/tclscripts/mged/mged.tcl: |
| 13:46.05 |
CIA-62 |
BRL-CAD:
another case where a tk function is curiously being overridden for
no apparent |
| 13:46.05 |
CIA-62 |
BRL-CAD:
reason. TextInsert was added by gdurf back in 1995 with an empty
log message, |
| 13:46.05 |
CIA-62 |
BRL-CAD: so
yank it. the current tk version looks similar enough but
better. |
| 13:48.44 |
CIA-62 |
BRL-CAD:
03brlcad * r45895 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl:
don't shadow the dot proc with a value |
| 13:51.16 |
CIA-62 |
BRL-CAD:
03brlcad * r45896 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl:
remove the Sketch_editor namespace lookalike prefix from a handful
of funcs that aren't listed as itcl class methods but are
pretending to be them. make them regular procs. |
| 13:53.34 |
CIA-62 |
BRL-CAD:
03brlcad * r45897
10/brlcad/trunk/src/tclscripts/rtwizard/RaytraceWizard.tcl: script
isn't always being run as a main application, make sure argv
exists |
| 13:55.31 |
CIA-62 |
BRL-CAD:
03brlcad * r45898 10/brlcad/trunk/src/tclscripts/ (cad_dialog.tcl
hoc.tcl): make sure the tk namespace exists before trying to set
variables in it |
| 14:04.00 |
tofu |
that should
actually take care of most if not all of the tclscript
blather |
| 14:04.12 |
CIA-62 |
BRL-CAD:
03brlcad * r45899 10/brlcad/trunk/src/tclscripts/mged/ (8
files): |
| 14:04.12 |
CIA-62 |
BRL-CAD: this
could use some rethinking, but instead of testing to make sure the
commands |
| 14:04.12 |
CIA-62 |
BRL-CAD: we
need actually exist at 'source' time, see if they exist at
run-time. this |
| 14:04.12 |
CIA-62 |
BRL-CAD:
should avoid pkgindex blather and be more likely that the command
is actually |
| 14:04.12 |
CIA-62 |
BRL-CAD:
already loaded. |
| 14:07.37 |
abhi2011 |
csgbrep.cpp
seems to be making a model by inserting arbs, ellipses etc using
mk_brep() |
| 14:08.55 |
tofu |
it would seem
that way because it is |
| 14:09.15 |
tofu |
it makes each
primitive in implicit and brep/nurbs form |
| 14:09.23 |
tofu |
irrelevant
for what you're doing |
| 14:09.45 |
abhi2011 |
ok but I can
use mkprep() to insert rt_db_internal |
| 14:09.47 |
tofu |
the point is
how it's writing out primitives using an existing rt_db_internal*
is very similar to what you're trying to do |
| 14:09.51 |
abhi2011 |
to a
wdb |
| 14:09.55 |
tofu |
no |
| 14:10.04 |
tofu |
ignore
mk_* |
| 14:10.10 |
abhi2011 |
ok |
| 14:10.53 |
tofu |
you were
trying to write an rt_db_internal to an inmem dbip, so you can get
an rtip from it |
| 14:10.59 |
abhi2011 |
yes
right |
| 14:11.06 |
abhi2011 |
mk_brep
writes a boundary repr |
| 14:11.18 |
tofu |
IGNORE
mk_* |
| 14:11.37 |
abhi2011 |
yes ignored
:) |
| 14:11.40 |
tofu |
you care
about the rt_db_internal |
| 14:11.46 |
abhi2011 |
yes |
| 14:11.53 |
tofu |
read
write_out() |
| 14:12.16 |
tofu |
it's yet
another example of writing an rt_db_internal, you might be able to
use a similar method |
| 14:12.30 |
tofu |
you may also
be able to just use wdb_put_internal() |
| 14:13.52 |
abhi2011 |
tofu: yes I
have tried wdb_put_internal(), however it requires a valid name t
be passed, a dummy name does not work |
| 14:14.05 |
tofu |
eh? |
| 14:14.29 |
abhi2011 |
well I have
tried it like this : wdb_put_internal(dbip->dbi_wdbp, "dummy.s",
&ip, 1.0) |
| 14:15.19 |
tofu |
it doesn't
know what is valid/invalid, so if that failed, it's something
else |
| 14:15.55 |
tofu |
in fact, the
name you provided isn't dummy at that point -- you're saying "write
this ip as dummy.s" |
| 14:16.18 |
tofu |
which is
correct -- so if it fails, something is probably either wrong with
the wdbp or ip |
| 14:16.21 |
abhi2011 |
yes
right |
| 14:17.07 |
abhi2011 |
hmm, I do a
valid lookup of the ip using if ( !rt_db_lookup_internal(dbip,
argv[2], &dp, &intern, LOOKUP_NOISY,
&rt_uniresource)){ |
| 14:18.09 |
tofu |
so then when
you say it "does not work", what do you mean exactly |
| 14:19.18 |
abhi2011 |
well I get a
bad pointer error : ERROR: bad pointer 0x7ffff73da148: s/b
rt_db_internal(xdbbd867), was Unknown_Magic(x7ffff73da5e0), file
/home/abhi/socis/brlcad/src/librt/wdb.c, line 289 |
| 14:19.42 |
abhi2011 |
so here is
the main program I have got so far to test : http://bin.cakephp.org/view/73267920 |
| 14:19.56 |
abhi2011 |
the program
tests the new function in librt |
| 14:20.36 |
abhi2011 |
this is the
function : http://bin.cakephp.org/view/267477296 |
| 14:23.49 |
abhi2011 |
trying to
find out if the ip i am passing is somehow in incorrect form :
wdb_put_internal (wdbp=0x634420, name=0x7fffe964745f "dummy.s",
ip=0x7fffffffd988, local2mm=1) |
| 14:25.16 |
abhi2011 |
hmm the
magick number is wrong |
| 14:26.56 |
abhi2011 |
the struct
rt_db_internal probably needs to be properly initialized, just
passing a pointer wont do |
| 14:27.35 |
abhi2011 |
i ll try with
RT_DB_INTERNAL_INIT(tmp_internal); |
| 14:30.20 |
abhi2011 |
hmm no ,
thats not the case, because i pass a valid ip using
rt_db_lookup_internal() in the program |
| 14:32.46 |
abhi2011 |
wdb_put_internal() causes bu_badmagic
(ptr=0x7fffffffd988, magic=230414439, str=0x7fffe96a4577
"rt_db_internal", file=0x7fffe96a4350
"/home/abhi/socis/brlcad/src/librt/wdb.c", line=289) to be
called |
| 14:34.39 |
tofu |
abhi2011: are
you up-to-date with your checkout? |
| 14:35.04 |
abhi2011 |
no I am not ,
will check out now |
| 14:35.16 |
tofu |
there were a
lot of magic number changes just yesterday and last night affecting
magic numbers, that error looks related |
| 14:35.23 |
abhi2011 |
oh
ok |
| 14:35.42 |
abhi2011 |
are magick
numbers in a definite range ? |
| 14:35.49 |
tofu |
should always
stay as up-to-date as possible, svn updating throughout the day
unless you're at a critical point yourself |
| 14:35.53 |
tofu |
yes |
| 14:35.58 |
tofu |
they're a
specific value that is expected |
| 14:35.59 |
abhi2011 |
so I can just
look at a number and say this looks wrong |
| 14:36.03 |
abhi2011 |
ok |
| 14:36.29 |
tofu |
s/b means
"should be" |
| 14:36.45 |
tofu |
so it should
have had a value of xdbbd867 ... but instead it encountered
x7ffff73da5e0 |
| 14:37.15 |
tofu |
which just
looks like the aforementioned type cast problem that has already
been fixed |
| 14:37.34 |
abhi2011 |
oh ok, yah
the 7fffff.. thing looks like a virtual memory pointer |
| 14:47.44 |
tofu |
make sure
you're actually passing correct data too, of course, that it really
is a valid rt_db_internal |
| 14:50.05 |
abhi2011 |
tofu: yes, I
get the rt_db_internal using rt_db_lookup_internal(), which does
not return an error |
| 14:50.51 |
CIA-62 |
BRL-CAD:
03n_reed * r45900 10/brlcad/trunk/src/libgcv/wfobj/ (7 files):
Removing unused C versions of obj parser sources. They will be
out-of-sync with the refactored C++ parser sources. |
| 14:51.44 |
CIA-62 |
BRL-CAD:
03Lighkatwheajec 07http://compilefarm.net * r3067
10/wiki/Main_Page: |
| 15:24.59 |
abhi2011 |
thats
strange, I get a seg fault after the latest checkout , during make
install |
| 15:25.04 |
abhi2011 |
while
Generating ../share/brlcad/7.20.3/db/terra.g |
| 15:26.01 |
abhi2011 |
http://bin.cakephp.org/view/1252572721 |
| 15:26.48 |
abhi2011 |
ok I ll
probably need to run cmake again as well |
| 15:30.30 |
CIA-62 |
BRL-CAD:
03n_reed * r45901 10/brlcad/trunk/src/libgcv/wfobj/ (obj_parser.h
obj_parser.h): Reverted obj_parser.h to last working
verion. |
| 15:52.08 |
abhi2011 |
thats wierd I
got the same error again |
| 15:52.55 |
abhi2011 |
anyone else
getting this error while building the latest version ? |
| 15:53.32 |
abhi2011 |
appears to be
related to rt_uniresource : ../bin/asc2g: Symbol `rt_uniresource'
has different size in shared object, consider
re-linking |
| 16:11.52 |
tofu |
abhi2011: you
need to fully rebuild |
| 16:15.10 |
brlcad |
whatever
dependency checking that cmake is doing apparently isn't full
proof, make clean and rebuild |
| 16:33.08 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 16:41.24 |
bhinesley |
starseeker:
at your service; let me know if you need me to do anything for the
termcap/term/curses detection issue |
| 17:01.47 |
CIA-62 |
BRL-CAD:
03n_reed * r45902 10/brlcad/trunk/src/libgcv/wfobj/ (7 files):
Changing .cc to .cpp. Whitespace and style. |
| 17:04.37 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 17:48.10 |
abhi2011 |
thats strange
a did a fresh checkout and a clean rebuild |
| 17:48.23 |
abhi2011 |
brlcad
compiled successfully |
| 17:48.45 |
abhi2011 |
and I
inserted my function into librt for finding the bounding
box |
| 17:49.01 |
abhi2011 |
but I still
get an error related to magick numbers |
| 17:49.13 |
abhi2011 |
ERROR: bad
pointer 0x7fff838b3c18: s/b rt_db_internal(xdbbd867), was
Unknown_Magic(x838b40b0), file
/home/abhi/socis/brlcad/src/librt/wdb.c, line 289 |
| 17:49.50 |
abhi2011 |
i dont think
this is a svn related problem, as I did a fresh build after
clearing everything |
| 17:51.09 |
brlcad |
what does
your function look like |
| 17:52.40 |
abhi2011 |
brlcad: here
it is http://bin.cakephp.org/view/84589638 |
| 17:53.37 |
abhi2011 |
this is the
test program : http://bin.cakephp.org/view/453281250 |
| 17:53.40 |
brlcad |
I have
trouble believing that compiles without warning |
| 17:54.38 |
brlcad |
listen to
your compiler :) |
| 17:55.17 |
brlcad |
the bad point
failure is correct from what I see |
| 17:55.23 |
brlcad |
*pointer |
| 18:03.41 |
abhi2011 |
brlcad: I ll
have a look at the warnings again :) |
| 18:09.21 |
abhi2011 |
ah shoot!!,
missed that one among the thousand other warnings |
| 18:15.28 |
brlcad |
you shouldn't
have any warnings in your code.... |
| 18:23.07 |
abhi2011 |
by the way,
while building brlcad, do you generally enable strict off : cmake
../brlcad -DBRLCAD-ENABLE_STRICT=OFF
-DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 18:23.41 |
``Erik |
leaves it at default strictness |
| 18:24.31 |
abhi2011 |
ok
:) |
| 18:25.46 |
bhinesley |
abhi2011:
We're supposed to leave it on. I'm running gcc 4.6, so it's been
necessary for me to disable it while the compiler warnings were
being dealt with; but all code should be strict
compliant. |
| 18:25.57 |
brlcad |
strict would
be very useful if we turned it off, the point is to fix the issues
reported |
| 18:27.15 |
abhi2011 |
ok, yes I
remember turning it off last month when I running on gcc 4.6.0
:P |
| 18:27.55 |
bhinesley |
abhi2011:
should be close to working now, if not working already |
| 18:28.05 |
abhi2011 |
nice
! |
| 18:28.18 |
bhinesley |
brlcad has
been working 25 hours a day on that |
| 18:28.30 |
bhinesley |
cracks whip |
| 18:28.36 |
abhi2011 |
yeah I have
seen him committing all day ! |
| 18:28.42 |
brlcad |
jumps |
| 18:28.46 |
abhi2011 |
:P |
| 18:29.13 |
abhi2011 |
well lots of
commits |
| 18:30.36 |
brlcad |
abhi2011: if
you read the announcements from CIA-62 or join the brlcad-commits
mailing list, it's easier to follow developments as they occur so
you are aware what's going on and how changes might affect
you |
| 18:31.17 |
brlcad |
the commits
mailing list can be particularly educational if you read through
the patches and comments, get more familiar reading
code |
| 18:31.50 |
brlcad |
(and that's
true for pretty much any dev and any project that has a commit
tracker) |
| 18:31.58 |
abhi2011 |
yes I have
been following the CIA-62 announcements, will join the
brlcad-commits mailing list |
| 18:32.43 |
brlcad |
not just to
see "oh, john has been very busy and codes day and night" .. but
actually have a pretty good idea of what john is doing and
why |
| 18:38.33 |
``Erik |
one would
hope the commit message does that, but the diff is what's really
happening |
| 18:44.13 |
CIA-62 |
BRL-CAD:
03Sean 07http://compilefarm.net * r3068
10/wiki/Main_Page: Reverted edits by
[[Special:Contributions/Lighkatwheajec|Lighkatwheajec]] ([[User
talk:Lighkatwheajec|Talk]]); changed back to last version by
[[User:Sean|Sean]] |
| 18:44.17 |
CIA-62 |
BRL-CAD:
03Sean 07http://compilefarm.net * r0
10/wiki/Special:Log/block: blocked [[User:Lighkatwheajec]] with an
expiry time of infinite (account creation disabled, e-mail
blocked): Spamming links to external sites |
| 18:47.27 |
abhi2011 |
yes, hoping
to get commit access soon too :) |
| 19:05.14 |
abhi2011 |
ok I am
finally past wdb_put_internal(), so rt_gettree() must always be
called before rt_prep_parallel() , to load the geometry into rtip
? |
| 19:05.46 |
brlcad |
actually
rt_gettree() should be sufficient, iirc |
| 19:05.55 |
abhi2011 |
ok |
| 19:06.07 |
brlcad |
you may have
the bounding boxes computed by then |
| 19:06.49 |
abhi2011 |
ok, so
rt_gettree() gets the tree structure for the passed object name,
and attaches it to the rtip list of regions ? |
| 19:07.12 |
abhi2011 |
or probably
marks them in rtip , that this and this will be raytraced in the
future |
| 19:08.16 |
``Erik |
hm, bounding
volume info is generated during ft_prep() |
| 19:09.02 |
abhi2011 |
ok, and
ft_prep() is probably called only by rt_prep() |
| 19:09.16 |
``Erik |
yeh (or
rt_prep_parallel() ) |
| 19:09.20 |
brlcad |
you'd think
that |
| 19:09.23 |
abhi2011 |
yes |
| 19:09.26 |
brlcad |
but iirc,
it's not |
| 19:09.43 |
brlcad |
don't guess,
read the code |
| 19:10.03 |
``Erik |
the 3 prims I
looked at set st_center and friends in their _prep() funcs,
rt_gettrees_muves() doesn't try to call prep on the
primitives |
| 19:10.04 |
brlcad |
I believe you
have everything you need after calling gettrees |
| 19:13.08 |
brlcad |
prior
statement true, latter statement not so true |
| 19:16.12 |
brlcad |
basically, a
slight nomenclature mismatch, always been the case
afaicr |
| 19:16.22 |
brlcad |
rt_prep() and
rt_prep_parallel() set up the spatial partitioning and other
"preparation" activities |
| 19:16.42 |
brlcad |
the actual
prep callbacks, however, are called before that during tree
loading |
| 19:17.10 |
brlcad |
we consider
all of that "prep time" when talking about rt, but code-wise, it's
a separate step |
| 19:17.40 |
``Erik |
huh, yeah,
_rt_gettree_leaf() does the ft_prep |
| 19:18.19 |
``Erik |
guess ya do
have the primitive aabb's after rt_gettree(), just not the
bvh |
| 19:18.24 |
brlcad |
thinks he brought a server to its knees |
| 19:18.38 |
``Erik |
while(1)fork(); ? |
| 19:18.48 |
brlcad |
a little more
insideous |
| 19:18.53 |
brlcad |
and
unintentional |
| 19:18.55 |
brlcad |
actual
work |
| 19:19.35 |
``Erik |
g-nmg -a
.00001 ? :D I oom'd a 64g box with something similar |
| 19:19.48 |
brlcad |
not even that
far |
| 19:20.01 |
brlcad |
three or four
big facetizations and a level 7 sphereflake output |
| 19:20.35 |
``Erik |
ah, our
sphflake example is level 3, right? |
| 19:20.41 |
brlcad |
a 0.1, two
0.01, and a default, along with sphflake |
| 19:20.50 |
brlcad |
something
around there |
| 19:20.57 |
brlcad |
I've done a 7
and 8 before |
| 19:21.31 |
brlcad |
something
like 100MB for 7, 1GB or so for 8 iirc |
| 19:22.44 |
brlcad |
course, could
have been completely coincidental too |
| 19:22.59 |
brlcad |
but it's
acting like a thrashed pig, a dead one at that |
| 19:25.51 |
``Erik |
hm, c++ link
issues with gcc 4.7, std::list stuff O.o |
| 19:32.10 |
abhi2011 |
ok I am
trying to understand the code in tree.c, one thing I can
immediately get : there is just one tree for the whole model right
? |
| 19:32.34 |
abhi2011 |
so
rt_gettrees() can get nodes from this main tree |
| 19:32.51 |
abhi2011 |
which are the
roots from smaller trees |
| 19:33.29 |
abhi2011 |
*for smaller
trees I mean |
| 19:33.31 |
brlcad |
``Erik: I
linked with 4.7 just last week |
| 19:34.08 |
brlcad |
ooh, server
sprung back to life! |
| 19:34.19 |
``Erik |
I'm
rebuilding with all local libs now, may've been a dep linked
against 4.2 (this is on fbsd) |
| 19:34.32 |
brlcad |
hehe, load in
the 50's |
| 19:35.10 |
``Erik |
sphflake and
the tesselations should all be single threaded... did someone do
something silly and try to start a java program on it or something?
O.o :D |
| 19:35.36 |
CIA-62 |
BRL-CAD:
03bhinesley * r45903 10/brlcad/trunk/src/libged/edit.c: flags for
all 3 coordinates supplied in the "[x [y [z]]]" format were being
set regardless of whether or not some of the optional coordinates
were omitted |
| 19:36.32 |
brlcad |
probably
memory, all four jobs I had running probably all wanted as much
memory as they could get |
| 19:36.58 |
brlcad |
hm, though
top seems to think there's plenty of memory, no swap in
use |
| 19:37.09 |
brlcad |
*shrug* |
| 19:37.37 |
``Erik |
http://paste.lisp.org/display/123942 |
| 19:37.49 |
brlcad |
aha... |
| 19:37.50 |
brlcad |
Program
terminated with signal SIGKILL, Killed. |
| 19:38.13 |
brlcad |
someone
intervened to bring it back to life |
| 19:38.50 |
brlcad |
apparently
facetizing an ehy was sinking the ship |
| 19:39.51 |
brlcad |
``Erik: at a
glance, the GLIBCXX_3.4.15 is suspicious |
| 19:40.19 |
``Erik |
yeh,
considering librt links against /lib/libc.so |
| 19:40.23 |
brlcad |
gcc 4.7
should have come with a libc update |
| 19:41.13 |
``Erik |
that librt
links but things using librt don't is also surprising |
| 19:42.09 |
``Erik |
hasn't really done c++ on gcc, or lately.. was almost all
back on msvc1.0 and borland 4.5/5.02 |
| 19:44.21 |
kunigami |
does anyone
know how to force cmake to find an include path? http://paste.ubuntu.com/662921/ |
| 19:47.03 |
``Erik |
hm,
interesting... it links against /usr/local/lib/gcc47/libstdc++.so,
then runtime loads /usr/lib/libstdc++.so... might need explicit
rpath info |
| 19:47.56 |
brlcad |
or ld_lib
path set |
| 19:48.11 |
brlcad |
or
/usr/local/lib config'd as a system lib dir before
/usr/lib |
| 19:48.17 |
``Erik |
yeah, my
little test program worked when I gave it
LD_LIBRARY_PATH |
| 19:48.31 |
``Erik |
you mean
/usr/local/lib/gcc47? I think /usr/local/lib is already
there |
| 19:48.52 |
brlcad |
right |
| 19:49.52 |
``Erik |
that's
letting the build continue *shrug* interesting that the rpath info
isn't being forced to the 'odd' library |
| 20:00.21 |
CIA-62 |
BRL-CAD:
03brlcad * r45904
10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: revolve
doesn't yet implement tessellation, but doesn't mean we should
bomb. the NMG_CK checks aren't right since it's this function's job
to fill them in. |
| 20:10.16 |
CIA-62 |
BRL-CAD:
03brlcad * r45905 10/brlcad/trunk/ (5 files in 3 dirs): revolve
using sk instead of skt like extrude is just asking for trouble.
make the two consistent, the same. |
| 20:13.19 |
CIA-62 |
BRL-CAD:
03starseeker * r45906
10/brlcad/trunk/src/other/CMakeLists.txt: |
| 20:13.20 |
CIA-62 |
BRL-CAD: Ah -
when doing the local termlib, we have to specify that we are using
the |
| 20:13.20 |
CIA-62 |
BRL-CAD:
termcap.h header as well. Probably didn't spot this sooner because
most systems |
| 20:13.20 |
CIA-62 |
BRL-CAD: had
a system termcap.h and the BRLCAD_INCLUDE_FILE test just happened
to work as |
| 20:13.20 |
CIA-62 |
BRL-CAD:
well. |
| 20:19.47 |
CIA-62 |
BRL-CAD:
03brlcad * r45907
10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: similarly
wrong to check them for validity when we're supposed to fill them
in |
| 20:20.35 |
CIA-62 |
BRL-CAD:
03brlcad * r45908
10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: prevent
tessellation from crashing on primitives that don't have a callback
set (like sketch) |
| 20:27.29 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45909 10/brlcad/trunk/src/libged/typein.c:
rt_revolve_internals sk is now skt. |
| 20:31.35 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r45910 10/brlcad/trunk/src/libgcv/bottess.c:
minor cleanup and reorg |
| 21:15.23 |
abhi2011 |
ok finally
got the function working, testing it on regions/combinations and
groups now before submitting a patch |
| 21:16.04 |
kunigami |
my problem
was that cmake searches first on default paths. Adding
NO_DEFAULT_PATH solved the problem |
| 21:21.54 |
CIA-62 |
BRL-CAD:
03kunigami * r45911
10/osl/trunk/osl/src/cmake/externalpackages.cmake: modified the way
osl searches for external packages. we want it to seach for local
libraries (that will be packed and compiled with osl) |
| 21:34.46 |
starseeker |
bhinesley:
does that lastest commit to src/other/CMakelists.txt fix your
compile issue? |
| 22:06.52 |
bhinesley |
applauds starseeker |
| 22:07.01 |
bhinesley |
works like a
charm |
| 22:08.29 |
bhinesley |
This will be
nice. No more grepping through build logs for my
warnings. |
| 22:49.43 |
brlcad |
starseeker:
vtk is the other project that came to mind that had implemented it
a long while back |
| 22:50.49 |
brlcad |
looking at
their docs, it looks like I was confusing their normal scene node
sorting |
| 22:51.52 |
brlcad |
which, for
what it's worth, is all we'd probably every want anytime soon
anyways since depth peeling is relatively-speaking very
expensive |
| 22:52.54 |
brlcad |
basically
cuts performance by about an order .. which may be fine and dandy
when your fps would have been 100+ .. but not when it's <1
fps |
| 22:53.08 |
brlcad |
http://www.vtk.org/Wiki/VTK/Depth_Peeling |
| 22:54.57 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 22:55.33 |
brlcad |
looks like
there was/is a related ogre gsoc project this year |
| 22:56.49 |
``Erik |
wishes ogre had a decent C interface for FFI
O.o |
| 23:00.31 |
abhi2011 |
I am getting
a strange error when I try to start Mged, after I shifted BRL-CAD
from the default installation location at /usr/brlcad |
| 23:00.49 |
abhi2011 |
its now in
/home/abhi/brlcad and is a debug build |
| 23:01.10 |
abhi2011 |
however when
mged starts up its not able to find helplib.tcl and so cant start
the gui |
| 23:02.44 |
abhi2011 |
I wonder how
it knew previously to look in
/usr/brlcad/share/brlcad/7.20.3/tclscripts |
| 23:03.25 |
abhi2011 |
there should
be a configuration for mged which I am missing i think |
| 23:09.50 |
bhinesley |
abhi2011:
with a debug build, you can run mged right from the build
directory, without installing |
| 23:12.25 |
bhinesley |
much faster
compile/dbug cycle that way anyways |
| 23:12.34 |
bhinesley |
*debug |
| 23:14.14 |
abhi2011 |
bhinesley: I
tried that too just now, so I am in brlcad-build, I cd into bin and
mged |
| 23:14.20 |
abhi2011 |
but the same
error persists |
| 23:14.47 |
bhinesley |
what options
are you building with |
| 23:15.18 |
abhi2011 |
cmake
../brlcad -DBRLCAD-ENABLE_STRICT=OFF
-DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 23:15.37 |
bhinesley |
actually, I'm
getting the same error |
| 23:16.01 |
abhi2011 |
is it after a
recent checkout ? |
| 23:16.38 |
abhi2011 |
the error is
from mged.c |
| 23:16.43 |
bhinesley |
yes, recent
checkout |
| 23:18.44 |
bhinesley |
yeah, it's
looking in the wrong directory. changing to
/home/bhinesley/brlcad-trunk/build/cmake/share/brlcad/7.20.3/tclscripts/geometree
and then running ../../../../../bin/mged works |
| 23:19.44 |
bhinesley |
since
../helplib.tcl is correct if the CWD is geomtree |
| 23:20.10 |
abhi2011 |
the cmake
changes wouldnt have a effect would it |
| 23:20.30 |
bhinesley |
I'm not sure,
but it does sound like a job for starseeker |
| 23:20.43 |
bhinesley |
puts hand above brow and looks to the
clouds |
| 23:20.53 |
abhi2011 |
:) |
| 23:22.41 |
bhinesley |
starseeker:
archer isn't launching from build dir either: no files matched glob
pattern "*.html" |
| 23:23.46 |
abhi2011 |
yes
../../../../../bin/mged works for me too |
| 23:58.13 |
abhi2011 |
brlcad: can
we expect the librt bb function rt_bound_dbfullpath(struct
rt_db_internal *ip, point_t *rpp_min, point_t *rpp_max) , to work
only on primitives |
| 23:59.10 |
abhi2011 |
or should I
expect the user to pass in regions or groups as well, in which I
can iterate through the region's or group's constituent
primitives |
| 00:00.21 |
abhi2011 |
though in my
original program, I was detecting a region by passing over the
region list in the rtip and checking for name matches |
| 00:03.43 |
abhi2011 |
so to detect
the fact that the user has passed a region in a struct
rt_db_internal , there should be a field in the struct
rt_db_internal that identifies the contents as a region |
| 00:04.47 |
abhi2011 |
or the user
would need to pass the model's directory so I can try name matches
to detect |
| 00:20.10 |
CIA-62 |
BRL-CAD:
03kunigami * r45912
10/osl/trunk/osl/src/cmake/externalpackages.cmake: force cmake to
ilmbase, openexr and llvm in the path os osl/trunk |
| 00:21.32 |
CIA-62 |
BRL-CAD:
03kunigami * r45913 10/osl/trunk/osl/src/testshade/CMakeLists.txt:
disable testshade_dso app because it uses an oiio version that is
not stable (its not used by brlcad) |
| 00:52.05 |
CIA-62 |
BRL-CAD:
03bhinesley * r45914 10/brlcad/trunk/src/libged/edit.c: |
| 00:52.05 |
CIA-62 |
BRL-CAD: With
the improved edit_*_get_arg_head()'s, individual subcommand init
functions |
| 00:52.05 |
CIA-62 |
BRL-CAD: are
no longer necessary; a generic edit_cmd_init() can handle it all.
Reduces |
| 00:52.05 |
CIA-62 |
BRL-CAD: the
number of functions needed for each subcommand to 4; nice. Also in
this |
| 00:52.05 |
CIA-62 |
BRL-CAD:
commit: noticed a variable for a return value being initialized to
a literal |
| 00:52.06 |
CIA-62 |
BRL-CAD:
value, rather than GED_OK. |
| 01:53.16 |
CIA-62 |
BRL-CAD:
03bhinesley * r45915 10/brlcad/trunk/src/libged/edit.c:
regrouping/sorting functions a bit |
| 02:05.14 |
starseeker |
bhinesley:
um. that's probably the html viewer not finding its
stuff |
| 02:05.25 |
starseeker |
looks at what mged is up too... |
| 02:06.11 |
bhinesley |
starseeker:
yeah, it's the one that I wrote :-P |
| 02:06.31 |
starseeker |
can you see
where it's failing? |
| 02:06.37 |
bhinesley |
yeah |
| 02:07.05 |
bhinesley |
man_browser.tcl:124 |
| 02:07.48 |
starseeker |
what's in
$path? |
| 02:07.56 |
bhinesley |
I'm
checking |
| 02:08.01 |
starseeker |
will see if he can duplicate the failure, one
sec... |
| 02:08.44 |
starseeker |
regardless,
we probably want to add -nocomplain to that glob - that's not a
reason for archer to fail to start |
| 02:08.55 |
bhinesley |
ah there it
is; its using the default for the class itself on :68 |
| 02:09.17 |
bhinesley |
starseeker:
true |
| 02:11.26 |
bhinesley |
seems the
other help browser needs it as well |
| 02:14.33 |
bhinesley |
hm, or
not. |
| 02:14.47 |
bhinesley |
I'm still
getting an error, even with -nocomplain |
| 02:17.00 |
CIA-62 |
BRL-CAD:
03starseeker * r45916 10/brlcad/trunk/src/tclscripts/mged/help.tcl:
I think we want to get helplib.tcl from the tclscripts
dir? |
| 02:18.15 |
starseeker |
bhinesley:
I'm guessing share/brlcad/7.20.3/html doesn't have anything in
it? |
| 02:18.59 |
bhinesley |
there are
folders and files |
| 02:19.05 |
starseeker |
O.o |
| 02:19.06 |
starseeker |
weird |
| 02:19.22 |
starseeker |
what does
puts $path print out? |
| 02:21.55 |
bhinesley |
well it's
looking for ./share/brlcad/7.20.3/html/mann/en/ |
| 02:22.09 |
starseeker |
which does
exist? |
| 02:22.20 |
bhinesley |
mann
doesn't |
| 02:22.34 |
starseeker |
urm. that's
the problem then |
| 02:32.04 |
CIA-62 |
BRL-CAD:
03starseeker * r45917
10/brlcad/trunk/src/tclscripts/man_browser.tcl: Don't refuse to
start archer just because the html docs aren't around. |
| 02:32.22 |
bhinesley |
was just about to do that ;) |
| 02:33.28 |
starseeker |
one remaining
wrinkle - when I nuked all of html and then re-ran make, the docs
rebuilt but toc.html wasn't present - it's copied during the
configure process, not the make process |
| 02:33.49 |
bhinesley |
meh... your
way looks better anyways |
| 02:33.56 |
starseeker |
probably
should have the archer help viewer check for that file as well as
one of the generated files |
| 02:35.51 |
starseeker |
wonders reworking the "copy during configure" cases into
build rules... wonder if that's practical/worth
it... |
| 02:40.52 |
CIA-62 |
BRL-CAD:
03starseeker * r45918
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: |
| 02:40.52 |
CIA-62 |
BRL-CAD:
Check for toc.html as well, since it comes from the configure
process and not |
| 02:40.52 |
CIA-62 |
BRL-CAD: the
make process in the build directory. May want to consider adding a
copy |
| 02:40.52 |
CIA-62 |
BRL-CAD:
build rule for things like this so make puts everything back where
it belongs, |
| 02:40.52 |
CIA-62 |
BRL-CAD: but
not a huge deal since re-running cmake takes care of
it. |
| 02:44.15 |
CIA-62 |
BRL-CAD:
03starseeker * r45919 10/brlcad/trunk/NEWS: A bug in Archer's help
browser code resulted in Archer failing to start if it was unable
to find the html files used for the help system - it now starts
even if those files are not present. |
| 02:44.28 |
starseeker |
ok, we should
be good to go again |
| 02:44.40 |
starseeker |
abhi2011:
does that fix it for you? |
| 02:45.15 |
starseeker |
bhinesley:
still begs the question of why your mann directory wasn't
present |
| 02:45.57 |
bhinesley |
I
reconfigured and I'm rebuilding... perhaps it is now. Do you
periodically reconfigure? I tend to just 'svn update' and
make |
| 02:47.15 |
bhinesley |
it should
trigger a reconfigure if it needs one, right? |
| 02:54.06 |
bhinesley |
starseeker:
no dice |
| 02:59.11 |
bhinesley |
ok iiii'm an
idiot. BRLCAD-BUILD_EXTRADOCS=OFF |
| 03:01.10 |
bhinesley |
that's what I
get for using ccmake |
| 03:15.46 |
starseeker |
bhinesley:
yeah, normally cmake is pretty good about reconfiguring/rebuilding
when it needs to |
| 03:16.08 |
starseeker |
earlier case
where brlcad had to recommend a clean rebuild was a bit
surprising |
| 03:16.56 |
starseeker |
heh - yeah,
if you tell it not to build the html docs it shouldn't
:-P |
| 03:17.10 |
bhinesley |
imaging that!
:) |
| 03:17.14 |
bhinesley |
*imagine |
| 03:17.31 |
starseeker |
did that fix
everything? |
| 03:17.37 |
bhinesley |
yes |
| 03:17.50 |
bhinesley |
thank
you |
| 03:18.18 |
starseeker |
np |
| 03:18.30 |
bhinesley |
looks like
there was no cmake issue? |
| 03:19.13 |
starseeker |
I didn't see
one - looked like just a few tcl file tweaks |
| 03:20.52 |
bhinesley |
oh I see it
now, help.tcl |
| 03:22.14 |
bhinesley |
well, at
least it exposed some problems |
| 03:22.52 |
starseeker |
sure - good
stuff :-) |
| 03:23.33 |
CIA-62 |
BRL-CAD:
03bhinesley * r45920
10/brlcad/trunk/src/tclscripts/man_browser.tcl: set -nocomplain on
glob, just in case; we don't want to fail to start due to some
missing files |
| 04:35.47 |
brlcad |
starseeker:
the earlier clean rebuild case wasn't cmake's fault -- just
coincidentally hitting a magic number failure after the magic
numbers were converter to uint32_t, but he was passing a bad
pointer (so the magic failure was the right thing to
do) |
| 04:37.54 |
brlcad |
abhi2011:
they can pass in any object, maybe even non-geometry |
| 04:38.13 |
brlcad |
note that the
name, rt_bound_dbfullpath(), is no longer right |
| 04:43.55 |
brlcad |
finishes organizing the logo submissions |
| 06:43.01 |
CIA-62 |
BRL-CAD:
03bhinesley * r45921 10/brlcad/trunk/src/libged/edit.c: |
| 06:43.01 |
CIA-62 |
BRL-CAD: Now
that there are functions to convert path+objects+offsets to
coords, |
| 06:43.01 |
CIA-62 |
BRL-CAD:
arguments that had to be split into multiple structs (due to
-x/-y/-z options) |
| 06:43.01 |
CIA-62 |
BRL-CAD: can
be consolidated. It would be slightly more efficient to do this as
the |
| 06:43.01 |
CIA-62 |
BRL-CAD:
arguments are parsed, but IMO not worth muddying up ged_edit()
over. |
| 06:58.41 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3069 10/wiki/User:Bhinesley: /* Log */ today |
| 07:22.18 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 09:14.25 |
CIA-62 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3070 10/wiki/User:Abhijit: /* Log */ |
| 09:42.04 |
abhi2011 |
brlcad: so I
would need to find the list of primitives in the region represented
by the rt_db_internal |
| 11:02.42 |
abhi2011 |
bhinesley:
did the mged and archer launching errors get resolved after the
latest checkout |
| 11:13.16 |
CIA-62 |
BRL-CAD:
03kunigami * r45922 10/osl/trunk/boost_1_46_1/: adding latest
compatible boost version with osl. doing it by parts |
| 11:14.45 |
CIA-62 |
BRL-CAD:
03kunigami * r45923 10/osl/trunk/boost_1_46_1/boost/: adding latest
compatible boost version with osl. part 2 |
| 11:38.34 |
abhi2011 |
ok,
db_walk_tree() allows a nice set of functions to be provided for
accepting and rejecting regions while building a boolean tree of
the regions, I will try and use it for adding the primitives of the
passed regions to the wdb |
| 11:52.11 |
kunigami |
hmm just saw
that boost has ~ 500MB. should upload it to svn anyway? |
| 11:53.03 |
kunigami |
I didn't have
to change anything on it from the original version. maybe add a
line on the script to download it directly? |
| 12:12.37 |
kunigami |
llvm is
pretty big too ~ 250MB |
| 12:36.21 |
abhi2011 |
kunigami:
doesnt boost source already ship with brlcad in
src/other/boost |
| 12:42.44 |
abhi2011 |
ok passing a
leaf function to db_walk_tree() wont work because its never called
even after a missing primitive is detected, was hoping to use the
function to add the primitive |
| 13:31.06 |
starseeker |
abhi2011:
mged and archer should launch now |
| 13:52.25 |
abhi2011 |
starseeker:
yes its fine now, thanks! |
| 14:01.18 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 14:05.50 |
brlcad |
kunigami:
that's a bit large to add, maybe see if you can identify the
portion used? boost has a tool to identify the headers/deps needed
so you don't have to download the kitchen sink |
| 14:06.05 |
brlcad |
llvm can be
expected as a system install |
| 14:19.41 |
CIA-62 |
BRL-CAD:
03n_reed * r45924 10/brlcad/trunk/src/libgcv/wfobj/ (5 files):
Using more readable names. Removed unused typedefs and some cryptic
size checks of questionable utility. |
| 14:36.21 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-184-068.wlan.tudelft.nl) |
| 15:12.02 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 16:27.57 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-184-068.wlan.tudelft.nl) |
| 17:20.55 |
*** join/#brlcad dtidrow_desk
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 17:58.58 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-184-068.wlan.tudelft.nl) |
| 18:05.35 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 18:36.53 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 18:47.58 |
kunigami1 |
brlcad:
ok |
| 18:51.24 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:12.44 |
abhi2011 |
brlcad:
currently the librt function for finding the bb works on shapes,
but if I pass regions then the db_walk_tree() detects that the
shapes of the regions are absent and causes the bounding box to not
be calculated |
| 19:13.44 |
abhi2011 |
so I am going
to use the code in db_walk_tree() to add primitive leaf nodes when
they are detected to be absent, which will involve significant
amounts of duplicate code |
| 19:14.56 |
abhi2011 |
so I was
wondering if there is an easier way to find and add the primitives
to the rt_db_internal representation of a region |
| 19:17.02 |
abhi2011 |
db_walk_tree() allows call backs when a
region is started and ended and for leaf nodes, but the leaf node
callback is never called if a leaf (primitive) is found to be
missing from the model tree |
| 19:40.03 |
CIA-62 |
BRL-CAD:
03starseeker * r45925 10/brlcad/trunk/src/other/incrTcl/itcl/ (4
files in 2 dirs): Take a stab at moving the itcl compilation logic
over to the cleaned up logic being used for tcl itself |
| 19:43.56 |
CIA-62 |
BRL-CAD:
03bob1961 * r45926
10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: |
| 19:43.56 |
CIA-62 |
BRL-CAD: Need
to destroy the ray object whenever the ged object is destroyed or
when |
| 19:43.56 |
CIA-62 |
BRL-CAD:
opening a different database. This fix was prompted by database
turds being left |
| 19:43.56 |
CIA-62 |
BRL-CAD: on
Windows platforms whenever the ray object was used. That is, the
ray object |
| 19:43.56 |
CIA-62 |
BRL-CAD: also
has the database copy (i.e. the turd) open and so the code that
removes the |
| 19:43.57 |
CIA-62 |
BRL-CAD:
database copy fails. |
| 19:49.30 |
brlcad |
abhi2011: I
don't think you can call db_walk_tree .. you don't know the name of
the rt_db_internal that you're trying to calculate a bounding box
for |
| 20:07.48 |
brlcad |
at least, you
can't call it for that dbi -- you could call it for all of the
comb's members to recursively get their bbs |
| 20:08.48 |
brlcad |
it might be
easier to just implement ft_prep for combs |
| 20:10.22 |
CIA-62 |
BRL-CAD:
03starseeker * r45927
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Do as MGED
does and default to Navy |
| 20:12.33 |
brlcad |
abhi2011:
aha, I think I have a solution, but it depends on what your code
looks like now |
| 20:12.59 |
brlcad |
since you DO
have it working for primitive, just work on cleaning up the code
and make your patch |
| 20:13.47 |
brlcad |
make it
gracefully fail on combs for now, then once your patch is
integrated, can work on bb of comb |
| 20:14.31 |
abhi2011 |
brlcad: hint
to the solution :P |
| 20:15.06 |
brlcad |
if you have
an rt_db_internal that is a comb, then you have a union tree
pointer |
| 20:15.17 |
abhi2011 |
yes |
| 20:15.22 |
brlcad |
if you have a
union tree pointer, then you can call the other/existing bbox
routine, rt_bound_tree() |
| 20:15.53 |
abhi2011 |
ah yes thats
the other function i used in my program before too |
| 20:17.05 |
brlcad |
you may still
need to call rt_gettree/rt_gettrees to load/evaluate the tree, but
that's easy |
| 20:17.05 |
abhi2011 |
rt_bound_tree(regp->reg_treetop,
reg_min, reg_max) |
| 20:17.31 |
brlcad |
that'd only
be for regions |
| 20:17.34 |
brlcad |
you have
combs |
| 20:17.40 |
brlcad |
combp->tree |
| 20:17.40 |
abhi2011 |
ah
yes |
| 20:17.52 |
brlcad |
see
rt_comb_internal in raytrace.h |
| 20:18.15 |
abhi2011 |
ok |
| 20:18.26 |
brlcad |
basically,
implementing much of what _ged_get_obj_bounds() does |
| 20:18.43 |
brlcad |
just instead
of using db_full_path objects you're using rt_db_internal
objects |
| 20:23.30 |
abhi2011 |
ok |
| 20:31.27 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 20:55.31 |
CIA-62 |
BRL-CAD:
03bob1961 * r45928
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: The
backgroundColor routine should be calling
::cadwidgets::Ged::get_rgb_color instead of getRgbColor for
consistency. |
| 20:57.16 |
CIA-62 |
BRL-CAD:
03bhinesley * r45929 10/brlcad/trunk/src/libged/edit.c: oops...
edit_cmd initialization routine introduced r45921 tried to set
pointer that was pointed to by uninitialized pointer to
NULL |
| 21:18.00 |
CIA-62 |
BRL-CAD:
03starseeker * r45930 10/brlcad/trunk/src/other/ (7 files in 4
dirs): |
| 21:18.00 |
CIA-62 |
BRL-CAD: Make
a stab at itk, probably the trickiest of these extensions. Need to
do some |
| 21:18.00 |
CIA-62 |
BRL-CAD: more
logic consolidation into tcl.cmake and the src/other
CMakeLists.txt |
| 21:18.00 |
CIA-62 |
BRL-CAD:
settings probably need some more study (there are a lot of possible
cases) but |
| 21:18.00 |
CIA-62 |
BRL-CAD:
getting there. Need to study STUBS usage in the standard Tcl/Tk
build more and |
| 21:18.01 |
CIA-62 |
BRL-CAD: see
if I need some conditionalization logic for those
flags... |
| 22:10.31 |
CIA-62 |
BRL-CAD:
03starseeker * r45931 10/brlcad/trunk/src/libbu/progname.c: We need
a static buffer here, otherwise our path disappears on
us. |
| 22:11.33 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 22:45.45 |
CIA-62 |
BRL-CAD:
03starseeker * r45932 10/brlcad/trunk/src/libbu/progname.c: avoid
overwriting the full argv0 path - bu_getprogname was storing its
basename in the save variable as argv0's full path
information. |
| 00:02.30 |
bhinesley |
starseeker:
cursor.c errors are back http://paste.pocoo.org/show/458445/ |
| 00:24.03 |
bhinesley |
starseeker:
scratch that, appears to be my fault |
| 00:28.44 |
abhi2011 |
ok I get an
error in analyze.c :
/home/abhi/socis/brlcad/src/libged/analyze.c:312:5: error: call to
function ‘rt_arb_centroid’ without a real prototype |
| 00:29.00 |
bhinesley |
starseeker:
double scratch that... not my fault |
| 00:29.44 |
abhi2011 |
some more :
/home/abhi/socis/brlcad/include/raytrace.h:3354:23: note:
‘rt_arb_centroid’ was declared here |
| 00:30.17 |
abhi2011 |
seems the
declaration is not being taken correctly |
| 00:31.02 |
abhi2011 |
bhinseley:
your error seems also related to implicit declarations |
| 00:31.57 |
bhinesley |
nods |
| 00:32.52 |
abhi2011 |
hmm even in
track.c its the same thing: error: call to function
‘track_mk_comb’ without a real prototype |
| 01:25.35 |
CIA-62 |
BRL-CAD:
03bhinesley * r45979 10/brlcad/trunk/src/libged/edit.c: |
| 01:25.37 |
CIA-62 |
BRL-CAD:
During certain batch translations, objects after the first target
object simply |
| 01:25.37 |
CIA-62 |
BRL-CAD:
moved to the same location as the first target object. This was due
to certain |
| 01:25.37 |
CIA-62 |
BRL-CAD:
translation vectors not being recalculated after executing the
first |
| 01:25.37 |
CIA-62 |
BRL-CAD:
translation. Since information about an argument is lost after the
first vector |
| 01:25.37 |
CIA-62 |
BRL-CAD: is
calculated, there needs to be a new vector (and therefore struct
edit_arg) |
| 01:25.38 |
CIA-62 |
BRL-CAD: for
each translation. |
| 01:53.12 |
starseeker |
bhinesley:
can you give me a make VERBOSE=1 with the cursor error? |
| 01:53.55 |
starseeker |
also, can you
tell me if brlcad_config.h has #define HAVE_TERMCAP_H 1
? |
| 01:57.13 |
bhinesley |
there is no
#define HAVE_TERMCAP_H |
| 01:57.19 |
starseeker |
growl |
| 01:57.19 |
bhinesley |
I'm running
make right now |
| 01:57.33 |
starseeker |
one sec...
let me see if I accidentally undid my fix |
| 01:57.48 |
bhinesley |
I saw it
there |
| 02:01.13 |
CIA-62 |
BRL-CAD:
03starseeker * r45980 10/brlcad/trunk/src/other/CMakeLists.txt:
Oops - variables changed, so update conditionals that use
them... |
| 02:01.18 |
starseeker |
bhinesley:
give that a shot |
| 02:01.39 |
starseeker |
sigh... the
hazards of radical rework |
| 02:04.05 |
bhinesley |
rebuilding |
| 02:07.10 |
dli |
starseeker,
does cmake scripts support system tcl/tk now? |
| 02:07.28 |
dli |
starseeker,
instead of brlcad local building |
| 02:09.02 |
starseeker |
dli: it
should - testing that now |
| 02:09.28 |
CIA-62 |
BRL-CAD:
03starseeker * r45981 10/brlcad/trunk/src/other/CMakeLists.txt: Be
slightly more aggressive with the find_library command for
itcl |
| 02:09.56 |
dli |
starseeker,
great, because gentoo people still don't accept my packages, due to
mandatory tcl/tk local building |
| 02:10.09 |
starseeker |
winces - yeah, not surprised |
| 02:13.54 |
starseeker |
dli: still
working on local itcl/itk - one second |
| 02:21.23 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 02:34.08 |
CIA-62 |
BRL-CAD:
03starseeker * r45982 10/brlcad/trunk/src/ (3 files in 3
dirs): |
| 02:34.09 |
CIA-62 |
BRL-CAD: Ah,
right. Original CMake logic written assuming package require based
Itcl/Itk |
| 02:34.09 |
CIA-62 |
BRL-CAD:
usage - when C libs were again necessary, just hacked in quickly.
Can't get away |
| 02:34.09 |
CIA-62 |
BRL-CAD: with
that anymore, so use variables where appropriate and look for itk C
library |
| 02:34.15 |
starseeker |
dli: give
that a shot |
| 02:36.02 |
dli |
starseeker,
revision 45982 |
| 02:36.16 |
dli |
starseeker,
testing now |
| 02:36.23 |
starseeker |
that works
for me here with system tcl/tk and itcl/itk - I don't have a system
iwidgets, tkhtml, tkpng or tktable |
| 02:36.53 |
starseeker |
the raster
toolkit, opennurbs and STEP Class Libraries will stay on because
we're currently maintaining our own versions of those |
| 02:38.02 |
starseeker |
dli: also,
remember the cmake options have changed a lot - still probably in
flux, actually |
| 02:40.35 |
dli |
starseeker,
this is reported configure options: |
| 02:40.38 |
dli |
starseeker,
http://pastebin.com/g7dD2VMP |
| 02:41.21 |
starseeker |
hmm -
surprized the optimized release summary option isn't
printing |
| 02:41.36 |
starseeker |
is that a
clean configure from a fully updated trunk? |
| 02:41.53 |
starseeker |
what
configure options are you passing in? |
| 02:42.37 |
bhinesley |
starseeker:
builds fine, thanks |
| 02:43.40 |
dli |
starseeker,
options passed to cmake: http://pastebin.com/h3ELaNfD |
| 02:44.16 |
starseeker |
dli: ah, let
me translate those |
| 02:44.58 |
starseeker |
dli: will
gentoo accept a BRL-CAD build of tkhtml? |
| 02:46.08 |
dli |
starseeker,
should be fine, since there's no tkhtml package in gentoo
yet |
| 02:46.50 |
starseeker |
they don't
want static libs? |
| 02:48.36 |
dli |
starseeker, I
think it's ok, but they want to be sure about how libs are
used/linked, so, package manager can avoid broken libraries better,
package deps better |
| 02:50.34 |
starseeker |
dli: um -
surprised you turned off the example geometry - is that a
policy? |
| 02:51.04 |
starseeker |
with
EXTRADOCS off, the html documentation won't be
available |
| 02:51.56 |
dli |
starseeker,
it's controlled by USE flag: examples |
| 02:52.43 |
dli |
starseeker,
http://pastebin.com/7ndb9WDQ |
| 02:53.16 |
dli |
starseeker,
so, USE="doc" will enable extradocs, extradocs_pdf,
extradocs_man |
| 02:54.20 |
dli |
starseeker,
aqua, does brlcad support aqua? |
| 02:54.35 |
starseeker |
no |
| 02:55.41 |
dli |
starseeker,
then, it's a mistake |
| 02:58.02 |
starseeker |
what are you
specifically setting up with the Gentoo build type? |
| 02:58.22 |
starseeker |
we generally
have Debug and Release - I haven't tried feeding in something
else |
| 02:59.30 |
dli |
starseeker,
only debug and release, if USE="debug" it's Debug, otherwise
Release |
| 02:59.49 |
starseeker |
you're
passing in CMAKE_BUILD_TYPE=Gentoo though |
| 03:00.25 |
dli |
starseeker,
it must be from the gentoo default :( need to disable that
then |
| 03:00.42 |
starseeker |
dli: well, it
might work - just completely untested |
| 03:01.21 |
starseeker |
dli: this is
closer, given our current state: http://pastebin.mozilla.org/1300959 |
| 03:01.31 |
starseeker |
you can see
what happens with that |
| 03:02.07 |
starseeker |
I will test
with a "nonsense" build type setting and see what happens
once... |
| 03:03.29 |
starseeker |
ah, that's
why the optimize and debug flags were not set |
| 03:04.15 |
dli |
starseeker, I
can try to set default build type to Release, then, if USE=Debug,
set it to Debug |
| 03:04.44 |
starseeker |
dli: I
wouldn't worry too much about the pdf doc building just yet - if
you still want to enable it, the options are BRLCAD_EXTRADOCS_PDF
and BRLCAD_EXTRADOCS_PDF_MAN |
| 03:04.54 |
starseeker |
remember
Apache FOP is needed for that |
| 03:05.24 |
starseeker |
dli: well, a
non-standard build type should still do SOMETHING sane |
| 03:05.43 |
starseeker |
I'm not sure
how successful we'd be fighting with the gentoo guys about
that |
| 03:06.09 |
dli |
starseeker,
BRLCAD_EXTRADOCS_PDF and BRLCAD_EXTRADOCS_PDF_MAN were already in
the package script |
| 03:06.40 |
starseeker |
ah,
k |
| 03:07.10 |
dli |
starseeker,
the complete gentoo package (ebuild) for the svn live version:
http://paste.pocoo.org/show/458500/ |
| 03:10.34 |
CIA-62 |
BRL-CAD:
03starseeker * r45983 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake:
Er, oops - fix default fallback settings for auto_option
macro |
| 03:10.55 |
starseeker |
dli: that
should help |
| 03:11.11 |
starseeker |
or at least,
the settings are saner - trying the build now |
| 03:11.58 |
starseeker |
yeah, this
should fall back to the /usr/brlcad path, no optimization and no
debug flags by default |
| 03:13.49 |
starseeker |
note that
tcl/tk need to be 8.5 - 8.4 will no longer be enough, IIRC (ttk
widgets, among other issues) |
| 03:14.35 |
starseeker |
tnt and jama
are headers, and if I'm remembering right we need our local
copies |
| 03:14.46 |
starseeker |
shouldn't be
a build issue at all |
| 03:15.09 |
starseeker |
(as far as
conflicting with a system install anyway, unless we're copying
those into our install tree - I'd need to check.) |
| 03:18.39 |
dli |
starseeker,
building, let's see how it works out |
| 04:02.55 |
starseeker |
dli: any
luck? |
| 18:08.28 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 18:08.28 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 18:10.43 |
CIA-62 |
BRL-CAD:
03starseeker * r45990
10/brlcad/trunk/src/archer/archer: |
| 18:10.43 |
CIA-62 |
BRL-CAD: Warn
if we appear to be running archer from a non-install directory with
an |
| 18:10.43 |
CIA-62 |
BRL-CAD:
install already in place - this is the situation where .tcl files
will get |
| 18:10.43 |
CIA-62 |
BRL-CAD:
pulled from /usr/brlcad/* instead of local copies, which if
unnoticed by the |
| 18:10.43 |
CIA-62 |
BRL-CAD:
developer makes for some very frustrating troubleshooting
(particularly for |
| 18:10.44 |
CIA-62 |
BRL-CAD:
those not familiar with bu_brlcad_root's behavior). We have enough
information |
| 18:10.45 |
CIA-62 |
BRL-CAD: to
spot this situation at runtime, so do it. |
| 18:12.54 |
bhinesley |
starseeker:
alright. Their verbage was a bit strong/misleading. |
| 18:18.49 |
starseeker |
bhinesley:
they have to write that for borderline cases where a student might
be trying to sprint right at the end and shoves so much code at a
mentor right before the eval that they *can't* properly evaluate
it |
| 18:19.43 |
bhinesley |
ah |
| 19:06.42 |
kunigami1 |
just
wondering: is it feasible to pack boost compressed in the osl code?
the 7ziped version has ~40MB |
| 19:07.14 |
starseeker |
kunigami1:
um. you couldn't extract the parts you need? |
| 19:07.47 |
kunigami1 |
I still
can't. I tried with 1.46.1. I'm currently trying with
1.47.0 |
| 19:08.24 |
kunigami1 |
I asked in
boost dev list, but the guy suggested to me exactly what I
did |
| 19:09.32 |
CIA-62 |
BRL-CAD:
03tbrowder2 * r45991 10/brlcad/trunk/sh/conversion.sh: add a SAVE
option to keep converted tgm from being deleted |
| 19:12.38 |
CIA-62 |
BRL-CAD:
03tbrowder2 * r45992 10/brlcad/trunk/NEWS: documented change for
users |
| 20:22.43 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 20:30.48 |
*** join/#brlcad merzo
(~merzo@137-79-132-95.pool.ukrtel.net) |
| 21:05.07 |
kunigami1 |
good, seems
that was a bug with boost 1.46. let me see if oiio and osl compile
with this smaller version |
| 21:15.56 |
plaes |
gotta love
git-send-email \o/ |
| 21:25.58 |
*** join/#brlcad KimK_ibmlaptop
(~kkirwan@209.248.147.2.nw.nuvox.net) |
| 22:08.59 |
CIA-62 |
BRL-CAD:
03starseeker * r45993
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Don't try adding
the debug flag manually if it's Xcode - let Xcode itself handle
things. Trying it manually caused an options conflict. |
| 22:55.28 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 23:03.09 |
CIA-62 |
BRL-CAD:
03starseeker * r45994
10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl:
rt isn't always in the path. Use the bu_brlcad_root,
rtwizard. |
| 23:07.40 |
CIA-62 |
BRL-CAD:
03starseeker * r45995 10/brlcad/trunk/NEWS: |
| 23:07.40 |
CIA-62 |
BRL-CAD:
rtwizard was relying on rt being present in the system path in
order to run it |
| 23:07.40 |
CIA-62 |
BRL-CAD: and
generate a picture - instead, have it find and use the rt command
specific |
| 23:07.40 |
CIA-62 |
BRL-CAD: to
its own BRL-CAD release without needing rt to be in the
path. |
| 23:15.24 |
*** join/#brlcad merzo
(~merzo@250-21-132-95.pool.ukrtel.net) |
| 23:17.12 |
bhinesley |
how do I get
the natural origins of primitives? |
| 23:17.20 |
bhinesley |
cries uncle |
| 23:22.40 |
CIA-62 |
BRL-CAD:
03starseeker * r45996
10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl: |
| 23:22.41 |
CIA-62 |
BRL-CAD: Wow.
Apparently the only reason rtwizard wouldn't output png ouput if
you |
| 23:22.41 |
CIA-62 |
BRL-CAD:
specified a .png extension was due to its regarding the filename as
a |
| 23:22.41 |
CIA-62 |
BRL-CAD:
framebuffer (-F) target instead of an output file (-o). Literally a
one |
| 23:22.41 |
CIA-62 |
BRL-CAD:
character fix, and rtwizard will now output png files if given a
.png filename. |
| 23:22.57 |
starseeker |
bhinesley:
"natural origins?" |
| 23:23.14 |
bhinesley |
yes, that's
what brlcad called it |
| 23:23.37 |
bhinesley |
as opposed to
the bounding box center... he said that there is a natural starting
point of primitives |
| 23:23.39 |
starseeker |
uh. is that
the point that (say) the sed command grabs from a
primitive? |
| 23:23.42 |
starseeker |
oh |
| 23:24.22 |
bhinesley |
I'm not sure,
I'll have to look at sed |
| 23:24.35 |
starseeker |
would suggest checking what sed does |
| 23:24.46 |
starseeker |
that'd be my
fist step anyway |
| 23:24.50 |
starseeker |
first step
even |
| 23:25.08 |
starseeker |
(probably be
shaking a fist at it too, come to think of it...) |
| 23:25.23 |
bhinesley |
heh |
| 23:26.10 |
starseeker |
look for
f_sed in chgview.c in mged |
| 23:26.20 |
bhinesley |
ok |
| 23:27.23 |
starseeker |
hmm... that
doesn't help much... |
| 23:28.45 |
bhinesley |
I guess
that's the problem, starseeker; I don't really know what I'm
looking for |
| 23:29.06 |
starseeker |
bhinesley:
that's a little outside my expertice also - let me dig a
minute |
| 23:29.20 |
bhinesley |
alright,
thank you |
| 23:33.29 |
starseeker |
you might try
looking at curr_e_axes_pos being set in edsol.c |
| 23:35.14 |
starseeker |
ah
hah! |
| 23:35.23 |
starseeker |
get_solid_keypoint, edsol.c
9222 |
| 23:36.38 |
bhinesley |
looking |
| 23:37.09 |
bhinesley |
looks
promising; I was thinking that it would have to be different for
each primitive type |
| 23:37.24 |
bhinesley |
retrieving
it, I mean |
| 23:38.19 |
starseeker |
winces - OK, if that's actually it, the options are 1) make a
libged version of that 2) refactor it into per-primitive calls via
the functable (a better way but more time-consuming) 3) ask brlcad
what to do (the best way but probably the most work
:-P) |
| 23:38.44 |
bhinesley |
hahaha
@3 |
| 23:39.30 |
starseeker |
I'd say start
with 1) for now (lord knows we've got lots of logic like that in
there that needs cleanup) and see if you can get it to actually
work |
| 23:39.57 |
starseeker |
if that's
what we need, then it'll be already isolated from mged and easier
to use for the "right thing" refactoring step |
| 23:42.21 |
bhinesley |
ok, it
doesn't sound so bad |
| 23:50.57 |
brlcad |
starseeker:
regarding r45996, does rtwizard's preview option still
work? |
| 23:51.51 |
starseeker |
I believe
so... |
| 23:52.33 |
starseeker |
tests |
| 23:52.50 |
starseeker |
oh, wait -
point |
| 23:52.54 |
starseeker |
it might
not... |
| 23:54.12 |
starseeker |
crud, yeah no
dice |
| 00:01.57 |
brlcad |
basically
it's a double-use variable so you'll have to conditionalize
somewhere, even if you split it into two variables |
| 00:02.37 |
brlcad |
unless you
change the logic to always go to a -o output file then pix-fb that
file |
| 00:02.54 |
brlcad |
but then
you'll need rm logic if it's a preview too |
| 00:03.12 |
brlcad |
nothing at
all tricky, but not a one-character fix ;) |
| 00:03.33 |
brlcad |
OSL solids up
from siggraph: http://s2011compilers.org |
| 00:04.13 |
brlcad |
unfortunately, he pulled the cool images
from alice in wonderland and the amazing spider man that showed OSL
in production use |
| 00:07.55 |
brlcad |
bhinesley:
heh, either of those options sound fine -- you only need to push
the logic up into libged, but if you want to push it further (up
into librt or into librt's individual primitives), even
better |
| 00:08.55 |
brlcad |
anytime there
is a switch or if table that itemizes primitives, that is a clear
indicator of functionality that need to be refactored up into
librt |
| 00:09.25 |
brlcad |
so that is
the long-term goal, libged gets that code one step closer so it's
still an improvement if that's as far as you take it |
| 00:11.09 |
bhinesley |
brlcad:
alright. If moving it to libged is supposedly easier, then I should
probably do that for now. I don't want to get sidetracked from
edit/translate just yet. |
| 00:11.16 |
brlcad |
plaes: thanks
for the patches, will review |
| 00:14.37 |
brlcad |
kunigami: if
it works compressed, just commit it uncompressed then .. the size
isn't critical, it just doesn't seem "right" if it's huge
huge |
| 00:16.29 |
brlcad |
bhinesley: as
for the "required to stop", you have it spot on -- that's just for
the official code tarball that has to be uploaded to google, you
dont' have to stop coding in the least |
| 00:17.34 |
brlcad |
technically,
you're being paid to "test google upload infrastructure" .. that's
how they legally pay students for work that they don't directly
evaluate |
| 00:18.04 |
bhinesley |
brlcad:
interesting |
| 00:18.45 |
brlcad |
yeah, it's
pretty funny |
| 00:19.49 |
brlcad |
bhinesley: oh
and libged is going to be easier because it's almost as simple as
move block of code from mged to libged .. whereas to put it into
librt properly would require adding a function to each individual
primitive |
| 00:20.07 |
brlcad |
maybe two
hours difference, but more work nonetheless |
| 00:20.18 |
bhinesley |
ah, I see.
the "OOP interface" |
| 00:20.41 |
brlcad |
nods |
| 00:20.52 |
CIA-62 |
BRL-CAD:
03starseeker * r45997 10/brlcad/trunk/src/tclscripts/rtwizard/lib/
(FbPage.itk PictureTypeBase.itcl): Ah, not quite so simple - the
same command feeds both the preview and the file-out operations, so
we need to accomidate both. |
| 00:21.30 |
starseeker |
brlcad: there
we go - both preview and png output |
| 00:22.02 |
brlcad |
you left a
debug puts ;) |
| 00:23.20 |
starseeker |
picky
picky... :-P |
| 00:23.40 |
CIA-62 |
BRL-CAD:
03starseeker * r45998
10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl:
remove stray debug output |
| 00:26.47 |
starseeker |
brlcad: does
rtwizard work on Windows? |
| 00:27.24 |
starseeker |
probably shouldn't ask that... |
| 00:28.43 |
starseeker |
brlcad:
something up with those BU_ASSERT changes you made, by the
way... |
| 00:31.27 |
CIA-62 |
BRL-CAD:
03starseeker * r45999 10/brlcad/trunk/NEWS: |
| 00:31.27 |
CIA-62 |
BRL-CAD:
rtwizard can output png files now, handing it the same way rt
itself does (use |
| 00:31.27 |
CIA-62 |
BRL-CAD: .png
as the file name suffix). Was primarly a matter of distinguishing
between |
| 00:31.27 |
CIA-62 |
BRL-CAD:
framebuffer and file targets - previously the 'file output' was
just a |
| 00:31.27 |
CIA-62 |
BRL-CAD:
framebuffer dump to a file. |
| 00:32.02 |
CIA-62 |
BRL-CAD:
03bhinesley * r46000 10/brlcad/trunk/src/libged/edit.c: Changing
memory allocations for structs to use BU_GETSTRUCT.
Simplified/reduced some things. Added some error checking. Nothing
major. |
| 00:32.17 |
CIA-62 |
BRL-CAD:
03starseeker * r46001 10/brlcad/trunk/TODO: png in rtwizard,
check. |
| 00:32.46 |
brlcad |
starseeker:
understood -- investigating, they should have been good to go as I
was pretty careful but "-1" is a special case |
| 00:33.01 |
starseeker |
brlcad:
thanks |
| 00:33.03 |
brlcad |
that might be
what is causing the current problem even, just in a different
way |
| 00:33.33 |
brlcad |
it writes out
a -1 to mean "this is an identity matrix, don't write it
out" |
| 00:34.35 |
CIA-62 |
BRL-CAD:
03bhinesley * r46002 10/brlcad/trunk/src/libged/ (CMakeLists.txt
Makefile.am get_solid_kp.c): Migrating
edit/edsol.c:get_solid_keypoint() to libged. It compiles cleanly,
but is otherwise untested. |
| 00:36.56 |
starseeker |
brlcad: how
were you figuring to do the temp color thing for
rtwizard? |
| 00:39.06 |
brlcad |
plaes: would
like to talk about your libfft patches when you got a sec,
questions 1) what's the impact (performance, correctness) using
fftw3.. our used to be much faster; 2) configure.ac can't call
PKG_* macros and that build system is deprecated anyways, cmake
build is where the action is at (which I see you had a separate
patch for); 3) again performance check, the fixed size convolutions
are highly optimizable .. what's the impact? |
| 00:39.13 |
brlcad |
starseeker:
options to rt |
| 00:39.42 |
brlcad |
probably set
variables |
| 00:39.50 |
starseeker |
erm. don't
know that trick |
| 00:40.43 |
brlcad |
basically,
get it to work with rt first, rtwizard just calls rt |
| 00:40.59 |
starseeker |
nods |
| 00:41.06 |
brlcad |
rtwizard
needs some gui interface to set/unset the colors |
| 00:41.15 |
brlcad |
but then
those just turn into command line opts |
| 00:41.32 |
starseeker |
are the rt
options already in place to override colors? |
| 00:41.35 |
brlcad |
do you know
how rtedge options work? same basic idea |
| 00:42.02 |
brlcad |
no, they're
not -- that's pretty much 90% of the task |
| 00:42.15 |
brlcad |
the rtwizard
gui part is nothing |
| 00:42.44 |
starseeker |
right |
| 00:44.08 |
brlcad |
bhinesley:
oof! .. so "moving code" probably wasn't the best term to
use |
| 00:44.18 |
brlcad |
those globals
gotta go |
| 00:44.59 |
brlcad |
the statics
will need to be non-static since libged is supposed to be
stateless |
| 00:45.09 |
brlcad |
that may or
may not break it |
| 00:45.38 |
brlcad |
params should
be const that can be const |
| 00:46.15 |
brlcad |
mged gets
away with a lot of shit that isn't tolerated for libged (as that is
the entire point of the library, clean refactoring) |
| 00:47.10 |
brlcad |
finally,
function should be added to ged_private.h (and renamed) so it
doesn't accidentally become public libged api |
| 00:48.49 |
bhinesley |
brlcad:
alright |
| 00:48.56 |
bhinesley |
still, I'll
see if I can get it working first |
| 00:53.30 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 00:53.35 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 01:19.46 |
CIA-62 |
BRL-CAD:
03starseeker * r46003 10/brlcad/trunk/ (3 files in 3 dirs): Need to
make the FindGL logic match up with the FindX11 logic to make sure
the two are in sync. Needs more testing. |
| 01:27.45 |
CIA-62 |
BRL-CAD:
03starseeker * r46004 10/brlcad/trunk/misc/CMake/
(BRLCAD_Util.cmake ThirdParty_TCL.cmake): more case correction
logic is needed - try this. |
| 02:04.13 |
CIA-62 |
BRL-CAD:
03bhinesley * r46005 10/brlcad/trunk/src/libged/ (ged_private.h
get_solid_kp.c): Make compliant with libged standards (rm
global/static vars). Declare in ged_private. Temporarily disable
support for ARS/BSPLINE, which will require a little more
work. |
| 02:05.09 |
CIA-62 |
BRL-CAD:
03bhinesley * r46006 10/brlcad/trunk/src/libged/get_solid_kp.c:
remove (temporary) cast to void |
| 02:11.47 |
CIA-62 |
BRL-CAD:
03bhinesley * r46007 10/brlcad/trunk/src/libged/edit.c: Enabled
support for using the natural origins of primitives as a reference
point. |
| 02:13.18 |
bhinesley |
starseeker:
Thank you, again, for helping me with that. I doubt that I would
have been able to figure that out any time soon. |
| 02:29.07 |
starseeker |
bhinesley: np
- that's what mentors are for :-) |
| 02:29.32 |
starseeker |
bhinesley:
you've got the fun part - turn it into a viable libged
function |
| 02:33.20 |
bhinesley |
starseeker:
well it seems to work just fine. Just need to make ARS/BSPLINE
work; they used a couple globals that were set elsewhere. Making
mged call the libged version is another matter. |
| 02:35.22 |
brlcad |
bhinesley:
looks much better, nice work :) |
| 02:36.18 |
bhinesley |
brlcad:
great, thanks! |
| 02:36.51 |
CIA-62 |
BRL-CAD:
03bhinesley * r46008 10/brlcad/trunk/src/libged/edit.c: Yikes;
dynamically allocate a character buffer since _ged_get_solid_kp()
writes to it. |
| 02:37.24 |
brlcad |
where's that
string freed? :) |
| 02:37.38 |
bhinesley |
... in the
code I'm about to write because you said that |
| 02:37.45 |
brlcad |
heh |
| 02:38.23 |
brlcad |
also very
minor point, but recommend bu_calloc unless you're in some
performance-critical loop |
| 02:38.40 |
bhinesley |
okay; why is
that? |
| 02:38.49 |
*** part/#brlcad milamber
(~devlin@d118-75-70-176.try.wideopenwest.com) |
| 02:38.51 |
brlcad |
zero-initialized memory |
| 02:39.02 |
bhinesley |
right, but
why? |
| 02:39.52 |
brlcad |
in general,
zero-initialized memory is much faster at exposing
initialization/deinitialization bugs in code |
| 02:40.10 |
bhinesley |
ah |
| 02:40.26 |
brlcad |
some
compilers will even make malloc() zero-initialize by default unless
you turn on -O# optimization level |
| 02:40.36 |
brlcad |
for that same
reason |
| 02:41.40 |
brlcad |
but the
standard doesn't require it, so it's better practice to do it
intentionally yourself, then you also have the added benefit that
you can test for nullity or 0-values |
| 02:41.53 |
CIA-62 |
BRL-CAD:
03bhinesley * r46009 10/brlcad/trunk/src/libged/edit.c: Forgot to
free string. |
| 02:42.03 |
brlcad |
r46008 leaks
memory, btw ;) |
| 02:42.22 |
brlcad |
and r46009
should make it crash ;) |
| 02:48.26 |
starseeker |
make a note of these slides -
http://www.slideshare.net/ckleclerc/2011-nasa-open-source-summit-david-wheeler |
| 02:49.02 |
CIA-62 |
BRL-CAD:
03bhinesley * r46010 10/brlcad/trunk/src/libged/edit.c: Use
*calloc* and *sizeof* like the grown-ups. |
| 02:49.50 |
bhinesley |
alright,
wth |
| 03:00.11 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 03:00.21 |
starseeker |
bhinesley:
problem? |
| 03:01.11 |
bhinesley |
NO. heh. Dumb
mistake that I am not able to fix instantly for some
reason. |
| 03:02.01 |
brlcad |
bhinesley:
need a hint? |
| 03:02.25 |
bhinesley |
nah, then I
will feel even stupider |
| 03:02.52 |
starseeker |
bhinesley:
you might as well - it saves time, and I need those hints all the
time :-P |
| 03:03.02 |
bhinesley |
sighs |
| 03:03.21 |
bhinesley |
Alright.
brlcad, is it because I need to use bu_strlcpy? |
| 03:03.25 |
brlcad |
how would I
know that r42009 will crash? |
| 03:04.35 |
brlcad |
that should
take you down the rabbit hole |
| 03:05.42 |
brlcad |
damn server
shut down during my latest nurbs performance testing after about
80% completion .. arf |
| 03:05.53 |
starseeker |
winces |
| 03:16.33 |
starseeker |
bhinesley:
try stepping through with a debugger (I'd start with the char *str;
line) |
| 03:24.06 |
CIA-62 |
BRL-CAD:
03starseeker * r46011 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake:
Er, oops - normalize, THEN check. |
| 03:24.58 |
brlcad |
nifty, some
oklahoma country music show wants to use our logo contest
rules |
| 03:25.21 |
starseeker |
hah,
awesome |
| 03:28.53 |
starseeker |
bhinesley:
focus on why brlcad said 46008 leaks memory |
| 03:31.05 |
starseeker |
brlcad:
should we revert that BU_ASSERT size_t change for now? it crashes
on my gentoo box too |
| 03:33.06 |
starseeker |
dli: hah -
saw the brlcad-9999 ebuild appear in one of the overlay updates
:-) |
| 03:34.35 |
dli |
starseeker,
still, 7.20.2 cmake version doesn't work |
| 03:34.46 |
dli |
starseeker, I
mean to build with system tcl/tk |
| 03:35.05 |
starseeker |
dli: even
with the patches to cmake? |
| 03:35.22 |
starseeker |
well,
presumably 7.20.4 will |
| 03:36.00 |
dli |
starseeker, I
can remove the 7.20.2 cmake ebuild for the time being |
| 03:36.33 |
brlcad |
starseeker:
working on the BU_ASSERT now, it should be something
obvious |
| 03:36.42 |
brlcad |
s/now/for a
lil bit now/ |
| 03:37.05 |
starseeker |
dli: probably
simpler |
| 03:37.45 |
starseeker |
a cmake patch
would be rather... large at this point :-) |
| 03:38.06 |
louipc |
:o |
| 03:38.30 |
louipc |
who wins the
contest by the way? |
| 03:39.18 |
louipc |
is looking forward to seeing the logos. |
| 03:42.46 |
starseeker |
sweet -
bzflag ebuild now updated to 2.4 :-) |
| 03:42.54 |
dli |
starseeker, I
will ask someone to review the package and update the gentoo main
tree |
| 03:47.22 |
CIA-62 |
BRL-CAD:
03bhinesley * r46012 10/brlcad/trunk/src/libged/edit.c: Ptr to
string, not pointer to char. |
| 03:48.09 |
CIA-62 |
BRL-CAD:
03bhinesley * r46013 10/brlcad/trunk/src/libged/get_solid_kp.c:
Enable BSPLINE support. |
| 04:01.48 |
brlcad |
bhinesley:
that's nfg |
| 04:03.04 |
brlcad |
str only
needs to be a char* |
| 04:06.07 |
brlcad |
r46012
technically avoids the crash on free, but doesn't fix the problem
-- you were closer with bu_strlcpy() thinking |
| 05:02.40 |
CIA-62 |
BRL-CAD:
03bhinesley * r46014 10/brlcad/trunk/src/libged/edit.c: Don't
dynamically allocate string. |
| 05:08.22 |
starseeker |
bhinesley:
doesn't get_solid_keypoint still need to write to str? |
| 05:09.55 |
bhinesley |
apparently I
don't know what the fuck I'm doing. |
| 05:10.33 |
starseeker |
bhinesley:
stay calm :-) |
| 05:10.54 |
starseeker |
we've all
made our share of this kind of mistake |
| 05:11.50 |
starseeker |
don't give up
- think about what brlcad said about 46008 and 46009 |
| 05:15.21 |
starseeker |
bhinesley:
sometimes in situations like this it's helpful to make your own
isolated C file and just try to get it to do the one thing you're
working on |
| 05:22.08 |
plaes |
brlcad: awake
now |
| 05:22.17 |
plaes |
lives in UTC+2 |
| 05:24.48 |
CIA-62 |
BRL-CAD:
03bhinesley * r46015 10/brlcad/trunk/src/libged/edit.c: keep a copy
of original ptr to free |
| 05:39.48 |
plaes |
brlcad: fftw
- 1) tried benchmarking it, didn't notice much difference (maybe I
need some bigger models to test with) |
| 05:41.22 |
plaes |
fftw - 2) Why
cannot it call the PKG_* macros? autoconf works for me.. for cmake
the paths to detect fftw and add it to libraries is
missing |
| 05:45.04 |
plaes |
and 3) fftw
chooses different algorithms baased on the size, we had currently
only "faster variant for length 256 |
| 05:46.10 |
plaes |
IIRC, it uses
faster algorithms for all powerof two sizes |
| 06:41.03 |
CIA-62 |
BRL-CAD:
03bhinesley * r46016 10/brlcad/trunk/src/libged/get_solid_kp.c:
Disable BSPLINE again... it's not working |
| 06:46.55 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3078 10/wiki/User:Bhinesley: /* Log */ today |
| 06:51.58 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 07:22.42 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 09:05.16 |
*** join/#brlcad milamber
(~devlin@d118-75-70-176.try.wideopenwest.com) |
| 09:18.31 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 12:33.50 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 13:07.38 |
kunigami |
brlcad: the
first time I tried uploading the full boost, the commit was
interrupted. (I'm almost sure that was not my connection that
failed) does sourceforge has some kind of cap? |
| 13:08.58 |
plaes |
you want to
bundle whole boost library? |
| 13:09.41 |
kunigami |
that was not
the first idea, but I'm having troubles in selecting only the
required subset |
| 13:09.57 |
plaes |
:S |
| 13:11.58 |
starseeker |
bhinesley:
closer, but you're still passing in str to get_solid_keypoint - you
want to pass in the buffer (that's the whole point of mallocing it
in the first place) |
| 13:12.15 |
kunigami |
I had
advances and managed to copy but now I'm stuck with a build error.
probably the build scripts were not copied properly. I'll report to
boost dev's list |
| 13:13.18 |
starseeker |
bhinesley:
look at other parts of the code that are working with buffers and
string assignment |
| 13:13.24 |
CIA-62 |
BRL-CAD:
03kunigami * r46017 10/osl/trunk/boost_1_46_1/: deleting initial
boost commits |
| 13:13.31 |
plaes |
most of the
times bundled libraries cause more damage than they fix.. (security
issues, etc..) |
| 13:14.01 |
starseeker |
plaes: we
will use system libs by default in our configuration if they are
available |
| 13:14.28 |
starseeker |
but if not,
we have to be able to fall back on our local versions rather than
fail to build |
| 13:14.59 |
plaes |
well, boost
is quite popular library |
| 13:15.09 |
plaes |
most of the
distros have it |
| 13:16.05 |
starseeker |
windows is
often where we end up needing local copies of things |
| 13:16.38 |
plaes |
yeah, package
management in windows sucks :( |
| 13:17.04 |
starseeker |
there are
other issues too (Tcl/Tk on OSX is not built for X11, which we
currently need) |
| 13:18.30 |
starseeker |
the linux
distros always hate bundling (and generally I agree with them) but
in the case of something like BRL-CAD we can't always wait for the
system to catch up |
| 13:19.04 |
starseeker |
(for example,
a lot of linux distros will still put tcl/tk 8.4 on by default,
which is too old for us now) |
| 13:19.48 |
kunigami |
interesting |
| 13:23.45 |
starseeker |
or there's
the package dli is working on for gentoo - they don't have a tkhtml
ebuild, but we're using that now for our doc viewing
system |
| 13:24.40 |
plaes |
yeah, I'm
using Gentoo too, though I'm compiling my own |
| 13:25.10 |
plaes |
ah, dli is
the one who maintains it |
| 13:25.16 |
starseeker |
is also a gentoo user |
| 13:26.11 |
plaes |
dlbtw, I
fixed dev-tcl/itk to install itkConfig.sh file ;) |
| 13:27.01 |
dli |
plaes, but
7.20.2 is still not in main tree, I don't have access to main tree,
only the sci-overlay |
| 13:27.29 |
plaes |
dli: why does
it depend explicitly on java? |
| 13:28.30 |
plaes |
also,
Calculating dependencies - * A file is not listed in the Manifest:
'/var/lib/layman/science/media-gfx/brlcad/brlcad-7.20.2-r1.ebuild' |
| 13:29.16 |
dli |
plaes, the
dependency on java is removed already for cmake version
:( |
| 13:29.56 |
dli |
plaes,
weird |
| 13:29.57 |
``Erik |
BRL-CAD does
have a JNI interface in src/librtserver that requires the java
headers and libraries, and I believe the pdf docs require apache
fop which is a java program |
| 13:30.23 |
dli |
plaes, sorry,
my fault, forgot to check git ls-files |
| 13:31.02 |
starseeker |
wants to build a desktop with one of those new AMD 12 core
processors :-) |
| 13:31.43 |
dli |
plaes, fixed
in overlay |
| 13:32.11 |
plaes |
it works
nice, now if you could add java USE flag too ;) |
| 13:32.12 |
dli |
starseeker,
in 5 years, netbooks will have that many cores :) |
| 13:34.19 |
dli |
plaes, I will
do that, need some time to test it though |
| 13:34.29 |
starseeker |
is still stuck on two at the moment - house keeps breaking,
so minor things like CPU core count take a
backseat |
| 13:36.20 |
``Erik |
pats his 650mhz p3 O.o |
| 13:37.04 |
dli |
``Erik, I run
an amd (athlon-4 k7) 500MHz |
| 13:39.52 |
starseeker |
if I can't
emerge world from scratch in less than a minute the machine isn't
powerful enough :-P |
| 13:41.18 |
dli |
starseeker, I
use ebuild qmerge to testing, so, easier than atomic
emerge |
| 13:45.17 |
starseeker |
dli: cool.
nice work, bty - thanks for the time you're putting in |
| 13:45.34 |
starseeker |
has some experience with gentoo integration and knows it
ain't so simple |
| 13:46.24 |
starseeker |
saddles up and heads out |
| 13:54.59 |
plaes |
wow, you guys
can then test my fftw patchset ;) |
| 14:14.10 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46018 10/brlcad/trunk/include/bu.h: add
BU_ASSERT_SSIZE_T |
| 14:14.47 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46019 10/brlcad/trunk/src/librt/comb/comb.c:
Change mi to ssize_t since we store -1 as a magic value and do a
< in the assertion. |
| 14:28.42 |
dli |
starseeker,
JavaVM/jni.h - not found, the icedtea6 jni.h is
/opt/icedtea6-bin-1.10.3/include/jni.h |
| 14:56.13 |
kunigami |
is there
anyway to be warned by subversion when I'm adding a file which does
match any pattern on config file? |
| 14:57.04 |
kunigami |
Currently, it
causes error when I'm already commiting and this way I have to
reverse |
| 14:57.16 |
kunigami |
*revert |
| 14:58.09 |
kunigami |
(I'm
referring to those mime types) |
| 15:00.38 |
``Erik |
typically,
it'll complain that you need to set the svn:mime-type and
svn:eol-style |
| 15:01.22 |
kunigami |
yup, but I'd
like it to complain when I'm adding the files, not when
committing. |
| 15:25.16 |
bhinesley |
starseeker:
_ged_get_solid_keypoint takes a char**. It changes what *str points
to. That's one of the reasons why it was crashing when I attempted
to free. There really is not point in allocating space; it never
writes to it. |
| 15:27.30 |
bhinesley |
_get_get_solid_keypoint does things like
*str = "V";, which was throwing me off. (*str = "V") != ((*str)[0]
= 'V') |
| 15:29.13 |
bhinesley |
so, silly
enough, my first commit with "char *str = "V";" actually worked
just fine |
| 15:35.29 |
brlcad |
right, as
long as you don't try to free(str) or write to str, but you could
pass &str to a char ** argument and repoint str to something
else |
| 15:36.32 |
bhinesley |
that's what I
ended up doing when I realized that the pointer had
changed |
| 15:36.36 |
brlcad |
plaes:
computing a fft is a pretty quick operation these days so you'd
probably want to perform a 256x256 convolution a few million times
in a loop, compare before/after |
| 15:37.33 |
brlcad |
plaes: PKG
macros are only available if pkg_config is installed, which isn't
for many platforms our autotools build supports, but then like I
said -- that build system is going away completely in a few months
in favor of cmake |
| 15:39.09 |
abhi2011 |
I have a
question about setting up commands in mged, so if a command is to
be run through a tcl procedure, then I guess it should not have a
entry in the table in mged/setup.c |
| 15:40.07 |
abhi2011 |
setting up a
tcl script in tclscripts/mged should be sufficient, and this should
avoid any conflicts with the setup.c mechanism of running commands
? |
| 15:41.40 |
bhinesley |
abhi2011:
meaning a purely Tcl command? |
| 15:41.41 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 15:41.57 |
brlcad |
kunigami: not
sure about getting svn to warn when it *doesn't* match a pattern..
though it's not clear what error you'd run into that begs a revert
-- if it aborts saying mime types aren't set, you can just set the
mimetypes and try again until they're all set |
| 15:42.26 |
abhi2011 |
bhinseley: no
the logic for the command is in a c file and I have been running it
so far using an entry in setup.c |
| 15:42.39 |
abhi2011 |
so its not a
pure tcl command |
| 15:43.03 |
abhi2011 |
what I want
is to call the command multiple times from a tclscript |
| 15:43.07 |
brlcad |
plaes: java
is not required, it just builds a jni binding library if it's
detected .. if an ebuild specified it as required, that could be
simplified/removed |
| 15:44.15 |
kunigami |
brlcad: I
need to add an entry to .subversion/conf when it gives an error.
But this will only make effect if I revert and add the file again.
The reason I'm complaining is that if I'm adding to much code, it
takes a lot of time before raising an error. I'm writing a simple
script by now |
| 15:44.20 |
brlcad |
bhinesley:
what about just removing the parameter altogether? |
| 15:44.38 |
brlcad |
if you don't
use it, it's just overhead logic that will fall out of
sync |
| 15:45.15 |
brlcad |
abhi2011: you
shouldn't need to do anything in tclscripts/mged |
| 15:45.42 |
brlcad |
you can call
it multiple times from a tclscript already |
| 15:46.20 |
brlcad |
if you just
want to avoid typing a test proc many times over, put your logic
into a .tcl file and "source file.tcl" to run that proc |
| 15:46.39 |
brlcad |
calling the
command in a loop in order to get interactive updating is not the
final form of the command |
| 15:46.48 |
brlcad |
it's just a
short-term workaround |
| 15:47.06 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 15:47.33 |
bhinesley |
brlcad: I
could; it would remove a lot of functionality, since we'd only be
able to get one type of point. I'm not sure how it would affect
getting the coordinates of a BSPLINE/ARS; I haven't been able to
get them to work yet in the first place |
| 15:47.53 |
bhinesley |
so if I am
personally not using it, it should be removed? |
| 15:48.19 |
brlcad |
bspline is
going to be deprecated/removed so a non-issue there |
| 15:48.38 |
bhinesley |
ok, I'll
remove that |
| 15:48.40 |
abhi2011 |
oh ok, I
thought the user would invoke a single command from mged , and then
a tclscript corresponding to the command would run to update the
position at each step (with the libged command running 1 step each
time) |
| 15:48.52 |
brlcad |
ars just
needs to define a point, perhaps the first point .. which it would
have had to do anyways for sed |
| 15:49.29 |
brlcad |
abhi2011: no,
soonish, the libged command will run all N time steps.. the tcl
script is just so you can see updates in the meantime |
| 15:49.45 |
brlcad |
getting
interactive updating *while* a command is running is going to
require a minor modification |
| 15:49.53 |
bhinesley |
brlcad: it
relied on 3 globals (es_ars_crv, es_ars_col, es_pt), which I do not
know how to set |
| 15:49.59 |
abhi2011 |
brlcad: ok I
understand |
| 15:50.37 |
starseeker |
hmm... get
solid keypoint apparently allows to select vertex or
height. |
| 15:51.16 |
starseeker |
or the A/B/C
points for sph/ell |
| 15:52.08 |
starseeker |
do we
actually use that ability? |
| 15:53.05 |
brlcad |
bhinesley:
quick glance through the code, those are set depending on the
editing mode |
| 15:53.22 |
brlcad |
lemme see if
it's obvious how the default is set |
| 15:53.25 |
bhinesley |
starseeker:
addressing me? well, it would be neat to incorporate the use of
those points into edit.c, but would make for some even more
daunting syntax. As it is, no, I do not use. |
| 15:54.06 |
starseeker |
bhinesley:
more thinking out loud - the ability is in the code, but if we make
no use of it it can be removed |
| 15:54.17 |
starseeker |
default looks
like it might be edsol.c:2565 |
| 15:55.32 |
bhinesley |
starseeker:
case ID_ARS doesn't use the string to select which
point |
| 15:56.01 |
bhinesley |
it uses
es_ars_crv and es_ars_col, which are both set to -1 in edsol.c
(?) |
| 15:56.59 |
brlcad |
bhinesley:
keep in mind that the logic will forever exist in svn (and in mged
until it's removed/refactored), so unless you're aiming for the
long term proper refactoring (i.e. librt prims) .. you should
simplify to just what you need |
| 15:57.45 |
bhinesley |
brlcad: no
problem |
| 15:58.08 |
brlcad |
starseeker:
if you're right, then it looks like you can't push an
ARS |
| 15:58.31 |
brlcad |
so using the
first point or average of all ars points would be perfectly
adequate |
| 15:58.50 |
bhinesley |
I've got to
step out for a bit, bbl |
| 15:58.55 |
brlcad |
cya |
| 15:59.00 |
brlcad |
hits road |
| 16:00.48 |
brlcad |
hm, cmake
build not catching warnings being spit out by atools
build |
| 16:01.05 |
starseeker |
am I missing
some flags? |
| 16:01.28 |
brlcad |
bhinesley:
mixing decls and code in edit.c, have to put all decls at the top
of a scope for c90 compliance |
| 17:12.22 |
bhinesley |
brlcad: ah
yes, assuming you're referring to the calloc, I was testing and
forgot to move that back |
| 17:23.58 |
CIA-62 |
BRL-CAD:
03bhinesley * r46020 10/brlcad/trunk/src/libged/edit.c: Don't mix
decls and code. |
| 17:25.20 |
bhinesley |
brlcad: saw
what you meant. |
| 17:25.29 |
plaes |
brlcad: did
you see my answer to your fftw3 questions? |
| 17:32.57 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 17:34.32 |
brlcad |
plaes: yes,
and I responded back :) |
| 17:35.37 |
plaes |
ah, didn't
scroll up too much |
| 17:36.05 |
plaes |
s/too/that |
| 17:36.07 |
brlcad |
<PROTECTED> |
| 17:36.46 |
plaes |
whoa,
cool |
| 17:36.48 |
bhinesley |
brlcad:
neat |
| 17:37.18 |
brlcad |
you can add
your own custom keywords to hilight too, but your nick is a
default |
| 17:37.35 |
starseeker |
<PROTECTED> |
| 17:37.44 |
starseeker |
is that irssi
specific |
| 17:37.53 |
brlcad |
helps to
leave off the leading space there starseeker ... :) |
| 17:37.59 |
starseeker |
nods |
| 17:38.14 |
brlcad |
that is a
client command, but lots of irc clients support it |
| 17:38.28 |
starseeker |
sweet |
| 17:38.29 |
bhinesley |
saw a student
in #gsoc send his /nickserv ident command |
| 17:38.38 |
bhinesley |
...with
hundreds in the room |
| 17:38.39 |
starseeker |
heh -
oops |
| 17:38.44 |
brlcad |
yeah,
happens, then hilarity ensues |
| 17:38.49 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 17:51.32 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 18:05.47 |
louipc |
like password
changing :P |
| 18:15.31 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 18:22.05 |
CIA-62 |
BRL-CAD:
03brlcad * r46021 10/brlcad/trunk/src/proc-db/: ignore
ringworld |
| 18:25.39 |
CIA-62 |
BRL-CAD:
03bhinesley * r46022 10/brlcad/trunk/src/libged/ (edit.c
ged_private.h get_solid_kp.c): Removed **strp parameter of
_ged_get_solid_keypoint(), and updated arguments in edit.c.
Temporarily disable certain primitive types that we're not yet
calculating the keypoint of. |
| 18:31.58 |
starseeker |
blinks - apparently all ars does is tessellate itself and
then call bot routines |
| 18:34.16 |
brlcad |
yeah, it was
the quick and dirty way back in the day when it was being
implemented |
| 18:34.20 |
brlcad |
someone
completely intending to go back and improve on it some
day |
| 18:35.05 |
brlcad |
prime example
why you shouldn't half-ass anything, that crap lives on much longer
that the dev that contributed it |
| 18:35.28 |
CIA-62 |
BRL-CAD:
03starseeker * r46023
10/brlcad/trunk/src/librt/primitives/ars/ars.c: Been commented out
for a long time, svn's got our back if we need it - outta
here. |
| 18:35.40 |
brlcad |
if it's worth
doing, do it while it's in context and we'll all waste a little
less time |
| 18:36.07 |
brlcad |
ars is really
just a useful input type, describes geometry using
waterlines |
| 18:37.39 |
brlcad |
should be a
nice smooth surface, or at least an option like dsp for faceted
linear interpolation in addition to smooth |
| 19:10.41 |
CIA-62 |
BRL-CAD:
03bhinesley * r46024 10/brlcad/trunk/src/libged/get_solid_kp.c:
Enable retrieval of natural origin of PIPE and ARBN. Hard coded in
a tolerance in ARBN for acceptable distance from point to plane,
used in calculating origin. |
| 19:11.21 |
bhinesley |
I am assuming
it is unacceptible to hard code in a tolerance (as in r46024).
Where should I get it from? |
| 19:11.21 |
CIA-62 |
BRL-CAD:
03brlcad * r46025 10/brlcad/trunk/src/other/libpng/Makefile.am: add
depends rule, support for 1.7, source our m4 dir |
| 19:14.20 |
bhinesley |
I should
mention that in the original file, it was set via
mged_tol.dist |
| 19:16.51 |
brlcad |
bhinesley:
the gedp has a ged_wdbp member that holds tolerance settings for
the current database |
| 19:17.09 |
bhinesley |
oh,
cool |
| 19:18.09 |
brlcad |
see rt_wdb in
raytrace.h (and the respective tolerance structs in
libbn) |
| 19:21.21 |
CIA-62 |
BRL-CAD:
03bhinesley * r46026 10/brlcad/trunk/src/libged/get_solid_kp.c: get
tolerance from db |
| 19:23.45 |
abhi2011 |
brlcad: I
have modifying the bb function to work on groups and regions :
http://bin.cakephp.org/view/1394071764 |
| 19:24.01 |
abhi2011 |
I am calling
rt_gettree() before rt_bound_tree() to evaluate the tree
first |
| 19:26.17 |
brlcad |
abhi2011:
excellent! |
| 19:26.19 |
brlcad |
that's
looking better |
| 19:26.47 |
brlcad |
probably
don't need the if (combp->region_flag) conditional if you're
going to do the same to both if/else cases |
| 19:27.23 |
abhi2011 |
ah yes, but I
am not sure if both regions and groups will require the same
treatment |
| 19:27.29 |
abhi2011 |
I am testing
with a region made as follows in mged r part1.r u rcc2.s -
sph2.s |
| 19:27.31 |
brlcad |
they will
:) |
| 19:27.36 |
brlcad |
regions are
combs |
| 19:27.41 |
abhi2011 |
yes
right |
| 19:27.49 |
abhi2011 |
yes
ok |
| 19:27.54 |
brlcad |
:) |
| 19:28.00 |
abhi2011 |
well , the
thing is when traversing the tree in the rt_bound_tree() call ,
the first call sees the subtraction operator in tp->tr_op and
proceeds smoothly down to the left child |
| 19:28.14 |
abhi2011 |
however in
the left tree where it should find the primitive rcc2.s, it
encounters an unknown op 12, I think it should have encountered a
tr_op = OP_SOLID for the rcc.s primitive |
| 19:28.28 |
abhi2011 |
this is
probably related to the fact that the rt_gettree() calls reports
missing primitives for the region : db_lookup(rcc2.s) failed in
/dummy, db_lookup(sph2.s) failed in /dummy, |
| 19:28.59 |
brlcad |
yeah, that's
exactly why |
| 19:29.08 |
brlcad |
you need more
than just the comb put into the inmem |
| 19:29.26 |
abhi2011 |
ok |
| 19:29.30 |
brlcad |
you have to
put the whole hierarchy |
| 19:30.11 |
brlcad |
db_functree()
is good for that |
| 19:30.15 |
abhi2011 |
ok, umm so I
should use dbi_walk_tree() and register callbacks |
| 19:30.17 |
abhi2011 |
oh
ok |
| 19:30.17 |
brlcad |
see
src/libged/keep.c |
| 19:30.49 |
brlcad |
the 'heep'
command does the same thing you need to do except it writes to a
file and you need to write to the inmem |
| 19:31.06 |
brlcad |
er, "keep"
command |
| 19:31.29 |
abhi2011 |
ah ,
ok |
| 19:32.20 |
*** join/#brlcad dli (~dli@66.49.191.45) |
| 19:32.39 |
brlcad |
hm, abhi2011
but wasn't the point of the inmem so you could call rt_gettrees on
it? |
| 19:32.50 |
brlcad |
which only
applied to primitives |
| 19:33.19 |
brlcad |
why not just
call rt_bound_tree() directly with the same (non-inmem)
dbip? |
| 19:33.42 |
abhi2011 |
well yes, for
primitives I do call rt_bound_tree() directly |
| 19:33.54 |
abhi2011 |
or
rather |
| 19:34.01 |
abhi2011 |
no I
dont |
| 19:34.16 |
abhi2011 |
its
rt_gettree() which is sufficient |
| 19:34.23 |
brlcad |
right |
| 19:34.37 |
abhi2011 |
however for
combs, the rt_gettree() is not sufficient |
| 19:34.45 |
abhi2011 |
but i havent
tried rt_gettrees() |
| 19:34.56 |
abhi2011 |
maybe that
will work |
| 19:35.08 |
brlcad |
er, that's
not my point |
| 19:35.53 |
brlcad |
okay, so the
problem is a bit convoluted because you lost the caller's
rt_db_internal pointer |
| 19:36.05 |
brlcad |
first step,
make that first parameter const |
| 19:36.07 |
abhi2011 |
yes
:) |
| 19:36.14 |
abhi2011 |
nope that
doesnt work |
| 19:36.18 |
brlcad |
it
can |
| 19:36.26 |
abhi2011 |
oh
ok |
| 19:36.35 |
abhi2011 |
wdb_put_internal() will be unable to free
it then |
| 19:36.39 |
brlcad |
yep |
| 19:36.45 |
brlcad |
so you have
to do something about that |
| 19:37.18 |
abhi2011 |
well I have
tried with const before but I ll try once more, perhaps I missed
something |
| 19:37.22 |
brlcad |
if you make a
copy, then that same ip should be just fine for
rt_bound_tree() |
| 19:37.28 |
abhi2011 |
ok |
| 19:38.11 |
brlcad |
it might even
be easier to deal with primitives differently |
| 19:38.57 |
brlcad |
instead of
using an inmem and calling gettrees(), it might be a lot simpler to
fill in an rt_comb_internal yourself with just that one primitive
as a leaf node |
| 19:39.22 |
brlcad |
then you
could call rt_bound_tree() the same for any rt_db_internal
regardless of it being a primitive or a combination |
| 19:40.08 |
abhi2011 |
ok
yes |
| 19:51.37 |
CIA-62 |
BRL-CAD:
03brlcad * r46027 10/brlcad/branches/cmake/: remove the cmake
branch as it was reviewed and merged back in April/May 2011. trunk
is where the action is now. |
| 19:54.00 |
*** join/#brlcad dli (~dli@67.55.32.136) |
| 19:57.43 |
brlcad |
starseeker:
can the goblin branch be killed? |
| 19:57.59 |
brlcad |
hasn't had
activity since early 2010 |
| 20:17.37 |
CIA-62 |
BRL-CAD:
03brlcad * r46028 10/brlcad/trunk/ (include/raytrace.h
src/librt/bbox.c): accept sf patch 3390331 (Addition of a new librt
function to return the bounding box) from Abhijit ( abhi2011 ).
applies cleanly even if it's still a work in progress. |
| 20:18.39 |
abhi2011 |
yipee
:P |
| 20:18.59 |
bhinesley |
abhi2011:
looking good, I will probably use that to calculate my bb centers
:) |
| 20:19.08 |
abhi2011 |
nice
:) |
| 20:22.09 |
CIA-62 |
BRL-CAD:
03brlcad * r46029 10/brlcad/trunk/AUTHORS: credit abhijit nandy
with his code contributions to date, namely efforts to implement a
librt routine that calculates bounding boxes for given geometry.
(see sf patch 3390331 and 3376910) |
| 20:22.38 |
brlcad |
abhi2011: so
with that, you are now vetted with commit access -- don't break
anything ;) |
| 20:23.23 |
brlcad |
that also
means, however, that you should commit the updates you have right
away, though, and then continually commit to svn throughout the day
while you work and make progress |
| 20:23.50 |
brlcad |
that makes it
a lot easier for other devs to track not only what you are doing,
but how and why you arrive at various implementation
decisions |
| 20:24.11 |
abhi2011 |
brlcad:
thanks, yes I will be careful :) |
| 20:24.26 |
brlcad |
just do a
good faith effort to make sure you don't break the build, follow
the HACKING guidelines, and work with other devs if an issue comes
up |
| 20:24.40 |
brlcad |
abhi2011: and
congrats ;) |
| 20:24.57 |
abhi2011 |
:)
haha |
| 20:25.22 |
abhi2011 |
yah I ll
finish the bb functions and test it before my next
commit |
| 20:25.44 |
abhi2011 |
i mean first
commit |
| 20:26.31 |
brlcad |
you're the
only one working on that function right now, so if what you have
*now* already compiles, you can go ahead and commit it |
| 20:26.39 |
brlcad |
then
test/fix, then recommit, etc |
| 20:26.46 |
brlcad |
you cannot
commit too frequently |
| 20:26.51 |
abhi2011 |
ok |
| 20:26.59 |
brlcad |
you can very
easily commit too infrequently (and many do) |
| 20:27.23 |
brlcad |
ftw: svn
commit -m "blah blah" my_file.c & |
| 20:27.33 |
brlcad |
backgrounds
the commit with the log message so you can keep coding
;) |
| 20:27.42 |
abhi2011 |
yes
ok |
| 20:27.50 |
abhi2011 |
been using
tortoise svn :P |
| 20:28.04 |
brlcad |
ah,
okay |
| 20:28.24 |
abhi2011 |
i mean before
for other projects , while in windows |
| 20:28.27 |
brlcad |
that's your
perrogative, just don't let the tool slow down your interaction and
commits :) |
| 20:28.40 |
abhi2011 |
yep |
| 20:28.58 |
abhi2011 |
i have a
question regarding the primary data structures |
| 20:29.06 |
abhi2011 |
used in
brl-cad |
| 20:29.39 |
abhi2011 |
so the tree
that the rt_* functions manipulate, thats the main boolean tree
used to represent the model |
| 20:29.56 |
brlcad |
sure, you can
look at it that way |
| 20:29.56 |
abhi2011 |
I mean the
union tree* structure |
| 20:30.02 |
brlcad |
nods |
| 20:30.52 |
brlcad |
note that
those represent the tree for a combination (i.e., a combination
represents a boolean recipe) |
| 20:31.16 |
brlcad |
so primitives
don't inherintly have a tree because they don't inherintly have a
boolean recipe, they are leaf nodes |
| 20:31.39 |
abhi2011 |
yes, so the
root has the boolean operations being performed on the leaves, for
each node , ok but if everthing is present in the tree leaves(which
I understand can only be the primitives) then why is there a need
to a slid table soltab |
| 20:32.22 |
brlcad |
a need to
what? |
| 20:33.08 |
abhi2011 |
oops... i
meant why is there a need for a solid table called struct
soltab |
| 20:33.34 |
abhi2011 |
it seems to
hold extra information about solids in the model |
| 20:33.56 |
abhi2011 |
but this
could have been packed into the union tree nodes |
| 20:34.24 |
starseeker |
brlcad:
sure |
| 20:35.16 |
CIA-62 |
BRL-CAD:
03bhinesley * r46030 10/brlcad/trunk/src/libged/get_solid_kp.c:
Enable retrieval of reasonable default keypoints for the remaining
primitive types (METABALL, BOT, ARS, NMG). Remove all
FIXME's/unnecessary comments, and trim all line
lengths. |
| 20:37.32 |
brlcad |
abhi2011:
struct soltab are basically unpacked rt_db_internal objects of
primitives only |
| 20:38.04 |
abhi2011 |
ok |
| 20:38.07 |
brlcad |
part legacy
part optimized expressiveness |
| 20:38.26 |
brlcad |
soltab is
basically a prep'd rt_db_internal |
| 20:38.42 |
brlcad |
primitive |
| 20:39.04 |
brlcad |
starseeker:
sure it can go or sure it has value and needs to stay?
:) |
| 20:39.16 |
abhi2011 |
ok, and I
read in some of the docs that an octree based space partitioning is
done before rays are shot by rt |
| 20:39.26 |
brlcad |
don't want to
remove it if there's some residual value there .. but if it's dead
in the water, might as well clean up |
| 20:39.54 |
brlcad |
abhi2011:
spatial partitioning is performed before rays are shot |
| 20:40.05 |
abhi2011 |
ok |
| 20:40.07 |
brlcad |
so that you
only evaluate against primitives that are "near" |
| 20:40.13 |
abhi2011 |
yes |
| 20:40.34 |
brlcad |
yay, all logo
finalists have responded .. time for the announcement |
| 20:40.37 |
brlcad |
waddles |
| 21:03.19 |
DarkCalf |
brlcad, have
you seen Minecraft? |
| 21:15.43 |
kunigami |
>.<
svn: Commit failed (details follow): |
| 21:15.43 |
kunigami |
svn: MERGE of
'/svnroot/brlcad/osl/trunk': timed out waiting for server (https://brlcad.svn.sourceforge.net) |
| 21:16.11 |
kunigami |
do you mind
if I perform several small commits on boost parts? |
| 21:19.14 |
CIA-62 |
BRL-CAD:
03kunigami * r46031 10/osl/trunk/boost/: adding boost by
parts |
| 21:20.27 |
CIA-62 |
BRL-CAD:
03kunigami * r46032 10/osl/trunk/boost/boost/: adding boost by
parts |
| 21:23.03 |
CIA-62 |
BRL-CAD:
03starseeker * r46033 10/brlcad/trunk/ (8 files in 8
dirs): |
| 21:23.03 |
CIA-62 |
BRL-CAD:
Start organizing a functab function specifically for bounding box
calculation. |
| 21:23.03 |
CIA-62 |
BRL-CAD: So
far, have functions for ell, tor, tgc and rec pulled out from prep
- arb8 is |
| 21:23.03 |
CIA-62 |
BRL-CAD:
implemented but the way arb prep works means we can't use it there.
sph just |
| 21:23.03 |
CIA-62 |
BRL-CAD:
calls the ell routine. |
| 21:24.13 |
starseeker |
brlcad: it
can go |
| 21:25.06 |
starseeker |
kunigami:
sure - that has to be done sometimes |
| 21:25.07 |
CIA-62 |
BRL-CAD:
03kunigami * r46034 10/osl/trunk/boost/boost/aligned_storage.hpp:
adding boost by parts |
| 21:25.17 |
CIA-62 |
BRL-CAD:
03kunigami * r46035 10/osl/trunk/boost/boost/array.hpp: adding
boost by parts |
| 21:25.28 |
CIA-62 |
BRL-CAD:
03kunigami * r46036 10/osl/trunk/boost/boost/asio.hpp: adding boost
by parts |
| 21:25.38 |
CIA-62 |
BRL-CAD:
03kunigami * r46037 10/osl/trunk/boost/boost/assert.hpp: adding
boost by parts |
| 21:25.50 |
kunigami |
ouch, |
| 21:25.57 |
CIA-62 |
BRL-CAD:
03kunigami * r46038 10/osl/trunk/boost/boost/bind.hpp: adding boost
by parts |
| 21:25.57 |
CIA-62 |
BRL-CAD:
03kunigami * r46039 10/osl/trunk/boost/boost/call_traits.hpp:
adding boost by parts |
| 21:27.33 |
CIA-62 |
BRL-CAD:
03kunigami * r46040 10/osl/trunk/boost/boost/algorithm/ (43 files
in 4 dirs): adding boost by parts |
| 21:29.58 |
CIA-62 |
BRL-CAD:
03kunigami * r46041 10/osl/trunk/boost/boost/archive/ (97 files in
4 dirs): adding boost by parts |
| 21:36.13 |
brlcad |
starseeker:
awesome, adding the new functab! |
| 21:36.38 |
brlcad |
fwiw, that
makes librt binary incompatible unless you make the new functab
entry be last |
| 21:36.50 |
starseeker |
brlcad:
starting it anyway - some of these aren't so simple (trying the
figure out how the frack to get a list of all vertices in an
nmg) |
| 21:36.59 |
starseeker |
brlcad: ah,
crap |
| 21:37.20 |
brlcad |
not .g
incompatible, librt.so incompat |
| 21:37.24 |
starseeker |
I should move
it then? |
| 21:37.43 |
CIA-62 |
BRL-CAD:
03kunigami * r46042 10/osl/trunk/boost/boost/asio/ (310 files in 13
dirs): adding boost by parts |
| 21:37.43 |
brlcad |
doesn't
matter -- but if it stays as-is, minor should be bumped |
| 21:38.01 |
starseeker |
grins evilly - oh good, then we'll do the deprications
too |
| 21:38.16 |
CIA-62 |
BRL-CAD:
03kunigami * r46043 10/osl/trunk/boost/boost/bind/ (14 files):
adding boost by parts |
| 21:38.28 |
CIA-62 |
BRL-CAD:
03kunigami * r46044 10/osl/trunk/boost/boost/cast.hpp: adding boost
by parts |
| 21:38.35 |
starseeker |
there has got
to be some way to iterate over all vertices in a model for
nmg... |
| 21:38.38 |
CIA-62 |
BRL-CAD:
03kunigami * r46045 10/osl/trunk/boost/boost/cerrno.hpp: adding
boost by parts |
| 21:38.48 |
CIA-62 |
BRL-CAD:
03kunigami * r46046 10/osl/trunk/boost/boost/checked_delete.hpp:
adding boost by parts |
| 21:38.59 |
CIA-62 |
BRL-CAD:
03kunigami * r46047 10/osl/trunk/boost/boost/compressed_pair.hpp:
adding boost by parts |
| 21:39.22 |
CIA-62 |
BRL-CAD:
03kunigami * r46048 10/osl/trunk/boost/boost/concept/ (11 files in
2 dirs): adding boost by parts |
| 21:39.33 |
CIA-62 |
BRL-CAD:
03kunigami * r46049 10/osl/trunk/boost/boost/concept_archetype.hpp:
adding boost by parts |
| 21:39.44 |
CIA-62 |
BRL-CAD:
03kunigami * r46050 10/osl/trunk/boost/boost/concept_check.hpp:
adding boost by parts |
| 21:41.37 |
CIA-62 |
BRL-CAD:
03kunigami * r46051 10/osl/trunk/boost/boost/config/ (73 files in 6
dirs): adding boost by parts |
| 21:41.49 |
CIA-62 |
BRL-CAD:
03kunigami * r46052 10/osl/trunk/boost/boost/config.hpp: adding
boost by parts |
| 21:41.59 |
CIA-62 |
BRL-CAD:
03kunigami * r46053 10/osl/trunk/boost/boost/cregex.hpp: adding
boost by parts |
| 21:42.08 |
CIA-62 |
BRL-CAD:
03kunigami * r46054 10/osl/trunk/boost/boost/cstdint.hpp: adding
boost by parts |
| 21:42.18 |
CIA-62 |
BRL-CAD:
03kunigami * r46055 10/osl/trunk/boost/boost/cstdlib.hpp: adding
boost by parts |
| 21:42.27 |
CIA-62 |
BRL-CAD:
03kunigami * r46056 10/osl/trunk/boost/boost/current_function.hpp:
adding boost by parts |
| 21:44.03 |
CIA-62 |
BRL-CAD:
03kunigami * r46057 10/osl/trunk/boost/boost/date_time/ (65 files
in 3 dirs): adding boost by parts |
| 21:45.07 |
CIA-62 |
BRL-CAD:
03kunigami * r46058 10/osl/trunk/boost/boost/detail/ (33 files):
adding boost by parts |
| 21:45.26 |
CIA-62 |
BRL-CAD:
03kunigami * r46059 10/osl/trunk/boost/boost/dynamic_bitset/ (.
config.hpp dynamic_bitset.hpp): adding boost by parts |
| 21:45.39 |
CIA-62 |
BRL-CAD:
03kunigami * r46060 10/osl/trunk/boost/boost/dynamic_bitset.hpp:
adding boost by parts |
| 21:45.47 |
CIA-62 |
BRL-CAD:
03kunigami * r46061
10/osl/trunk/boost/boost/dynamic_bitset_fwd.hpp: adding boost by
parts |
| 21:45.57 |
CIA-62 |
BRL-CAD:
03kunigami * r46062
10/osl/trunk/boost/boost/enable_shared_from_this.hpp: adding boost
by parts |
| 21:46.13 |
abhi2011 |
I have a
question regarding commits, so suppose I have commited 2 or more
files but I want to commit only a particular file as of now, can I
do that |
| 21:46.25 |
CIA-62 |
BRL-CAD:
03kunigami * r46063 10/osl/trunk/boost/boost/exception/ (16 files
in 2 dirs): adding boost by parts |
| 21:46.29 |
abhi2011 |
*i mean
suppose I have modified |
| 21:46.38 |
CIA-62 |
BRL-CAD:
03kunigami * r46064 10/osl/trunk/boost/boost/exception_ptr.hpp:
adding boost by parts |
| 21:46.41 |
kunigami |
you can do:
svn commit -m "message" name-of-the-file |
| 21:46.51 |
starseeker |
sure - svn
commit path/to/specific/file -m "message" |
| 21:46.53 |
abhi2011 |
kunigami:
thanks :) |
| 21:46.54 |
starseeker |
er,
yeah |
| 21:47.00 |
abhi2011 |
yes |
| 21:47.21 |
CIA-62 |
BRL-CAD:
03kunigami * r46065 10/osl/trunk/boost/boost/filesystem/ (24 files
in 4 dirs): adding boost by parts |
| 21:47.30 |
CIA-62 |
BRL-CAD:
03kunigami * r46066 10/osl/trunk/boost/boost/filesystem.hpp: adding
boost by parts |
| 21:47.37 |
plaes |
brlcad
doesn't support STEP ? |
| 21:47.42 |
CIA-62 |
BRL-CAD:
03kunigami * r46067 10/osl/trunk/boost/boost/foreach.hpp: adding
boost by parts |
| 21:47.51 |
CIA-62 |
BRL-CAD:
03kunigami * r46068 10/osl/trunk/boost/boost/foreach_fwd.hpp:
adding boost by parts |
| 21:48.24 |
CIA-62 |
BRL-CAD:
03kunigami * r46069 10/osl/trunk/boost/boost/format/ (20 files in 2
dirs): adding boost by parts |
| 21:48.35 |
CIA-62 |
BRL-CAD:
03kunigami * r46070 10/osl/trunk/boost/boost/format.hpp: adding
boost by parts |
| 21:49.13 |
CIA-62 |
BRL-CAD:
03kunigami * r46071 10/osl/trunk/boost/boost/function/ (20 files in
2 dirs): adding boost by parts |
| 21:49.23 |
CIA-62 |
BRL-CAD:
03kunigami * r46072 10/osl/trunk/boost/boost/function.hpp: adding
boost by parts |
| 21:49.34 |
starseeker |
plaes: we're
working on it - step-g |
| 21:49.36 |
CIA-62 |
BRL-CAD:
03kunigami * r46073 10/osl/trunk/boost/boost/function_equal.hpp:
adding boost by parts |
| 21:49.49 |
plaes |
aha |
| 21:50.01 |
starseeker |
kunigami: uh,
you might want to try committing per dir, not per
file... |
| 21:50.03 |
CIA-62 |
BRL-CAD:
03kunigami * r46074 10/osl/trunk/boost/boost/functional/ (13 files
in 3 dirs): adding boost by parts |
| 21:50.17 |
starseeker |
oh, nevermind
I see |
| 21:52.16 |
kunigami |
starseeker:
I could have done a better job committing each dir's first and then
all the single files in a single bundle :( sorry |
| 21:52.29 |
CIA-62 |
BRL-CAD:
03kunigami * r46075 10/osl/trunk/boost/boost/fusion/ (111 files in
21 dirs): adding boost by parts |
| 21:52.43 |
CIA-62 |
BRL-CAD:
03kunigami * r46076 10/osl/trunk/boost/boost/get_pointer.hpp:
adding boost by parts |
| 21:53.31 |
brlcad |
starseeker:
there's nmg_visit() |
| 21:53.54 |
CIA-62 |
BRL-CAD:
03kunigami * r46077 10/osl/trunk/boost/boost/graph/ (45 files in 7
dirs): adding boost by parts |
| 21:53.58 |
brlcad |
otherwise, I
believe it's always treated as a recursive structure so integrity
is better preserved |
| 21:54.13 |
starseeker |
nods - OK, let me try a trick... |
| 21:54.16 |
CIA-62 |
BRL-CAD:
03kunigami * r46078 10/osl/trunk/boost/boost/implicit_cast.hpp:
adding boost by parts |
| 21:54.16 |
CIA-62 |
BRL-CAD:
03kunigami * r46079 10/osl/trunk/boost/boost/integer/ (.
integer_mask.hpp static_log2.hpp): adding boost by
parts |
| 21:54.17 |
brlcad |
for all
regions, for all shells, for all loops, for all edges, for all
vertices, etc |
| 21:54.26 |
CIA-62 |
BRL-CAD:
03kunigami * r46080 10/osl/trunk/boost/boost/integer.hpp: adding
boost by parts |
| 21:54.33 |
brlcad |
nmg_visit()
has a vertex callback though, so that might be easiest |
| 21:54.36 |
CIA-62 |
BRL-CAD:
03kunigami * r46081 10/osl/trunk/boost/boost/integer_fwd.hpp:
adding boost by parts |
| 21:54.37 |
starseeker |
(by the way -
is there a way to clear a bu_ptbl without having to free
memory?) |
| 21:54.47 |
CIA-62 |
BRL-CAD:
03kunigami * r46082 10/osl/trunk/boost/boost/integer_traits.hpp:
adding boost by parts |
| 21:54.57 |
CIA-62 |
BRL-CAD:
03kunigami * r46083 10/osl/trunk/boost/boost/intrusive_ptr.hpp:
adding boost by parts |
| 21:55.12 |
CIA-62 |
BRL-CAD:
03kunigami * r46084 10/osl/trunk/boost/boost/io/ (. detail/
detail/quoted_manip.hpp ios_state.hpp): adding boost by
parts |
| 21:55.23 |
CIA-62 |
BRL-CAD:
03kunigami * r46085 10/osl/trunk/boost/boost/io_fwd.hpp: adding
boost by parts |
| 21:55.28 |
brlcad |
starseeker: I
believe so |
| 21:55.33 |
brlcad |
bu.h ftw
;) |
| 21:55.39 |
starseeker |
is looking |
| 21:56.29 |
starseeker |
ah -
bu_ptbl_zero perhaps... |
| 21:56.39 |
starseeker |
nope there it
is |
| 21:56.41 |
starseeker |
bu_ptbl_reset |
| 21:56.42 |
starseeker |
:-) |
| 22:01.09 |
CIA-62 |
BRL-CAD:
03kunigami * r46086 10/osl/trunk/boost/boost/is_placeholder.hpp:
adding boost by parts |
| 22:01.51 |
CIA-62 |
BRL-CAD:
03kunigami * r46087 10/osl/trunk/boost/boost/iterator/ (17 files in
2 dirs): adding boost by parts |
| 22:02.08 |
CIA-62 |
BRL-CAD:
03kunigami * r46088 10/osl/trunk/boost/boost/iterator.hpp: adding
boost by parts |
| 22:02.26 |
CIA-62 |
BRL-CAD:
03kunigami * r46089 10/osl/trunk/boost/boost/iterator_adaptors.hpp:
adding boost by parts |
| 22:02.38 |
CIA-62 |
BRL-CAD:
03kunigami * r46090 10/osl/trunk/boost/boost/lexical_cast.hpp:
adding boost by parts |
| 22:02.48 |
CIA-62 |
BRL-CAD:
03kunigami * r46091 10/osl/trunk/boost/boost/limits.hpp: adding
boost by parts |
| 22:02.59 |
CIA-62 |
BRL-CAD:
03kunigami * r46092 10/osl/trunk/boost/boost/make_shared.hpp:
adding boost by parts |
| 22:08.36 |
CIA-62 |
BRL-CAD:
03kunigami * r46093 10/osl/trunk/boost/boost/math/ (206 files in 7
dirs): adding boost by parts |
| 22:08.50 |
CIA-62 |
BRL-CAD:
03kunigami * r46094 10/osl/trunk/boost/boost/mem_fn.hpp: adding
boost by parts |
| 22:08.59 |
CIA-62 |
BRL-CAD:
03kunigami * r46095 10/osl/trunk/boost/boost/memory_order.hpp:
adding boost by parts |
| 22:10.26 |
CIA-62 |
BRL-CAD:
03kunigami * r46096 10/osl/trunk/boost/boost/mpi/ (55 files in 4
dirs): adding boost by parts |
| 22:10.39 |
CIA-62 |
BRL-CAD:
03kunigami * r46097 10/osl/trunk/boost/boost/mpi.hpp: adding boost
by parts |
| 22:13.58 |
CIA-62 |
BRL-CAD:
03starseeker * r46098 10/brlcad/trunk/src/librt/primitives/
(nmg/nmg.c table.c): |
| 22:13.58 |
CIA-62 |
BRL-CAD: This
appears to be a working bbox routine for nmg, but I need someone to
review |
| 22:13.58 |
CIA-62 |
BRL-CAD: it
and make sure I haven't accidently swatted some other prep function
during |
| 22:13.58 |
CIA-62 |
BRL-CAD: this
re-org. I can get a bbox and raytrace a facetized
sphere. |
| 22:31.17 |
CIA-62 |
BRL-CAD:
03kunigami * r46099 10/osl/trunk/boost/boost/mpl/ (902 files in 29
dirs): adding boost by parts |
| 22:33.13 |
CIA-62 |
BRL-CAD:
03kunigami * r46100 10/osl/trunk/boost/boost/multi_index/ (54 files
in 2 dirs): adding boost by parts |
| 22:33.24 |
CIA-62 |
BRL-CAD:
03kunigami * r46101
10/osl/trunk/boost/boost/multi_index_container.hpp: adding boost by
parts |
| 22:33.36 |
CIA-62 |
BRL-CAD:
03kunigami * r46102
10/osl/trunk/boost/boost/multi_index_container_fwd.hpp: adding
boost by parts |
| 22:33.46 |
CIA-62 |
BRL-CAD:
03kunigami * r46103 10/osl/trunk/boost/boost/next_prior.hpp: adding
boost by parts |
| 22:33.56 |
CIA-62 |
BRL-CAD:
03kunigami * r46104 10/osl/trunk/boost/boost/non_type.hpp: adding
boost by parts |
| 22:34.07 |
CIA-62 |
BRL-CAD:
03kunigami * r46105 10/osl/trunk/boost/boost/noncopyable.hpp:
adding boost by parts |
| 22:34.22 |
CIA-62 |
BRL-CAD:
03kunigami * r46106 10/osl/trunk/boost/boost/none.hpp: adding boost
by parts |
| 22:34.30 |
CIA-62 |
BRL-CAD:
03kunigami * r46107 10/osl/trunk/boost/boost/none_t.hpp: adding
boost by parts |
| 22:35.21 |
CIA-62 |
BRL-CAD:
03kunigami * r46108 10/osl/trunk/boost/boost/numeric/ (20 files in
3 dirs): adding boost by parts |
| 22:35.33 |
CIA-62 |
BRL-CAD:
03kunigami * r46109 10/osl/trunk/boost/boost/operators.hpp: adding
boost by parts |
| 22:35.45 |
CIA-62 |
BRL-CAD:
03kunigami * r46110 10/osl/trunk/boost/boost/optional/ (.
optional.hpp optional_fwd.hpp): adding boost by parts |
| 22:35.56 |
CIA-62 |
BRL-CAD:
03kunigami * r46111 10/osl/trunk/boost/boost/optional.hpp: adding
boost by parts |
| 22:36.27 |
CIA-62 |
BRL-CAD:
03kunigami * r46112 10/osl/trunk/boost/boost/parameter/ (17 files
in 2 dirs): adding boost by parts |
| 22:36.49 |
CIA-62 |
BRL-CAD:
03kunigami * r46113 10/osl/trunk/boost/boost/pending/ (9 files in 2
dirs): adding boost by parts |
| 22:36.59 |
CIA-62 |
BRL-CAD:
03kunigami * r46114 10/osl/trunk/boost/boost/pointee.hpp: adding
boost by parts |
| 22:37.22 |
CIA-62 |
BRL-CAD:
03kunigami * r46115 10/osl/trunk/boost/boost/pool/ (12 files in 2
dirs): adding boost by parts |
| 22:41.21 |
CIA-62 |
BRL-CAD:
03kunigami * r46116 10/osl/trunk/boost/boost/preprocessor/ (183
files in 35 dirs): adding boost by parts |
| 22:41.39 |
CIA-62 |
BRL-CAD:
03kunigami * r46117 10/osl/trunk/boost/boost/progress.hpp: adding
boost by parts |
| 22:41.58 |
CIA-62 |
BRL-CAD:
03kunigami * r46118 10/osl/trunk/boost/boost/property_map/ (9 files
in 3 dirs): adding boost by parts |
| 22:46.44 |
CIA-62 |
BRL-CAD:
03kunigami * r46119 10/osl/trunk/boost/boost/python/ (208 files in
7 dirs): adding boost by parts |
| 22:46.59 |
CIA-62 |
BRL-CAD:
03kunigami * r46120 10/osl/trunk/boost/boost/python.hpp: adding
boost by parts |
| 22:48.36 |
CIA-62 |
BRL-CAD:
03kunigami * r46121 10/osl/trunk/boost/boost/random/ (61 files in 2
dirs): adding boost by parts |
| 22:48.51 |
CIA-62 |
BRL-CAD:
03kunigami * r46122 10/osl/trunk/boost/boost/random.hpp: adding
boost by parts |
| 22:49.57 |
CIA-62 |
BRL-CAD:
03kunigami * r46123 10/osl/trunk/boost/boost/range/ (45 files in 4
dirs): adding boost by parts |
| 22:50.09 |
CIA-62 |
BRL-CAD:
03kunigami * r46124 10/osl/trunk/boost/boost/ref.hpp: adding boost
by parts |
| 22:51.47 |
CIA-62 |
BRL-CAD:
03kunigami * r46125 10/osl/trunk/boost/boost/regex/ (57 files in 4
dirs): adding boost by parts |
| 22:52.02 |
CIA-62 |
BRL-CAD:
03kunigami * r46126 10/osl/trunk/boost/boost/regex.hpp: adding
boost by parts |
| 22:52.12 |
CIA-62 |
BRL-CAD:
03kunigami * r46128 10/osl/trunk/boost/boost/regex_fwd.hpp: adding
boost by parts |
| 22:52.21 |
CIA-62 |
BRL-CAD:
03starseeker * r46127 10/brlcad/trunk/src/librt/primitives/
(bot/bot.c bot/g_bot_include.c table.c): Add bbox routine for
bots. |
| 22:52.21 |
CIA-62 |
BRL-CAD:
03kunigami * r46129 10/osl/trunk/boost/boost/scoped_array.hpp:
adding boost by parts |
| 22:52.32 |
CIA-62 |
BRL-CAD:
03kunigami * r46130 10/osl/trunk/boost/boost/scoped_ptr.hpp: adding
boost by parts |
| 22:53.52 |
CIA-62 |
BRL-CAD:
03kunigami * r46131 10/osl/trunk/boost/boost/serialization/ (51
files in 2 dirs): adding boost by parts |
| 22:54.06 |
CIA-62 |
BRL-CAD:
03kunigami * r46132 10/osl/trunk/boost/boost/shared_array.hpp:
adding boost by parts |
| 22:54.17 |
CIA-62 |
BRL-CAD:
03kunigami * r46133 10/osl/trunk/boost/boost/shared_ptr.hpp: adding
boost by parts |
| 22:55.53 |
CIA-62 |
BRL-CAD:
03kunigami * r46134 10/osl/trunk/boost/boost/smart_ptr/ (50 files
in 2 dirs): adding boost by parts |
| 22:56.08 |
CIA-62 |
BRL-CAD:
03kunigami * r46135 10/osl/trunk/boost/boost/smart_ptr.hpp: adding
boost by parts |
| 23:00.50 |
CIA-62 |
BRL-CAD:
03kunigami * r46136 10/osl/trunk/boost/boost/spirit/ (209 files in
36 dirs): adding boost by parts |
| 23:01.10 |
CIA-62 |
BRL-CAD:
03kunigami * r46137 10/osl/trunk/boost/boost/static_assert.hpp:
adding boost by parts |
| 23:01.24 |
CIA-62 |
BRL-CAD:
03kunigami * r46138 10/osl/trunk/boost/boost/swap.hpp: adding boost
by parts |
| 23:01.45 |
CIA-62 |
BRL-CAD:
03kunigami * r46139 10/osl/trunk/boost/boost/system/ (.
api_config.hpp config.hpp error_code.hpp system_error.hpp): adding
boost by parts |
| 23:04.48 |
CIA-62 |
BRL-CAD:
03kunigami * r46140 10/osl/trunk/boost/boost/test/ (126 files in 13
dirs): adding boost by parts |
| 23:06.06 |
CIA-62 |
BRL-CAD:
03kunigami * r46141 10/osl/trunk/boost/boost/thread/ (47 files in 4
dirs): adding boost by parts |
| 23:06.17 |
CIA-62 |
BRL-CAD:
03kunigami * r46142 10/osl/trunk/boost/boost/thread.hpp: adding
boost by parts |
| 23:06.30 |
CIA-62 |
BRL-CAD:
03kunigami * r46143 10/osl/trunk/boost/boost/throw_exception.hpp:
adding boost by parts |
| 23:06.43 |
CIA-62 |
BRL-CAD:
03kunigami * r46144 10/osl/trunk/boost/boost/timer.hpp: adding
boost by parts |
| 23:06.54 |
CIA-62 |
BRL-CAD:
03kunigami * r46145 10/osl/trunk/boost/boost/token_functions.hpp:
adding boost by parts |
| 23:07.05 |
CIA-62 |
BRL-CAD:
03kunigami * r46146 10/osl/trunk/boost/boost/token_iterator.hpp:
adding boost by parts |
| 23:07.15 |
CIA-62 |
BRL-CAD:
03kunigami * r46147 10/osl/trunk/boost/boost/tokenizer.hpp: adding
boost by parts |
| 23:07.30 |
CIA-62 |
BRL-CAD:
03kunigami * r46148 10/osl/trunk/boost/boost/tr1/ (. detail/
detail/config.hpp detail/config_all.hpp memory.hpp): adding boost
by parts |
| 23:07.46 |
CIA-62 |
BRL-CAD:
03kunigami * r46149 10/osl/trunk/boost/boost/tuple/ (6 files in 2
dirs): adding boost by parts |
| 23:07.56 |
CIA-62 |
BRL-CAD:
03kunigami * r46150 10/osl/trunk/boost/boost/type.hpp: adding boost
by parts |
| 23:10.43 |
CIA-62 |
BRL-CAD:
03kunigami * r46151 10/osl/trunk/boost/boost/type_traits/ (121
files in 3 dirs): adding boost by parts |
| 23:11.00 |
CIA-62 |
BRL-CAD:
03kunigami * r46152 10/osl/trunk/boost/boost/type_traits.hpp:
adding boost by parts |
| 23:11.57 |
CIA-62 |
BRL-CAD:
03kunigami * r46153 10/osl/trunk/boost/boost/typeof/ (29 files in 3
dirs): adding boost by parts |
| 23:12.13 |
CIA-62 |
BRL-CAD:
03kunigami * r46154 10/osl/trunk/boost/boost/units/ (. detail/
detail/utility.hpp): adding boost by parts |
| 23:12.43 |
CIA-62 |
BRL-CAD:
03kunigami * r46155 10/osl/trunk/boost/boost/unordered/ (16 files
in 2 dirs): adding boost by parts |
| 23:12.52 |
CIA-62 |
BRL-CAD:
03kunigami * r46156 10/osl/trunk/boost/boost/unordered_map.hpp:
adding boost by parts |
| 23:13.03 |
CIA-62 |
BRL-CAD:
03kunigami * r46157 10/osl/trunk/boost/boost/unordered_set.hpp:
adding boost by parts |
| 23:13.34 |
CIA-62 |
BRL-CAD:
03kunigami * r46158 10/osl/trunk/boost/boost/utility/ (15 files in
2 dirs): adding boost by parts |
| 23:13.45 |
CIA-62 |
BRL-CAD:
03kunigami * r46159 10/osl/trunk/boost/boost/utility.hpp: adding
boost by parts |
| 23:13.57 |
CIA-62 |
BRL-CAD:
03kunigami * r46160 10/osl/trunk/boost/boost/version.hpp: adding
boost by parts |
| 23:14.05 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 23:14.07 |
CIA-62 |
BRL-CAD:
03kunigami * r46161 10/osl/trunk/boost/boost/visit_each.hpp: adding
boost by parts |
| 23:16.11 |
CIA-62 |
BRL-CAD:
03kunigami * r46162 10/osl/trunk/boost/boost/wave/ (62 files in 5
dirs): adding boost by parts |
| 23:16.21 |
CIA-62 |
BRL-CAD:
03kunigami * r46163 10/osl/trunk/boost/boost/wave.hpp: adding boost
by parts |
| 23:16.32 |
CIA-62 |
BRL-CAD:
03kunigami * r46164 10/osl/trunk/boost/boost/weak_ptr.hpp: adding
boost by parts |
| 23:24.12 |
CIA-62 |
BRL-CAD:
03kunigami * r46165 10/osl/trunk/boost/doc/ (. src/
src/minimal.css): adding boost by parts |
| 23:32.14 |
brlcad |
starseeker:
have you been hooking the new bbox funcs into prep? |
| 23:32.21 |
starseeker |
brlcad:
yeah |
| 23:32.24 |
brlcad |
cool |
| 23:32.25 |
starseeker |
where I
can |
| 23:51.21 |
CIA-62 |
BRL-CAD:
03kunigami * r46166 10/osl/trunk/boost/libs/ (481 files in 118
dirs): adding boost by parts |
| 23:52.56 |
CIA-62 |
BRL-CAD:
03kunigami * r46167 10/osl/trunk/boost/tools/: adding boost by
parts |
| 23:53.42 |
CIA-62 |
BRL-CAD:
03kunigami * r46168 10/osl/trunk/boost/tools/build/ (. boost.css
index.html v2/): adding boost by parts |
| 23:55.16 |
CIA-62 |
BRL-CAD:
03kunigami * r46169 10/osl/trunk/boost/tools/build/v2/ (21 files):
adding boost by parts |
| 23:58.51 |
``Erik |
O.o svn has a
builtin variant of .cvsignore? (the ringworld commit caught my
eye) |
| 00:00.25 |
CIA-62 |
BRL-CAD:
03kunigami * r46170 10/osl/trunk/boost/tools/build/v2/ (53 files in
6 dirs): adding boost by parts |
| 00:01.22 |
``Erik |
(a couple
people (slow committers) have asked why we aren't on git, any valid
argument?) |
| 00:02.40 |
CIA-62 |
BRL-CAD:
03starseeker * r46171 10/brlcad/trunk/src/librt/primitives/bot/
(bot.c g_bot_include.c): Whoops - shouldn't be resetting stp
here. |
| 00:04.36 |
CIA-62 |
BRL-CAD:
03starseeker * r46172 10/brlcad/trunk/src/librt/primitives/
(ars/ars.c table.c): It's not strictly necessary for prep as long
as we're using BoT internally for ars, but go ahead and add a bbox
routine for ars. |
| 00:05.22 |
starseeker |
``Erik: we
aim to have everybody committing to a common branch to avoid
"working in isolation" too much, as I understand it |
| 00:05.33 |
starseeker |
git makes it
much easier to wander off in a corner and work in
isolation |
| 00:06.10 |
``Erik |
that was my
thought, but I'd probably present it as "suck it up, stub it so it
compiles and commit a lot, stop whining" |
| 00:06.52 |
``Erik |
my two office
mates are reluctant to commit until they feel things are "done",
which throws away the continual peer review aspect |
| 00:07.39 |
starseeker |
nods - we've tried to discuss that with 'em before, but to no
avail |
| 00:08.14 |
starseeker |
wonders if he should bother with a bbox routine for poly -
I'm not even sure how I'd test it |
| 00:08.38 |
CIA-62 |
BRL-CAD:
03kunigami * r46173 10/osl/trunk/boost/tools/build/v2/ (283 files
in 38 dirs): adding boost by parts |
| 00:10.22 |
``Erik |
'poly'? |
| 00:10.47 |
``Erik |
open nmg,
basically? |
| 00:11.38 |
``Erik |
be easy to
write such a func, set max to -infinity, min to infinity, then for
each vertex, see if max{x,y,z} is bigger and min{x,y,z} is smaller,
update them as you go |
| 00:16.20 |
``Erik |
wanders off, hasta la pasta |
| 00:17.28 |
CIA-62 |
BRL-CAD:
03kunigami * r46174 10/osl/trunk/boost/tools/build/v2/test/ (365
files in 50 dirs): adding boost by parts |
| 00:22.13 |
CIA-62 |
BRL-CAD:
03kunigami * r46175 10/osl/trunk/boost/tools/build/v2/engine/ (99
files): adding boost by parts |
| 00:24.14 |
abhi2011 |
is anyone
able to compile with strict warnings on : cmake ../brlcad
-DBRLCAD_BUNDLED_LIBS=Bundled -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 00:24.16 |
CIA-62 |
BRL-CAD:
03kunigami * r46176 10/osl/trunk/boost/tools/build/v2/engine/ (14
files in 2 dirs): adding boost by parts |
| 00:24.57 |
abhi2011 |
i am still
getting the function prototype errors I was getting yesterday from
a fresh checkout :
/home/abhi/socis/brlcad/src/libged/inside.c:935:2: error: call to
function ‘rt_arb_get_cgtype’ without a real
prototype |
| 00:41.40 |
CIA-62 |
BRL-CAD:
03kunigami * r46177
10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/ (92 files):
adding boost by parts |
| 00:44.53 |
CIA-62 |
BRL-CAD:
03kunigami * r46178
10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/ (59 files in 5
dirs): adding boost by parts |
| 00:46.36 |
CIA-62 |
BRL-CAD:
03kunigami * r46179
10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/doc/ (37 files):
adding boost by parts |
| 00:47.39 |
CIA-62 |
BRL-CAD:
03kunigami * r46180 10/osl/trunk/boost/ (Jamroot boost-build.jam
boost.png bootstrap.sh): woot the last boost files |
| 00:50.52 |
CIA-62 |
BRL-CAD:
03kunigami * r46181 10/osl/trunk/compile.sh: added rule for boost
and osl - it remains fixing the destination dir of oiio and osl and
testing on another machine |
| 01:21.57 |
starseeker |
``Erik: oh, I
know it's easy to write but the primitive is an old one |
| 01:22.24 |
starseeker |
make and in
don't support it, so creating one would require a bit of
nonsense |
| 01:24.18 |
starseeker |
I can on
gentoo - what gcc/os are you using? |
| 01:25.15 |
CIA-62 |
BRL-CAD:
03bhinesley * r46182 10/brlcad/trunk/src/libged/edit.c: (log
message trimmed) |
| 01:25.15 |
CIA-62 |
BRL-CAD:
Started logging tests of translate options/args. Ex. of a more
complex set of |
| 01:25.15 |
CIA-62 |
BRL-CAD: args
that is working: "translate -a -x comb/combA 3 -z combB/combC 0 0
11 -y |
| 01:25.15 |
CIA-62 |
BRL-CAD:
combD/combE 0 7 combF/combG", which moves the instance of combG in
combF from |
| 01:25.15 |
CIA-62 |
BRL-CAD: it's
bounding box center to (x= apparent bb ctr of comb/combA offset 3
units), |
| 01:25.16 |
CIA-62 |
BRL-CAD: (y=
apparent bb ctr of combF/combG offset 7 units), (z= apparent bb ctr
of |
| 01:25.17 |
CIA-62 |
BRL-CAD:
combB/combC offset 11 units). Disable use of batch operator as an
argument to |
| 01:30.11 |
brlcad |
abhi2011: so
fix it :) |
| 01:30.38 |
brlcad |
for whatever
reason, nobody else is hitting that warning, making you the perfect
person to fix it |
| 01:32.15 |
brlcad |
starseeker:
poly was the precursor to BoT |
| 01:34.27 |
CIA-62 |
BRL-CAD:
03brlcad * r46183 10/brlcad/trunk/TODO: the hf and polysolid
primitives are both supplanted by newer more complete primitives
(half and BoT respectively), so mark them for removal in
rel8 |
| 01:35.02 |
abhi2011 |
yep I turned
of strict warnings :P |
| 01:35.35 |
brlcad |
abhi2011:
that's no fix :P |
| 01:35.46 |
brlcad |
you do
understand what that message means, yes? |
| 01:36.24 |
abhi2011 |
hehe yeah,
will look into it, though its strange that I am getting it for
almost every c function |
| 01:37.08 |
brlcad |
shouldn't
have to look into it .. should be obvious -- if it's not, then you
definitely should "fix" that warning |
| 01:37.29 |
brlcad |
prototype is
empty |
| 01:37.44 |
brlcad |
it wants a
real decl with the args listed |
| 01:37.58 |
brlcad |
decl is in
include/raytrace.h |
| 01:38.56 |
abhi2011 |
yes and I am
sure its included in the appropriate c file |
| 01:39.43 |
brlcad |
sure, but the
prototype is *empty* |
| 01:39.53 |
brlcad |
that's what
the compiler is warning you about |
| 01:40.10 |
brlcad |
make it be
not empty |
| 01:40.33 |
bhinesley |
abhi2011:
curious which gcc you're running |
| 01:40.48 |
abhi2011 |
yes, I can do
that, I am just wondering if its code being modified by someone
else |
| 01:41.19 |
abhi2011 |
brlcad:
4.5.1 20101208 |
| 01:41.53 |
CIA-62 |
BRL-CAD:
03brlcad * r46184 10/brlcad/trunk/TODO: need to include deprecation
output on the old build system as well as when creating (or perhaps
exporting) bspline/poly/hf primitives. |
| 01:42.30 |
brlcad |
abhi2011: no
entiendo.. "code being modified by someone else"? |
| 01:43.23 |
brlcad |
no code is
sacred, if code is found deficient, it gets
fixed/improved/refactored |
| 01:43.37 |
brlcad |
revision
control is our safety net |
| 01:44.48 |
abhi2011 |
brlcad: ok :)
, though I was wondering whats the compiler version you are
using |
| 01:45.11 |
abhi2011 |
because it
seems more like a compiler flag issue |
| 01:45.15 |
bhinesley |
abhi2011:
we're all over the place. I'm using 4.6 |
| 01:45.19 |
abhi2011 |
ok |
| 01:45.51 |
CIA-62 |
BRL-CAD:
03brlcad * r46185 10/brlcad/trunk/doc/deprecation.txt: |
| 01:45.51 |
CIA-62 |
BRL-CAD: they
were never officially documented as such, so do so now. mark the
bspline, |
| 01:45.51 |
CIA-62 |
BRL-CAD:
poly, and hf primitives as deprecated. as removing them is a rather
major |
| 01:45.51 |
CIA-62 |
BRL-CAD:
backwards-incompatible change, they're better suited to rel8 than
they are the |
| 01:45.51 |
CIA-62 |
BRL-CAD:
usual 3-minor release timeframe. they should be documented
somewhere |
| 01:45.52 |
CIA-62 |
BRL-CAD:
regardless. |
| 01:46.34 |
brlcad |
abhi2011: we
intentionally consider all warnings as errors for this exact
reason, so that the issues get fixed |
| 01:48.41 |
brlcad |
the compiler
usually issues warnings for pretty good reasons, so it's our
project stance to halt regardless of version or environment (unless
the issue is fundamentally unavoidable or a bug outside our control
that cannot be compensated for easily) |
| 01:49.47 |
starseeker |
brlcad: do we
have a tool to convert bspline/poly/hf primitives to their newer
versions? |
| 01:49.59 |
starseeker |
wonders if cline can also get chopped... |
| 01:50.19 |
brlcad |
starseeker:
nope |
| 01:50.22 |
abhi2011 |
brlcad: yes,
I understand that, the errors came for a huge number of functions
across multiple files, so I ll see if fixing one of them makes a
difference |
| 01:50.40 |
brlcad |
starseeker:
actually "yes" .. it just doesn't |
| 01:50.42 |
brlcad |
dbupgrade |
| 01:51.13 |
starseeker |
nods |
| 01:51.37 |
starseeker |
so that would
be added for a 5->6 upgrade? |
| 01:51.51 |
brlcad |
I added code
to run bspline through brep, worked well |
| 01:51.59 |
brlcad |
but the other
two are relics |
| 01:52.45 |
starseeker |
nods - but I'm guessing we still don't get to ignore 'em in
the upgrade path? |
| 01:52.59 |
brlcad |
shouldn't |
| 01:55.33 |
starseeker |
do we teach
dbupgrade to convert 'em now when run on a v5 file? |
| 01:57.29 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 02:03.50 |
CIA-62 |
BRL-CAD:
03bhinesley * r46186 10/brlcad/trunk/src/libged/edit.c: Simplify
iterating through arguments for execution of batch
commands. |
| 02:11.42 |
brlcad |
starseeker:
that would probably be okay |
| 02:12.52 |
brlcad |
presently
does nothing with v5 files, of course |
| 02:35.52 |
CIA-62 |
BRL-CAD:
03brlcad * r46187
10/brlcad/trunk/src/librt/primitives/table.c: |
| 02:35.52 |
CIA-62 |
BRL-CAD:
there's no need to intentionally make matters any harder for
ourselves than they |
| 02:35.52 |
CIA-62 |
BRL-CAD: need
to be, move the bbox routine to the end so we can reduce the risk
of |
| 02:35.52 |
CIA-62 |
BRL-CAD:
calling the wrong callback and crashing (or worse) if an older
library somehow |
| 02:35.52 |
CIA-62 |
BRL-CAD: got
linked. also didn't seem to be any particular grouping reason to
have it |
| 02:35.52 |
CIA-62 |
BRL-CAD:
between ifree/describe .. more closely related to prep and params,
which the |
| 02:35.53 |
CIA-62 |
BRL-CAD:
latter is conveniently at the end. |
| 02:36.35 |
CIA-62 |
BRL-CAD:
03brlcad * r46188 10/brlcad/trunk/include/raytrace.h: oops, this
file goes with r46187. move bbox to the end. |
| 02:37.00 |
brlcad |
starseeker:
you see tom's note? |
| 02:37.05 |
brlcad |
revenge of
the red |
| 02:40.42 |
CIA-62 |
BRL-CAD:
03brlcad * r46189 10/brlcad/trunk/src/libged/red.c: remove the
WARNING blather. all of the known red issues were fixed and are now
integrated into our release regression testing with a rather
extensive set of tests. |
| 03:04.47 |
abhi2011 |
ok I was
looking into the error: call to function ‘blahblah’ without a
real prototype , that I have been getting : it seems many(about 40+
functions, probably more) have been declared as follows Function(),
and overhauling all of them would involve updating a huge number of
files |
| 03:08.05 |
abhi2011 |
Not sure if
it would be a good idea to do that |
| 03:08.21 |
bhinesley |
$5 says that
it would be :) |
| 03:09.12 |
abhi2011 |
hehe :), well
I ll get started then |
| 03:09.38 |
bhinesley |
i'm really
curious as to why you're being alerted to these issues and not me
(and others?). As brlcad pointed out, at least with the first
warning, there is an actual problem that we can all observe; not
the result of some configuration issue on your end. |
| 03:10.32 |
bhinesley |
slight
differences in the compiler, I must assume |
| 03:10.42 |
abhi2011 |
well I am
using a standard cmake configuration : cmake ../brlcad
-DBRLCAD-ENABLE_STRICT=ON -DBRLCAD_BUNDLED_LIBS=Bundled
-DCMAKE_BUILD_TYPE=Debug
-DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 03:10.51 |
abhi2011 |
yes, the
funny thing is, it wasnt there last week |
| 03:11.01 |
abhi2011 |
exactly same
compiler |
| 03:11.25 |
bhinesley |
shrugs |
| 03:22.09 |
brlcad |
yeah, that's
the odd part |
| 03:22.51 |
brlcad |
I pulled
latest gcc svn (gcc 4.7) and don't get that warning, even though
it's clearly a valid warning with the dumb k&r declarations
being used |
| 03:24.19 |
brlcad |
abhi2011: so
yeah, it would be a great idea to fix them since you're the one
getting the reports .. but it's impossible that it's a "huge"
number of files :) |
| 03:24.48 |
brlcad |
40+ functions
would, at worst, be 40+ files .. that's quick n' easy, maybe 20 min
on a bad day :) |
| 03:25.18 |
brlcad |
more than
likely, it's 90% in raytrace.h |
| 03:27.08 |
CIA-62 |
BRL-CAD:
03brlcad * r46190 10/brlcad/trunk/TODO: report that rtcheck doesn't
work in previous release. probably the rt output bug, but warrants
a quick test before the next release. |
| 03:31.21 |
CIA-62 |
BRL-CAD:
03bhinesley * r46191 10/brlcad/trunk/src/libged/edit.c: (log
message trimmed) |
| 03:31.21 |
CIA-62 |
BRL-CAD:
Argument type flags were being cleared by mistake. This led to an
assert failure |
| 03:31.21 |
CIA-62 |
BRL-CAD: when
trying to calculate vectors, as there was no argument flagged
EDIT_FROM; |
| 03:31.22 |
CIA-62 |
BRL-CAD:
which should at least defaulted to something. The batch operator is
now working, |
| 03:31.22 |
CIA-62 |
BRL-CAD: at
least in the simple cases that I tried. Also, a variable tracking
the number |
| 03:31.22 |
CIA-62 |
BRL-CAD: of
arguments in a linked list was only incremented by 1 for each batch
operator, |
| 03:31.23 |
CIA-62 |
BRL-CAD:
rather than adding the number of target objects to the total. I
didn't observe |
| 03:31.44 |
bhinesley |
^-- amazing
the trouble a missing bit can cause |
| 03:41.04 |
CIA-62 |
BRL-CAD:
03bhinesley * r46192 10/brlcad/trunk/src/libged/edit.c: Error about
not yet supporting use of the batch operator to specify individual
coordinates was a bit overzealus. |
| 03:41.42 |
bhinesley |
yay, all
kinds of neat stuff works now |
| 03:53.06 |
brlcad |
heh |
| 03:53.10 |
brlcad |
awesome! |
| 03:53.39 |
brlcad |
bhinesley: so
you're soon to be on my radar to obtain deeper understanding of all
the changes you've made of lagte |
| 03:53.55 |
brlcad |
the code is
getting a bit complex for the task at hand |
| 03:54.52 |
brlcad |
but a bit
premature to comment other than "that's a lot of code!"
:) |
| 03:55.07 |
brlcad |
nice work on
tackling such a complex task |
| 04:00.17 |
bhinesley |
great, I look
forward to your comments/ideas |
| 04:04.47 |
bhinesley |
if I remove
incomplete scale/rotate stuff, there are 1176 LOC according to
cloc; and about as many lines in comments |
| 04:05.33 |
brlcad |
starseeker:
nmg bbox looks good to me on the surface, save for one issue -- an
empty nmg will likely crash, need to init vert_table |
| 04:06.41 |
brlcad |
bhinesley:
like I said, that's a lot of code (for something as basically
amounts to a xform call) :) |
| 04:07.06 |
brlcad |
the arg
processing probably begs refactoring |
| 04:07.11 |
bhinesley |
the translate
command is 158 LOC |
| 04:07.29 |
brlcad |
yeah, that's
more what I'd expect |
| 04:07.50 |
brlcad |
so there's a
ton of infrastructure around the meat of the matter |
| 04:07.57 |
brlcad |
not saying
that's good or bad, it is what it is |
| 04:08.09 |
bhinesley |
same
here |
| 04:08.43 |
brlcad |
it is,
however, a pretty strong cue that something probably needs to be
refactored |
| 04:09.37 |
bhinesley |
that's not
suprising. I've learned a lot (about brlcad and coding), and there
were a lot of suprises along the way. |
| 04:11.29 |
bhinesley |
I certainly
didn't expect it to take me this long |
| 04:11.37 |
bhinesley |
but there it
is |
| 04:17.21 |
brlcad |
yep |
| 04:18.14 |
brlcad |
hopefully you
stick to it too, there's a lot of interesting projects you could
cut your teeth on now that you've become a little familiar with the
code |
| 04:18.33 |
brlcad |
some a lot
more exciting that argument parsing ;) |
| 04:18.37 |
bhinesley |
hehe |
| 04:29.16 |
CIA-62 |
BRL-CAD:
03bhinesley * r46193 10/brlcad/trunk/src/libged/edit.c: These
arguments to translate work, since r46191/92. |
| 05:37.50 |
CIA-62 |
BRL-CAD:
0399.125.86.110 07http://brlcad.org
* r3079 10/wiki/User:Bhinesley: /* Log */ crossed out tasks, logged
today |
| 06:38.09 |
brlcad |
publishes the logo contest finalists |
| 06:38.15 |
brlcad |
waddles off into the night |
| 07:34.57 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 11:18.46 |
abhi2011 |
brlcad: yes,
I have begun modifying the k&r styles |
| 14:00.34 |
CIA-62 |
BRL-CAD:
03kunigami * r46194 10/osl/trunk/oiio/Makefile: modified the build
script a bit so that oiio exports to a default destination
install |
| 14:02.10 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 14:09.59 |
CIA-62 |
BRL-CAD:
03kunigami * r46195 10/osl/trunk/osl/ (Makefile
src/CMakeLists.txt): added missing make from osl root and also
turned off -werror |
| 14:11.35 |
CIA-62 |
BRL-CAD:
03kunigami * r46196 10/osl/trunk/compile.sh: now both osl and oiio
should be build on default dirs |
| 14:17.25 |
CIA-62 |
BRL-CAD:
03kunigami * r46197 10/osl/trunk/boost/boostcpp.jam: missing file
to build boost |
| 14:17.48 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 14:19.52 |
CIA-62 |
BRL-CAD:
03kunigami * r46198 10/osl/trunk/compile.sh: boost should be built
before oiio/osl |
| 14:51.32 |
CIA-62 |
BRL-CAD:
03starseeker * r46199
10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: initialize bu_ptbl
for nmg vert list in bbox routine. |
| 14:55.00 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 15:05.07 |
kunigami |
is there any
environment variable I can set so that cmake find_library will look
there too? |
| 15:10.48 |
``Erik |
mebbe
LD_LIBRARY_PATH ? |
| 15:13.13 |
kunigami |
hmm I tried
that, but didn't work. INut 'll check again |
| 15:19.04 |
kunigami |
nope. by the
way, I'm trying to call FindPNG module, but it's not setting
anything. I've build brlcad and so libpng was build on <brlcad
dest>/lib/, which is the path that I added to
LD_LIBRARY_PATH |
| 15:29.22 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 15:30.28 |
kunigami |
anyone having
problems with ITK_LBRARY not being found? |
| 15:34.43 |
brlcad |
abhi2011: so
version control 101 -- if you've been modifying them, then you
should be committing already |
| 15:35.20 |
brlcad |
fix one,
commit, fix another, commit -- at least per file |
| 15:35.52 |
brlcad |
waiting to
commit them all as one mega change is much harder to
review |
| 15:39.48 |
starseeker |
kunigami:
you're using a system itk? |
| 15:40.36 |
starseeker |
kunigami: I
believe the environment variable is CMAKE_LIBRARY_PATH |
| 15:58.13 |
CIA-62 |
BRL-CAD:
03r_weiss * r46200 10/brlcad/trunk/src/ (4 files in 4 dirs):
Updated files 'get_solid_kp.c', 'rec.c', 'tgc.c' and 'nmg.c' to
remove the compiler error/warning message 'ISO C90 forbids mixed
declarations and code'. |
| 16:00.02 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 16:02.48 |
kunigami |
starseeker:
I'm using -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON, so I believe it's
using from the source |
| 16:06.59 |
starseeker |
kunigami:
that option has changed - try
-DBRLCAD_BUNDLED_LIBS=Bundled |
| 16:07.05 |
kunigami |
starseeker:
thanks, that name led me to the CMAKE_PREFIX_PATH |
| 16:07.19 |
kunigami |
starseeker:
oh, |
| 16:10.43 |
kunigami |
hmm, no, the
error remains |
| 16:10.56 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46201 10/brlcad/trunk/src/librt/bbox.c: Updated librt
function for finding bb from rt_db_internal |
| 16:20.29 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46202 10/brlcad/trunk/include/raytrace.h: Updated
declaration for the bb function as well |
| 16:28.52 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46203 10/brlcad/trunk/src/fb/fb-orle.c: Filled in
empty K&R style prototypes with the parameter
datatypes |
| 16:29.41 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46204 10/brlcad/trunk/include/orle.h: Filled in empty
K&R style prototypes with the parameter datatypes |
| 16:31.37 |
kunigami |
damn |
| 16:32.17 |
abhi2011 |
there appears
to be 2 structures in use in libfb with exactly the same definition
: struct ColorMap and struct RLEColorMap |
| 16:33.19 |
abhi2011 |
kunigami: I
was getting the itk error 2 days ago, but a clean checkout and the
bundled options helped compile it successfully |
| 16:33.55 |
kunigami |
I had
mistyped the command to DBRLCAD-BUNDLED_LIBS=Bundled sorry
:( |
| 16:34.09 |
abhi2011 |
:) |
| 16:36.13 |
abhi2011 |
and strangely
some of the functions in libfb are defined with struct RLEColorMap
* but are passed struct ColorMap * , leading to a lot of
warnings |
| 16:37.10 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 16:40.07 |
starseeker |
abhi2011,
kunigami: if you guys can use cmake-gui, it will show you the most
common "user" options |
| 16:50.53 |
CIA-62 |
BRL-CAD:
03starseeker * r46205 10/brlcad/trunk/src/librt/primitives/
(poly/poly.c table.c): add a bbox routine for poly - pretty minimal
shifting of the logic, as this is on its way out
anyway. |
| 16:54.11 |
kunigami |
starseeker:
do you know if it is available for mac? |
| 16:55.55 |
brlcad |
abhi2011: why
did you add fb.h to orle.h ? |
| 16:56.14 |
brlcad |
orle
shouldn't need fb.h iirc |
| 16:57.08 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 16:58.39 |
CIA-62 |
BRL-CAD:
03brlcad * r46206 10/brlcad/trunk/src/fb/ (cmap-crunch.c fb-cmap.c
fb-orle.c fbpoint.c): remove authors, revision control tracks
actual authorship |
| 17:00.31 |
bhinesley |
kunigami: not
sure about your question, but fyi the curses version, ccmake, will
achieved the same end |
| 17:03.49 |
kunigami |
bhinesley:
I'll take a look on that. thanks! |
| 17:07.23 |
abhi2011 |
brlcad: that
was to allow the declaration of struct ColorMap to be available, I
had modified the declaration of rle_wmap() to be rle_wmap(FILE *,
ColorMap *); as a ColorMap* was being passed to it in
fb-orle.c |
| 17:07.46 |
abhi2011 |
But i later
changed it to rle_wmap(FILE *, RLEColorMap *); |
| 17:08.06 |
abhi2011 |
when I
checked the definition of rle_wmap() |
| 17:08.32 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 17:09.00 |
CIA-62 |
BRL-CAD:
03brlcad * r46207 10/brlcad/trunk/src/fb/fb-orle.c: the structures
are just coincidentally the same, so we need to copy the color map
values before passing to rle_wmap. if fbio's structure ever
changed, the hard cast would have been a potentially nasty bug to
diagnose. |
| 17:09.22 |
abhi2011 |
So my
question is I do get a lot of warnings (which of course are treated
as errors), wherever a struct RLEColorMap * should be passed
instead of struct ColorMap* |
| 17:09.26 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 17:10.45 |
abhi2011 |
brlcad: ok so
I can copy the struct ColorMap values to a struct RLEColorMap
instead and pass a struct RLEColorMap* as expected |
| 17:13.09 |
CIA-62 |
BRL-CAD:
03brlcad * r46208 10/brlcad/trunk/src/fb/ (cmap-crunch.c fb-cmap.c
fb-orle.c fb-rle.c): ws indent style cleanup |
| 17:13.31 |
brlcad |
abhi2011:
yeah, that's probably better |
| 17:13.37 |
abhi2011 |
ok |
| 17:13.52 |
brlcad |
I'm actually
not 100% positive that they're actually compatible too, but that's
how the code is presently written |
| 17:14.02 |
brlcad |
the new rle
color maps have a different ordering iirc |
| 17:14.59 |
CIA-62 |
BRL-CAD:
03brlcad * r46209 10/brlcad/trunk/include/orle.h: shouldn't need
fb.h here |
| 17:16.24 |
brlcad |
abhi2011:
coincidentally, that's why the compiler warnings are a good thing
-- we wouldn't have known that a struct was being implicitly
converted until the arg list was added to the function
prototype |
| 17:17.31 |
CIA-62 |
BRL-CAD:
03kunigami * r46210 10/osl/trunk/jpeg-8c/ (180 files): oiio also
depends on jpge |
| 17:17.45 |
starseeker |
kunigami:
cmake? sure |
| 17:17.46 |
abhi2011 |
brlcad: ok I
ll explicitly specify the struct members while copying instead of a
plain A = B |
| 17:19.19 |
starseeker |
kunigami:
http://www.cmake.org/files/v2.8/cmake-2.8.5-Darwin-universal.dmg |
| 17:23.41 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 17:29.04 |
brlcad |
kunigami:
heh, the list just keeps growing :) |
| 17:29.29 |
kunigami |
brlcad:
libtiff is coming too! |
| 17:29.33 |
brlcad |
:) |
| 17:30.38 |
brlcad |
kunigami:
it's a good thing OSL is actually worth it ... can't wait to see a
full detail rendering run over a weekend |
| 17:31.06 |
kunigami |
brlcad:
:) |
| 17:31.08 |
starseeker |
isn't sure if brlcad is making an assertion or a challenge
:-P |
| 17:31.18 |
kunigami |
hehe |
| 17:32.46 |
CIA-62 |
BRL-CAD:
03starseeker * r46211 10/brlcad/trunk/src/librt/primitives/
(bspline/bspline.cpp table.c): Take a stab at a bbox routine for
brep. Like poly, not going to put much effort into this one - in
this can't won't even hook it into prep. |
| 17:33.10 |
starseeker |
hmm
s/can't/case |
| 17:33.42 |
brlcad |
and
s/brep/bspline/ |
| 17:34.03 |
starseeker |
er,
yeah |
| 17:34.37 |
brlcad |
is excited, actually getting 3D geometry for the
logo |
| 17:34.49 |
brlcad |
though that
will be fun to model in BRL-CAD |
| 17:37.34 |
kunigami |
by far, the
thing that is taking more time is to add entries on
subversion/config of files without extension :( |
| 17:37.57 |
starseeker |
kunigami:
yep, always a problem when adding an external repo |
| 17:38.48 |
brlcad |
kunigami:
write a script? |
| 17:39.00 |
brlcad |
they're all
header files, no? |
| 17:39.06 |
starseeker |
notes that the moose is out, abstract art is in
;-) |
| 17:39.38 |
kunigami |
brlcad: I
wrote a script to tell which files are not covered by config before
adding them https://gist.github.com/1150253 |
| 17:39.42 |
brlcad |
the moose
isn't necessarily out, but the other won had considerably more
votes |
| 17:39.51 |
brlcad |
s/won/one/
jessh |
| 17:40.19 |
kunigami |
maybe I can
assume a default (svn:eol-style=native;svn:mime-type=text/plain) in
those cases |
| 17:41.08 |
brlcad |
maybe I'm
missing something, but you should be able to add most all of boost
with a 'find' command one-liner |
| 17:42.28 |
brlcad |
starseeker: I
think what'll amount to is a mix -- the moose is still the mascot,
just the logo doesn't necessarily refer to it |
| 17:42.38 |
starseeker |
nods |
| 17:42.41 |
brlcad |
like how
redhat's is a hat, even though the mascot is a penguin |
| 17:43.00 |
brlcad |
or ubuntu
with the three holding hands |
| 17:43.51 |
bhinesley |
what could
cause the compiler to warn about variables as being "set but not
used", when they are in fact set and used (in rec.c
vars:magsq_c/magsq_d)? |
| 17:44.11 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 17:44.52 |
bhinesley |
oh gosh, n/m
I was in the wrong function with the same vars |
| 17:45.12 |
starseeker |
bhinesley:
that's a consequence of the bbox function logic moving |
| 17:45.13 |
brlcad |
kunigami: cp
boost /path/to/svn/boost ; cd /path/to/svn ; find boost -type d
-exec svn add {} \; -type f -exec svn add {} \; -exec svn ps
svn:eol-style native {} \; -exec svn ps svn:mime-type text/plain {}
\; |
| 17:45.23 |
brlcad |
something
like that at least, should do the trick |
| 17:45.26 |
starseeker |
magsq_c and
magsq_d are apparently not used in prep now |
| 17:45.33 |
kunigami |
brlcad: now
I'm not sure we're talking about the same things. Here are the
files of libtiff that svn won't know how to set
mime-type/eol-style: http://paste.ubuntu.com/668472/ |
| 17:46.31 |
brlcad |
yeah, so I'd
just take that list as-is, set them as text/plain and move on
:) |
| 17:47.17 |
brlcad |
cat log | awk
'{print $4}' | xargs svn ps svn:eol-style native |
| 17:47.18 |
brlcad |
<PROTECTED> |
| 17:47.21 |
CIA-62 |
BRL-CAD:
03starseeker * r46212
10/brlcad/trunk/src/librt/primitives/rec/rec.c: compilers should be
happy. |
| 17:48.06 |
kunigami |
hmmm I didn't
know that it was a command to set it. I was editing the config file
manually >.< |
| 17:49.24 |
bhinesley |
starseeker:
yeah sorry, I would have removed them but went to the wrong
function and it looked fine :-| |
| 17:49.37 |
starseeker |
np - my
fault, it was my change |
| 17:49.51 |
bhinesley |
ah |
| 17:50.17 |
starseeker |
is extracting bounding box logic from prep routines -
occasionally messy |
| 17:52.36 |
brlcad |
kunigami: oh
dear!... |
| 17:53.18 |
brlcad |
kunigami:
http://brlcad.org/wiki/Mime-types |
| 17:53.38 |
brlcad |
specifically,
the part near the end |
| 17:54.06 |
kunigami |
I should have
read past the 5th line too :( |
| 18:03.22 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 18:07.17 |
CIA-62 |
BRL-CAD:
03starseeker * r46213 10/brlcad/trunk/src/librt/primitives/
(ebm/ebm.c table.c): ebm bbox routine. |
| 18:14.46 |
CIA-62 |
BRL-CAD:
03starseeker * r46214 10/brlcad/trunk/src/librt/primitives/
(table.c vol/vol.c): vol is basically a variation on ebm as far as
bbox goes. |
| 18:16.37 |
CIA-62 |
BRL-CAD:
03bhinesley * r46215 10/brlcad/trunk/src/libged/edit.c: |
| 18:16.37 |
CIA-62 |
BRL-CAD:
Testing "translate -k -x 3 -a -y 5 shp" revealed that the default
"to" points |
| 18:16.37 |
CIA-62 |
BRL-CAD: (ex:
x/z of -a) were being set to shp's bb-ctr, rather than the kp
specified |
| 18:16.37 |
CIA-62 |
BRL-CAD: with
-k (which in turn defaults points to the bb-ctr of shp). That cmd
should |
| 18:16.37 |
CIA-62 |
BRL-CAD: move
the bb-ctr of shp to y=5 and not change its x/z pos (the -k part
is |
| 18:16.38 |
CIA-62 |
BRL-CAD:
superflous). It was moving the y-axis, but was also moving on the
x-axis an |
| 18:16.39 |
CIA-62 |
BRL-CAD:
amount equal to the difference between the bb ctr of shp and
x=3. |
| 18:17.03 |
brlcad |
starseeker:
the good news is that all counts towards GS/GE work |
| 18:17.34 |
*** join/#brlcad nsd_
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 18:21.38 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 18:32.03 |
starseeker |
brlcad:
question - looking at bn_tol in bn.h, the comments say double perp;
/**< @brief nearly 0 */ but BN_VECT_ARE_PARALLEL is doing
NEAR_EQUAL comparisions between _tol->perp and -1.0/1.0. Won't
those always be false? |
| 18:44.58 |
CIA-62 |
BRL-CAD:
03kunigami * r46216 10/osl/trunk/tiff-3.9.5/ (447 files in 26
dirs): oiio also depends on tiff |
| 18:51.02 |
brlcad |
starseeker: I
believe the comment is misleading |
| 18:52.32 |
bhinesley |
starts cracking on docbook |
| 18:53.08 |
brlcad |
starseeker:
oh, my bad -- it's right |
| 18:53.19 |
CIA-62 |
BRL-CAD:
03kunigami * r46217 10/osl/trunk/compile.sh: added rules for jpeg
and tiff |
| 18:54.07 |
brlcad |
perp is close
to zero, the comparison isn't between tol->perp and -1.0/1.0 ..
it's between the dot product value and -1/1 .. within a
tol->perp near-zero tolerance |
| 18:55.19 |
brlcad |
since the dot
product is already range clamped, the tight distance tolerance
becomes too tight.. you want a different tolerance close to zero
but bigger than SMALL_FASTF, probably even bigger than
0.0005 |
| 18:56.18 |
brlcad |
interestingly
enough, looks like it's 1e-6 in most places I can find |
| 18:56.53 |
starseeker |
there's an
RT_DOT_TOL in the header, but I'm not sure it's used |
| 18:57.09 |
brlcad |
hm, 0 in some
places 0.001 (which feels right) in others, and 1e-6 in most places
(feels too tight) |
| 18:57.51 |
brlcad |
heh, nice
relevant comment in libbn/plane.c |
| 18:57.57 |
brlcad |
<PROTECTED> |
| 18:57.58 |
CIA-62 |
BRL-CAD:
03starseeker * r46218 10/brlcad/trunk/src/librt/primitives/
(arbn/arbn.c table.c): |
| 18:57.59 |
CIA-62 |
BRL-CAD: Make
a stab at arbn bbox. This is another one where prep won't call the
bbox |
| 18:57.59 |
CIA-62 |
BRL-CAD:
routine directly, since it needs the same work for other stuff.
Tried to pix |
| 18:57.59 |
CIA-62 |
BRL-CAD:
sensible defaults for tolerances, since we don't pass a tolerance
into this |
| 18:57.59 |
CIA-62 |
BRL-CAD:
function. |
| 18:58.47 |
brlcad |
looks like
RT_DOT_TOL isn't used |
| 18:59.01 |
starseeker |
growl. It
should be |
| 18:59.20 |
brlcad |
used during
typein |
| 18:59.27 |
brlcad |
for hyp and
ehy |
| 18:59.40 |
starseeker |
needs something in the arbn bbox routine |
| 18:59.53 |
starseeker |
sure don't
want to hardcode a number |
| 19:00.20 |
brlcad |
looks like
cline, ehy, epa, hyp, nmg, red, revolve, rhc, rpc, and tgc use
RT_DOT_TOL internally |
| 19:00.44 |
brlcad |
so it is
used.. just probably not in all the places it should |
| 19:00.52 |
starseeker |
nods |
| 19:03.33 |
starseeker |
yipe - pipe
bbox is going to be a bit of fun |
| 19:07.06 |
bhinesley |
s/yipe/yipee |
| 19:07.41 |
brlcad |
starseeker:
just call bbox on all the individual tgc and sph
elements |
| 19:07.49 |
brlcad |
er,
tor |
| 19:08.22 |
starseeker |
brlcad:
actually, as I'm digging in it looks like there's already some more
or less split out functionality for this |
| 19:08.33 |
brlcad |
hm,
okay |
| 19:08.51 |
starseeker |
rt_bend_pipe_prep deals pretty much
entirely with per-bend bbox issues,fromt he looks of it - just a
head insertion at the end |
| 19:09.31 |
starseeker |
oh, wait -
hmm |
| 19:09.38 |
starseeker |
scratch that,
it is mixed abit |
| 19:10.29 |
starseeker |
that bp
struct is not a throwaway |
| 19:11.08 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 19:11.34 |
starseeker |
and we do
need this logic, otherwise it becomes possible (I think) to create
pipes with really really bad bboxes |
| 19:16.40 |
CIA-62 |
BRL-CAD:
03r_weiss * r46219 10/brlcad/trunk/src/libbn/plane.c: (log message
trimmed) |
| 19:16.41 |
CIA-62 |
BRL-CAD:
Within file 'plane.c' updated functions 'bn_coplanar',
'bn_isect_2planes' and |
| 19:16.41 |
CIA-62 |
BRL-CAD:
'bn_isect_lseg3_lseg3_new'. Corrected a bug in 'bn_coplanar' when
computing the |
| 19:16.41 |
CIA-62 |
BRL-CAD:
distance between planes. Within function 'bn_isect_2planes' changed
some |
| 19:16.41 |
CIA-62 |
BRL-CAD:
floating point compares from zero to SMALL_FASTF and improved the
comments. |
| 19:16.41 |
CIA-62 |
BRL-CAD:
Within 'bn_isect_lseg3_lseg3_new' fixed a bug when line segments
are colinear |
| 19:16.42 |
CIA-62 |
BRL-CAD: and
the intersection in on the end point(s), the clamping of the exact
end point |
| 19:40.18 |
brlcad |
now that's
some good stuff |
| 19:40.49 |
brlcad |
r_weiss
should get to more nitty gritty libbn review like that instead of
futzing with nmg! |
| 19:41.08 |
brlcad |
someone
should go pat him on the back, that's more like it :) |
| 19:42.23 |
brlcad |
except for
the whole bn_isect_lseg3_lseg3_new() |
| 19:44.11 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:50.40 |
CIA-62 |
BRL-CAD:
03r_weiss * r46220
10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: Updated
function 'nmg_ck_vert_on_fus' within file 'nmg_misc.c'. Simplified
logic, did some code cleanup. Removed an unnecessary floating point
compare to zero. |
| 20:09.18 |
CIA-62 |
BRL-CAD:
03kunigami * r46221 10/osl/trunk/compile.sh: oiio will add /dist,
no need to do that with $prefix |
| 20:17.03 |
CIA-62 |
BRL-CAD:
03starseeker * r46222
10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: Richard pointed out
a pre-existing nmg bounding box function - use that. |
| 20:22.42 |
bhinesley |
considers investigating how much work it would be to get
linkends between manual pages working |
| 20:24.34 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 20:28.34 |
CIA-62 |
BRL-CAD:
03bhinesley * r46223 10/brlcad/trunk/doc/docbook/system/mann/en/
(CMakeLists.txt Makefile.am translate.xml): Add placeholders for
edit/translate commands |
| 20:29.07 |
bhinesley |
oops |
| 20:33.17 |
CIA-62 |
BRL-CAD:
03bhinesley * r46224 10/brlcad/trunk/doc/docbook/system/mann/en/
(edit.xml translate.xml): Overwrote translate.xml last commit...
reverting and adding edit |
| 20:55.35 |
CIA-62 |
BRL-CAD:
03bhinesley * r46225 10/brlcad/trunk/doc/docbook/system/mann/en/
(CMakeLists.txt Makefile.am edit-translate.xml): |
| 20:55.35 |
CIA-62 |
BRL-CAD:
Unless mged's translate command is deprecated, we'll need two sets
of |
| 20:55.35 |
CIA-62 |
BRL-CAD:
"translate" manuals. Name the new page "edit translate", where the
command will |
| 20:55.35 |
CIA-62 |
BRL-CAD:
display the page. Don't mention the Archer alias "translate", since
the same man |
| 20:55.35 |
CIA-62 |
BRL-CAD: page
will be seen in mged. |
| 20:56.16 |
CIA-62 |
BRL-CAD:
03r_weiss * r46226
10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: |
| 20:56.16 |
CIA-62 |
BRL-CAD:
Added a new function 'nmg_isect_2faceuse' to file 'nmg_inter.c'
which finds the |
| 20:56.16 |
CIA-62 |
BRL-CAD:
intersection line between two faceuse. This new function is based
on function |
| 20:56.16 |
CIA-62 |
BRL-CAD:
bn_isect_2planes but can better determine coplanar and parallel
faceuse because |
| 20:56.18 |
CIA-62 |
BRL-CAD:
vertex distances to the faceuse planes are used instead of the
angle between the |
| 20:56.18 |
CIA-62 |
BRL-CAD:
planes and the distance between the planes at their point closest
to the origin. |
| 21:19.29 |
CIA-62 |
BRL-CAD:
03n_reed * r46227 10/brlcad/trunk/src/conv/obj-g_new.c: minor style
and ws changes |
| 21:25.17 |
CIA-62 |
BRL-CAD:
03n_reed * r46228 10/brlcad/trunk/src/libgcv/wfobj/obj_parser.cpp:
minor readability changes |
| 21:38.22 |
CIA-62 |
BRL-CAD:
03n_reed * r46229 10/brlcad/trunk/src/libgcv/wfobj/
(obj_grammar.h.in obj_grammar.yy obj_grammar.yy obj_rules.ll):
Replaced Bison parser input with Lemon parser input. Parser gives
identical output for a lot of input obj files, but there are still
some discrepancies that need to get worked out. |
| 21:39.26 |
brlcad |
woot! |
| 21:45.17 |
CIA-62 |
BRL-CAD:
03starseeker * r46230 10/brlcad/trunk/src/librt/primitives/
(rpc/rpc.c table.c): Add rpc bbox routine - while we're at it, make
a tighter bbox instead of bounding the bounding sphere. |
| 21:46.14 |
starseeker |
go
n_reed! |
| 21:48.55 |
CIA-62 |
BRL-CAD:
03bhinesley * r46231 10/brlcad/trunk/src/libged/edit.c: |
| 21:48.55 |
CIA-62 |
BRL-CAD: I've
been using the "translate" alias to test, so I didn't notice that
the |
| 21:48.55 |
CIA-62 |
BRL-CAD:
calling the edit command directly was recently broken. It was
trying to call |
| 21:48.55 |
CIA-62 |
BRL-CAD:
subcommand functions of the edit help command, which don't exist.
Fixed other |
| 21:48.55 |
CIA-62 |
BRL-CAD:
small problems with the help system. I replaced some 1-off goto's
with the code |
| 21:48.56 |
CIA-62 |
BRL-CAD: they
were redirecting to, to please the Lords of Kobol. |
| 21:50.00 |
CIA-62 |
BRL-CAD:
03r_weiss * r46232
10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: |
| 21:50.00 |
CIA-62 |
BRL-CAD:
Within file 'nmg_inter.c' updated function
'nmg_isect_two_generic_faces' and |
| 21:50.00 |
CIA-62 |
BRL-CAD:
disabled functions 'nmg_isect_nearly_coplanar_faces'
and |
| 21:50.00 |
CIA-62 |
BRL-CAD:
'nmg_isect_coplanar_edges' to quiet compiler errors/warnings
because they are no |
| 21:50.00 |
CIA-62 |
BRL-CAD:
longer used. Simplified the function 'nmg_isect_two_generic_faces'
which was |
| 21:50.00 |
CIA-62 |
BRL-CAD:
possible by using the new function
'nmg_isect_2faceuse'. |
| 21:55.14 |
CIA-62 |
BRL-CAD:
03r_weiss * r46233 10/brlcad/trunk/include/raytrace.h: Updated
include file 'raytrace.h' to add the new function
'nmg_isect_2faceuse'. |
| 21:56.47 |
CIA-62 |
BRL-CAD:
03starseeker * r46234
10/brlcad/trunk/src/librt/primitives/rpc/rpc.c: comment doesn't
apply anymore |
| 22:02.14 |
CIA-62 |
BRL-CAD:
03r_weiss * r46235 10/brlcad/trunk/src/librt/bbox.c: Updated file
'bbox.c' to stop compiler errors. |
| 22:14.48 |
starseeker |
wonders if smaller rpc bounding boxes are technically user
visible... |
| 22:14.56 |
starseeker |
may have
minor raytrace consequences |
| 22:49.42 |
CIA-62 |
BRL-CAD:
03r_weiss * r46236
10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated
function 'nmg_ck_fu_verts' in file 'nmg_fuse.c'. Fixed a bug which
caused a seg fault if a loopuse contained a single vertex instead
of an edgeuse. Also did some code cleanup. |
| 22:51.38 |
CIA-62 |
BRL-CAD:
03kunigami * r46237
10/osl/trunk/boost/boost/math/policies/error_handling.hpp:
workaround to resolve the problem with -fno-rtti and typeid. I've
commented out... it wont change the logic of the program since
typeid was only used to compose a print message |
| 22:52.31 |
CIA-62 |
BRL-CAD:
03kunigami * r46238 10/osl/trunk/compile.sh: osl was being wrongly
build in /dest/dest/ |
| 00:26.06 |
CIA-62 |
BRL-CAD:
03kunigami * r46239 10/brlcad/trunk/src/liboptical/ (render_svc.cpp
render_svc.h): the osl that I commited on svn defines a few more
pure virtual functions. added definitons for these functions
copying from /osl/src/testshade/ |
| 01:33.06 |
abhi2011 |
brlcad:
regarding the bb function in librt, there was a issue with
wdb_put_internal() always freeing the passed rt_db_internal
* |
| 01:33.28 |
abhi2011 |
well making
the rt_db_internal * parameter constant makes no
difference |
| 01:34.39 |
abhi2011 |
the compiler
discards the const qualifier and throws a warning : warning:
passing argument 3 of ‘wdb_put_internal’ discards qualifiers
from pointer target type , which is due to the same parameter not
being declarared as const in wdb_put_internal() |
| 01:35.45 |
abhi2011 |
so I
currently allow it to be freed and look it up again afterwards
using db_lookup() and rt_db_get_internal() |
| 01:37.28 |
abhi2011 |
however after
this, when I try to walk the tree for a combination, using
db_functree(dbip, dp, comb_func, leaf_func, &rt_uniresource,
NULL) the comb_func gets called as expected when the combination is
detected |
| 01:37.54 |
abhi2011 |
but the
leaf_func for the leaves of the combination, is not
called |
| 01:40.16 |
abhi2011 |
instead
db_lookup() reports missing primitives, so I don't think the
primitives' information is still available for adding to the in-mem
dbip , using db_functree() |
| 01:43.04 |
abhi2011 |
here is the
modified code : http://bin.cakephp.org/view/1374634731
not committed yet as it does not work yet |
| 02:11.55 |
bhinesley |
abhi2011: it
doesn't have to work to commit, it just has to build
strict |
| 02:29.05 |
bhinesley |
abhi2011:
there must not be any solids in your combination |
| 02:35.17 |
bhinesley |
redacts his last statement |
| 02:35.47 |
bhinesley |
I don't know
what's happening, so personally, I would examine the tree in
gdb |
| 04:07.36 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 06:56.10 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 07:44.25 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 09:51.45 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 10:34.10 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 10:40.29 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 11:41.44 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 11:44.45 |
*** join/#brlcad juanman
(~quassel@201.255.22.2) |
| 11:44.51 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 11:57.49 |
kunigami |
is it
possible to a script permanently set an environment variable? after
building osl I'd like brl-cad to know where it is installed. any
other option to do that? (maybe a config file...) |
| 11:59.35 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 12:07.34 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 12:09.39 |
starseeker |
kunigami:
which part of BRL-CAD needs to know where osl is? |
| 12:10.35 |
kunigami |
starseeker:
the cmake at liboptical and at other/osl/shaders |
| 12:15.27 |
CIA-62 |
BRL-CAD:
03kunigami * r46240 10/osl/trunk/compile.sh: added option to
compile each library alone |
| 12:15.43 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 12:49.09 |
starseeker |
kunigami: I'd
suggest looking at what we do for the src/other
libraries |
| 12:49.44 |
starseeker |
however, if
it's always going to be installed first, you probably want
find_library |
| 12:50.01 |
starseeker |
or write a
FindOSL.cmake file |
| 12:56.44 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 12:56.46 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:09.00 |
CIA-62 |
BRL-CAD:
03tbrowder2 * r46241 10/brlcad/trunk/sh/conversion.sh: added an
OPATH (object path); added 's' to seconds displays; wrapped a long
line for ease of checking output format |
| 13:09.38 |
CIA-62 |
BRL-CAD:
03tbrowder2 * r46242 10/brlcad/trunk/NEWS: updated for change to
conversion.sh |
| 13:10.18 |
CIA-62 |
BRL-CAD:
03tbrowder2 * r46243 10/brlcad/trunk/NEWS: corrected my last
entry |
| 13:11.07 |
CIA-62 |
BRL-CAD:
03tbrowder2 * r46244 10/brlcad/trunk/NEWS: wrapped overflowing
entry |
| 13:22.58 |
kunigami |
starseeker:
but src/other libraries are build together with brl-cad, so it can
set cmake variables that brl-cad sees. osl is build separately and
is not necessarily build in any default place or a fixed place
relative to brl-cad, so unless osl itself informs cmake, I don't
see how find_library or FindOSL would be able to find
it |
| 13:41.25 |
CIA-62 |
BRL-CAD:
03kunigami * r46245 10/osl/trunk/openexr/configure: missing pthread
flag on tests |
| 13:42.51 |
CIA-62 |
BRL-CAD:
03kunigami * r46246 10/osl/trunk/openexr/exrenvmap/main.cpp:
missing string.h library |
| 13:43.25 |
CIA-62 |
BRL-CAD:
03kunigami * r46247 10/osl/trunk/openexr/exrmaketiled/main.cpp:
missing string.h library |
| 13:44.56 |
CIA-62 |
BRL-CAD:
03kunigami * r46248
10/osl/trunk/oiio/src/ico.imageio/icooutput.cpp: missing zlib.h
header |
| 14:15.15 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 15:06.46 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 15:06.54 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 15:13.45 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 15:24.24 |
starseeker |
FindOSL would
work like any other find_package file |
| 15:24.40 |
starseeker |
assuming
you're installing osl somewhere standard |
| 15:31.31 |
dli |
starseeker,
what does this mean? http://pastebin.com/hHMAsVYd |
| 15:45.07 |
starseeker |
dli: I can't
see that site - can you use another pastebin? (mozilla's should
work) |
| 15:45.37 |
dli |
starseeker,
never mind, I guess it's due to gentoo cmake-utils eclass changes,
fixed already |
| 15:45.51 |
starseeker |
cool |
| 15:46.29 |
dli |
starseeker,
pushed to overlay, when will 7.20.4 be released? |
| 15:46.52 |
dli |
starseeker,
either I should try to make cmake work for 7.20.2 or just wait for
7.20.4 |
| 16:02.36 |
starseeker |
would recommend waiting for 7.20.5 |
| 16:02.40 |
starseeker |
er
7.20.4 |
| 16:03.03 |
CIA-62 |
BRL-CAD:
03starseeker * r46249 10/brlcad/trunk/src/librt/primitives/
(part/part.c table.c): Add a bbox routine for part |
| 16:06.30 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 16:06.47 |
CIA-62 |
BRL-CAD:
03starseeker * r46250 10/brlcad/trunk/NEWS: Tightened the bounding
boxes for rpc primitives, particularly axis aligned rpcs - should
slightly speed up rpc raytracing. |
| 16:10.31 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 16:16.58 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 16:20.17 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 16:22.46 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 16:30.23 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 17:28.58 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 17:33.13 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 17:42.05 |
CIA-62 |
BRL-CAD:
03kunigami * r46251
10/osl/trunk/osl/src/cmake/externalpackages.cmake: on ubuntu, llvm
is installed in /usr/lib/llvm-2.8/include - how to specify this
path to cmake such that it works for any library
version? |
| 17:42.47 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 17:52.18 |
CIA-62 |
BRL-CAD:
03starseeker * r46252 10/brlcad/trunk/ (3 files in 3 dirs): epa
bbox routine - also improved bounding boxes for epa, similar
arrangement to the rpc. |
| 18:02.18 |
CIA-62 |
BRL-CAD:
03starseeker * r46253 10/brlcad/trunk/ (3 files in 3 dirs): Add
improved bounding box logic for ehy, based on epa
improvements. |
| 18:08.08 |
kunigami |
I'd like to
use svn external do bring libz and libpng together with osl. Is it
"svn propset svn:external
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/other/libz
osl" ? |
| 18:18.20 |
kunigami |
command that
worked: svn propset svn:externals 'https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/other/libz
libz' . |
| 18:22.39 |
CIA-62 |
BRL-CAD:
03starseeker * r46254 10/brlcad/trunk/src/librt/primitives/
(eto/eto.c table.c): Add bbox routine for eto. |
| 18:24.36 |
CIA-62 |
BRL-CAD:
03n_reed * r46255 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.yy
obj_parser.cpp obj_parser_state.h): storing lemon parser-handle in
combined state object |
| 18:30.50 |
CIA-62 |
BRL-CAD:
03kunigami * r46256 10/osl/trunk/: adding libz and libpng as
external dependence of osl/trunk |
| 18:41.52 |
CIA-62 |
BRL-CAD:
03kunigami * r46257 10/osl/trunk/compile.sh: added compile targets
for libz and libpng |
| 18:47.35 |
CIA-62 |
BRL-CAD:
03starseeker * r46258 10/brlcad/trunk/src/librt/primitives/
(hf/hf.c table.c): add an hf bbox routine - not too worried about
this one as hf is on its way out. |
| 18:48.47 |
kunigami |
hmmm osl is
seg faulting with the local builds :( maybe it didn't like some of
the versions. |
| 18:57.43 |
CIA-62 |
BRL-CAD:
03kunigami * r46259 10/osl/trunk/: svn propset svn:externals is not
additive. have to specify all external dependences at
once |
| 18:59.44 |
CIA-62 |
BRL-CAD:
03starseeker * r46260 10/brlcad/trunk/src/librt/primitives/
(dsp/dsp.c table.c): dsp bbox routine - this is another one that
has to dupliate a lot of prep, so don't double up on the work -
leave the prep calculations as-is. |
| 19:08.04 |
CIA-62 |
BRL-CAD:
03kunigami * r46261 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp
liboslrend.h osl_rt.cpp sh_osl.cpp): removed unnused code, debug
messages and the old AddShader, which is not to be used |
| 19:11.47 |
CIA-62 |
BRL-CAD:
03bhinesley * r46262
10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: Started
manual; more specifics on the argument style are needed.
WIP |
| 19:11.52 |
CIA-62 |
BRL-CAD:
03kunigami * r46263 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt
Makefile.am osl_rt.cpp): deleting the stand-alone osl rt. It was
already out-dated and it has no use since sh_osl is
functional |
| 19:12.47 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 19:16.33 |
CIA-62 |
BRL-CAD:
03bob1961 * r46264 10/brlcad/trunk/src/libged/erase.c: |
| 19:16.34 |
CIA-62 |
BRL-CAD: This
reverts the fix for r45409 (i.e. ged_splitGDL was no longer
splitting |
| 19:16.34 |
CIA-62 |
BRL-CAD:
things correctly. This caused a noticeable performance issue as
well as the |
| 19:16.34 |
CIA-62 |
BRL-CAD:
results of 'who' being wrong). The segmentation fault problem was
resolved in |
| 19:16.34 |
CIA-62 |
BRL-CAD:
_ged_eraseFirstSubpath. |
| 19:16.35 |
plaes |
kunigami: it
could be running against system library |
| 19:16.58 |
plaes |
ldd is your
friend ;) |
| 19:17.58 |
kunigami |
yup, ldd
tells me it is using brlcad version. but that was the objective.
I'm testing in a system with minimal system libraries to check if
the libraries we're providing are enough |
| 19:33.36 |
CIA-62 |
BRL-CAD:
03starseeker * r46265
10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: gah -
extrude bbox logic is pretty close to worst case - don't see any
immedate way to do a bbox better, so just try to do a
'self-contained' version that doesn't use stp structures and cleans
up after itself. |
| 19:34.40 |
CIA-62 |
BRL-CAD:
03starseeker * r46266 10/brlcad/trunk/src/librt/primitives/table.c:
whoops, add to table.c |
| 19:36.03 |
CIA-62 |
BRL-CAD:
03kunigami * r46267 10/osl/trunk/jpeg-8c/Makefile.in: missing
file... |
| 19:39.07 |
starseeker |
humph - the
way submodel is set up, I can't do a bbox routine for it without
adding an rtip parameter |
| 19:41.51 |
CIA-62 |
BRL-CAD:
03kunigami * r46268 10/osl/trunk/tiff-3.9.5/Makefile.in: doh!
missing file... |
| 19:48.09 |
CIA-62 |
BRL-CAD:
03kunigami * r46269 10/osl/trunk/tiff-3.9.5/ (23 files in 23 dirs):
hmm! actually there are a lot more Makefile.in |
| 20:37.05 |
CIA-62 |
BRL-CAD:
03kunigami * r46270 10/osl/trunk/compile.sh: set linker path for
linux env and make oiio use tbb |
| 20:54.37 |
kunigami |
here's the
backtrace of the segfault: http://paste.ubuntu.com/669543/
-- the program does not even finished to load... it seems to be a
runtime linking error |
| 21:00.31 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 21:31.43 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 21:37.47 |
bhinesley |
starseeker:
what handles the generation of html files from docbook format?
Using synopfragment tags would be really nice for my uses, but
they're not getting formatted correctly. |
| 21:38.15 |
bhinesley |
I'll take a
look at it if you can point me in the right direction |
| 21:39.12 |
starseeker |
um... the
docbook stylesheets probably control that |
| 21:39.46 |
starseeker |
we haven't
customized any of our output from docbook yet - that's a bit of a
job |
| 21:40.02 |
bhinesley |
seems odd
that they wouldn't format their own tag correctly |
| 21:41.07 |
bhinesley |
investigates |
| 21:46.27 |
CIA-62 |
BRL-CAD:
03starseeker * r46271 10/brlcad/trunk/src/librt/primitives/
(cline/cline.c table.c): add bbox routine for cline |
| 21:51.02 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 21:56.41 |
CIA-62 |
BRL-CAD:
03starseeker * r46272 10/brlcad/trunk/src/librt/primitives/
(superell/superell.c table.c): break out bbox logic for
superell |
| 22:16.57 |
CIA-62 |
BRL-CAD:
03starseeker * r46273 10/brlcad/trunk/src/librt/primitives/ (4
files in 2 dirs): metaballs already had most of the bbox
functionality broken out - make it conform to the new functab setup
and have it call the sphere routine itself to make it
standalone. |
| 22:45.23 |
CIA-62 |
BRL-CAD:
03starseeker * r46274 10/brlcad/trunk/src/librt/primitives/
(brep/brep.cpp table.c): |
| 22:45.24 |
CIA-62 |
BRL-CAD: Do
the simple thing with rt_brep_bbox and call the openNURBS routine -
a quick |
| 22:45.24 |
CIA-62 |
BRL-CAD:
check results in a pretty good bbox, although we'll stick with the
bvh result |
| 22:45.24 |
CIA-62 |
BRL-CAD: for
prep. The fact that bi->brep is NULL'ed by prep is a bit
worrisome, leading |
| 22:45.24 |
CIA-62 |
BRL-CAD: to
questions about whether this routine will work after raytrace - why
are we |
| 22:45.24 |
CIA-62 |
BRL-CAD:
NUll'ing the bi->brep during prep? |
| 23:12.47 |
CIA-62 |
BRL-CAD:
03starseeker * r46275 10/brlcad/trunk/src/librt/primitives/
(hyp/hyp.c table.c): Go with the epa/ehy approach for hyp too.
Might actually be slightly larger surface area for some views when
hyp is rotated, but MUCH better than sphere for axis aligned
cases. |
| 23:40.33 |
CIA-62 |
BRL-CAD:
03starseeker * r46276 10/brlcad/trunk/src/librt/primitives/
(revolve/revolve.c table.c): Make a stab at implementing a
stand-alone bbox function for revolve - again, too much extra logic
to want to have prep call it. |
| 23:44.08 |
CIA-62 |
BRL-CAD:
03bhinesley * r46277 10/brlcad/trunk/ (3 files in 2
dirs): |
| 23:44.09 |
CIA-62 |
BRL-CAD:
Wrote synopsis for 'edit translate'. It looks fine in brlman, but
there is a |
| 23:44.09 |
CIA-62 |
BRL-CAD:
mysterious line break in the html manual browser, and no line
breaks in several |
| 23:44.09 |
CIA-62 |
BRL-CAD:
places where there should be. First priority is to fix the issue.
Failing that, |
| 23:44.09 |
CIA-62 |
BRL-CAD: I
can simply remove the synopfragment tags (which are what is
breaking the |
| 23:44.09 |
CIA-62 |
BRL-CAD:
formatting) and rearrange things a bit. Added synopsis for 'edit',
and cleaned |
| 23:44.10 |
CIA-62 |
BRL-CAD: up
indentation. |
| 23:46.45 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 23:54.00 |
CIA-62 |
BRL-CAD:
03starseeker * r46278 10/brlcad/trunk/src/librt/primitives/
(pnts/pnts.c table.c): Points apparently don't have any prep, but
go ahead and add a bounding box function. |
| 02:06.02 |
*** join/#brlcad nsd_
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 02:38.05 |
starseeker |
bhinesley:
excellent! |
| 02:47.17 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 05:11.11 |
abhi2011 |
ok I have got
objects updating inside mged now using rt_matrix_transform()
according to bullet output |
| 10:44.25 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 11:48.08 |
abhi2011 |
ok I was
wondering how conditional compiling is implemented in the build
system |
| 11:48.43 |
abhi2011 |
so I have
some files which are based on Bullet's libraries, but if Bullet is
not installed then the compile will fail |
| 11:49.19 |
abhi2011 |
yet if these
files are not compiled then a function which is called from libged
will not exsist and that too would cause the build to
fail |
| 11:50.05 |
abhi2011 |
perhaps there
is a way to compile a dummy function in a separate file if bullet
is not detected , so both the above errors can be avoided
? |
| 11:53.19 |
kunigami1 |
abhi2011: you
can do something I did for OSL. take a look at Cmakelists.txt at
liboptical |
| 11:53.39 |
abhi2011 |
kunigami1:
thanks I ll take a look |
| 11:59.46 |
abhi2011 |
ok so you use
a top level cmake flag to enable or disable osl :
BRLCAD-ENABLE_OSL |
| 12:00.13 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 12:57.10 |
starseeker |
IF(BULLET_FOUND) could be my first
guess |
| 13:07.34 |
*** join/#brlcad Elrohir
(~kvirc@p5B149541.dip.t-dialin.net) |
| 13:50.19 |
kunigami1 |
abhi2011: by
the way, to set the BLCAD-ENABLE_OSL flag there, you can call cmake
with -DBRLCAD-ENABLE_OSL=ON |
| 13:54.14 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46310 10/brlcad/trunk/src/libged/simulate.c: #if
0 out some unused code |
| 13:54.48 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46311 10/brlcad/trunk/src/mged/cmd.c: remove
unused variable |
| 14:00.21 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-185-238.wlan.tudelft.nl) |
| 14:39.24 |
``Erik |
fwiw, I
believe today is "pencils down" for gsoc |
| 14:40.42 |
``Erik |
abhi:
awesome, very awesome |
| 14:47.32 |
abhi2011 |
yep preparing
the cmake logic for commit now :) |
| 15:33.59 |
CIA-62 |
BRL-CAD:
03d_rossberg * r46312 10/brlcad/trunk/src/librt/ (bbox.c
primitives/rpc/rpc.c): |
| 15:33.59 |
CIA-62 |
BRL-CAD: For
the Windows build: MSVC is not C99 |
| 15:33.59 |
CIA-62 |
BRL-CAD:
moved variable declarations upwards |
| 15:43.15 |
CIA-62 |
BRL-CAD:
03bob1961 * r46313 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): The rectangle used for selection was
no longer being drawn due to a previous modification (i.e. not
drawing rectangle if its lwidth is 0). This restores the desired
behavior in Archer. |
| 15:44.55 |
plaes |
congrats on
the new logo |
| 16:40.40 |
*** join/#brlcad DarkCalf
(DC@173.231.40.98) |
| 19:01.35 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:36.45 |
brlcad |
starseeker:
for submodels, each callback is basically a mini program in itself
meaning they have to open the subdatabase files (like rt and
company) to do their processing |
| 19:36.58 |
brlcad |
responding to
backlog so comments may be OBE |
| 19:45.27 |
brlcad |
abhi2011:
there should be no reason to prefer static over dynamic libraries
when linking bullet (and you shouldn't be adding /usr/local/* to
the default link/search paths (e.g., LINK_DIRECTORIES)) .. that's
something to be specified during cmake |
| 19:46.07 |
brlcad |
(i.e. that's
a "non-std" location in itself) |
| 19:47.16 |
brlcad |
plaes: thx!
it is pretty nifty |
| 19:47.40 |
plaes |
yup, nice and
simple |
| 19:53.04 |
brlcad |
kunigami1:
you can't export variables to a parent context so you'd have to
wrap that in a script |
| 19:53.53 |
plaes |
are these
images here created with brlcad: http://ronja.twibright.com/3d/
? |
| 19:54.07 |
brlcad |
abhi2011: you
can't just mark a variable as 'const' and expect it to work --
that's why I said you'd have to make a copy. if you're calling a
non-const function but need the object to remain unmodified, you
have to make your own copy of that object beforehand |
| 19:54.12 |
brlcad |
plaes:
yes |
| 19:55.36 |
plaes |
how do I save
such images? :) |
| 19:57.04 |
brlcad |
what do you
mean? |
| 19:57.56 |
*** join/#brlcad DarkCalf
(DC@173.231.40.98) |
| 19:58.03 |
plaes |
well, I know
that the models are made by brlcad, but how do I save such
black-and-white images |
| 19:58.58 |
brlcad |
rtedge |
| 19:59.17 |
plaes |
\o/ |
| 19:59.20 |
brlcad |
rt is the
usual renderer, but there are a handful of other rt*
renderes |
| 19:59.54 |
brlcad |
rt and rtedge
both work within mged equivalently |
| 20:00.04 |
brlcad |
some of the
others are external to mged |
| 20:00.14 |
brlcad |
all can be
run external |
| 20:01.09 |
plaes |
lots of cool
stuff still hidden in all these programs ;) |
| 20:01.22 |
brlcad |
nods |
| 20:04.36 |
plaes |
building
stuff with primitives is like "simulating" machining..
;) |
| 20:06.20 |
plaes |
first build a
part on the computer and then try it out in real life - http://timmu.store20.com/galerii/?galerie=frees |
| 20:17.45 |
abhi2011 |
brlcad: ok ,
yes I understand now |
| 20:19.43 |
abhi2011 |
I was
checking with the db_functree() function and i saw that it tries to
lookup the primitives for a combination in the dbip which I pass to
it, which is of course what it should do |
| 20:20.31 |
abhi2011 |
and it fails
as expected as the dbip does not have the primitive in it , as its
the in mem db_i I made in the function |
| 20:22.20 |
brlcad |
plaes: that's
a pretty nifty old machine there |
| 20:22.39 |
abhi2011 |
so its back
to square one , which is how to get union tree for the constituent
primitives when passed just the rt_db_internal for a region
containing those primitives |
| 20:29.20 |
brlcad |
abhi2011:
that's why I said earlier that in order to call db_functree(), you
need to use the unmodified dbi from the original dbip ... not your
in-mem copy |
| 20:29.50 |
brlcad |
to use the
inmem, you'd need to recursively call db_functree() on the original
dbi and copy them into the inmem, just so you could look them up
again |
| 20:30.02 |
brlcad |
basically a
big pain and probably unnecessary |
| 20:30.25 |
brlcad |
much easier
to create a new comb, add your primitive, then have all objects go
through the other existing bb routine |
| 20:30.42 |
abhi2011 |
brlcad: ok
yah that would work, I was trying to find a way to not pass an
extra parameter as the idea was to just pass a
rt_db_internal |
| 20:31.08 |
abhi2011 |
yes so I
tried making a comb too |
| 20:31.14 |
abhi2011 |
however it
needs a tree as well |
| 20:31.27 |
abhi2011 |
if you lines
414 to 418 in bbox.c |
| 20:31.32 |
abhi2011 |
*if you
see |
| 20:31.44 |
brlcad |
you don't
need an extra parameter |
| 20:32.18 |
abhi2011 |
the
unmodfiied db_i is globally available then ? |
| 20:32.35 |
abhi2011 |
the original
db_i i mean |
| 20:33.21 |
brlcad |
I think you
might be a bit confused by the different approaches being
discussed |
| 20:34.22 |
abhi2011 |
well there
are 2 approaches : either use db_functree() or make a comb
:) |
| 20:35.10 |
abhi2011 |
since making
a comb is easier , lets focus on that then |
| 20:36.14 |
abhi2011 |
so the idea
was that make a rt_comb_internal with 1 leaf for shapes , for
combinations, well they are already a rt_comb_internal |
| 20:36.43 |
brlcad |
so far,
sounding good |
| 20:36.50 |
abhi2011 |
ok
:P |
| 20:37.33 |
abhi2011 |
so the basics
challenge in making a rt_comb_internal out of a shape is : the tree
parameter in the rt_comb_internal structure |
| 20:37.50 |
CIA-62 |
BRL-CAD:
03bob1961 * r46314
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Updated
ArcherCore::selectTreePath to make the selected tree item
visible. |
| 20:38.10 |
abhi2011 |
or rather the
tree member |
| 20:38.12 |
brlcad |
not a
challenge at all erally :) |
| 20:38.38 |
abhi2011 |
umm but I
would need the tree for the shape right, I cant get that from the
rt_db_internal |
| 20:38.56 |
brlcad |
you need a
tree, yes |
| 20:39.09 |
brlcad |
filling in a
tree is simple |
| 20:39.34 |
brlcad |
if the
rt_db_internal is already a comb, you can just access the comb's
tree |
| 20:39.50 |
brlcad |
if the
rt_db_internal is a primitive, you'll make a comb and add that
primitive to the comb's tree |
| 20:40.21 |
abhi2011 |
so something
like combp->tree = intern->tree |
| 20:40.23 |
brlcad |
see the
comb.c file, for the comb command, shows creating an
rt_comb_internal and filling it in |
| 20:40.34 |
abhi2011 |
where intern
is the rt_db_internal |
| 20:40.41 |
abhi2011 |
for the
primitive |
| 20:40.53 |
brlcad |
that doesn't
look or sound right |
| 20:41.16 |
brlcad |
intern->tree is not valid |
| 20:41.39 |
abhi2011 |
yes
rt_db_internal does not have a tree member, so the tree in the
rt_db_internal has to be accessed |
| 20:42.01 |
abhi2011 |
ok that part
should be easy |
| 20:42.11 |
brlcad |
IFF intern is
a comb, then intern->idb_ptr is an rt_comb_internal |
| 20:42.20 |
abhi2011 |
oh!
:P |
| 20:42.56 |
abhi2011 |
umm no I knew
that |
| 20:43.22 |
abhi2011 |
IFF intern is
a primitive, then where is the tree , will find that
out |
| 20:43.29 |
brlcad |
so you'd call
something like rt_bound_tree(intern->idb_ptr->tree) if it's a
comb or rt_bound_tree(my_comb->tree) if it's a
primitive |
| 20:43.29 |
abhi2011 |
:) |
| 20:43.46 |
abhi2011 |
yes I
understand that |
| 20:44.03 |
brlcad |
you have to
make my_comb |
| 20:44.08 |
abhi2011 |
yes |
| 20:44.13 |
brlcad |
see comb.c
:) |
| 20:44.19 |
abhi2011 |
yep
:) |
| 20:44.32 |
brlcad |
you'll need a
tiny subset similar to what _ged_combadd() does |
| 20:45.02 |
brlcad |
look for the
GETSTRUCT lines to see where an rt_comb_internal is
allocated |
| 20:45.19 |
abhi2011 |
ok |
| 20:46.46 |
abhi2011 |
by the way ,
on a different note, I am curious about the other approach : that
is using db_functree(), you said the original db_i need not be
passed |
| 20:47.09 |
abhi2011 |
so then it
can be got using a global variable or a function ? |
| 20:52.24 |
brlcad |
no, I think
you're misunderstanding something I was saying -- you are passed a
db_i to your function -- you can just use it |
| 20:52.32 |
brlcad |
you just need
to make a copy of it if you're going to pass it to some other
non-const function |
| 20:54.55 |
abhi2011 |
well , the
function is like this : int rt_bound_internal(struct rt_db_internal
*ip, point_t rpp_min, point_t rpp_max), so there is no db_i
passed |
| 20:55.53 |
brlcad |
sorry, I was
using "db_i" to mean db_internal |
| 20:56.21 |
brlcad |
not to be
confused with a database instance db_i |
| 20:56.24 |
abhi2011 |
oh ok , I
though you meant struct db_i |
| 20:56.28 |
abhi2011 |
yah i get it
:) |
| 20:57.35 |
brlcad |
you only
needed a db_i to call rt_dirbuild() iirc, so that primitive
bounding boxes get calculated |
| 20:58.11 |
abhi2011 |
yes, this
db_i however was constructed from the original .g database
file |
| 20:58.20 |
abhi2011 |
so it had all
the primitives |
| 20:58.21 |
brlcad |
that approach
is still fine, it's just combs that are even simpler with
rt_bound_tree(ip->idb_ptr->tree) |
| 20:58.41 |
abhi2011 |
yes |
| 20:58.46 |
abhi2011 |
<PROTECTED> |
| 20:59.00 |
abhi2011 |
meanwhile, I
got bullet running in mged |
| 20:59.04 |
abhi2011 |
and the cmake
logic done |
| 20:59.08 |
brlcad |
outstanding |
| 20:59.33 |
abhi2011 |
about to
commit that : had some changes to top level cmake file , hope
starseeker is standing by :P |
| 20:59.35 |
brlcad |
sounds like
more work is needed on the cmake logic, but shouldn't be too
difficult |
| 20:59.48 |
brlcad |
what's the
diff look like? |
| 21:00.05 |
abhi2011 |
I ll pastebin
it 1 sec |
| 21:01.19 |
abhi2011 |
basically
added logic to compile a dummy simulate.c file that does nto bullet
headers, if bullet is absent |
| 21:01.46 |
abhi2011 |
in the top
level there is logic to find the bullet library and link
/usr/local/lib |
| 21:03.10 |
brlcad |
presuming you
saw my earlier comment, assuming /usr/local/lib is no
good |
| 21:04.04 |
abhi2011 |
oh ok, I
think I missed that |
| 21:04.31 |
abhi2011 |
reading now
:) |
| 21:04.40 |
brlcad |
I mean,
/usr/local is probalby the only "non-default" system locations that
could be added, but adding it should be systematic for include
headers, libs, and bins |
| 21:05.11 |
brlcad |
and it still
shouldn't be subdir aware like /usr/local/lib/bullet/. |
| 21:06.03 |
brlcad |
libs not in
"system" paths should be declared to cmake or handled by some
Find*.cmake routines |
| 21:07.46 |
abhi2011 |
ok, I would
have thought that /usr/local/lib would be searched by default by
cmake |
| 21:07.57 |
abhi2011 |
so I would
not need to specify it |
| 21:08.18 |
abhi2011 |
well I am
using the stock FindBullet.cmake module |
| 21:09.09 |
abhi2011 |
its installed
by cmake, and it finds and sets the ${BULLET_INCLUDE_DIR},
${BULLET_LIBRARIES} correctly |
| 21:09.44 |
abhi2011 |
but its not
setting the ${BULLET_LIBRARY_DIR} variable, which is what I would
link to , to keep things standard |
| 21:10.35 |
abhi2011 |
here is the
top level CMakeLists.txt diff : http://bin.cakephp.org/view/1810550039 |
| 21:10.46 |
abhi2011 |
will try to
get rid of LINK_DIRECTORIES("/usr/local/lib") |
| 21:13.17 |
abhi2011 |
this is the
libged/CMakeLists.txt file that also required changes : http://bin.cakephp.org/view/860235467 |
| 21:16.44 |
abhi2011 |
ok , so I am
thinking maybe I can remove the LINK_DIRECTORIES("/usr/local/lib")
line in the top level CMakeLists.txt file |
| 21:17.09 |
abhi2011 |
as long as a
user does not enable bullet , the rest of the build will be
fine |
| 21:17.27 |
abhi2011 |
if he does
enable bullet, then there will be a linking error |
| 21:17.53 |
abhi2011 |
so the exact
location where the user has installed the libs can be specified
using a cmake command line flag |
| 21:18.20 |
abhi2011 |
that would
eliminate any hardcoded library paths |
| 21:21.55 |
abhi2011 |
of course
that begs the question as to why ${BULLET_LIBRARY_DIR} is not being
set by the stock FindBullet.cmake module , its probably not looking
at the right place |
| 21:26.28 |
brlcad |
so several
comments |
| 21:26.50 |
brlcad |
sure,
searching /usr/local/lib might be expected .. but that has nothing
to do with bullet and shouldn't be part of your
patch/commit |
| 21:27.12 |
brlcad |
certainly
shouldn't be specific to an if(BRLCAD-ENABLE_BULLET)
section |
| 21:27.58 |
brlcad |
which brings
up my second point, and enable/disable toggle for that seems
unnecessary -- it should test for bullet and, if found, use it.
otherwise, the command implementation is disabled at
compile-time |
| 21:30.08 |
abhi2011 |
brlcad: ok I
understand |
| 21:30.26 |
brlcad |
abhi2011:
you also do not need simulatedummy.c -- that should be logic
contained within the simulate.c file (#ifdef) OR put it all in a
subdir with it's own CMakeLists.txt file |
| 21:30.45 |
brlcad |
probably
should put it all in a subdir anyways just because you have
multiple implementation files |
| 21:31.13 |
abhi2011 |
ok , yes that
will be easier |
| 21:32.25 |
abhi2011 |
yes I thought
about the #ifdef , but I havent found a compile time symbol that is
defined if bullet was found |
| 21:33.38 |
abhi2011 |
ok, I think
there will be some symbol which will be defined if the bullet
headers are detected, will go through the headers |
| 21:33.48 |
brlcad |
if one is not
defined, you can define one |
| 21:33.59 |
brlcad |
but make sure
one isn't already defined |
| 21:34.04 |
abhi2011 |
yes, but
bullet is detected by cmake |
| 21:34.16 |
brlcad |
yes, so?
:) |
| 21:34.20 |
abhi2011 |
i cant define
a symbol to be used in a c file , in the cmake logic |
| 21:34.26 |
brlcad |
sure you
can |
| 21:34.29 |
abhi2011 |
umm...but as
usual i am off mark :P |
| 21:34.37 |
abhi2011 |
ok thats
totally cool :) |
| 21:34.56 |
abhi2011 |
ok will find
out about it |
| 21:35.15 |
brlcad |
see
include/brlcad_config.h in your build directory for a list of
symbols already being defined during cmake |
| 21:35.26 |
abhi2011 |
ok |
| 22:02.07 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 22:15.15 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 23:00.39 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 23:28.47 |
CIA-62 |
BRL-CAD:
03brlcad * r46315 10/brlcad/trunk/src/libged/edit.c: quellage, may
be unitialized |
| 00:19.38 |
*** join/#brlcad kanzure_
(~kanzure@131.252.130.248) |
| 00:59.51 |
CIA-62 |
BRL-CAD:
03starseeker * r46316 10/brlcad/trunk/ (41 files in 39 dirs): (log
message trimmed) |
| 00:59.51 |
CIA-62 |
BRL-CAD: Stub
in a way for view information to be passed to plot routines.
Inactive at |
| 00:59.51 |
CIA-62 |
BRL-CAD: the
moment, and the struct being passed in just has a single token
value - this |
| 00:59.51 |
CIA-62 |
BRL-CAD: is
setting up the path through which information can be passed, not
actually |
| 00:59.51 |
CIA-62 |
BRL-CAD:
doing it (yet). This will introduce a binary compatibility, so it
may need to |
| 00:59.52 |
CIA-62 |
BRL-CAD: be
reverted, but I'm committing it at this time to preserve the
information for |
| 00:59.53 |
CIA-62 |
BRL-CAD:
future use; the commit diff is a good starting point when determing
what |
| 02:04.48 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 02:13.51 |
starseeker |
crud
s/compatibility/incompatibility |
| 02:15.47 |
abhi2011 |
ok I have
modified the cmake logic and put the simulation files in
libged/simulation |
| 02:16.30 |
abhi2011 |
added 1
symbol to indicate bullet was found or not |
| 02:27.45 |
abhi2011 |
here is the
diff of the 3 cmake files, 2 existing, 1 added : http://bin.cakephp.org/view/295759995 |
| 02:29.39 |
abhi2011 |
minimal
changes to the top level file |
| 02:30.36 |
starseeker |
abhi2011: you
don't need the MESSAGE line for the Bullet find pakage |
| 02:30.38 |
starseeker |
package
even |
| 02:31.56 |
brlcad |
starseeker:
hm |
| 02:31.57 |
starseeker |
also, I would
expect the BRLCAD_ADDLIB line to use "${BULLET_LIBRARIES}" instead
of individually listing them - does that not work? |
| 02:32.03 |
brlcad |
isn't scale
sufficient? |
| 02:32.29 |
starseeker |
brlcad: not
for what I'm experimenting with at the moment |
| 02:32.38 |
starseeker |
if that
doesn't pan out, then possibly |
| 02:32.44 |
abhi2011 |
starseeker:
ok I will remove the message line |
| 02:33.09 |
brlcad |
I'd had
similar thoughts to add view information to the plot callback for
levels-of-detail, but data-wise the callback still only needs a
single scaling factor |
| 02:33.41 |
abhi2011 |
well
${BULLET_LIBRARIES} contains the static libraries with the .a
extensions as thats what applications normally use |
| 02:34.06 |
abhi2011 |
however when
I tried linking against the static libraries I was getting an error
related to the -fPIC flag |
| 02:34.12 |
starseeker |
brlcad: I'm
experimenting with some view-dependent logic at the moment - too
early to know if it's viable or not |
| 02:34.37 |
abhi2011 |
I ll try it
once more, though I think -static needs to be specified when
compiling mged |
| 02:34.48 |
abhi2011 |
to alllow
bullet to link to it statically |
| 02:35.04 |
brlcad |
starseeker:
er, like rtedge-style plotting? |
| 02:35.27 |
starseeker |
brlcad: no,
some level-of-detail stuff for bots |
| 02:35.48 |
abhi2011 |
starseeker:
therefore I compiled the dynamic libs for bullet with .so
extensions and use those which requires individually specifiying
the libs |
| 02:35.59 |
starseeker |
brlcad: I can
revert that commit if it's a problem - it's way too early to know
if what I'm thinking will work or not |
| 02:36.10 |
brlcad |
er, but how
is it view-dependent (beyond scale) |
| 02:36.37 |
starseeker |
view
direction and matrix |
| 02:36.55 |
starseeker |
window size,
etc |
| 02:37.06 |
brlcad |
but how?
:) |
| 02:37.25 |
brlcad |
window size I
can see easily, but that is encompassed by scale |
| 02:37.27 |
starseeker |
sigh... OK,
fine: http://vdslib.virginia.edu/ |
| 02:38.22 |
starseeker |
knew he shouldn't have committed that... |
| 02:38.33 |
brlcad |
i'm not
looking for a bunny out of a hat, I'm really just curious
how |
| 02:38.48 |
brlcad |
LoD doesn't
need view dir |
| 02:39.27 |
starseeker |
this isn't a
standard "decimate the mesh" approach - http://www.cs.virginia.edu/~luebke/publications/pdf/vds.cad.pdf |
| 02:41.00 |
starseeker |
the 1.0 code
apparently isn't around anymore, but thanks to debian an earlier
version is: http://bzflag.bz/~starseeker/vdslib-0.9-6.1.tar.gz |
| 02:41.28 |
starseeker |
is looking at the polyview example app they have in there,
and intending to do what they're doing with bots and
vlists |
| 02:42.22 |
abhi2011 |
ok I have
modified libged/simulation/CMakeLists.txt to link to the static
libs but I get an error : http://bin.cakephp.org/view/372893931 |
| 02:42.27 |
abhi2011 |
same one as
before |
| 02:43.01 |
starseeker |
got libvds, libstdvds and polyview compiling today, and
polyview kinda worked |
| 02:43.02 |
abhi2011 |
something to
with 32 bit libraries on 64 bit platforms |
| 02:43.57 |
starseeker |
abhi2011:
urm. what does the file command tell you about your bullet
libraries? |
| 02:45.36 |
starseeker |
brlcad: it
may be that once I fully understand what vds is doing scale will
turn out to be sufficient for our needs, but I was going to first
verify in the most straightforward way I could that I could
duplicate what polyview is doing inside MGED |
| 02:46.56 |
abhi2011 |
libBulletCollision.a gives :
libBulletCollision.a: current ar archive |
| 02:47.10 |
starseeker |
hmm |
| 02:47.19 |
abhi2011 |
libBulletCollision.so.2.78: ELF 64-bit LSB
shared object, x86-64, version 1 (SYSV), dynamically linked, not
stripped |
| 02:47.36 |
abhi2011 |
those are the
static and dynamic counterparts of the same basic
library |
| 02:47.42 |
brlcad |
starseeker:
interesting approach, I hadn't seen that paper before (or at least
not that I remember) |
| 02:47.45 |
starseeker |
OK, but the
bullet find_package isn't returning the dynamic lib? |
| 02:48.13 |
abhi2011 |
no , the
stock FindBullet.cmake does not |
| 02:48.25 |
brlcad |
a quick read
through the paper, there are several issues it claims that are
somewhat non-issues these days (e.g., memory use for the
lod) |
| 02:48.55 |
abhi2011 |
I could make
a FindBullet.cmake specifically for returning dynamic
libs |
| 02:49.01 |
brlcad |
and issues
caused by his approach (distant object popping, trouble with the
folding) |
| 02:49.01 |
starseeker |
brlcad: I got
triggered by a comment from Bob when he was working with one of the
big BoT models about how the interactivity sucked so bad, so I went
hunting this weekend for something that might be viable (since it's
for sure anybody dealing with a big BoT model would have the same
issue) |
| 02:49.16 |
starseeker |
abhi2011:
that might be worth doing |
| 02:49.36 |
starseeker |
abhi2011: we
do custom Find*.cmake files when the stock ones don't suffice -
there are several in misc/CMake |
| 02:50.19 |
starseeker |
brlcad: yeah,
the mesh probably won't be perfect, but if it's "close enough" and
interactive it will beat the heck out of one refresh every 30 sec.
when zooming |
| 02:50.27 |
abhi2011 |
ok yes I can
make a custom one, I wonder whats up with the compiler though, it
should have allowed static linking |
| 02:50.48 |
starseeker |
abhi2011: are
you compiling 32 or 64 bit? (-m32 or -m64?) |
| 02:51.06 |
abhi2011 |
maybe bullet
builds the 32 bit version by default |
| 02:51.06 |
brlcad |
abhi2011: the
subdir should match the command name |
| 02:51.14 |
starseeker |
brlcad:
apparently it was a SIGGRAPH thing back in the late
1990s |
| 02:51.21 |
starseeker |
s/thing/paper |
| 02:51.31 |
abhi2011 |
starseeker: i
avent checked that , will check now |
| 02:51.37 |
brlcad |
starseeker: I
noticed |
| 02:51.46 |
abhi2011 |
brlcad: ok I
ll change it |
| 02:51.51 |
starseeker |
was hoping to try it before he got told why it wouldn't be a
good idea :-P |
| 02:51.58 |
brlcad |
heh |
| 02:52.48 |
brlcad |
it's not
evidently a bad idea, just odd -- not many folks did research on
view-dependent LoD |
| 02:52.48 |
starseeker |
it took a
little time to propagate the rt_*_plot change, and I didn't want to
leave it uncommitted, so I figured do it in one fell swoop that
could be easily undone |
| 02:53.13 |
brlcad |
and from my
quick read, it's still not entirely clear that it is exactly
view-dependent from our plot-perspective |
| 02:53.48 |
starseeker |
it might not
be - I was going on what the polyview app was feeding via vds
functions |
| 02:53.49 |
brlcad |
you feed an
initial mesh at a given LoD along with the view params, then it
generates a quadree simplification based on the current
view |
| 02:55.22 |
starseeker |
right - but
since our plotting routines call the functab for each primitive to
get the lines to draw, I was assuming that the simplification
output (in vlist form) was what would need to come back from
rt_bot_plot |
| 02:55.29 |
brlcad |
you could
still keep plot view agnostic, returning a plot at some
predetermined scale, then have a function churn through the
view-dependent simplification |
| 02:56.10 |
starseeker |
maybe, but
that starts to get deep into the tangle of code that is the draw
logic |
| 02:56.25 |
starseeker |
was trying to stay below that rats nest, at least for the
first trial |
| 02:56.53 |
brlcad |
that's where
injecting view-dependent information is going to be a mess ...
plot() for some of the prims is already a nightmare |
| 02:57.10 |
brlcad |
but yeah,
that seems to be the way the algorithm wants it anyways |
| 02:57.16 |
brlcad |
you got to
have the mesh to start with |
| 02:57.17 |
starseeker |
brlcad: but
we don't have to use it unless we want to |
| 02:57.31 |
brlcad |
hm? |
| 02:57.36 |
starseeker |
for now,
every primitive except BoT will totally ignore the view
info |
| 02:58.37 |
brlcad |
that's my
point, though -- the algorithm doesn't know or care about object
types, and shouldn't need to |
| 02:58.44 |
starseeker |
the main
problem I was looking at was caching the vds tree |
| 02:58.55 |
brlcad |
the same
logic that'd let you simplify a bot will simplify any plot() data
set |
| 02:58.56 |
starseeker |
uh... which
algorithm? |
| 02:59.04 |
brlcad |
this view-dep
lod paper |
| 02:59.07 |
starseeker |
oh - not sure
about that, actually |
| 02:59.14 |
starseeker |
it may need
face data as well as edges |
| 02:59.29 |
brlcad |
sure, it
wants manifold surfaces |
| 02:59.39 |
brlcad |
several of
the plot impls go through nmg anyways |
| 02:59.56 |
starseeker |
sure, so for
those it might be viable - but (say) ell or eto won't
care |
| 03:00.12 |
starseeker |
wasn't going to tangle with nmg in the first
round |
| 03:01.47 |
brlcad |
that's
actually a good point |
| 03:01.55 |
brlcad |
the paper did
require topology |
| 03:02.45 |
brlcad |
which .. BoTs
ain't got |
| 03:03.01 |
brlcad |
tess() would
be more appropriate than plot() |
| 03:04.04 |
brlcad |
then it is
back to being agnostic to entity type |
| 03:04.40 |
brlcad |
that
said..... |
| 03:04.58 |
brlcad |
bob's problem
is fixed with a *very* simple scale-based LoD reduction
:) |
| 03:05.34 |
starseeker |
except how do
we know how to draw the bots at various scales? |
| 03:05.45 |
starseeker |
this seemed
like a systematic way to address that cleanly |
| 03:07.13 |
brlcad |
easy, you
pass the scale you want to the bot |
| 03:07.27 |
starseeker |
and then the
bot does... what? |
| 03:07.38 |
brlcad |
if the
super-detailed bot is being drawn tiny, the scale factor will be
tiny |
| 03:08.11 |
starseeker |
right, but
that still begs the question of which subset of edges from the BoT
to draw at that scale |
| 03:08.21 |
brlcad |
the scale
factor is basically used to collapse edges or introduce new
edges |
| 03:08.44 |
brlcad |
so at scale
near zero, it's a point or a single tiny vlist segment |
| 03:09.00 |
brlcad |
at near one,
it's whatever "full detail" means |
| 03:09.04 |
starseeker |
right, but
the details of that collapsing are the difficulty |
| 03:09.18 |
starseeker |
that problem
is probably a subset of what vds is doing, actually |
| 03:09.21 |
brlcad |
you have that
info directly from the scale value |
| 03:09.28 |
brlcad |
that scale is
in relation to the model size |
| 03:09.50 |
brlcad |
so
tessellating as we do now, we make ton's of segments that are
effectively all overlapping |
| 03:10.11 |
brlcad |
detecting
that next_point == curr_point within tolerance is easy |
| 03:10.27 |
brlcad |
we just
don't/didn't even have the scale to even know that |
| 03:11.45 |
starseeker |
isn't sure next_point == curr_point is enough, but I suppose
I don't understand enough about how plot is doing its
drawing |
| 03:12.13 |
starseeker |
bbiab |
| 03:12.14 |
brlcad |
it's not
really == .. it's within tolerance given the current
scale |
| 03:12.56 |
brlcad |
NEAR_EQUAL(curr_point, next_point,
collapse_distance) |
| 03:15.30 |
brlcad |
the only
thing you don't explictly know with just a scale size is the number
of pixels since that's really what (should) drives the edge
collapse |
| 03:16.33 |
brlcad |
so you encode
that implicitly in the scale (e.g., 1.0 immplies 1024x1024 spacing
of edges scaled to that object's bbox) |
| 03:16.56 |
brlcad |
or you pass
the interpixel spacing (i.e., the collapse_distance) instead of
scale |
| 03:19.57 |
brlcad |
OR you pass
both and you get arbitrary on-demand LoD :) |
| 03:20.22 |
brlcad |
abhi2011:
../../../src/libged/simulate.c:63:1: error: C++ style comments are
not allowed in ISO C90 |
| 03:28.31 |
abhi2011 |
brlcad: yes I
removing those comments |
| 03:30.06 |
brlcad |
starseeker:
another thought -- you could get a boost within libdm itself,
agnostic to any primitive plot() implementation |
| 03:32.31 |
brlcad |
libdm knows
the view size and pixel size so there are several optimizations
that could be made right off the bat -- like not even calling plot
if object is smaller than a pixel, and reducing the plot vlist
eliminating edges that are less than half a pixel distance in
length |
| 03:33.52 |
brlcad |
that's
probably a couple hours effort in an afternoon to get something
that simple working .. hmm! |
| 03:38.54 |
brlcad |
looks like
drawH_part2() is where the action is at |
| 04:03.46 |
CIA-62 |
BRL-CAD:
03brlcad * r46317
10/brlcad/trunk/doc/docbook/system/mann/en/Makefile.am: file was
renamed to edit_translate.xml |
| 04:26.24 |
CIA-62 |
BRL-CAD:
03brlcad * r46318 10/brlcad/trunk/include/ (bu.h magic.h
raytrace.h): if NO_BOMBING_MACROS is enabled, then it will leave
empty if-statements throughout the code making the compiler
unhappy. sacrifice a no-opish ((void)0) to keep the compilation
gods happy. |
| 05:15.35 |
CIA-62 |
BRL-CAD:
03brlcad * r46319 10/brlcad/trunk/src/libged/Makefile.am: update
Makefile.am at the same time as CMakeLists.txt, add simulate.c and
simphysics.cpp to unbreak autotools build. |
| 05:16.08 |
CIA-62 |
BRL-CAD:
03brlcad * r46320
10/brlcad/trunk/src/tclscripts/mged/CMakeLists.txt: no packages
presently exist in mged dir |
| 05:26.04 |
plaes |
hum.. how do
I "exit" from oed back to the viewing state? |
| 05:26.30 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 05:30.13 |
plaes |
aha..
reject |
| 05:33.52 |
CIA-62 |
BRL-CAD:
03brlcad * r46321 10/brlcad/tags/zlib_1_0_4/: there is no reason
for keeping a tag of zlib 1.0.4 |
| 05:45.58 |
brlcad |
pressing
escape in the graphics window will do it too |
| 05:57.59 |
CIA-62 |
BRL-CAD:
03brlcad * r46322 10/brlcad/tags/ (12 files in 12 dirs): similarly
no reason to keep around the old cvs branch tags that were useful
for tracking branch start points, end points, and branch
termination. relegated the legacy into svn history. |
| 06:23.48 |
plaes |
hmm..
rtwizard doesn't set the path properly |
| 07:15.20 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 07:25.09 |
CIA-62 |
BRL-CAD:
03d_rossberg * r46323 10/brlcad/trunk/CMakeLists.txt: |
| 07:25.09 |
CIA-62 |
BRL-CAD:
quell cmake warning |
| 07:25.09 |
CIA-62 |
BRL-CAD: and
apparently trimmed trailing spaces |
| 07:25.18 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 07:57.09 |
*** join/#brlcad b0ef
(~b0ef@226.27.202.84.customer.cdi.no) |
| 08:20.48 |
*** join/#brlcad Unknown_Monkey
(~max@netblock-208-127-49-10.dslextreme.com) |
| 08:22.38 |
Unknown_Monkey |
hey I
installed brlcad on my ubuntu machine and when i run mged and I
draw a cone or anything It doesnt show up the screen is blank and
when I click on the window the cone drawing shows up but then it
disappers |
| 08:24.37 |
*** join/#brlcad DarkCalf
(DC@2002:ade7:2862::ade7:2862) |
| 08:27.30 |
Unknown_Monkey |
DarkCalf: can
you help me |
| 12:19.46 |
CIA-62 |
BRL-CAD:
03brlcad * r46324 10/brlcad/tags/ (itcl3-2/ libpng_1_0_2/ tcl8-3/
tk8-3/): revmoed additional 3rd party dependencies that don't
really belong amongst our other tags |
| 13:09.05 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 13:35.15 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46325 10/brlcad/trunk/src/libged/simulate.c: Removed
C++ style comments in C file to conform to C90 |
| 13:37.36 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46326 10/brlcad/trunk/src/libged/simphysics.cpp:
Changed mode to C++ in the file style section at the
bottom |
| 13:41.17 |
CIA-62 |
BRL-CAD:
03n_reed * r46327 10/brlcad/trunk/src/conv/obj-g_new.c: Fixed
missing header and implicit return statement that g++ complained
about. |
| 13:42.43 |
CIA-62 |
BRL-CAD:
03brlcad * r46328 10/brlcad/tags/ (10 files in 10 dirs): more
removal of cvs branching artifacts where it was necessary to tag
before and after merging, pushed into the depths of svn
history |
| 14:07.26 |
CIA-62 |
BRL-CAD:
03n_reed * r46329 10/brlcad/trunk/src/libgcv/wfobj/ (10 files):
Replaced flex scanner with re2c equivalent. |
| 14:12.51 |
starseeker |
woot! |
| 14:13.17 |
starseeker |
ditches view stuff and hits the re2c/lemon
logic |
| 14:16.07 |
CIA-62 |
BRL-CAD:
03starseeker * r46330 10/brlcad/trunk/src/other/ (CMakeLists.txt
byacc/ flex/ m4/): We're not using them right now, re2c/lemon work
is progressing, and svn has our back if we have to return to this
route - clear out m4/byacc/flex |
| 14:31.24 |
CIA-62 |
BRL-CAD:
03starseeker * r46331 10/brlcad/trunk/src/other/ (450 files in 13
dirs): Check in vanilla copies of re2c-0.13.5 and the latest lemon
from sqlite.org. No build system logic yet, baselining with the
vanilla sources. |
| 14:40.27 |
CIA-62 |
BRL-CAD:
03starseeker * r46332 10/brlcad/trunk/src/other/ (20 files in 3
dirs): Add first stages of CMake logic for re2c and lemon
building |
| 14:59.43 |
CIA-62 |
BRL-CAD:
03starseeker * r46333 10/brlcad/trunk/ (4 files in 2 dirs): Add
more CMake logic for re2c/lemon, this time relating to deciding
whether or not to build local copies - this is Not Done,
particularly the FindRE2C and FindLEMON files, but
checkpointing. |
| 15:18.34 |
*** join/#brlcad b0ef
(~b0ef@226.27.202.84.customer.cdi.no) |
| 15:30.48 |
CIA-62 |
BRL-CAD:
03bob1961 * r46334 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Updated Ged::pane_mouse_ray to calculate the mLastMouseRayStart
point (i.e. the point from which to fire a ray) so that all
displayed geometry is in front of the ray firing point. |
| 15:36.28 |
abhi2011 |
ok I have
modified the cmake logic to detect bullet dynamic libs |
| 15:36.37 |
abhi2011 |
all I had to
do was remove the static libs |
| 15:36.44 |
abhi2011 |
time for a
whoosh! commit |
| 15:37.06 |
brlcad |
abhi2011: try
to commit incrementally if you can without breaking the
build |
| 15:37.15 |
abhi2011 |
brlcad: ok
:P |
| 15:37.20 |
brlcad |
like one
commit moves the files into a subdir, another fixes the bullet
rules, etc |
| 15:37.45 |
brlcad |
you shouldn't
move modified files, for example |
| 15:38.17 |
brlcad |
edit, commit,
then move, commit OR move, commit, then edit, commit |
| 15:40.03 |
abhi2011 |
ok I have
deleted 2 files : simulate.c and simphysics.cpp in libged
however |
| 15:40.20 |
abhi2011 |
moved them to
libged/simulate directory |
| 15:40.50 |
abhi2011 |
ok for those
2, I ll commit last |
| 15:40.54 |
brlcad |
that's wrong
|
| 15:41.10 |
brlcad |
svn will
handle the move for you, and is preferred because it will preserve
the commit history |
| 15:43.04 |
brlcad |
cd src/libged
&& svn revert simulate.c simphysics.cpp && mv
simulate simulate.backup && mkdir simulate && svn
add simulate && svn commit -m "stub in simulate dir"
simulate && svn mv simulate.c simulate/simulate.c
&& svn mv simphysics.cpp simulate/simphysics.cpp &&
.... etc |
| 15:43.42 |
abhi2011 |
ok |
| 15:44.26 |
CIA-62 |
BRL-CAD:
03brlcad * r46335 10/brlcad/tags/ (merge-to-head-20051223/
stable-branch/): move cvs branch tagging artifact
removal |
| 15:45.07 |
abhi2011 |
ok then I ll
checkout fresh again , and do the changes one by one |
| 15:47.42 |
abhi2011 |
hmm, no i
think just deleting the simulate directory and recreating through
the commands you gave should be enough, ok will do that |
| 15:47.57 |
CIA-62 |
BRL-CAD:
03brlcad * r46336 10/brlcad/tags/temp_tag/: remove what looks like
a tag related to the merging of the bobWinPort work, some artifact
tag that was retained through conversion from cvs. |
| 15:52.03 |
CIA-62 |
BRL-CAD:
03brlcad * r46337 10/brlcad/tags/CMD/: nice.. remove very old
version of remrt that was tagged in the early 90's. nice and easy
to read. |
| 15:56.45 |
CIA-62 |
BRL-CAD:
03brlcad * r46338 10/brlcad/tags/help/: remove mysterious 'help'
tag from 7.8, no apparent purpose and certainly no need to keep it
around now |
| 16:03.56 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46339 10/brlcad/trunk/src/libged/simulate/: stub in
simulate dir |
| 16:10.08 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46340 10/brlcad/trunk/src/libged/ (5 files in 2
dirs): stub for 2 files moved to simulate dir |
| 16:13.20 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46341 10/brlcad/trunk/src/mged/cmd.c: stub for
simulate cmd wrapper modification |
| 16:23.12 |
CIA-62 |
BRL-CAD:
03brlcad * r46342 10/brlcad/tags/Original/: remove '98 tagging of
the html docs |
| 16:27.27 |
CIA-62 |
BRL-CAD:
03brlcad * r46343 10/brlcad/tags/release-7-0/: clearly not actually
release 7.0 .. remove the cvs tag relic that was made on a few
files just before the project was converted to open
source. |
| 16:30.44 |
CIA-62 |
BRL-CAD:
03brlcad * r46344 10/brlcad/tags/rel-5-0beta/: remove the
rel-5-0beta cvs-to-svn relic as it's not actually the 5.0 beta
release. the rel-5-0-beta tag has that so this one that just has
tcl/tk can get gone. |
| 16:31.29 |
brlcad |
and with
that, our tags should now be all in order, each representing some
snapshot in time for a given production |
| 16:40.40 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46345 10/brlcad/trunk/CMakeLists.txt: Added detection
of bullet dynamic libraries using the stock CMAKE FindCMake.cmake
module |
| 16:42.59 |
*** join/#brlcad plaes
(~plaes@gn237.zone.eu) |
| 16:45.01 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46346 10/brlcad/trunk/src/libged/ (4 files in 2
dirs): Changes in the CMake build logic and source files to allow
the simulate command to link to bullet |
| 16:45.22 |
abhi2011 |
and that
completes the changes to link to bullet for the mged simulate
command |
| 16:46.37 |
abhi2011 |
hope I didnt
break anything |
| 16:52.26 |
abhi2011 |
so if anyone
installs bullet (has to be told to specifically compile shared
libs) and tries out the simulate command then let me know
:) |
| 17:02.36 |
CIA-62 |
BRL-CAD:
03n_reed * r46347 10/brlcad/trunk/src/libgcv/wfobj/Makefile.sample:
Adding local makefile to demonstrate necessary build
steps. |
| 17:42.33 |
*** join/#brlcad molto_crescendo
(~molto_cre@BZ.BZFLAG.BZ) |
| 17:42.57 |
brlcad |
I
wonder |
| 17:43.45 |
molto_crescendo |
okay |
| 17:49.48 |
starseeker |
brlcad:
wonder... what? |
| 17:50.10 |
brlcad |
starseeker:
never mind :) |
| 17:51.13 |
starseeker |
heh -
k |
| 18:00.25 |
starseeker |
wheee - that
was fun! |
| 18:10.02 |
CIA-62 |
BRL-CAD:
03starseeker * r46348
10/brlcad/trunk/src/other/lemon/CMakeLists.txt: need lempar.c in
the same directory as the lemon binary |
| 18:10.48 |
molto_crescendo |
yep, same
directory |
| 18:11.18 |
CIA-62 |
BRL-CAD:
03brlcad * r46349 10/brlcad/trunk/src/other/Makefile.am:
bison/flex/m4 removed, stay in sync with CMakeLists.txt |
| 18:12.27 |
CIA-62 |
BRL-CAD:
03brlcad * r46350 10/brlcad/trunk/src/other/Makefile.am: add lemon
and re2c dirs |
| 18:16.59 |
brlcad |
abhi2011:
nice work regardless, hopefully get a chance to test it later this
wek |
| 18:17.03 |
brlcad |
s/wek/week/ |
| 18:23.35 |
``Erik |
weeeee,
earthquakes |
| 18:23.36 |
brlcad |
abhi2011: one
cleanup, the " |
| 18:24.27 |
brlcad |
abhi2011: the
simulate "library" can just be named simulate (not libgedsim) since
it's not intended to be installed/used as a standalone library but
as a module to libged |
| 18:25.01 |
abhi2011 |
brlcad:
ok |
| 18:49.39 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:28.50 |
CIA-62 |
BRL-CAD:
03starseeker * r46351 10/brlcad/trunk/ (391 files in 59 dirs): Get
the new obj-g building as part of BRL-CAD. |
| 19:29.20 |
CIA-62 |
BRL-CAD:
03brlcad * r46352 10/brlcad/trunk/TODO: |
| 19:29.21 |
CIA-62 |
BRL-CAD:
primitive testing has uncovered off-by-one raytrace errors during
identical |
| 19:29.21 |
CIA-62 |
BRL-CAD:
subsequent invocations of rt due to some floating point issue
during parallel |
| 19:29.21 |
CIA-62 |
BRL-CAD:
processing. single processor results in zero errors yet parallel
gives subtle |
| 19:29.21 |
CIA-62 |
BRL-CAD:
changes. should investigate to see if there's a code issue though
the problem |
| 19:29.21 |
CIA-62 |
BRL-CAD:
persists back as far as at least 7.8 (on 64-bit Linux). |
| 19:38.03 |
brlcad |
starseeker: I
presume you put boost there because of conflicts or uncertainty
with src/other/boost ? |
| 19:41.13 |
starseeker |
yep |
| 20:58.45 |
*** join/#brlcad Elrohir
(~kvirc@p5B14AEDB.dip.t-dialin.net) |
| 20:59.49 |
CIA-62 |
BRL-CAD:
03starseeker * r46353 10/brlcad/trunk/src/other/boost/ (88 files in
30 dirs): Clear old boost libs |
| 21:22.25 |
CIA-62 |
BRL-CAD:
03n_reed * r46354 10/brlcad/trunk/src/libged/ (CMakeLists.txt
simulate/CMakeLists.txt): get the build working - probably not the
'right' fix (starseeker) |
| 21:40.51 |
CIA-62 |
BRL-CAD:
03n_reed * r46355 10/brlcad/trunk/src/mged/setup.c: Need to use
HAVE_BULLET in mged too - no ged_simulate, no simulate
command. |
| 21:52.46 |
CIA-62 |
BRL-CAD:
03n_reed * r46356 10/brlcad/trunk/src/conv/obj-g_new.c: Removed
obsolete debug output. |
| 22:00.40 |
CIA-62 |
BRL-CAD:
03n_reed * r46357 10/brlcad/trunk/src/libgcv/wfobj/obj_rules.re:
Removed obsolete debug output. |
| 22:30.31 |
CIA-62 |
BRL-CAD:
03starseeker * r46358 10/brlcad/trunk/src/other/boost/ (1467 files
in 127 dirs): add the bcp reported subset of boost 1.47 needed for
spirit.hpp. Made a quick stab at CMakeLists.txt build logic for the
libs, not sure if it's right. |
| 22:33.30 |
CIA-62 |
BRL-CAD:
03starseeker * r46359 10/brlcad/trunk/src/libpc/CMakeLists.txt:
because we have both boost and libs dirs now, include
src/other/boost not src/other |
| 22:36.31 |
molto_crescendo |
exit |
| 22:38.30 |
*** join/#brlcad abhi2011
(~chatzilla@x033197.its-s.tudelft.nl) |
| 22:39.37 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 22:45.28 |
bhinesley |
hmm...
playing around with Blender. There is a setting to "manipulate
object centers only". I didn't think of allowing translations based
on angles (without actually rotating the object being
translated). |
| 22:46.08 |
brlcad |
bhinesley:
not sure I follow |
| 22:46.30 |
brlcad |
a translation
based on an angle means what exactly? |
| 22:47.34 |
brlcad |
like only
translating against an object's local coordinate system instead of
global? |
| 22:48.15 |
brlcad |
so a box
tilted 45 degrees and translated "by x" would go "up" at a 45
degree translation? |
| 22:48.20 |
bhinesley |
brlcad: hard
to explain. In Blender, you can set your 3d cursor where you would
like the center of a rotation to take place. Then you enable
"manipulate object centers only". When you "rotate", you're not
really rotating. You're just moving the object to some other
point. |
| 22:48.52 |
bhinesley |
brlcad: no,
it does local vs. global translations too, but that's not what I'm
refering to. |
| 22:49.27 |
brlcad |
yeah .. okay
.. confused then :) |
| 22:51.30 |
bhinesley |
brlcad: say
you place a box at 1,0,0 and the center of rotation at 0,0,0. If
you rotate the box 90 degrees on the z-axis, you'll end up at 0,1,0
with the cube still facing the same directions. |
| 22:51.40 |
brlcad |
finds http://blenderunderground.com/blender-3d-faq/#mi_centers
to be unhelpful |
| 22:52.24 |
brlcad |
ahh, good
example |
| 22:53.40 |
brlcad |
sounds like a
flag to the rotate command ;) |
| 22:53.57 |
brlcad |
or a
different "pivot" command |
| 22:54.29 |
brlcad |
since you're
really pivoting around a point, seems apropos |
| 22:55.17 |
bhinesley |
nods |
| 22:55.36 |
bhinesley |
rotate is
already too complex |
| 22:57.03 |
bhinesley |
to the user
it would "feel" like a special type of rotation, but under cover a
pivot command would just call translate. |
| 22:57.41 |
brlcad |
or call
rotate twice |
| 22:57.58 |
bhinesley |
hmm, not a
bad idea. |
| 23:02.13 |
bhinesley |
could be used
to create polar arrays (i.e. lugnuts on a wheel) |
| 23:02.38 |
brlcad |
the existing
pattern tool already does that albeit manually in the
implementation |
| 23:03.06 |
brlcad |
spherical and
cylindrical |
| 23:03.14 |
bhinesley |
ah,
nice |
| 23:04.25 |
bhinesley |
brlcad: what
is it called? is it in Archer? |
| 23:04.26 |
CIA-62 |
BRL-CAD:
03brlcad * r46360 10/brlcad/trunk/TODO: potential lead, -B works
with parallel enabled so something fishy is going on. possibly
conversion from float to double ... but random numbers should not
be involved! |
| 23:04.45 |
brlcad |
bhinesley:
the interface is just atrocious |
| 23:04.49 |
brlcad |
so it's in
mged ;) |
| 23:05.22 |
brlcad |
Pattern tool
under the Tools menu |
| 23:05.27 |
bhinesley |
ah, I see,
thanks |
| 23:07.16 |
CIA-62 |
BRL-CAD:
03starseeker * r46361 10/brlcad/trunk/src/ (CMakeLists.txt
util/CMakeLists.txt): libpc ain't happy about the boost change -
turn it off for now. |
| 23:14.07 |
CIA-62 |
BRL-CAD:
03starseeker * r46362 10/brlcad/trunk/src/libgcv/wfobj/
(CMakeLists.txt boost_shared_ptr/): Well, can now use
src/other/boost for obj-g anyway... |
| 23:23.57 |
CIA-62 |
BRL-CAD:
03starseeker * r46363 10/brlcad/trunk/src/other/boost/boost/spirit/
(32 files in 11 dirs): hmm - may not have gotten everything. bcp
--scan of the libpc headers resulted in a few more boost
files. |
| 09:01.02 |
*** join/#brlcad DarkCalfz
(DC@173.231.40.98) |
| 09:19.28 |
*** join/#brlcad plaes
(~plaes@gn237.zone.eu) |
| 10:24.09 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 10:38.15 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 10:38.15 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 10:38.51 |
*** join/#brlcad CIA-62
(~CIA@cia.atheme.org) |
| 10:39.08 |
*** join/#brlcad plaes
(~plaes@gn237.zone.eu) |
| 10:39.43 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 10:39.43 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 10:40.33 |
*** join/#brlcad DarkCalfz
(DC@173.231.40.98) |
| 10:40.33 |
*** join/#brlcad kunigami2
(~kunigami@loco-gw.ic.unicamp.br) |
| 10:40.33 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 10:40.38 |
*** join/#brlcad merzo
(~merzo@12-152-132-95.pool.ukrtel.net) |
| 10:41.58 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 10:41.58 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 10:41.58 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 10:45.33 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 10:45.33 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 13:45.10 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 13:46.37 |
abhi2011 |
is there a
way to calculate a transformation matrix to convert between
co-ordinate systems |
| 13:47.17 |
abhi2011 |
bullet's
co-ordinate system assumes the y axis as up, but is right handed,
just like mged |
| 13:48.09 |
abhi2011 |
so objects
fall towards the xz plane when gravity is applied |
| 13:48.45 |
abhi2011 |
the
transformation matrix has to map the translations and rotations to
mged's co-ordinate system correctly |
| 13:57.08 |
abhi2011 |
i ll try a
simple rotation about the x-axis |
| 14:55.21 |
abhi2011 |
trying to
reset some primtives to the origin before the simulation
starts |
| 14:55.47 |
abhi2011 |
apparently
rt_matrix_transform() applies a translation/rotation to the
existing transform |
| 14:56.22 |
abhi2011 |
there does
not seem to be a functions that can directly set the absolute world
transform of a comb/primitive |
| 15:29.17 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 17:19.42 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 17:29.05 |
*** join/#brlcad merzo
(~merzo@77-191-133-95.pool.ukrtel.net) |
| 18:28.00 |
brlcad |
abhi2011:
perhaps there's a way to specify the coordinate system to
bullet |
| 18:29.37 |
brlcad |
otherwise,
you can just apply the rotation before you feed values to bullet
and the reverse when you read values and apply them back on
geometry |
| 18:32.40 |
abhi2011 |
brlcad:
ok |
| 18:33.57 |
abhi2011 |
about the
bounding box function, I have been trying with combp = (struct
rt_comb_internal *)ip->idb_ptr; and
rt_bound_tree(combp->tree, tree_min, tree_max) |
| 18:34.32 |
abhi2011 |
however
rt_bound_tree() does not implement the OP_DB_LEAF case which causes
the traversal of the tree to get stuck |
| 18:35.50 |
abhi2011 |
so I was
considering adding that case, but even if I rt_bound_tree() does
get me to the leaf, it seems the leaf only had information about a
primtive's name |
| 18:36.22 |
abhi2011 |
not its shape
information such as a pointer to its ft_bbox() method etc, or any
geometry info |
| 18:49.29 |
brlcad |
abhi2011: so
it sounds like there's some disconnect, that you're not setting up
something correctly |
| 18:50.59 |
brlcad |
if I recall
correctly, you had it working earlier, when you were mimicking what
the bb command does (ala _ged_get_obj_bounds) |
| 18:51.13 |
brlcad |
now you're
basically saying that method doesn't work |
| 18:51.22 |
brlcad |
but you had
it working for combs, so what's changed? |
| 18:55.53 |
brlcad |
IF ip is a
comb (which you have to check), then you still have to call
rt_gettree() to "load" the members of that comb and calculate the
primitive bb's (and THEN you can call rt_bound_tree() to get the
overall comb bb) |
| 18:56.57 |
brlcad |
read
src/libged/get_obj_bounds.c again -- it does what you're trying to
do |
| 18:57.12 |
brlcad |
it just
starts with a char*name instead of an rt_db_internal |
| 18:58.39 |
brlcad |
when your
function is done and working, it should drop right into
_ged_get_obj_bounds() and _ged_get_obj_bounds2() |
| 18:58.58 |
brlcad |
(or better
still, into the callers of those functions so they can be
eliminated) |
| 19:30.08 |
abhi2011 |
brlcad: yes I
just found that out, that I need to call rt_gettree() for combs,
otherwise the members are not loaded |
| 19:30.24 |
abhi2011 |
well now I ll
get it working |
| 19:35.28 |
abhi2011 |
ok I got the
reason why I had said rt_bound_tree() was working
before |
| 19:36.15 |
abhi2011 |
it was with a
standalone program which obtained a struct rt_i *rtip directly from
the the database file , using rtip = rt_dirbuild(argv[1], title,
sizeof(title)); |
| 19:36.54 |
abhi2011 |
this trip
does have the primtives and can be safely passed to
rt_gettree(rtip, argv[2]), to load all the primtives for a
combination |
| 19:37.19 |
abhi2011 |
but in the bb
box function, I create an in-mem rtip |
| 19:37.40 |
abhi2011 |
which does
not know anything about the primitives |
| 19:37.59 |
abhi2011 |
as it was not
made from the original file |
| 19:39.09 |
abhi2011 |
so calling
rt_gettree() as follows : ( when I am trying to find the bb for a
comb of course), would lead to the members of that comb still not
getting loaded |
| 19:40.52 |
abhi2011 |
if
(rt_gettree(rtip, "dummy") < 0){... |
| 19:42.36 |
abhi2011 |
the only
thing thats changed is the rtip between the 2 cases (the one where
I build rtip using rt_dirbuild() and the bb function case which
uses an in-mem rtip ) |
| 19:46.44 |
abhi2011 |
brlcad: thats
why the original rtip that was made from the database file would be
needed to get to the primtives, because rt_gettree() needs to get
the original rtip |
| 20:14.34 |
brlcad |
I'm not sure
much of that made sense to me :) |
| 20:16.05 |
brlcad |
recounting
what you did to me isn't necessary, I know what you did :) it was
a question to ask yourself to hopefully help you figure out what
you now need to do to get things working |
| 20:18.14 |
abhi2011 |
yes ok :) ,
I am certain now that the original dbip needs to be passed and I ll
get the bb using it and wrap up the function |
| 20:18.29 |
abhi2011 |
perhaps in
the near future i ll be able to remove it |
| 20:19.02 |
brlcad |
if it's a
comb, your job is really easy |
| 20:19.58 |
brlcad |
the only real
work remaining is/was supposed to be figuring out how to calculate
the bb for a primitive |
| 20:20.14 |
brlcad |
you had *A*
solution, just not the ideal solution |
| 20:20.55 |
brlcad |
so you could
go with what you had (using the inmem) ... or figure out how to
build an rt_comb_internal by hand with just that one
primitive |
| 20:22.31 |
brlcad |
I'd suggest
getting it to work for both comb and prims using the two methods
you already know work, then trying to build the rt_comb_internal as
a replacement method for prims |
| 20:22.56 |
brlcad |
that way, the
code will be at least functional and can be tested for any object
type |
| 20:43.09 |
*** join/#brlcad merzo
(~merzo@194-13-133-95.pool.ukrtel.net) |
| 21:02.24 |
abhi2011 |
brlcad: yes,
I will be building a rt_comb_internal for finding the bb of both
prims and combs |
| 21:03.46 |
abhi2011 |
the only
other thing I will be doing is adding an extra paramter to
rt_bound_internal() |
| 21:04.42 |
abhi2011 |
will make it
like : rt_i rt_bound_internal(struct rt_i *rtip, struct
rt_db_internal *ip, point_t rpp_min, point_t rpp_max) |
| 21:05.06 |
brlcad |
why? you
shouldn't need to do that |
| 21:05.14 |
abhi2011 |
ah
ha...:) |
| 21:05.20 |
abhi2011 |
so that is
because |
| 21:05.39 |
abhi2011 |
the rtip that
I pass to rt_gettree() should be the original rtip |
| 21:05.53 |
abhi2011 |
not one
created from an in-mem dbip |
| 21:07.19 |
brlcad |
it feels like
we're talking in circles :) |
| 21:07.53 |
abhi2011 |
the in-mem
dbip has no geometry information about the primtives in the model,
and consequently neither does the struct rt_i* made from
it |
| 21:08.25 |
abhi2011 |
well, yeah I
know it feels that way, and its my fault really |
| 21:09.09 |
abhi2011 |
the
rt_bound_tree(combp->tree, tree_min, tree_max) method never
worked before actually |
| 21:09.13 |
brlcad |
sure, that
you found out last week -- you'd have to add all of the comb's
members (that's why you were researching db_functree()) |
| 21:09.22 |
abhi2011 |
yes
exactly |
| 21:09.35 |
abhi2011 |
and
db_functree() runs against the same problem see |
| 21:09.45 |
abhi2011 |
its unable to
add the primtives |
| 21:10.03 |
brlcad |
because? |
| 21:10.04 |
abhi2011 |
because it
uses db_lookup() on the in-mem db_i |
| 21:10.24 |
abhi2011 |
the one I
create and pass to it inside the rt_bound_internal()
function |
| 21:10.24 |
brlcad |
you don't run
functree on the inmem |
| 21:11.11 |
brlcad |
youd run
functree on the original dbi to add them to the inmem |
| 21:11.11 |
abhi2011 |
yes, I should
run it on the original struct db_i |
| 21:11.31 |
abhi2011 |
yes, but the
original db_i is not passed |
| 21:11.34 |
abhi2011 |
to the
function |
| 21:11.43 |
abhi2011 |
so I would
need to pass it |
| 21:12.30 |
brlcad |
that would be
better than passing an rtip, but still seems
unnecessary.. |
| 21:12.39 |
abhi2011 |
yes, umm
why |
| 21:12.51 |
abhi2011 |
there is no
other way to add the primitives |
| 21:13.14 |
abhi2011 |
other than
picking them form the original struct db_i and putting them in the
in-mem struct db_i |
| 21:16.27 |
brlcad |
the why would
be because the rt_comb_internal should already have a union tree *
filled out |
| 21:16.46 |
brlcad |
the inmem one
you were trying didn't, but that's obvious why .. you only added
the comb |
| 21:18.25 |
brlcad |
the caller
will be passing you an rt_db_internal that should be filled out,
that tree should be passable to rt_bound_tree() as-is ..
no? |
| 21:18.42 |
brlcad |
if it's not,
it sounds like a problem in the caller code |
| 21:19.24 |
brlcad |
(like not
calling dirbuild or gettrees or something .. don't think it matters
which) |
| 21:19.24 |
abhi2011 |
yes it should
be passable to rt_bound_tree(), however the structure of the tree
is wrong |
| 21:20.09 |
abhi2011 |
the tree
leads to the primtive node , but that node has just the primtive
name |
| 21:20.49 |
abhi2011 |
it does not
have any geometry information and the tr_op is not
OP_SOLID |
| 21:20.55 |
abhi2011 |
its
OP_DB_LEAF |
| 21:20.59 |
abhi2011 |
which is not
correct |
| 21:21.18 |
brlcad |
so why is
that, sounds like something not getting set up right |
| 21:21.30 |
abhi2011 |
yes so let me
explain :) |
| 21:21.39 |
brlcad |
like I said
-- "it sounds like a problem in the caller code" |
| 21:22.21 |
abhi2011 |
hmm
yeah |
| 21:22.33 |
abhi2011 |
the
rt_db_internal() should have a complete tree |
| 21:23.56 |
abhi2011 |
but the
caller code is very straight forward : http://bin.cakephp.org/view/1978180787 |
| 21:24.36 |
brlcad |
rt_bound_tree() is clearly used by
src/libged/bb.c (via get_obj_bounds.c()) so if they can do the
setup, you should be able to too (even if it requires the caller to
do something first) |
| 21:25.23 |
abhi2011 |
ok |
| 21:25.28 |
brlcad |
so if that
caller code isn't working right, there's something else you need to
have it do |
| 21:26.35 |
brlcad |
maybe see
what rt_gettree() does since that's what get_obj_bounds.c calls
before calling librt |
| 21:26.45 |
abhi2011 |
ah! |
| 21:26.46 |
brlcad |
you may need
to do some subportion of what it's doing |
| 21:27.00 |
abhi2011 |
so its called
before |
| 21:27.11 |
abhi2011 |
yes I ll
check it |
| 21:27.13 |
brlcad |
there's no
point in calling rt_gettree in the caller code because you don't
have an rtip |
| 21:27.33 |
brlcad |
but maybe
there is some other rt function that sets up and initializes the
rt_comb_internal properly |
| 21:27.40 |
brlcad |
very likely
:) |
| 21:27.44 |
abhi2011 |
ok |
| 21:28.00 |
brlcad |
something
related to loading a union tree * |
| 21:29.48 |
abhi2011 |
yeah the
first thing get_obj_bounds() does it /* Make a new rt_i instance
from the existing db_i sructure */ and finally calls rt_gettree()
on it |
| 21:31.05 |
abhi2011 |
which I could
do in my caller code too :P, but lets see if there some other
way |
| 21:34.47 |
brlcad |
yeah, if the
caller had to do all of that, it would defeat the simplicity we're
going for |
| 21:35.13 |
brlcad |
if you find
out that you have to add a dbip parameter, that's fine -- but you
should make sure first |
| 21:37.25 |
abhi2011 |
well yes,
there is no way to intialize the tree of an rt_comb_internal() for
a regions without doing walk on the database instance tree using
the original db_i |
| 21:38.09 |
brlcad |
how do you
know that? |
| 21:39.14 |
abhi2011 |
because only
the original db_i would have the information about the geometry of
the primitives |
| 21:40.02 |
abhi2011 |
and that db_i
would need to be used to look up any primitive names that we
encounter while traversing the tree for a comb |
| 21:40.21 |
brlcad |
right, okay
-- I misread what you were saying |
| 21:40.50 |
brlcad |
the question
is whether there is already a routine or simple method that will
initialize it for you |
| 21:41.02 |
brlcad |
other than
rt_gettree() |
| 21:46.16 |
brlcad |
if something
doesn't exist, that actually might be a good case for adding a
function that creates a non op_db_leaf union tree suitable for your
function (which calling code would then be required to call
beforehand) |
| 21:47.31 |
brlcad |
basically
something like rt_gettree() but specifically for combs, like maybe
a new rt_comb_tree() function |
| 21:48.15 |
abhi2011 |
ok |
| 21:48.58 |
abhi2011 |
i did come
across |
| 21:48.59 |
abhi2011 |
db_comb_describe |
| 21:49.07 |
abhi2011 |
and
rt_comb_describe() |
| 21:52.32 |
abhi2011 |
ok yeah,
adding a function that creates a non op_db_leaf union tree would
still require passing the original db_i to it, so all the geometry
info about the model is available |
| 21:53.00 |
brlcad |
yes,
something like: union tree *rt_comb_tree(const struct db_i *dbip,
const struct rt_db_internal *ip) |
| 21:55.41 |
abhi2011 |
ok |
| 21:55.45 |
brlcad |
I hate to say
it, because that's probably the way to go, but I think we're
getting out of scope |
| 21:55.51 |
brlcad |
a bit at
least |
| 21:56.27 |
brlcad |
figuring out
how to implement that function properly would probably take a few
days at best, a couple weeks at worst |
| 21:56.33 |
abhi2011 |
yeah I dont
see any other function in raytrace.h that could make a
rt_comb_internal |
| 21:57.10 |
brlcad |
plus figuring
out the important parts from rt_gettree() is probably a little bit
out of depth |
| 21:57.26 |
brlcad |
that's
relatively complex code so it'd be a challenge |
| 21:57.44 |
abhi2011 |
yah that
would really go deep into 3D geometry I think :P |
| 21:57.59 |
brlcad |
not
really |
| 21:58.06 |
brlcad |
it gets deep
into librt structures is all |
| 21:58.13 |
abhi2011 |
ok |
| 21:58.15 |
brlcad |
at lot of
recursion and complex data structures |
| 21:58.41 |
brlcad |
doable, but
not immediately relevant for the goals of this project |
| 21:59.07 |
brlcad |
so pass the
dbip, but add a FIXME note to the comment header with the details
we've talked about |
| 21:59.31 |
abhi2011 |
ok |
| 21:59.34 |
brlcad |
stating the
need for something like rt_comb_tree to get a portion of the
rt_gettree() initialization |
| 21:59.54 |
abhi2011 |
right |
| 03:50.06 |
CIA-62 |
BRL-CAD:
03Jimblack 07http://brlcad.org *
r3084 10/wiki/Main_Page: |
| 05:06.55 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 05:06.55 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 07:18.40 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 09:35.05 |
CIA-62 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3085 10/wiki/User:Abhijit: /* Log */ |
| 09:35.25 |
CIA-62 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3086 10/wiki/User:Abhijit: /* Log */ |
| 11:10.13 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:38.19 |
abhi2011 |
brlcad: about
passing the struct db_i* in rt_bound_internal() |
| 12:40.13 |
abhi2011 |
it would be
necessary to call rt_gettree() inside this function |
| 12:40.33 |
abhi2011 |
to get the
primtives for a comb loaded |
| 12:40.55 |
abhi2011 |
is that fine,
or would it be better to avoid calling rt_gettree() ? |
| 12:41.37 |
abhi2011 |
if I do need
to call rt_gettree(), then the 2nd parameter is the name of the
comb/primitive |
| 12:44.16 |
abhi2011 |
which is
generally got using a directory pointer using
dp->d_namep |
| 12:45.42 |
abhi2011 |
the only way
to get a directory pointer is to use again use name of the comb and
then db_lookup() |
| 12:48.17 |
abhi2011 |
I have been
searching for getting the comb or primitive name from a struct
rt_db_internal if at its possible |
| 12:51.10 |
abhi2011 |
seems all of
this can be avoided if the caller code simply calls rt_gettree()
before passing the struct rt_db_internal* |
| 12:51.23 |
abhi2011 |
then we do
not even need to pass the struct db_i * |
| 12:54.56 |
abhi2011 |
or the
calling code can pass the name of the comb/primitive |
| 13:18.20 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 14:16.20 |
CIA-62 |
BRL-CAD:
03starseeker * r46446 10/brlcad/trunk/TODO.cmake: Update todo items
for CMake |
| 14:48.43 |
CIA-62 |
BRL-CAD:
03starseeker * r46447 10/brlcad/trunk/src/other/CMakeLists.txt:
mark BRLCAD_TERMLIB_BUILD as advanced |
| 14:53.27 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl) |
| 14:57.11 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 15:04.18 |
CIA-62 |
BRL-CAD:
03starseeker * r46448
10/brlcad/trunk/src/other/re2c/bootstrap/parser.hh: May need the
parser.hh file too... |
| 15:04.54 |
CIA-62 |
BRL-CAD:
03starseeker * r46449
10/brlcad/trunk/src/other/re2c/bootstrap/parser.hh: fix
comment |
| 15:08.16 |
CIA-62 |
BRL-CAD:
03starseeker * r46450
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: MSVC doesn't know
what to do with D_FORTIFY_SOURCE, apparently |
| 16:38.14 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl) |
| 16:42.44 |
brlcad |
abhi2011:
gah |
| 16:44.22 |
brlcad |
that's a
problem, rt_db_internals are nameless ... forgot about
that |
| 16:44.30 |
abhi2011 |
oh shoot
:P |
| 16:44.42 |
abhi2011 |
yeah by the
time its reaches the rt layer |
| 16:44.46 |
abhi2011 |
names are no
longer relevant |
| 16:45.01 |
brlcad |
that's by
design, so you can write a given rt_db_internal as many times as
you want with different names |
| 16:45.19 |
abhi2011 |
ok |
| 16:45.21 |
brlcad |
you might
have to resort one layer higher, with a struct directory
* |
| 16:46.26 |
abhi2011 |
yes , however
a struct directory * is made using db_lookup(), which unfortunately
also requires a name , and I cannot use a dummy name, I have to use
the exact name of the comb the user passed |
| 16:46.59 |
brlcad |
huh? |
| 16:47.14 |
brlcad |
libged knows
the name |
| 16:47.26 |
brlcad |
the same name
you used to get the rt_db_internal |
| 16:47.36 |
brlcad |
instead of
that, you'll just pass the directory |
| 16:48.48 |
abhi2011 |
oh ok, so I
pass the directory and the struct db_i *, something like this :
rt_bound_internal(struct db_i *dbip, struct directory *dp , struct
rt_db_internal *ip, point_t rpp_min, point_t rpp_max) |
| 16:49.04 |
brlcad |
if you pass
the dp, you no longer should pass the ip |
| 16:49.09 |
brlcad |
you can get
the ip from the dp |
| 16:49.12 |
abhi2011 |
yes
right |
| 16:49.15 |
abhi2011 |
ok |
| 16:49.26 |
abhi2011 |
I was
wondering :) |
| 16:49.39 |
abhi2011 |
why we simply
have a function which accepts the dp and the name |
| 16:49.52 |
abhi2011 |
um no scratch
that |
| 16:50.05 |
abhi2011 |
dp and dbip
is enough |
| 16:50.38 |
abhi2011 |
i thought it
would be easy to have a function that just accept the name of the
comb/primitive and the dbip |
| 16:50.49 |
abhi2011 |
that would be
easy to pass by a user |
| 16:51.37 |
abhi2011 |
something
like rt_bound_internal(char*name , struct db_i *dbip, point_t
rpp_min, point_t rpp_max) |
| 16:52.14 |
brlcad |
that's
libged's responsibility |
| 16:52.22 |
abhi2011 |
oh
ok |
| 16:52.25 |
brlcad |
libged works
with strings, names |
| 16:52.34 |
abhi2011 |
ok |
| 16:53.56 |
abhi2011 |
yeah I get it
now :) |
| 16:53.57 |
brlcad |
really, I
want to just pass the rt_db_internal, but as we already discussed,
another routine needs to be written first to fill out the comb's
tree properly |
| 16:54.04 |
abhi2011 |
yes |
| 16:54.14 |
brlcad |
don't are
about names (or even directory), just want the bb given
geometry |
| 16:54.28 |
abhi2011 |
yes
true |
| 16:54.37 |
brlcad |
working with
a dbip+dp is a start, though |
| 16:55.13 |
brlcad |
that can be
refactored to call a lower-level calculate-my-bb-with-just-this-ip
later |
| 16:55.53 |
abhi2011 |
ok |
| 16:57.59 |
abhi2011 |
I have a
question regarding the transformation matrices of
primitives |
| 16:58.45 |
abhi2011 |
so in the
commands that somehow transform the object, I can see that the
commands generally call rt_matrix_transform() |
| 17:00.00 |
abhi2011 |
and this
function ultimately goes and put a new matrix in the tl_mat member
of the struct union tree |
| 17:00.22 |
abhi2011 |
that exists
in the tr_l member of a union tree* |
| 17:00.40 |
brlcad |
usually |
| 17:00.46 |
abhi2011 |
however this
is a transform matrix, not the matrix representing the absolute
world position |
| 17:01.07 |
abhi2011 |
however
bullet gives me the matrix that represents the transform in
absolute world co-ordinates |
| 17:01.50 |
abhi2011 |
so if the
object were to start from (0,0,0) and with no rotations along any
of the axes, then the transform matrix from bullet can be applied
to get the object to its intended position |
| 17:02.27 |
abhi2011 |
now the thing
is, I generally copy an existing object in mged, and then apply
bullet's transform on it |
| 17:02.41 |
abhi2011 |
however this
new object is no made at the origin |
| 17:02.58 |
abhi2011 |
its made in
the existing object's position |
| 17:03.09 |
abhi2011 |
which is
correct as far as copying is concerned |
| 17:03.42 |
brlcad |
waits for the question |
| 17:03.51 |
abhi2011 |
however , it
would be great if I were able to reset any copies I make , to the
origin |
| 17:04.02 |
abhi2011 |
there are no
such commands to do this in mged however |
| 17:04.38 |
abhi2011 |
and if I
apply bullet's transforms on a copy, which is not in the origin,
then the translation adds to the existing position |
| 17:04.57 |
brlcad |
you're going
way too far down the rabbit hole |
| 17:05.08 |
abhi2011 |
:) |
| 17:05.11 |
brlcad |
ask a
question :) |
| 17:05.46 |
brlcad |
or at least
ask me to explain how brl-cad tracks positions if you don't know
what to ask :) |
| 17:05.52 |
abhi2011 |
ok |
| 17:06.39 |
abhi2011 |
yeah it would
be better if you explain :) |
| 17:07.02 |
abhi2011 |
my issue is
how to apply the bullet transforms on a object which is not at the
origin |
| 17:07.48 |
abhi2011 |
since the
transforms got from bullet specify the translations of the object
with respect to the origin, not the position of the object at the
start of the simulation |
| 17:08.28 |
brlcad |
so if you
remember my earlier comments from when you first got started -- and
why you've been messing around with bounding boxes for so
long... |
| 17:10.15 |
brlcad |
geometry in
brl-cad is described in a rather pure mathematical sense, sometimes
in implicit form and sometimes in an explicit form |
| 17:11.13 |
abhi2011 |
yes |
| 17:12.28 |
abhi2011 |
however the
positions of the objects are stored explicitly somewhere in a
comb/prims attributes |
| 17:12.44 |
brlcad |
yes and no
(sorry multitasking) |
| 17:12.52 |
brlcad |
combinations,
for example, have no position |
| 17:12.59 |
brlcad |
they are just
a grouping |
| 17:13.06 |
abhi2011 |
ah yes
right |
| 17:13.08 |
brlcad |
they can
apply a transformation to that grouping |
| 17:13.20 |
abhi2011 |
ok |
| 17:13.21 |
brlcad |
that have an
*implicit* position |
| 17:13.35 |
abhi2011 |
ok |
| 17:13.41 |
brlcad |
it's implied
that the position of a combination is the position of all it's
continuent submembers |
| 17:13.48 |
abhi2011 |
yes
right |
| 17:14.06 |
brlcad |
so if you
calculate that bb of a comb, for example, you could pretend that
one of the corners or that the center is that comb's
"position" |
| 17:14.30 |
abhi2011 |
ok |
| 17:14.36 |
brlcad |
the same can
be said of all of the primitives |
| 17:14.57 |
brlcad |
many/most of
them have an explicit position, but it's defined per
primitive |
| 17:15.18 |
abhi2011 |
ok |
| 17:16.25 |
starseeker |
remembers he needs to look at rt_bot_bbox
again... |
| 17:16.26 |
brlcad |
for a sphere,
it's the center point; for a cylinder, it's the center of the base
oval; for a torus, it's also at the center which doesn't even
happen to be *on* the object (it's in the void in the
middle) |
| 17:17.00 |
brlcad |
you could get
at that "position", but it's somewhat meaningless for this
purpose |
| 17:17.10 |
brlcad |
all that
matters really is having a consistent handle |
| 17:17.13 |
brlcad |
that's where
the bb comes in |
| 17:17.33 |
abhi2011 |
ok |
| 17:17.35 |
brlcad |
get the bb
for any object, then you can consistently consider the bb center to
be a position |
| 17:18.00 |
abhi2011 |
ok |
| 17:18.02 |
brlcad |
from bullet's
perspective, all you're dealing with is a lot of boxes |
| 17:18.09 |
abhi2011 |
yes
true |
| 17:18.24 |
brlcad |
you can
implement an overlap/collision detection handler later |
| 17:18.42 |
abhi2011 |
however a bb
would not roll on a surface even if it represents a
sphere |
| 17:18.49 |
abhi2011 |
yes
right |
| 17:19.00 |
brlcad |
sure it
will |
| 17:19.24 |
brlcad |
at least, it
should be able to |
| 17:19.47 |
brlcad |
you're not
using the "box" as *geometry* |
| 17:19.54 |
brlcad |
that's just
your handle |
| 17:19.59 |
abhi2011 |
yes right I
get that now |
| 17:20.20 |
abhi2011 |
its the
handle to the geometry in mged |
| 17:21.31 |
brlcad |
the bbox
routines you're working with are also not oobb's, they'
aabb's |
| 17:21.42 |
abhi2011 |
yes
right |
| 17:22.25 |
brlcad |
so even for
simple arb8's, you'll not be able to get objects doing anything
more than translating without collision detection |
| 17:22.39 |
brlcad |
translation
should be the first proof-of-concept step though |
| 17:22.58 |
abhi2011 |
ok |
| 17:23.49 |
brlcad |
e.g., take a
10x10x10 axis-aligned box at 0 0 100, drop it to a ground plane at
0 0 0 |
| 17:24.06 |
brlcad |
demo should
either stop immediately or bounce :) |
| 17:24.12 |
CIA-62 |
BRL-CAD:
03starseeker * r46451 10/brlcad/trunk/src/other/CMakeLists.txt:
when doing win, also need xlib |
| 17:24.17 |
abhi2011 |
yes
ok |
| 17:24.51 |
abhi2011 |
but say the
user runs the sim for 100 steps |
| 17:24.56 |
brlcad |
that initial
collision detection could rely purely on bullet since the bb's are
all axis-aligned |
| 17:25.23 |
brlcad |
or you write
a collision detection routine that just returns 1 if the bb's
overlap |
| 17:25.23 |
abhi2011 |
ok |
| 17:25.33 |
abhi2011 |
right |
| 17:25.52 |
abhi2011 |
about setting
the position of the box |
| 17:25.57 |
abhi2011 |
in
mged |
| 17:27.14 |
brlcad |
so for
starters, you should only work with comb's for now (in mged and in
code), just to keep things simple |
| 17:27.18 |
brlcad |
one entity
type |
| 17:28.07 |
brlcad |
no primitives
by themselves |
| 17:28.43 |
abhi2011 |
ok, and I set
the comb position by simply obtaining how far the object has
translated along z axis and using rt_matrix_transform() to
translate the comb to the new position |
| 17:29.06 |
abhi2011 |
I mean *how
far the* comb* has translated |
| 17:29.28 |
brlcad |
you know how
to apply a translation matrix, I presume? |
| 17:29.53 |
abhi2011 |
yes, just
pass it to rt_matrix_transform() |
| 17:30.12 |
abhi2011 |
with the
proper elements set |
| 17:30.46 |
brlcad |
there are
loads of vector and matrix routines in vmath.h and libbn (bn.h and
src/libbn) |
| 17:31.24 |
abhi2011 |
ok |
| 17:33.16 |
brlcad |
for
example |
| 17:33.57 |
brlcad |
the 'rot' and
'orot' (aka orotate) commands are how rotations are applied to
geometry within mged |
| 17:34.09 |
brlcad |
src/libged/rot.c and
src/libged/orot.c |
| 17:34.45 |
brlcad |
you can see
there how rot.c sets up a rotation vector and calls bn_mat_angles()
to obtain a rotation matrix |
| 17:35.47 |
abhi2011 |
yes, I have
seen rot.c and orot.c, they both transform the object's existing
orientation |
| 17:35.56 |
brlcad |
similarly
orotate.c calls bn_mat_angles() but then also
bn_mat_xform_about_pt() along with some routines to normalize the
matrix before applying it to a comb |
| 17:36.28 |
abhi2011 |
so I would
need to get the transform of the comb wrt the position of the comb
at the beginning of the sim |
| 17:36.46 |
abhi2011 |
so if the
comb is say at position 0,0,100 and at the end of it at
0,0,1 |
| 17:37.19 |
abhi2011 |
then I would
need the translation matrix to be set for a translation of
0,0,99 |
| 17:37.21 |
abhi2011 |
and not the
translation with respect to the origin of 0,0,1 |
| 17:38.36 |
brlcad |
for
translation (what you need first), tra.c is keen which sets up a
translation vector then calls vutil.c |
| 17:39.15 |
abhi2011 |
yes I checked
that yesterday, quite straighforward code |
| 17:39.57 |
abhi2011 |
the mistake I
was making was applying the wrong translations (with respect to the
origin) |
| 17:40.05 |
brlcad |
actually, if
it starts at 0,0,100, it won't end at 0,0,1 .. :) |
| 17:40.37 |
abhi2011 |
yeah it will
fall to 0,0,0 |
| 17:40.58 |
abhi2011 |
at the
end |
| 17:41.25 |
abhi2011 |
before
bouncing around |
| 17:42.08 |
abhi2011 |
if the ground
plane is at 0,0,0 |
| 17:42.37 |
brlcad |
if the box is
10x10x10, and you're using center as V and ground at 0,0,0, then
it'll stop at 0,0,5 :) |
| 17:43.02 |
abhi2011 |
yes , i was
ignoring the height, yes right |
| 17:46.06 |
brlcad |
so what I
imagine will happen is you'll get the bb's for all objects, pass
those to bullet to set up the scene, perform one timestep and
bullet is going to return some information indicating that the box
moves down (a vector) OR that the box is in a new position (a new
position) |
| 17:46.14 |
brlcad |
if it's a
vector, you just apply it like tra |
| 17:46.42 |
brlcad |
if it's a
point, you calculate the vector based on the previous position and
apply that vector like tra |
| 17:47.13 |
abhi2011 |
yes , I would
need to create a rigid body and give it a collision shape in
bullet, so I ll just use a box for now |
| 17:47.49 |
abhi2011 |
yes
right |
| 17:49.03 |
CIA-62 |
BRL-CAD:
03starseeker * r46452
10/brlcad/trunk/src/other/incrTcl/itk/CMakeLists.txt: Ah, right -
if itk is taking responsibility for its path setting, need to be
more complete. |
| 17:55.07 |
*** join/#brlcad nsd_
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 18:03.34 |
CIA-62 |
BRL-CAD:
03n_reed * r46453 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy:
Only reporting first syntax error instead of all of
them. |
| 18:06.22 |
CIA-62 |
BRL-CAD:
03starseeker * r46454
10/brlcad/trunk/src/other/incrTcl/itk/CMakeLists.txt: more itk
build logic cleanup |
| 18:14.07 |
brlcad |
nice ... in
response to "why reinvent the wheel?" |
| 18:14.12 |
brlcad |
"Because
after long enough time, there's always someone who's irked about
the performance of the wheel and wants to replace it with conveyor
belts or robot legs. Sometimes even square wheels. And because
we've done round wheels for so long, old lessons have faded or been
deemed outdated and so we try it. Then it turns out it's not that
great except for very limited use cases, but we're too deep
invested and stubborn so we'll try fixing it. After a lot of
fightin |
| 18:15.48 |
brlcad |
that probably
trucated the end... |
| 18:15.50 |
brlcad |
"After a lot
of fighting against windmills, we slowly reinvent and rediscover
the reasons why we used a wheel in the first place. Then the cycle
starts over. Same with most NIH projects, they start out as being
radically different and then end up looking much the same after
tackling the same challenges." |
| 18:17.01 |
starseeker |
heh |
| 18:18.07 |
starseeker |
supposes some of the CMake logic probably would fall into
that category... |
| 18:20.51 |
starseeker |
"oh, so
THAT |
| 18:20.58 |
starseeker |
's why that
compile flag is there" |
| 18:45.17 |
brlcad |
starseeker:
you could change the -D_FORTIFY_SOURCE=2 to a #define and you'd
elimiante the MSVC conditional |
| 18:46.09 |
starseeker |
erm. you
mean #define D_FORTIFY_SOURCE 2 in brlcad_config.h? |
| 18:46.17 |
starseeker |
how would
that eliminate the conditional? |
| 18:46.38 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 18:46.54 |
brlcad |
you're
presently checking for a "c flag" (which is bogus, it's a cppflag)
named "D_FORTIFY_SOURCE=2" |
| 18:47.02 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 18:47.12 |
brlcad |
that turns
into -D_FORTIFY_SOURCE=2 to gcc |
| 18:47.17 |
starseeker |
right |
| 18:47.26 |
brlcad |
presumably
/D_FORTIFY_SOURCE=2 for msvc or something similar |
| 18:48.06 |
brlcad |
either way, I
assume you hit some compilation error due to that since the
D_FORTIFY_SOURCE is rather lame gcc-specific way to test that
flag |
| 18:48.06 |
CIA-62 |
BRL-CAD:
03n_reed * r46455 10/brlcad/trunk/src/conv/obj-g_new.c: Added check
for valid number of command line arguments. |
| 18:48.17 |
brlcad |
that is
equivalent to #define _FORTIFY_SOURCE 2 |
| 18:48.25 |
starseeker |
not an error,
just a blathering warning from MSVC |
| 18:48.26 |
brlcad |
-DVAR=VAL |
| 18:48.36 |
brlcad |
is #define
VAR VAL |
| 18:49.24 |
brlcad |
so that's my
point, you could eliminate the blather by outputting the symbol
instead of trying to pass it as a compile flag |
| 18:49.40 |
brlcad |
less logic,
no conditionals |
| 18:51.07 |
brlcad |
if (MSVC)
conditionals make baby jesus cry, el no le gusta |
| 18:51.11 |
starseeker |
should it
still be conditionalized on debugging? |
| 18:51.15 |
brlcad |
sure |
| 18:51.20 |
starseeker |
hmm... |
| 18:51.59 |
starseeker |
<snort>
I'd say MSVC takes care of the crying all by itself |
| 18:52.51 |
brlcad |
sure, but it
still gets to the whole platform vs feature issue -- the
conditional is only valid today and is a major pita to maintain,
debug, and unwind later |
| 18:54.11 |
brlcad |
there's
always a better way and it's usually not even more code if
refactored according to dry principle |
| 18:56.34 |
CIA-62 |
BRL-CAD:
03starseeker * r46456 10/brlcad/trunk/ (3 files in 3 dirs): Make
_FORTIFY_SOURCE a config.h define instead of a compile flag
check. |
| 18:56.47 |
starseeker |
that what you
mean? |
| 18:57.45 |
brlcad |
exactly |
| 18:58.19 |
starseeker |
wonders why he didn't do that initially... did I misread the
autotools logic? |
| 18:59.09 |
brlcad |
wouldn't have
been an msvc issue for autotools build |
| 18:59.27 |
brlcad |
most all *nix
platforms support -DVAR=VAL |
| 18:59.37 |
brlcad |
s/platforms/compilers/ so the test
works |
| 18:59.48 |
starseeker |
ah,
right |
| 18:59.48 |
brlcad |
that
assumption is flawed for non |
| 18:59.54 |
brlcad |
"non
gcc-like" compilers |
| 19:00.21 |
brlcad |
CHECK_C_FLAG_GATHER must be something you
wrote? |
| 19:00.25 |
starseeker |
yes |
| 19:00.35 |
brlcad |
because stfw
results only in references to brl-cad :) |
| 19:01.44 |
starseeker |
yeah, there
are a few custom macros - I really should probably try to cut down
/ consolidate those at some point |
| 19:03.32 |
n_reed |
brlcad:
stfw... your initialisms are starting to get obscure |
| 19:14.59 |
brlcad |
~stfw |
| 19:14.59 |
ibot |
[stfw] Search
The F*cking Web. See http://justf*ckinggoogleit.com/ |
| 19:15.56 |
n_reed |
Already
looked it up. |
| 19:17.02 |
n_reed |
Just that
"pita" took me a sec because it wasn't in caps. "dry" I knew, but
stfw... |
| 19:17.22 |
brlcad |
wow, you knew
dry but now stfw.. that's pretty much backwards ;) |
| 19:17.36 |
brlcad |
dry is pretty
obscure |
| 19:17.54 |
brlcad |
half million
hits for stfw can't be that obscure |
| 19:18.20 |
n_reed |
well i don't
text or chat as a rule, but i have read 97 things,
so... |
| 19:23.26 |
brlcad |
stfw is
pretty chat-specific, maybe even irc-specific |
| 19:23.34 |
brlcad |
(but not
likely) |
| 19:25.50 |
``Erik |
dry is pretty
big with ruby and python folk O.o |
| 19:26.59 |
n_reed |
of which i'm
neither; that makes sense though i guess |
| 19:56.29 |
starseeker |
O.o http://labs.qt.nokia.com/2011/08/24/qt-quick-3d-tutorial-video/ |
| 20:03.52 |
CIA-62 |
BRL-CAD:
03n_reed * r46457 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy:
Allowing "" as a user-defined object name. |
| 20:05.14 |
CIA-62 |
BRL-CAD:
03starseeker * r46458 10/brlcad/trunk/src/mged/CMakeLists.txt: Fix
space in mged CMakeLists.txt - also did this for bwish, got sucked
into a previous commit. |
| 20:29.41 |
starseeker |
woot! new
obj-g (kinda) works on Windows |
| 21:14.36 |
abhi2011 |
brlcad: I
have a question regarding solid table pointers : const struct
soltab |
| 21:15.40 |
abhi2011 |
so is there a
way to get one from the struct rt_db_internal of a
primtive |
| 21:16.30 |
abhi2011 |
I need to
insert it into the rt_comb_internal |
| 21:16.40 |
abhi2011 |
while finding
the bb of a primtive |
| 21:26.06 |
abhi2011 |
or I can
avoid making a rt_comb_internal and just use the bounds already got
in the rtip (as rt_gettree() has been called) |
| 21:31.07 |
abhi2011 |
there is a
third option to use ip->idb_meth->ft_bbox() which is the new
interface for finding bbs of primitives, but thats known to not
work correctly for BOTs |
| 21:39.01 |
abhi2011 |
hmm found
rt_find_solid(), will use that |
| 22:11.48 |
*** join/#brlcad merzo
(~merzo@24-13-133-95.pool.ukrtel.net) |
| 23:11.30 |
CIA-62 |
BRL-CAD:
03n_reed * r46459 10/brlcad/trunk/src/conv/obj-g_new.c: MSVC
compiler doesn't support %zu format. Changed all instances to
%lu. |
| 00:57.35 |
brlcad |
n_reed: MSVC
doesn't need to support %zu for those functions, that's OUR
function |
| 00:58.24 |
brlcad |
bu_log()
implements support for %z along with the other bu_* vararg
functions, so what was there before was correct |
| 01:00.08 |
starseeker |
it didn't
work though |
| 01:00.38 |
starseeker |
on MSVC
anyway |
| 01:15.02 |
brlcad |
why |
| 01:16.09 |
brlcad |
it's
perfectly valid code, so if msvc is complaining, the complaint
should be scrutinized as to why |
| 01:16.53 |
brlcad |
either there
was some *other* stdlib printf-style function it encountered with a
%zu (in which case the "fix" should have been just for that
instance) |
| 01:17.51 |
brlcad |
or it really
is complaining just because it thinks it recognizes a varargs-style
function with print specifiers (in which case if it's trying to be
that clever, there should be options to turn the behavior
off) |
| 01:18.39 |
brlcad |
given we have
%zu's sprinkled in hundreds of places throughout the code, and have
for several releases, I find it a little hard to believe that it's
the latter... |
| 01:19.45 |
brlcad |
on a somewhat
related note... msvc is an environment where we've not yet vetted
"warnings mean error" because it reports too many false positives
by default, if that's coming into play |
| 01:23.35 |
brlcad |
if it's just
a warning being spit out, there are hundreds of other places so
that'd be a good one to just ignore in the output or disable for
that compiler |
| 01:44.30 |
*** join/#brlcad merzo
(~merzo@24-13-133-95.pool.ukrtel.net) |
| 01:57.25 |
starseeker |
it was
incorrect behavior - printing "zu" instead of the number in
question |
| 01:57.40 |
starseeker |
dunno if it
was one instance in the code or not though - have to ask
n_reed |
| 01:58.48 |
starseeker |
it compiles
fine and runs, just getting the strings messed up somewhere along
the line on WIN32 |
| 02:36.46 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 02:43.21 |
brlcad |
yeah, that
sounds like a bonefide libbu bug then |
| 02:43.37 |
brlcad |
all
printf-style printing is consolidated into just one or two
functions |
| 02:44.26 |
brlcad |
yeah,
src/libbu/vls.c:bu_vls_vprintf() |
| 02:44.58 |
brlcad |
ooh, I think
I see the issue |
| 02:57.00 |
CIA-62 |
BRL-CAD:
03brlcad * r46460 10/brlcad/trunk/CMakeLists.txt: might help to
actually test for size_t :) |
| 02:59.38 |
starseeker |
winces |
| 02:59.41 |
starseeker |
thanks |
| 03:01.46 |
CIA-62 |
BRL-CAD:
03starseeker * r46461 10/brlcad/trunk/src/conv/obj-g_new.c: Put zu
back - hopefully actually testing for size_t fixed it
(oopsie). |
| 03:02.05 |
brlcad |
not likely,
working ona fix |
| 03:13.37 |
CIA-62 |
BRL-CAD:
03brlcad * r46462
10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: take a stab
at implementing a new build test for c99 format specifiers. not all
of them, though, only care about %z for now since it's the one
currently causing havoc with msvc builds. |
| 03:18.21 |
CIA-62 |
BRL-CAD:
03brlcad * r46463 10/brlcad/trunk/CMakeLists.txt: |
| 03:18.21 |
CIA-62 |
BRL-CAD:
arguable whether testing libc supports %z as a print width
specifier is a |
| 03:18.21 |
CIA-62 |
BRL-CAD:
compiler characteristic or type testing but go with the latter. add
the (new |
| 03:18.21 |
CIA-62 |
BRL-CAD: and
untested) BRLCAD_CHECK_C99_FORMAT_SPECIFIERS macro so we can toggle
code |
| 03:18.21 |
CIA-62 |
BRL-CAD:
logic based on HAVE_C99_FORMAT_SPECIFIERS |
| 03:18.57 |
brlcad |
starseeker:
feel free to sanity check my feeble cmake foo there |
| 03:25.08 |
CIA-62 |
BRL-CAD:
03brlcad * r46464 10/brlcad/trunk/src/libbu/vls.c: use bu_strlcpy()
instead of strncpy() since it guarantees null-termination which we
were doing manually |
| 03:33.16 |
starseeker |
main concern
is that HAVE_STDINT_H may not be defined in that context without
setting a flag... |
| 03:54.13 |
CIA-62 |
BRL-CAD:
03starseeker * r46465
10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: This test
succeeds on a platform where I would expect it to succeed - may
need more tweaking, but I *think* this will do it. |
| 03:54.32 |
CIA-62 |
BRL-CAD:
03brlcad * r46466 10/brlcad/trunk/src/libbu/vls.c: |
| 03:54.33 |
CIA-62 |
BRL-CAD: add
in initial logic to replace instances of %z in format specifiers
for |
| 03:54.33 |
CIA-62 |
BRL-CAD:
platforms that don't support that c99 feature. since msvc is
presently the only |
| 03:54.33 |
CIA-62 |
BRL-CAD:
known platform with this busted feature behavior, scan the format
specifier and |
| 03:54.33 |
CIA-62 |
BRL-CAD:
replace instances of %z with %I which is presently more commonly
found on |
| 03:54.33 |
CIA-62 |
BRL-CAD:
win32/win64 environments. |
| 03:58.20 |
CIA-62 |
BRL-CAD:
03brlcad * r46467
10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: we
definitely need stdio.h (for sprintf()) but it shouldn't be
conditional (c89 is required) |
| 03:58.48 |
starseeker |
brlcad: you
were checking for 1 as a return from sprintf, but even on gentoo it
returns 3 (I'm fairly sure my system is new enough to support
zu...) |
| 04:01.05 |
brlcad |
hm |
| 04:05.36 |
starseeker |
what about
printing 1234 as a size_t and looking for 4 instead of
3? |
| 04:07.28 |
CIA-62 |
BRL-CAD:
03brlcad * r46468
10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: in that
same vein, we need string.h for strcmp |
| 04:09.38 |
brlcad |
starseeker:
BRLCAD_HEADER_STDC looks somewhat useless as-is |
| 04:09.54 |
starseeker |
brlcad: yeah,
probably |
| 04:10.00 |
CIA-62 |
BRL-CAD:
03starseeker * r46469
10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: tweak so
that number of chars in number doesn't match number of chars in
specifer |
| 04:10.01 |
brlcad |
iirc, the
point of AC_HEADERS_STDC is to halt if they're
available |
| 04:10.02 |
starseeker |
IIRC it was
marked as obsolete |
| 04:10.14 |
brlcad |
er, not
available |
| 04:10.23 |
brlcad |
so we know
not to even try proceeding |
| 04:10.25 |
starseeker |
usually I
just define it as 1... |
| 04:10.50 |
brlcad |
it? |
| 04:10.57 |
starseeker |
wasn't sure
if any of our supported platforms wouldn't have STDC |
| 04:11.24 |
brlcad |
we've had a
minimum compilation requirement of c89 for a couple years
now |
| 04:11.31 |
starseeker |
#define
STDC_HEADERS 1 |
| 04:11.58 |
brlcad |
yeah, that's
useless to set unless it's used somewhere by a 3rd party relying on
it getting set |
| 04:12.03 |
brlcad |
if we rely on
it, we shouldn't |
| 04:12.19 |
starseeker |
I think it's
just tcl (where I'm hhandling it anyway) |
| 04:12.40 |
brlcad |
we shouldn't
be testing anything c89 provides as a strict matter of principle
(other than as a build environment sanity check like I mentioned,
to halt) |
| 04:13.16 |
starseeker |
the only
reason it was ever there was because I was going for full parity
with the autotools build |
| 04:13.37 |
brlcad |
then it
should halt, not set a #define :) |
| 04:13.59 |
starseeker |
brlcad: I was
going to yank it |
| 04:14.44 |
brlcad |
*shrug* it's
fine in that one place, but it should serve a purpose (sanity
test) |
| 04:15.14 |
brlcad |
that's
particularly why configure.ac has that whole block that itemizes
which headers are c89, which are c95, which are c99, etc
.. |
| 04:15.22 |
starseeker |
doubt it's
worth maintaining unless there's a realistic chance we'll need it -
IIRC it was a bit of a poin |
| 04:15.25 |
starseeker |
pain
even |
| 04:15.46 |
brlcad |
absolutely
shouldn't waste time testing for c89 headers, setting HAVE_*_H
defines, nor wrapping them in #ifdef blocks |
| 04:16.36 |
starseeker |
yeah, looks
like only tcl/tk really cares |
| 04:17.06 |
brlcad |
it's just 16
lines of "code" ... if that's painful ... some threshold might need
adjusting :) |
| 04:17.28 |
starseeker |
more painful
trying to figure out what the AC macro in question was
doing |
| 04:17.38 |
brlcad |
that macro by
itself is inconsequential |
| 04:17.40 |
starseeker |
still doubts he fully duplicated all of its
testing |
| 04:18.01 |
brlcad |
it's more
making sure we don't check for c89 headers in other places like
you'd just added to that new macro |
| 04:18.53 |
brlcad |
undoubtedly,
looks like you test for but never even use
HAVE_STRING_H_MEMCHR |
| 04:19.12 |
brlcad |
and
HAVE_STDLIB_H_FREE |
| 04:19.55 |
brlcad |
unless you
make it halt, just yank it |
| 04:20.21 |
CIA-62 |
BRL-CAD:
03starseeker * r46470 10/brlcad/trunk/ (CMakeLists.txt
misc/CMake/BRLCAD_CheckFunctions.cmake): nevermind about
STDC_HEADERS - we don't really need it, only tcl/tk really use it
so let them deal with it. |
| 04:20.28 |
brlcad |
more
effective would be a test for exactly all of the c89
headers |
| 04:21.33 |
brlcad |
starseeker:
where'd be a good place to replicate the header comment block from
configure.ac to help prevent folks from adding unnecessary
tests? |
| 04:22.10 |
starseeker |
probably
stage 5 in the toplevel CMakeLists.txt file |
| 04:22.16 |
brlcad |
oh, duh
.. |
| 04:22.32 |
brlcad |
sprintf
returns number of chars printed -- was thinking sscanf |
| 04:22.42 |
starseeker |
most of the
tests are there and should go there - CheckFunctions was for
special stuff that needed something more complicated than just
checking the include file |
| 04:23.37 |
starseeker |
again based
on the autoconf tests - it may be that a lot of those could be
reduced to header checks on modern hardware |
| 04:24.43 |
starseeker |
(around line
1031 in CMakeLists.txt) |
| 04:25.04 |
brlcad |
ah, already
there .. got it |
| 04:25.39 |
starseeker |
mostly went with what was in configure.ac - "foreign" tests
that crept in usually resulted from AC_* macros of one sort or
another |
| 04:25.49 |
brlcad |
maybe worth a
build system regression? |
| 04:26.09 |
starseeker |
oh, checking
for improper tests? |
| 04:26.41 |
brlcad |
yeah |
| 04:27.10 |
brlcad |
probably
fine |
| 04:27.35 |
starseeker |
shrugs - yeah, at some point that might be worth
doing |
| 04:27.51 |
starseeker |
is hoping like heck that once this is done the build system
will require only occasional tweaking |
| 04:31.52 |
brlcad |
no
chance |
| 04:32.31 |
brlcad |
the only time
the build system doesn't require changes is when the source code
doesn't change |
| 04:33.35 |
brlcad |
even for
fully managed IDE environments like msvc, you want/need/have to
change the build system all the time as the code
evolves |
| 04:34.39 |
CIA-62 |
BRL-CAD:
03starseeker * r46471 10/brlcad/trunk/CMakeLists.txt: Hmm... it
might be that platforms with multiple CFG types shouldn't share the
same output directories... try this. |
| 04:35.28 |
starseeker |
growl |
| 04:35.31 |
brlcad |
the best you
can aim for is make the build system logic simple enough to
maintain and clean enough to be extended by a new/inexperienced
developer easily |
| 04:35.51 |
brlcad |
that's why I
kept saying "this is still code" |
| 04:36.35 |
brlcad |
all the same
coding rules and guidelines still apply, dry principle, neat
organized code, concise yet descriptive vars, etc |
| 04:38.08 |
CIA-62 |
BRL-CAD:
03brlcad * r46472 10/brlcad/trunk/CMakeLists.txt: |
| 04:38.08 |
CIA-62 |
BRL-CAD:
checking order changed. update docs. need to check compiler
characteristics |
| 04:38.08 |
CIA-62 |
BRL-CAD:
earlier within cmake so that flags are set properly. remember there
was a |
| 04:38.08 |
CIA-62 |
BRL-CAD:
specific reason for delaying the compiler testing until after
headers/libs/types |
| 04:38.08 |
CIA-62 |
BRL-CAD: with
the autotools build but don't remember what that reason was any
longer (and |
| 04:38.09 |
CIA-62 |
BRL-CAD: it's
not documented) so go with the flow -- makes more sense to test
the |
| 04:38.10 |
CIA-62 |
BRL-CAD:
compiler flags earlier anyways. |
| 04:42.11 |
CIA-62 |
BRL-CAD:
03starseeker * r46473 10/brlcad/trunk/CMakeLists.txt: typo, wording
tweak |
| 04:47.52 |
CIA-62 |
BRL-CAD:
03starseeker * r46474 10/brlcad/trunk/CMakeLists.txt: more
rewording |
| 04:50.45 |
CIA-62 |
BRL-CAD:
03starseeker * r46475 10/brlcad/trunk/CMakeLists.txt: I suppose the
date/timestamp code failing to generate a date should be fatal -
that has to be fixed if it breaks. |
| 04:55.18 |
starseeker |
hmm - I may
need to keey the #define DEBUG statement off of something other
than CMAKE_BUILD_TYPE... |
| 04:55.38 |
starseeker |
makes a note to check what that's used for
tomorrow... |
| 05:03.14 |
CIA-62 |
BRL-CAD:
03starseeker * r46476 10/brlcad/trunk/CMakeLists.txt: don't need
the math expression anymore |
| 07:27.29 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 08:08.14 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 08:35.31 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 10:32.48 |
CIA-62 |
BRL-CAD:
03n_reed * r46477 10/brlcad/trunk/src/libbu/vls.c: Typo; statement
with no effect. |
| 10:42.18 |
*** join/#brlcad n_reed_
(44378e88@gateway/web/freenode/ip.68.55.142.136) |
| 11:30.51 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl) |
| 11:53.23 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:24.28 |
brlcad |
thx n_reed,
didn't get a chance to compile-test it yet |
| 13:05.45 |
abhi2011 |
phew finally
the bb function works for all cases |
| 13:06.38 |
abhi2011 |
seems the
tree returned in a struct rt_db_internal by the function
rt_db_lookup_internal(), has the wrong op codes |
| 13:07.15 |
abhi2011 |
even if I use
the dbip got from a rtip : rt_db_lookup_internal(rtip->rti_dbip,
dp->d_namep, &dp, &intern, LOOKUP_NOISY,
&rt_uniresource) |
| 13:07.59 |
abhi2011 |
had to resort
to getting the region for a passed comb (if the comb is a region) :
regp = _rt_getregion(rtip, dp->d_namep); |
| 13:08.18 |
abhi2011 |
once I get
the region, then rt_bound_tree(regp->reg_treetop, tree_min,
tree_max) always works |
| 13:09.34 |
abhi2011 |
cant
understand why the tree returned in the struct rt_db_internal by
the function rt_db_lookup_internal() should have the wrong
op_code |
| 13:16.29 |
abhi2011 |
its certainly
not due to a lack of preparing the rtip by using rt_gettree()
etc |
| 13:18.51 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 14:27.49 |
brlcad |
abhi2011:
what do you mean by wrong op code? |
| 14:28.43 |
abhi2011 |
the code at
the primitive node is set to OP_DB_LEAF (12) when it should be set
to OP_SOLID (1) |
| 14:30.11 |
abhi2011 |
so by the
code i mean tr_a.tu_op |
| 14:30.29 |
abhi2011 |
in the union
tree of combp->tree |
| 14:31.57 |
abhi2011 |
so one would
expect this to work : http://bin.cakephp.org/view/716816388 |
| 14:32.09 |
abhi2011 |
but it
returns the bb for a region as 0 |
| 14:33.41 |
abhi2011 |
because the
tree could not be traversed completely due to the wrong code in
tr_a.tu_op, which is used during the recursion in rt_bound_tree()
as switch ( tp->tr_op)... |
| 14:38.49 |
abhi2011 |
all the other
functions which use rt_bound_tree() find a matching a region by
using for (BU_LIST_FOR(regp, region, &(rtip->HeadRegion)))
{... |
| 14:38.56 |
abhi2011 |
so they never
encounter this problem |
| 14:42.40 |
CIA-62 |
BRL-CAD:
03brlcad * r46478 10/brlcad/trunk/src/libbu/ (10
files): |
| 14:42.40 |
CIA-62 |
BRL-CAD:
rename all of the test programs to have a test_ prefix instead of a
tester |
| 14:42.40 |
CIA-62 |
BRL-CAD:
suffix. makes them easier to identify and groups tests together.
should help |
| 14:42.40 |
CIA-62 |
BRL-CAD: keep
things more organized moving forward as more unit tests are
written. |
| 14:45.46 |
CIA-62 |
BRL-CAD:
03brlcad * r46479 10/brlcad/trunk/src/libbu/ (test_basename.c
test_htond.c test_progname.c test_timer.c): update file names in
headers and usage |
| 14:56.56 |
brlcad |
abhi2011: the
code is fine |
| 14:57.17 |
brlcad |
that code
just means that it's a leaf node (which it is) and that the node is
still in db format (which it is) |
| 14:57.56 |
brlcad |
the problem
may just be that rt_bound_tree() needs to implement that switch
case |
| 14:58.51 |
brlcad |
very likely
is the problem |
| 15:00.58 |
brlcad |
nice work on
the new rt_bound_internal() though, looking great in that paste --
only issue I see are the exact (== 0) floating point comparisons at
the bottom, those should be NEAR_ZERO()) |
| 15:51.33 |
brlcad |
starseeker:
running cmake in debug mode and encountering some strange
issues |
| 15:52.37 |
brlcad |
variety of
tests that fail but shouldn't, failures detecting 32bit/64bit,
error about TEST_BIG_ENDIAN during debug but not during
non-debug |
| 15:56.49 |
abhi2011 |
brlcad: ok
then I ll add a OP_DB_LEAF case to rt_bound_internal |
| 15:57.02 |
brlcad |
abhi2011:
cool |
| 15:58.09 |
abhi2011 |
just hope its
that simple :P |
| 15:59.36 |
brlcad |
you can't
just pretend an OP_DB_LEAF is an OP_SOLID if that's what you're
thinking |
| 15:59.41 |
brlcad |
you have to
add the logic for that case |
| 16:01.26 |
abhi2011 |
yes i
understand that, however I do expect the solid pointer to be
present in tp->tr_a.tu_stp; |
| 16:02.24 |
abhi2011 |
because a
OP_DB_LEAF is the end of the line for the tree , there should no
more recursion needed |
| 16:02.32 |
brlcad |
actually I
believe that is exactly what OP_DB_LEAF means is not done
yet |
| 16:02.59 |
brlcad |
if it's in db
format, then a solid hasn't been loaded yet |
| 16:03.04 |
abhi2011 |
yes |
| 16:03.09 |
abhi2011 |
hmm |
| 16:03.29 |
abhi2011 |
and
rt_db_lookup_internal() always returns in db format |
| 16:03.41 |
brlcad |
look around
some other switch statements that use OP_DB_LEAF to see what they
do |
| 16:03.47 |
abhi2011 |
yes |
| 16:05.58 |
abhi2011 |
umm but a
question, why would the logic work if I get the same region using a
match from : for (BU_LIST_FOR(regp, region,
&(rtip->HeadRegion))) {... |
| 16:06.07 |
abhi2011 |
somehow that
is not in db format |
| 16:06.50 |
abhi2011 |
the regions
got from the rtip->HeadRegion contains a "all solids loaded"
format which works with rt_bound_tree() |
| 16:07.54 |
abhi2011 |
so something
like this works : http://bin.cakephp.org/view/1320641560 |
| 16:08.23 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 16:08.26 |
brlcad |
not sure, but
probably simply because it's just a different container -- gettrees
happens to fill out a soltab because it needs it, yet the "other"
one you get from lookup has not been loaded |
| 16:09.24 |
brlcad |
the region
search is a bit bogus, though .. not sure what that will do for
models that have no regions defined |
| 16:12.50 |
abhi2011 |
yes they
would then have groups |
| 16:13.21 |
abhi2011 |
but hmm, even
for groups I search for regions that the group contains |
| 16:13.36 |
abhi2011 |
it maybe that
the group has just prims |
| 16:41.06 |
abhi2011 |
hmm most
cases using the OP_DB_LEAF simply play around with the prim name in
tp->tr_l.tl_name , moving it from x to y :P |
| 16:41.23 |
abhi2011 |
or they
exists at the lowest db_* function level |
| 16:42.22 |
abhi2011 |
dont see any
case of converting a union tree with a OP_DB_LEAF op to a solid
with usable geometry |
| 16:45.35 |
abhi2011 |
I would have
though that there would be a function which would accept a union
tree with a OP_DB_LEAF in one of its leaves and look it up using
the db_lookup() function, then fill it with the corresponding "all
solids loaded" representation |
| 16:45.41 |
abhi2011 |
something
like that |
| 16:46.39 |
abhi2011 |
maybe I can
lookup the solid in the rtip using the tp->tr_l.tl_name, in the
OP_DB_LEAF case |
| 16:48.29 |
brlcad |
even if you
can, that's pretty much self-defeating |
| 16:48.36 |
abhi2011 |
yah
:P |
| 16:49.12 |
brlcad |
better
question to ask is how the OP_SOLID was created |
| 16:49.48 |
abhi2011 |
very deep
inside rt_gettree() |
| 16:50.41 |
abhi2011 |
or rather
rt_gettrees_muves() |
| 16:55.22 |
abhi2011 |
hmm
db_walk_tree() in the above function preps the leaves |
| 17:02.21 |
abhi2011 |
struct soltab
*_rt_find_identical_solid() seems interesting |
| 17:05.58 |
CIA-62 |
BRL-CAD:
03starseeker * r46480
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: Quiet
potentially uninitialized warning. |
| 17:54.44 |
CIA-62 |
BRL-CAD:
03brlcad * r46481 10/brlcad/trunk/src/libbu/ (CMakeLists.txt
Makefile.am test_vls.c): |
| 17:54.44 |
CIA-62 |
BRL-CAD: add
a preliminary vls unit test to make sure our printing format
specifier |
| 17:54.44 |
CIA-62 |
BRL-CAD:
behavior is consistent with stdio's behavior. particularly for
non-standard |
| 17:54.44 |
CIA-62 |
BRL-CAD:
format specifier issues like %z and %ll, make sure something sane
is happening. |
| 18:10.58 |
CIA-62 |
BRL-CAD:
03starseeker * r46482 10/brlcad/trunk/ (CMakeLists.txt
src/conv/obj-g_new.c): Ah, right - we include tcl headers, so we
define STDC_HEADERS for them. Document that. |
| 18:28.11 |
CIA-62 |
BRL-CAD:
03brlcad * r46483 10/brlcad/trunk/src/libbu/test_vls.c: expand to
include more types, legths, and some precision tests. |
| 18:30.19 |
CIA-62 |
BRL-CAD:
03brlcad * r46484 10/brlcad/trunk/src/libbu/vls.c: bu_strlcpy()
size includes the null character, make sure len is adjusted
accordingly |
| 18:44.49 |
CIA-62 |
BRL-CAD:
03brlcad * r46485 10/brlcad/trunk/src/libbu/str.c: consistency in
the >= logic -- looks like it is/was right, but was misleading
how it was using the operator |
| 18:48.32 |
CIA-62 |
BRL-CAD:
03brlcad * r46486 10/brlcad/trunk/src/libbu/vls.c: revert back to
strncpy() until we can get a proper debug in. |
| 18:54.42 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46487 10/brlcad/trunk/src/libbu/test_vls.c: mark
unused variable |
| 18:59.20 |
``Erik |
huh, for all
asc2g runs:
db_dirbuild(/usr/tmp/brlcadbuild/share/brlcad/7.20.3/db/xmp.g):
improper database, _GLOBAL object attribute 'units'= is
invalid |
| 19:05.19 |
brlcad |
yeah, that's
probably r46486 off-by-one |
| 19:10.10 |
CIA-62 |
BRL-CAD:
03brlcad * r46488 10/brlcad/trunk/src/libbu/vls.c: len is not
-1 |
| 19:15.11 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:16.09 |
abhi2011 |
there is some
code supporting the 'E' command which involves case
OP_DB_LEAF |
| 19:16.30 |
abhi2011 |
seems the
directory pointer is lookedup using dp=db_lookup() |
| 19:16.43 |
abhi2011 |
and then a
solid is added using eptr = add_solid(dp, tp->tr_l.tl_mat,
dgcdp); |
| 19:18.28 |
abhi2011 |
hmm nope, its
seems libged related , struct _ged_client_data has to be passed to
add_solid() |
| 19:18.38 |
brlcad |
``Erik: does
that fix it? |
| 19:23.55 |
starseeker |
brlcad: fixes
it here |
| 19:25.59 |
abhi2011 |
brlcad: I
think the only way to convert the OP_DB_LEAF would be to try and
look it up using db_look() |
| 19:26.16 |
abhi2011 |
prep.c uses
that for example |
| 19:27.04 |
brlcad |
abhi2011:
sounds reasonable |
| 19:27.09 |
abhi2011 |
otherwise the
only other way is to pick some code from rt_gettree() which is
going to take quite a while |
| 19:27.22 |
brlcad |
db_lookup()
would be needed to get a handle on geometry anyways (at some
point) |
| 19:28.16 |
CIA-62 |
BRL-CAD:
03brlcad * r46489 10/brlcad/trunk/src/libbu/test_vls.c: put ac and
av to good use |
| 19:28.49 |
abhi2011 |
ok |
| 19:29.17 |
brlcad |
you just
shouldn't need an rtip |
| 19:29.24 |
brlcad |
it's a db
operation |
| 19:30.31 |
brlcad |
(rt_gettree()
obviously uses an rtip, but that's because it's specificially
"getting geometry trees ready for ray tracing") |
| 19:32.52 |
``Erik |
brlcad:
yup |
| 19:33.45 |
brlcad |
cool,
thx |
| 19:35.07 |
``Erik |
(hopefully
their eyes don't bleed too much from my cmake patch)
O:-) |
| 19:48.54 |
CIA-62 |
BRL-CAD:
03brlcad * r46490 10/brlcad/trunk/src/libbu/test_vls.c: test more
width, precision, and format specifier flags to make sure vls does
what libc does |
| 19:57.00 |
starseeker |
brlcad:
http://www.cmake.org/pipermail/cmake/2011-August/046044.html |
| 20:01.20 |
brlcad |
"or the stuff
from the previous try-compile might affect the next one" <--
shouldn't happen, imho |
| 20:01.58 |
brlcad |
that sounds
like the bug to me or unexpected behavior at best |
| 20:02.46 |
brlcad |
good to hear
there's somewhat of a way to debug, but that's kinda beating around
the bush |
| 20:03.56 |
starseeker |
brlcad: I was
going to ask if the behavior could be changed to saving the files
of each test in its own subdirectory - did you want to respond
yourself? You'll undoubtedly make a more compelling case than I'll
be able to |
| 20:08.19 |
brlcad |
I'd just say
what I said here save the bush part, maybe ask why reuse the same
directory (particularly given it makes the build tests stateful) ..
the tests should be stateless, shouldn't matter if there was
already output |
| 20:08.33 |
brlcad |
(it shouldn't
read then write, it should write then read ...) |
| 20:10.07 |
brlcad |
otherwise,
i'm not on that mailing list so I won't be responding anytime soon
:) |
| 20:10.25 |
CIA-62 |
BRL-CAD:
03brlcad * r46491 10/brlcad/trunk/src/libbu/test_vls.c: couple more
tests |
| 20:15.03 |
starseeker |
urk https://sites.google.com/site/x32abi/ |
| 20:15.15 |
starseeker |
just in case
32/64 bit wasn't complicated enough... |
| 20:29.01 |
brlcad |
? |
| 20:29.27 |
starseeker |
sounded like
that might be yet a third option to the 32/64 bit option
matrix... |
| 20:29.35 |
brlcad |
that's just
describing the 64bit abi |
| 20:30.34 |
brlcad |
options on
how to run a 32-bit app on 64-bit platform (and do so portably per
the abi) |
| 20:31.00 |
starseeker |
it says it's
a "32bit psABI for x86-64 with 32bit pointer size" - does that just
mean a 32 bit API for 64 bit hardware? |
| 20:31.08 |
starseeker |
ah |
| 20:31.18 |
starseeker |
so no
compiler flags needed (hopefully) |
| 20:31.56 |
brlcad |
that's part
of it, an implementation of part of the spec |
| 20:32.48 |
brlcad |
so you can
run a 32-bit app with it's 32-bit pointers and have it play
nicely |
| 20:33.08 |
brlcad |
not something
we'll likely have to care about |
| 20:33.15 |
starseeker |
phew |
| 21:45.36 |
CIA-62 |
BRL-CAD:
03starseeker * r46492 10/brlcad/trunk/src/other/re2c.dist: add the
new re2c file to the ignore list |
| 22:29.20 |
CIA-62 |
BRL-CAD:
03n_reed * r46493
10/brlcad/trunk/src/other/lemon/CMakeLists.txt: |
| 22:29.20 |
CIA-62 |
BRL-CAD:
Lemon needs the template file in the same directory as the binary.
On systems |
| 22:29.20 |
CIA-62 |
BRL-CAD:
using configurations, that means we need to copy this file into
the |
| 22:29.20 |
CIA-62 |
BRL-CAD:
configuration binary directory, not just bin. May be more files
where this is |
| 22:29.20 |
CIA-62 |
BRL-CAD: true
- TODO. |
| 22:54.49 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 22:54.49 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 23:05.27 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 23:05.27 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 00:13.02 |
*** join/#brlcad nsd_
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 00:33.34 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46518 10/brlcad/trunk/src/librt/bbox.c: Modified the
BB function to get the BB for groups, combs and prims through tree
traversal |
| 00:39.47 |
*** join/#brlcad juanman
(~quassel@201.255.13.201) |
| 00:39.51 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 00:55.00 |
CIA-62 |
BRL-CAD:
03starseeker * r46519 10/brlcad/trunk/include/raytrace.h: fix the
rt_bound_internal header definition |
| 01:18.01 |
CIA-62 |
BRL-CAD:
03starseeker * r46520
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: There's a TODO item
to check for the -mss3 compiler flag - this does so and adds it,
but raises the qeustion about the original concerns documented for
sse flags |
| 02:18.57 |
*** join/#brlcad DarkCalff
(DC@173.231.40.98) |
| 02:28.19 |
CIA-62 |
BRL-CAD:
03brlcad * r46521 10/brlcad/trunk/src/conv/obj-g_new.c: don't peek
into the struct, bu_vls_addr() was correct. vls_str is just the
internal memory buffer allocated which may be offset and
truncated. |
| 02:33.04 |
CIA-62 |
BRL-CAD:
03brlcad * r46522 10/brlcad/trunk/src/conv/obj-g_new.c: ws
consistency, indent, trailing ws |
| 02:41.30 |
CIA-62 |
BRL-CAD:
03brlcad * r46523
10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: simplify,
there's a libbu bu_strdup() function for copying strings (and if
there wasn't, there's a libc function for that too,
strdup()). |
| 02:50.38 |
CIA-62 |
BRL-CAD:
03n_reed * r46524 10/brlcad/trunk/src/ (conv/obj-g_new.c
libgcv/wfobj/obj_parser.cpp): Don't have to copy vector elements to
array since C++ promises they are contiguous. |
| 02:59.46 |
CIA-62 |
BRL-CAD:
03brlcad * r46525 10/brlcad/trunk/src/libgcv/wfobj/obj_parser.cpp:
should be using c++ or (better) libbu memory management so error
behavior is consistent during out-of-memory conditions. signatures
don't match, though, so not a drop-in replacement as a registered
callback function. |
| 03:04.29 |
brlcad |
starseeker:
if you're testing for hypot, you could just add it to
brlcad_config.h instead of config_win.h .. the latter should nearly
go away entirely with cmake |
| 03:04.59 |
brlcad |
we couldn't
test for them with autotools, so here's a place where cmake can
outshine if it's cleaned up |
| 03:05.42 |
brlcad |
everything it
was just setting should be a functionality test (that either is
tested every time or at least run if msvc) |
| 03:17.08 |
*** join/#brlcad n_reed
(44378e88@gateway/web/freenode/ip.68.55.142.136) |
| 03:18.18 |
starseeker |
brlcad: it's
a little different... I need to define hypot to _hypot if hypot
isn't a symbol... I don't actually know how hypot and math.h are
set up elsewhere... hmm... |
| 03:19.12 |
starseeker |
again rams his head into the hard reality that There Is No
Good non-GPL Open Source Terminal Emulation For
Windows |
| 03:21.24 |
starseeker |
brlcad: is
libtermlib in src/other portable to Windows? |
| 03:29.35 |
starseeker |
yeah, the
test needed for windows will fail when it shouldn't on
Linux |
| 03:30.35 |
starseeker |
and
check_function_exists refused to work on windows |
| 03:33.18 |
starseeker |
however, even
in the worst case I can certainly do the MSVC tests and add them to
brlcad_config.h instead of config_win |
| 03:33.56 |
starseeker |
have to be
careful about maintaining the order in which they appear in the
header though |
| 03:35.07 |
starseeker |
safe way to
go would be to make some MSVC_TEST macros that would generate a
config_win the way brlcad_config is being generated now |
| 03:35.40 |
starseeker |
would
eliminate the hardcoded file, but still maintain the position of
config_win relative to brlcad_config in the include
order |
| 03:38.37 |
starseeker |
hmm - have we
ever looked at this? http://en.wikipedia.org/wiki/Tera_Term |
| 03:40.17 |
starseeker |
might just be
another putty... |
| 03:42.12 |
n_reed |
I think I've
heard it mentioned in the same sentence as putty before |
| 03:46.56 |
CIA-62 |
BRL-CAD:
03n_reed * r46526
10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: Changed
remaining instances of local string copy to bu_strdup. This memory
is freed in obj-g_new.c. |
| 03:49.46 |
starseeker |
yeah, same as
putty - if they go local they use the cygwin term stuff |
| 03:49.58 |
starseeker |
cygwin seems
to be the only game in town |
| 03:58.44 |
CIA-62 |
BRL-CAD:
03brlcad * r46527 10/brlcad/trunk/src/conv/obj-g_new.c:
bu_free_array() does the same as free_lib_array() plus a sanity
null |
| 04:00.22 |
n_reed |
clearly there
is a bu routine for everything |
| 04:02.18 |
CIA-62 |
BRL-CAD:
03brlcad * r46528 10/brlcad/trunk/src/conv/obj-g_new.c: reorder to
avoid forward decl |
| 04:05.04 |
brlcad |
starseeker:
they're all just symbols that exist or don't exist, how's that
different? |
| 04:05.53 |
brlcad |
thinks you're making it more complicated than it needs to
be |
| 04:06.21 |
starseeker |
a quick test
I just did indicates neither hypot nor _hypot exist as symbols
directly on linux |
| 04:07.12 |
brlcad |
I don't
believe that |
| 04:07.24 |
brlcad |
more than
likely, the test was flawed |
| 04:07.39 |
starseeker |
me either,
but the tests did not succeed (either CHECK_SYMBOL_EXISTS or
CHECK_FUNCTION_EXISTS) |
| 04:07.50 |
brlcad |
and why did
they fail exactly? |
| 04:08.10 |
brlcad |
more exactly,
if you wrote a little main with hypot, does it work? |
| 04:08.37 |
brlcad |
taking cmake
out of the picture first will tell you if it's a test setup
problem |
| 04:09.06 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 04:09.45 |
``Erik |
um, with
ffast-math, several math 'functions' become "magic" keywords to
gcc |
| 04:09.52 |
brlcad |
from a pure
feature test perspective, the way to platform-agnostically "do it
right" would be to test for hypot, if not found then test for
_hypot, if not found then error else #define _hypot
hypot |
| 04:10.29 |
brlcad |
last time I
tested it, ffast-math won't pass benchmark validation |
| 04:10.54 |
``Erik |
compile/link
with the same flags should find 'em (as a "run" test), but a pure
compile/link test might show weirdness in some
circumstances |
| 04:12.01 |
brlcad |
even with
ffast-math, you can still capture a pointer to the function and it
should compile/link |
| 04:12.03 |
``Erik |
I think fabs
is in the same bucket |
| 04:12.15 |
``Erik |
(haven't read
backlog, just got home) |
| 04:14.41 |
``Erik |
(or mebbe it
was an -O level that changed 'em from libray funcs to intrinsics,
hrm) |
| 04:18.21 |
starseeker |
either way,
the simple test is not working, which means it's not just a snap of
the fingers to do this |
| 04:19.07 |
starseeker |
the hypot
case was important because it's extremely noisy in VS10, but
otherwise it's not terribly urgent |
| 04:20.58 |
starseeker |
oh, that
remeinds me |
| 04:21.02 |
starseeker |
brlcad:
http://www.cmake.org/pipermail/cmake/2011-August/046059.html |
| 04:22.15 |
starseeker |
writing a
main with hypot does not work in isolation, I have to include
math.h |
| 04:22.37 |
brlcad |
I still don't
buy his reasonsing -- of course it'd leave a lot of dirs if there
were a lot of tests |
| 04:22.39 |
starseeker |
but math.h
does not directly define hypot the way it does in MSVC - tis
somewhere further down the include list |
| 04:22.51 |
brlcad |
but then the
user asked for all of those tests to get left around |
| 04:23.01 |
starseeker |
brlcad: oh, I
agree - my initial response was "yeah, it's a lot of dirs...
so?" |
| 04:23.39 |
brlcad |
starseeker: I
expect hypot() to fail on windows |
| 04:23.46 |
brlcad |
it's a c99
function, msvc is not c99 compliant |
| 04:23.57 |
starseeker |
it did, until
VS10 |
| 04:24.21 |
brlcad |
it has/had
_hypot() |
| 04:24.34 |
starseeker |
essentially,
VS10 does the #define hypot _hypot in math.h for us |
| 04:25.38 |
brlcad |
so then back
to the original assertion that it should be sufficient to test for
hypot, if not found then test for _hypot, if not found then error
else #define |
| 04:26.03 |
starseeker |
right - but
the test for hypot that succeeds on Windows fails on
Linux |
| 04:26.04 |
brlcad |
if that means
a simple custom test, that's still a very simple test |
| 04:26.24 |
brlcad |
so why does
linux fail? |
| 04:27.04 |
brlcad |
#include
"math.h" ; int main(int ac, char *av[]) { return (int)hypot(1.0,
2.0); } fails? |
| 04:27.12 |
brlcad |
you probably
need -lm |
| 04:28.29 |
brlcad |
or LIBM or
whatever you tested earlier |
| 04:29.17 |
starseeker |
yeah, looks
like it |
| 04:29.45 |
starseeker |
I can write a
macro to do that, I guess |
| 04:30.43 |
brlcad |
doesn't cmake
already do that? |
| 04:30.54 |
brlcad |
how are
functions tested if you can't specify link libraries? |
| 04:31.10 |
starseeker |
there's a
global variable you temporarily populate |
| 04:31.45 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 04:32.27 |
brlcad |
sounds akin
to how you do it in autotools for custom tests, but standard func
tests had that already built into the macro (because it's pretty
much necessary) |
| 04:33.58 |
starseeker |
some of the
macros have the extra options to let you pass stuff -
check_symbol_exists doesn't happen to be one of them, so a
BRLCAD_CHECK_SYMBOL_EXISTS wrapper is in order |
| 04:35.09 |
starseeker |
can also add
an option for a "fallback" symbol that is used for a define (e.g.
BRLCAD_CHECK_SYMBOL_EXISTS(hypot "math.h" HAVE_HYPOT _hypot) or
some such |
| 04:35.41 |
starseeker |
er
BRLCAD_CHECK_SYMBOL_EXISTS(hypot "math.h" "${M_LIBRARY}" _hypot)
rather |
| 04:35.53 |
brlcad |
check_library_exists didn't do
it? |
| 04:37.10 |
brlcad |
I wouldn't
recommend having a fallback -- even on windows, some of them have
_funcs and some don't (and it has changed over the years across
versions of msvc) |
| 04:37.13 |
starseeker |
hmm... that
might have worked - wasn't my first thought, as I wasn't looking to
confirm that the library exists but detect a symbol within
it |
| 04:37.32 |
brlcad |
really are
two separate tests, might as well be named "foo" and
"bar" |
| 04:37.57 |
brlcad |
check_library_exists tests whether a
function is in the specified library |
| 04:38.04 |
starseeker |
shakes his head - in this case, testing for _hypot and doing
the #define hypot _hypot is conditional on the outcome of the first
test |
| 04:38.58 |
brlcad |
them being
conditional doesn't mean they're not separate tests, it's what you
do with the results that is conditional |
| 04:39.21 |
*** part/#brlcad n_reed
(44378e88@gateway/web/freenode/ip.68.55.142.136) |
| 04:39.40 |
starseeker |
testing for
_hypot is a total waste of time if we have hypot though |
| 04:40.02 |
brlcad |
of course,
you test for hypot first |
| 04:40.11 |
brlcad |
it's just
nested testing |
| 04:40.33 |
brlcad |
if test funcA
fails, test funcB; if test funcB succeeds, "do something useful" ..
which in this case is #define funcA funcB |
| 04:40.35 |
starseeker |
oh, I know
why check_library_exists wasn't the right approach - with MSVC,
there IS no math library |
| 04:40.38 |
starseeker |
M_LIBRARY is
empty |
| 04:40.50 |
brlcad |
not
true |
| 04:41.05 |
starseeker |
our M_LIBRARY
variable is empty |
| 04:41.06 |
brlcad |
there IS a
math library .. it's just not self-contained |
| 04:41.13 |
brlcad |
sure |
| 04:41.18 |
starseeker |
that's what
matters |
| 04:41.21 |
brlcad |
there is not
"m.dll :) |
| 04:41.27 |
starseeker |
right |
| 04:41.55 |
brlcad |
so you're not
testing all the possible libraries that might have that
symbol |
| 04:42.20 |
starseeker |
on Windows
it's not necessary - we don't have to specifically link a math
library |
| 04:42.50 |
brlcad |
irrelevant
from a configuration perspective |
| 04:43.28 |
*** join/#brlcad BenDansie
(~chatzilla@182-239-205-11.ip.adam.com.au) |
| 04:44.14 |
brlcad |
I'm not
disagreeing, this is all old old news to me :) .. it's how to think
about solving the problem in generic non-platform specific
terms |
| 04:44.28 |
BenDansie |
Hi
all |
| 04:44.44 |
brlcad |
this isn't
really specific to windows, there are other symbols that behave
exactly like this for other platforms/environments |
| 04:44.48 |
brlcad |
BenDansie:
hello |
| 04:44.57 |
starseeker |
brlcad: sure,
but there are practical aspects to this - our Windows config is
already a factor of 10 longer than any other platform |
| 04:45.12 |
starseeker |
all of these
new tests we're talking about here will make that worse |
| 04:45.24 |
brlcad |
our source
code is probably a factor 10 larger than other software too, not
sure that matters |
| 04:46.04 |
starseeker |
I mean it
takes forever to run a CMake config on Windows - from a development
cycle standpoint, lengthening it further sucks |
| 04:46.26 |
brlcad |
like the
earlier discussion -- IFF after all the tests are added it really
drags things down, then the tests could all get wrapped in *just
one* big if-MSVC-then-do-these-tests conditional |
| 04:46.28 |
starseeker |
I'm not
denying it may be worth it from a "cross platform cleanliness"
standpoint, but it will have an impact |
| 04:47.14 |
BenDansie |
Hope I'm not
interrupting, but could someone lend me a hand with how to import
an iges file and export to something else like stl or obj? I'm new
to BRL-CAD. Would be greatly appreciated |
| 04:47.58 |
brlcad |
adding 10 min
to the windows build at arl is frankly inconsequential, that's a
limitation of that environment and specific to that
platform |
| 04:48.01 |
brlcad |
the build
already takes a couple hours, barely a blip |
| 04:48.15 |
brlcad |
BenDansie: it
depends what kind of iges file you have |
| 04:48.30 |
brlcad |
it'll either
work or crash and burn |
| 04:49.26 |
brlcad |
the iges
importer hasn't been updated in quite a while so there are several
"gotchyas" possible, some out of our control, some specific to iges
versioning, some specific to what software exported the iges
file |
| 04:49.41 |
BenDansie |
Right. The
deal is I work for a multimedia company, and we've been supplied
the .igs file straight from the cad designers. So we are figuring
it out as we go to convert the file into something we can
use. |
| 04:50.06 |
BenDansie |
So assuming
it works, what is the process? Trying to read through the
documentation on the website |
| 04:50.18 |
brlcad |
what software
are you trying to use the geometry in? |
| 04:50.38 |
brlcad |
iges-g has
pretty extensive usage |
| 04:51.16 |
brlcad |
iges-g -d -o
file.g file.igs |
| 04:51.21 |
brlcad |
or -3 instead
of -d |
| 04:51.47 |
brlcad |
or maybe -p
in addition to -d |
| 04:51.53 |
starseeker |
if it brings
in spline/NURBS surfaces, that's not going to export to an stl file
at the moment |
| 04:51.54 |
BenDansie |
3ds Max,
which has an importer, but it fails on the larger of the two files
we need. |
| 04:51.55 |
brlcad |
it totally
depends what's in the .igs file |
| 04:51.57 |
BenDansie |
thanks |
| 04:52.28 |
brlcad |
that doesn't
bode well if 3dsmax fails :) |
| 04:52.57 |
BenDansie |
ah. Rhino
also fails, but due to memory. Rhino still being 32 bit |
| 04:53.06 |
brlcad |
I can take a
quick look at trying the conversion myself if you care to share the
datafile |
| 04:53.08 |
starseeker |
BenDansie:
can you have them send you several smaller .igs files with
pieces? |
| 04:53.36 |
brlcad |
could be a
simple matter of blowing out 32-bit memory, in which case you may
need a 64-bit compile of BRL-CAD too |
| 04:53.45 |
brlcad |
though I
suspect our iges importer is leaner than 3ds |
| 04:54.35 |
brlcad |
notes that exists is a nice parallel to
"test" |
| 04:54.52 |
brlcad |
should use a
similar syntax |
| 04:55.30 |
brlcad |
starseeker:
that's up there with 'search' ;) |
| 04:55.37 |
brlcad |
a lot simpler
to implement though |
| 04:55.56 |
starseeker |
erm... test
being the unix command line program test? |
| 04:56.11 |
BenDansie |
Well, step
one is to go back and grab the 64 bit version it seems...
:) |
| 04:56.42 |
starseeker |
reads the man page... |
| 04:58.10 |
starseeker |
irk. there
are a few dragons here. what does it mean for an object to be
greater than or less than another object? we don't support
modification date for objects (at the moment,
anyway)... |
| 04:59.07 |
starseeker |
the -d, -f,
etc options would probably translate into something like test -g
sph obj1.s, test -g eto obj1.s, etc... |
| 05:00.42 |
starseeker |
could really
go hog wild and do test -O obj1.s obj2.s for overlap testing
:-P |
| 05:01.34 |
starseeker |
or I guess
test obj1.s -O obj2.s would be more in keeping with the STRING1 =
STRING2 theme |
| 05:02.11 |
starseeker |
would have to
be dbtest though - looks like test does something in
tcl |
| 05:04.06 |
brlcad |
starseeker:
right, so the date-baesd tests cannot be implemented today (but
will be with rel8) |
| 05:04.32 |
brlcad |
the other
>, < tests are lexicographical, though, are trivial to
implemnet |
| 05:04.50 |
starseeker |
sure, if we
go with string comparisons of the names |
| 05:05.01 |
brlcad |
and EXACTLY
regarding specialty options like overlap testing |
| 05:05.06 |
starseeker |
rather liked the idea of bounding box
volumes... |
| 05:05.10 |
brlcad |
that'd be the
bomb |
| 05:05.34 |
brlcad |
"test" does
existance, date, lexi, and more |
| 05:06.11 |
brlcad |
exists even
works as an alternate name like search:find |
| 05:06.33 |
BenDansie |
"file is not
in iges ascii format" - am I out of luck on this one? |
| 05:06.41 |
brlcad |
does foo
exist lexicographically before bar? well: exists foo <
bar |
| 05:07.07 |
brlcad |
BenDansie:
no, there are binary and ascii versions of iges files |
| 05:07.45 |
brlcad |
er, scratch
that |
| 05:07.50 |
brlcad |
thinking of a
different format |
| 05:08.19 |
starseeker |
considers exists vs. dbtest... hmm. exists might be a little
too specific for something so general |
| 05:08.55 |
starseeker |
exists
"works" lexicographically perhaps, but I wouldn't have thought of
it out of context |
| 05:09.15 |
brlcad |
BenDansie: do
you know if your file is binary or ascii? |
| 05:09.44 |
starseeker |
or we could
make a ged tcl namespace and stuff all of our commands in there,
then default to that namespace in mged |
| 05:10.16 |
starseeker |
require
explicit tcl namespace calls or a "set namespace tcl" option or
some such |
| 05:10.33 |
starseeker |
then search
really could be find and test could be test :-) |
| 05:11.41 |
BenDansie |
ahah! making
progress now. Seems the first time I tried I did the export
filenames the wrong way around and wrote over the .igs |
| 05:11.48 |
brlcad |
if you read
the manpage for test, most of the tests are "does this
exist" |
| 05:11.51 |
BenDansie |
copied the
original again and got further |
| 05:12.01 |
brlcad |
that's what
makes "exists" a particularly good fit |
| 05:12.53 |
brlcad |
BenDansie:
aha, that'll do it ;) |
| 05:13.16 |
starseeker |
checks out the bsd test codebases... yay, another deliverable
nobody asked for :-P |
| 05:13.35 |
brlcad |
I wouldn't
even use bsd as a starting point |
| 05:13.52 |
brlcad |
the tests are
simple to write |
| 05:14.38 |
starseeker |
was thinking
the multiple expression evaluation logic |
| 05:14.45 |
brlcad |
ah,
perhaps |
| 05:14.57 |
BenDansie |
Converting
solid entities: |
| 05:14.58 |
brlcad |
that is
pretty powerful stuff |
| 05:14.59 |
BenDansie |
No parameter
curve for eu x5a97f20 |
| 05:15.00 |
BenDansie |
ivert=x67c9b20, jvert=x67ca0c0,
eu->vu_p->v_p=x67ca0c0,
eu->eumate_p->vu_p->v_p= |
| 05:15.00 |
starseeker |
EXPRESSION1
-a EXPRESSION2 etc. |
| 05:15.02 |
BenDansie |
x67ca0a0 |
| 05:15.03 |
BenDansie |
Add_nurb_loop_to_face: Edgeuse/vertex
mixup! |
| 05:15.18 |
brlcad |
BenDansie:
don't use -n |
| 05:15.20 |
starseeker |
sounds like
it's importing NURBS |
| 05:16.09 |
brlcad |
nor
-t |
| 05:16.49 |
brlcad |
if you run
without any options, it should give an analysis of what is in the
file |
| 05:16.55 |
brlcad |
iges-g -o
file.g file.igs |
| 05:17.05 |
brlcad |
probably
saying, "try adding -3" |
| 05:17.43 |
brlcad |
default may
even work if you're REALLY really REALLY lucky |
| 05:22.31 |
starseeker |
sweet -
public domain even:
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/bin/test/test.c |
| 05:23.35 |
starseeker |
will vacuum out the file specific stuff tomorrow and see
about converting that into exists |
| 05:26.23 |
CIA-62 |
BRL-CAD:
03brlcad * r46529 10/brlcad/trunk/TODO: the new 'exists' command is
a beautiful corollary to the unix 'test' command.. embrace the
familiar usage (make it the same where possible) and extend with
geometry-specific features. |
| 05:27.12 |
brlcad |
I love how
core unix commands are so short and sweet, easy to understand and
modify |
| 05:27.35 |
brlcad |
great
examples of how less is more |
| 07:48.36 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 09:42.49 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 09:42.50 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 09:43.47 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 10:13.56 |
*** join/#brlcad betta_y_omega
(~betta_y_o@90.166.231.220) |
| 10:46.37 |
CIA-62 |
BRL-CAD:
03Ontwe 07http://brlcad.org * r3087
10/wiki/Wiki_Support_for_unexperienced_users: New page: New Users
often need help about [http://www.mediawiki.com
Mediawiki] |
| 11:03.37 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 12:31.49 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 12:32.45 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 12:42.44 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 13:07.11 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 13:15.45 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46530 10/brlcad/trunk/src/conv/obj-g_new.c: cast
const char** to char ** to match type. Add missing third parameter
to bu_free_array. |
| 13:40.58 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46531 10/brlcad/trunk/src/libgcv/bottess.c:
Convert big scary macros to functions. Change explicit static to
HIDDEN. Add more optional output. |
| 13:49.59 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46532 10/brlcad/trunk/src/libgcv/bottess.c:
remove inline keyword |
| 14:08.18 |
CIA-62 |
BRL-CAD:
03n_reed * r46533 10/brlcad/trunk/src/conv/obj-g_new.c: Should be
passing char**, not char***, to bu_free_array. |
| 14:15.07 |
abhi2011 |
anyone else
getting an error during install like : CMake Error at
include/cmake_install.cmake:36 (FILE): file INSTALL cannot find
"/home/abhi/socis/brlcad/include/config_win_cmake.h". |
| 14:34.37 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46534 10/brlcad/trunk/TODO: add marching cubes
to libged facetize |
| 14:38.51 |
brlcad |
gah, we
really need to get continuous integration going .. |
| 14:38.56 |
brlcad |
too many
commit/compile failures |
| 14:39.48 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Wiki Support for
unexperienced users]]": content was: 'New Users often need help
about [http://www.mediawiki.com Mediawiki]'
(and the only contributor was
'[[Special:Contributions/Ontwe|Ontwe]]') |
| 14:41.25 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Ontwe]] with an expiry
time of infinite (account creation disabled, e-mail blocked):
Spamming links to external sites |
| 14:51.39 |
CIA-62 |
BRL-CAD:
0391.124.110.50 07http://brlcad.org
* r3088 10/wiki/Google_Summer_of_Code: |
| 14:53.11 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 15:00.11 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r3089
10/wiki/Google_Summer_of_Code: Reverted edits by
[[Special:Contributions/91.124.110.50|91.124.110.50]] ([[User
talk:91.124.110.50|Talk]]); changed back to last version by
[[User:Sean|Sean]] |
| 15:30.15 |
starseeker |
abhi2011: ah,
sorry - that's me |
| 15:30.25 |
starseeker |
abhi2011: one
second... |
| 15:32.52 |
CIA-62 |
BRL-CAD:
03starseeker * r46535 10/brlcad/trunk/include/CMakeLists.txt:
Ooops, right - config_win_cmake is now a configure_file, treat it
accordingly. |
| 15:34.38 |
starseeker |
that should
do it |
| 15:34.44 |
starseeker |
bhinesley:
around? |
| 15:43.47 |
CIA-62 |
BRL-CAD:
03d_rossberg * r46536 10/brlcad/trunk/src/librt/bbox.c: |
| 15:43.47 |
CIA-62 |
BRL-CAD: for
the Windows build: MSVC is not C99 |
| 15:43.47 |
CIA-62 |
BRL-CAD:
moved variable declarations upwards |
| 15:51.46 |
CIA-62 |
BRL-CAD:
03n_reed * r46537 10/brlcad/trunk/src/conv/obj-g_new.c: Freeing the
rest of the arrays with bu_free_array. |
| 16:20.53 |
CIA-62 |
BRL-CAD:
03n_reed * r46538 10/brlcad/trunk/src/libgcv/wfobj/re2c_utils.c:
Using bu_vls_addr instead of accessing vls_str
directly. |
| 16:23.57 |
abhi2011 |
starseeker:
all good now :) |
| 17:22.12 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46539 10/brlcad/trunk/src/conv/stl/g-stl.c: add
-8 (marching cubes) to usage |
| 17:33.23 |
brlcad |
starseeker:
so I have a clean checkout/configure going now and still seeing a
slew of tests fail that should not be failing |
| 17:34.52 |
brlcad |
dlopen,
getprogname (which might be "correct"), setprogname (also maybe
"correct" with std99), strlcat, strlcpy,
sizeof(socklen_t) |
| 17:35.08 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 17:41.43 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 18:25.51 |
*** join/#brlcad merzo
(~merzo@98-229-132-95.pool.ukrtel.net) |
| 19:05.58 |
CIA-62 |
BRL-CAD:
03brlcad * r46540 10/brlcad/trunk/CMakeLists.txt: distinguish
compilation of 3rd party sources from our own build settings with
different labels. Use 'Compile' instead of 'Build' since that helps
disambiguate what the ON/OFF means (i.e., action not
feature). |
| 19:06.55 |
*** join/#brlcad merzo
(~merzo@98-229-132-95.pool.ukrtel.net) |
| 20:32.51 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46541 10/brlcad/trunk/src/libged/simulate/simulate.h:
Added new header file to declare structures for passing sim
parameters |
| 20:33.42 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46542
10/brlcad/trunk/src/libged/simulate/CMakeLists.txt: Added
simulate.h new header to CMake |
| 20:35.10 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46543 10/brlcad/trunk/src/libged/simulate/
(simphysics.cpp simulate.c): Changed simulate command logic to
duplicate and pass regions to bullet |
| 20:38.21 |
CIA-62 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3090 10/wiki/User:Abhijit: /* Log */ |
| 20:42.35 |
CIA-62 |
BRL-CAD:
03abhi2011 * r46544 10/brlcad/trunk/src/libged/simulate/simulate.h:
Modified some comments to indicate the reason for
simulate.h |
| 21:00.12 |
CIA-62 |
BRL-CAD:
03bob1961 * r46545 10/brlcad/trunk/ (include/ged.h include/tclcad.h
src/libtclcad/tclcad_obj.c): Moved and renamed a few mode related
macros that are used only by libtclcad from ged.h to
tclcad.h. |
| 21:22.24 |
starseeker |
brlcad: out
of curiosity, what does autotools configure say about those on the
same machine? |
| 21:23.41 |
brlcad |
don't know,
blew away my autotools build |
| 21:23.55 |
starseeker |
ah,
k |
| 21:24.03 |
brlcad |
don't want to
mix the two for a few days just to make sure everything I'm seeing
is "pure cmake" |
| 21:24.24 |
brlcad |
still trying
to verify that nothing in main dir isn't getting
modified |
| 21:25.36 |
brlcad |
so far
looking good after a full build |
| 21:28.16 |
starseeker |
if you really
want to go whole hog on that, strip all the svn:ignore stuff we've
got |
| 21:28.24 |
starseeker |
did that in the cmake branch |
| 21:28.40 |
starseeker |
was planning
to do it in trunk once we no longer support autotools |
| 22:32.44 |
CIA-62 |
BRL-CAD:
03n_reed * r46546 10/brlcad/trunk/src/conv/obj-g_new.c: Distance
tolerance changed from .0005 to .005. |
| 22:33.29 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 22:46.07 |
CIA-62 |
BRL-CAD:
03starseeker * r46547 10/brlcad/trunk/ (CMakeLists.txt
include/CMakeLists.txt): Improve handling of newlines for system
conf files |
| 22:49.51 |
CIA-62 |
BRL-CAD:
03starseeker * r46548 10/brlcad/trunk/CMakeLists.txt: use all the
CPUs we can - go with 20 as a good number given current systems
(2011) |
| 23:16.04 |
*** join/#brlcad nsd_
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 23:35.32 |
*** join/#brlcad n_reed
(44378e88@gateway/web/freenode/ip.68.55.142.136) |
| 23:51.02 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 00:14.21 |
CIA-62 |
BRL-CAD:
0364.120.86.29 07http://ist.brlcad.org * r3099
10/wiki/Hunderte_gratis_Besucher_mit_Social_Bookmarking_26: New
page: [[Image:social_bookmarking_service_1862.jpg|thumb|]]
Toothsome yous any [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that permits owners to share links on
th... |
| 00:25.28 |
CIA-62 |
BRL-CAD:
03173.208.25.215 07http://brlcad.org * r3100
10/wiki/Service_was_lovely_71: New page:
[[Image:social_bookmarking_service_5574.jpg|thumb|]] StumbleUpon is
a [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] with users to find new websites based
on t... |
| 00:30.48 |
CIA-62 |
BRL-CAD:
03173.234.94.105 07http://bz.brlcad.org * r3101
10/wiki/Shitty_service_at_friendlys_on_57_79: New page:
[[Image:social_bookmarking_service_2992.jpg|thumb|]] Whilst
checking your daily website metrics within Google Analytics, you
might be delighted to find that is someone has shared a link
t... |
| 00:31.18 |
CIA-62 |
BRL-CAD:
03173.234.175.26 07http://www.solidgeometry.org *
r3102
10/wiki/Okay_now_I_m_just_annoyed_Can_Social_Distortion_consider_the_stage_now_75:
New page: [[Image:social_bookmarking_service_3643.jpg|thumb|]]
StumbleUpon may be an essential device to increase your amount
about visitors. StumbleUpon is a [http://lease-a-seo.com/social-bookma... |
| 00:51.26 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 00:58.30 |
CIA-62 |
BRL-CAD:
03173.234.143.96 07http://brlcad.org * r3103
10/wiki/The_Bayou_Bonfouca_Bridge_on_LA_433_is_back_in_service_St_Tammany_87:
New page: [[Image:social_bookmarking_service_5054.jpg|thumb|]]
Delicious is some [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that is allows buyers to share links on
t... |
| 01:03.25 |
CIA-62 |
BRL-CAD:
03173.234.94.105 07http://bz.brlcad.org * r3104
10/wiki/I_am_not_anti_public_I_just_Do_Not_like_you_20: New page:
[[Image:social_bookmarking_service_2366.jpg|thumb|]] StumbleUpon is
any [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] to users to learn new websites based on
... |
| 01:13.07 |
CIA-62 |
BRL-CAD:
03173.234.143.96 07http://ist.brlcad.org * r3105
10/wiki/Baby_Social_Worker_Doctor_is_my_favourite_Doctor_24: New
page: [[Image:social_bookmarking_service_5000.jpg|thumb|]] Whilst
checking your everyday web site metrics in Google Analytics, you
might be thrilled to find that is someone has shared a link
to... |
| 01:17.55 |
CIA-62 |
BRL-CAD:
0364.120.117.41 07http://ist.brlcad.org * r3106
10/wiki/Lol_mi_no_put_on_me_service_yet_eno_beb_Oh_lol_when_74: New
page: [[Image:social_bookmarking_service_1881.jpg|thumb|]] Tasty is
some [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that allows consumers to share links on
the w... |
| 01:42.30 |
CIA-62 |
BRL-CAD:
03173.234.187.29 07http://bz.brlcad.org * r3107
10/wiki/Ppc_services_social_bookmarking_website_promotion_14: New
page: [[Image:social_bookmarking_service_1744.jpg|thumb|]] Web 2.0
tools can link your students along with resources around the world.
Web 2.0 explains the progress toward collaborative,
share... |
| 01:57.46 |
CIA-62 |
BRL-CAD:
03173.234.176.193 07http://ist.brlcad.org * r3108
10/wiki/In_two_weeks_yeah_haha_get_off_twitter_this_is_my_social_network_30:
New page: [[Image:social_bookmarking_service_5335.jpg|thumb|]]
Whilst checking your regular website metrics in Google Analytics,
you might be delighted to find that someone has shared some link to
... |
| 02:03.10 |
CIA-62 |
BRL-CAD:
03173.234.93.135 07http://brlcad.org * r3109
10/wiki/La_vida_social_no_me_dejo_escribir_mucho_estas_ultimas_horas_87:
New page: [[Image:social_bookmarking_service_1607.jpg|thumb|]] Web
2.0 gear can link your students by resources around the community.
Web 2.0 explains the progress toward collaborative, shared,
mu... |
| 02:04.54 |
CIA-62 |
BRL-CAD:
0364.120.38.9 07http://bz.brlcad.org * r3110
10/wiki/Amr_ta_On_em_alguma_rede_social_67: New page:
[[Image:social_bookmarking_service_4116.jpg|thumb|]] While checking
your every day internet site metrics from Google Analytics, you
might be delighted to find that somebody has shared
any... |
| 02:05.06 |
CIA-62 |
BRL-CAD:
03173.234.245.28 07http://www.solidgeometry.org *
r3111 10/wiki/At_your_service_sir_87: New page:
[[Image:social_bookmarking_service_4617.jpg|thumb|]] While checking
your regular website metrics with Google Analytics, you might be
delighted to discover that someone has shared a link
t... |
| 02:33.55 |
CIA-62 |
BRL-CAD:
0364.120.38.9 07http://bz.brlcad.org * r3112
10/wiki/I_dont_have_no_service_26: New page:
[[Image:social_bookmarking_service_4706.jpg|thumb|]] Label the
website in keywords to assist other owners identify hers content.
Trouble: Tolerably Easy Directions 1 Warning up for a
[... |
| 02:34.37 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.208.24.246]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:35.40 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:35.40 |
CIA-62 |
BRL-CAD:
deleted "[[Sunday morning televised service at the crystal
cathedral Channel 40 |
| 02:35.40 |
CIA-62 |
BRL-CAD:
25]]": content was:
'[[Image:social_bookmarking_service_4995.jpg|thumb|]]Web
2.0 |
| 02:35.40 |
CIA-62 |
BRL-CAD:
describes the shift toward cooperative, shared, multimedia
experiences on the |
| 02:35.40 |
CIA-62 |
BRL-CAD: Web.
Parti...' (and the only contributor was |
| 02:35.40 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.208.24.246|173.208.24.246]]') |
| 02:36.11 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.187.29]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:36.46 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:36.46 |
CIA-62 |
BRL-CAD:
deleted "[[Not long after support had to stay choir practice lol
39]]": content |
| 02:36.46 |
CIA-62 |
BRL-CAD: was:
'[[Image:social_bookmarking_service_3018.jpg|thumb|]]StumbleUpon
remains a |
| 02:36.46 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service]...' |
| 02:36.46 |
CIA-62 |
BRL-CAD: (and
the only contributor was |
| 02:36.47 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.187.29|173.234.187.29]]') |
| 02:37.12 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.11.159]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:37.22 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:37.22 |
CIA-62 |
BRL-CAD:
deleted "[[Que puto empinado social 53]]": content was: |
| 02:37.22 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_3786.jpg|thumb|]]StumbleUpon
remains some |
| 02:37.22 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking servi...' (and |
| 02:37.23 |
CIA-62 |
BRL-CAD: the
only contributor was |
| 02:37.23 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.11.159|173.234.11.159]]') |
| 02:38.07 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:64.120.86.29]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:38.18 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:38.18 |
CIA-62 |
BRL-CAD:
deleted "[[Hunderte gratis Besucher mit Social Bookmarking 26]]":
content was: |
| 02:38.18 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_1862.jpg|thumb|]]Toothsome yous
any |
| 02:38.18 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] |
| 02:38.19 |
CIA-62 |
BRL-CAD:
th...' (and the only contributor was |
| 02:38.19 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/64.120.86.29|64.120.86.29]]') |
| 02:38.39 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.208.25.215]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:38.54 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:38.54 |
CIA-62 |
BRL-CAD:
deleted "[[Service was lovely 71]]": content was: |
| 02:38.54 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_5574.jpg|thumb|]]StumbleUpon is
a |
| 02:38.54 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] |
| 02:38.54 |
CIA-62 |
BRL-CAD:
with...' (and the only contributor was |
| 02:38.55 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.208.25.215|173.208.25.215]]') |
| 02:39.04 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.94.105]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:39.16 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:39.16 |
CIA-62 |
BRL-CAD:
deleted "[[Shitty service at friendlys on 57 79]]": content
was: |
| 02:39.16 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_2992.jpg|thumb|]]Whilst
checking your daily |
| 02:39.16 |
CIA-62 |
BRL-CAD:
website metrics within Google Analytics, you might be delighted to
fi...' (and |
| 02:39.17 |
CIA-62 |
BRL-CAD: the
only contributor was |
| 02:39.17 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.94.105|173.234.94.105]]') |
| 02:40.02 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:40.02 |
CIA-62 |
BRL-CAD:
deleted "[[Okay now I m just annoyed Can Social Distortion consider
the stage |
| 02:40.02 |
CIA-62 |
BRL-CAD: now
75]]": content was: |
| 02:40.02 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_3643.jpg|thumb|]]StumbleUpon
may be an |
| 02:40.02 |
CIA-62 |
BRL-CAD:
essential device to increase your amount about visitors.StumbleUpon
is a...' |
| 02:40.03 |
CIA-62 |
BRL-CAD: (and
the only contributor was |
| 02:40.04 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.175.26|173.234.175.26]]') |
| 02:40.22 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.143.96]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:40.44 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:40.44 |
CIA-62 |
BRL-CAD:
deleted "[[The Bayou Bonfouca Bridge on LA 433 is back in service
St Tammany |
| 02:40.44 |
CIA-62 |
BRL-CAD:
87]]": content was: |
| 02:40.44 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_5054.jpg|thumb|]]Delicious is
some |
| 02:40.44 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] |
| 02:40.45 |
CIA-62 |
BRL-CAD:
tha...' (and the only contributor was |
| 02:40.45 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.143.96|173.234.143.96]]') |
| 02:41.15 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:41.15 |
CIA-62 |
BRL-CAD:
deleted "[[I am not anti public I just Do Not like you 20]]":
content was: |
| 02:41.15 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_2366.jpg|thumb|]]StumbleUpon is
any |
| 02:41.15 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] |
| 02:41.15 |
CIA-62 |
BRL-CAD:
to...' (and the only contributor was |
| 02:41.15 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.94.105|173.234.94.105]]') |
| 02:41.52 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:41.52 |
CIA-62 |
BRL-CAD:
deleted "[[Baby Social Worker Doctor is my favourite Doctor 24]]":
content was: |
| 02:41.52 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_5000.jpg|thumb|]]Whilst
checking your |
| 02:41.52 |
CIA-62 |
BRL-CAD:
everyday web site metrics in Google Analytics, you might be
thrilled to fin...' |
| 02:41.52 |
CIA-62 |
BRL-CAD: (and
the only contributor was |
| 02:41.52 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.143.96|173.234.143.96]]') |
| 02:42.04 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:64.120.117.41]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:42.25 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:42.26 |
CIA-62 |
BRL-CAD:
deleted "[[Lol mi no put on me service yet eno beb Oh lol when
74]]": content |
| 02:42.26 |
CIA-62 |
BRL-CAD: was:
'[[Image:social_bookmarking_service_1881.jpg|thumb|]]Tasty is
some |
| 02:42.26 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that |
| 02:42.26 |
CIA-62 |
BRL-CAD:
al...' (and the only contributor was |
| 02:42.26 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/64.120.117.41|64.120.117.41]]') |
| 02:42.39 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:42.39 |
CIA-62 |
BRL-CAD:
deleted "[[Ppc services social bookmarking website promotion 14]]":
content was: |
| 02:42.39 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_1744.jpg|thumb|]]Web 2.0 tools
can link your |
| 02:42.39 |
CIA-62 |
BRL-CAD:
students along with resources around the world.Web 2.0 explains
th...' (and the |
| 02:42.39 |
CIA-62 |
BRL-CAD: only
contributor was
'[[Special:Contributions/173.234.187.29|173.234.187.29]]') |
| 02:42.55 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.176.193]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:43.08 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:43.08 |
CIA-62 |
BRL-CAD:
deleted "[[In two weeks yeah haha get off twitter this is my social
network |
| 02:43.08 |
CIA-62 |
BRL-CAD:
30]]": content was:
'[[Image:social_bookmarking_service_5335.jpg|thumb|]]Whilst |
| 02:43.08 |
CIA-62 |
BRL-CAD:
checking your regular website metrics in Google Analytics, you
might be |
| 02:43.09 |
CIA-62 |
BRL-CAD:
delighted to find...' (and the only contributor was |
| 02:43.09 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.176.193|173.234.176.193]]') |
| 02:43.41 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.93.135]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:43.52 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:43.53 |
CIA-62 |
BRL-CAD:
deleted "[[La vida social no me dejo escribir mucho estas ultimas
horas 87]]": |
| 02:43.53 |
CIA-62 |
BRL-CAD:
content was:
'[[Image:social_bookmarking_service_1607.jpg|thumb|]]Web 2.0
gear |
| 02:43.53 |
CIA-62 |
BRL-CAD: can
link your students by resources around the community.Web 2.0
explains the |
| 02:43.53 |
CIA-62 |
BRL-CAD:
pro...' (and the only contributor was |
| 02:43.53 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.93.135|173.234.93.135]]') |
| 02:44.05 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:64.120.38.9]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:44.21 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:44.21 |
CIA-62 |
BRL-CAD:
deleted "[[Amr ta On em alguma rede social 67]]": content
was: |
| 02:44.21 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_4116.jpg|thumb|]]While checking
your every |
| 02:44.21 |
CIA-62 |
BRL-CAD: day
internet site metrics from Google Analytics, you might be
delighte...' (and |
| 02:44.22 |
CIA-62 |
BRL-CAD: the
only contributor was
'[[Special:Contributions/64.120.38.9|64.120.38.9]]') |
| 02:44.31 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:44.31 |
CIA-62 |
BRL-CAD:
deleted "[[At your service sir 87]]": content was: |
| 02:44.31 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_4617.jpg|thumb|]]While checking
your regular |
| 02:44.31 |
CIA-62 |
BRL-CAD:
website metrics with Google Analytics, you might be delighted to
dis...' (and |
| 02:44.32 |
CIA-62 |
BRL-CAD: the
only contributor was |
| 02:44.32 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.245.28|173.234.245.28]]') |
| 02:44.41 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:44.41 |
CIA-62 |
BRL-CAD:
deleted "[[I dont have no service 26]]": content was: |
| 02:44.41 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_4706.jpg|thumb|]]Label the
website in |
| 02:44.41 |
CIA-62 |
BRL-CAD:
keywords to assist other owners identify hers
content.Trouble:Tolerably ...' |
| 02:44.42 |
CIA-62 |
BRL-CAD: (and
the only contributor was |
| 02:44.42 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/64.120.38.9|64.120.38.9]]') |
| 02:46.28 |
CIA-62 |
BRL-CAD:
03173.208.56.140 07http://ist.brlcad.org * r3113
10/wiki/Wer_nutzt_Evernote_f%C3%BCr_bookmarking_3: New page:
[[Image:social_bookmarking_service_2094.jpg|thumb|]] Web 2.0 tools
can connect your students with assets around the planet. Trouble:
Average Directions 1 Permit students to use Web 2.0... |
| 02:50.59 |
starseeker |
hopes he's doing the blocking right... |
| 02:51.38 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.208.56.140]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 02:51.49 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 02:51.49 |
CIA-62 |
BRL-CAD:
deleted "[[Wer nutzt Evernote f??r bookmarking 3]]": content
was: |
| 02:51.49 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_2094.jpg|thumb|]]Web 2.0 tools
can connect |
| 02:51.49 |
CIA-62 |
BRL-CAD: your
students with assets around the planet.Trouble:AverageDirect...'
(and the |
| 02:51.49 |
CIA-62 |
BRL-CAD: only
contributor was
'[[Special:Contributions/173.208.56.140|173.208.56.140]]') |
| 03:04.11 |
CIA-62 |
BRL-CAD:
03173.208.101.9 07http://brlcad.org
* r3114
10/wiki/At_T_must_have_constructed_lines_all_over_my_house_because_I_now_have_service_3:
New page: [[Image:social_bookmarking_service_2703.jpg|thumb|]] Web
2.0 tools can connect your scholars along with assets around the
globe. Web 2.0 explains the proceed toward collaborative,
shared... |
| 03:05.04 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.208.101.9]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 03:05.15 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 03:05.15 |
CIA-62 |
BRL-CAD:
deleted "[[At T must have constructed lines all over my house
because I now have |
| 03:05.15 |
CIA-62 |
BRL-CAD:
service 3]]": content was: |
| 03:05.15 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_2703.jpg|thumb|]]Web 2.0 tools
can connect |
| 03:05.16 |
CIA-62 |
BRL-CAD: your
scholars along with assets around the globe.Web 2.0 explains th...'
(and |
| 03:05.16 |
CIA-62 |
BRL-CAD: the
only contributor was |
| 03:05.17 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.208.101.9|173.208.101.9]]') |
| 03:07.59 |
starseeker |
brlcad: is
there some magic wand that needs to be waved to stop the
crapstorm? |
| 03:22.37 |
CIA-62 |
BRL-CAD:
03173.234.244.30 07http://www.solidgeometry.org *
r3115
10/wiki/Yeah_with_the_invention_about_social_networking_that_s_an_easy_feat_Lol_73:
New page: [[Image:social_bookmarking_service_3389.jpg|thumb|]]
Label the website with keywords to help other consumers identify
thems content. Directions 1 Warning increase with some [http://leas... |
| 03:23.56 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.244.30]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 03:24.18 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 03:24.18 |
CIA-62 |
BRL-CAD:
deleted "[[Yeah with the invention about social networking that s
an easy feat |
| 03:24.18 |
CIA-62 |
BRL-CAD: Lol
73]]": content was: |
| 03:24.18 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_3389.jpg|thumb|]]Label the
website with |
| 03:24.18 |
CIA-62 |
BRL-CAD:
keywords to help other consumers identify thems content.Directions1
W...' (and |
| 03:24.18 |
CIA-62 |
BRL-CAD: the
only contributor was |
| 03:24.19 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.244.30|173.234.244.30]]') |
| 03:33.39 |
CIA-62 |
BRL-CAD:
03173.208.41.35 07http://ist.brlcad.org * r3116
10/wiki/Red_social_96: New page:
[[Image:social_bookmarking_service_2017.jpg|thumb|]] While checking
your regular website metrics with Google Analytics, you might be
happy to reveal that someone has shared some link to
y... |
| 03:34.08 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.208.41.35]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 03:34.17 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 03:34.17 |
CIA-62 |
BRL-CAD:
deleted "[[Red social 96]]": content was: |
| 03:34.17 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_2017.jpg|thumb|]]While checking
your regular |
| 03:34.17 |
CIA-62 |
BRL-CAD:
website metrics with Google Analytics, you might be happy to reveal
...' (and |
| 03:34.18 |
CIA-62 |
BRL-CAD: the
only contributor was |
| 03:34.18 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.208.41.35|173.208.41.35]]') |
| 03:36.20 |
CIA-62 |
BRL-CAD:
03173.208.50.128 07http://brlcad.org * r3117
10/wiki/Vou_sair_aqui_e_ter_uma_vida_social_55: New page:
[[Image:social_bookmarking_service_2071.jpg|thumb|]] Tasty is some
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that is permits users to share links on
the w... |
| 03:36.48 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.208.50.128]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 03:36.58 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 03:36.58 |
CIA-62 |
BRL-CAD:
deleted "[[Vou sair aqui e ter uma vida social 55]]": content
was: |
| 03:36.58 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_2071.jpg|thumb|]]Tasty is
some |
| 03:36.58 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that |
| 03:36.59 |
CIA-62 |
BRL-CAD:
is...' (and the only contributor was |
| 03:36.59 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.208.50.128|173.208.50.128]]') |
| 03:37.40 |
starseeker |
can't figure out how the heck to disable automatic posting on
the wiki... |
| 03:50.50 |
CIA-62 |
BRL-CAD:
03173.208.40.36 07http://ist.brlcad.org * r3118
10/wiki/Esse_joguinho_The_Sims_Social_do_facebook_esta_me_irritando_j%C3%A1_D_16:
New page: [[Image:social_bookmarking_service_4382.jpg|thumb|]]
StumbleUpon yous a [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that lets you scan by means of random
we... |
| 03:52.45 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.208.40.36]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 03:52.58 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 03:52.58 |
CIA-62 |
BRL-CAD:
deleted "[[Esse joguinho The Sims Social do facebook esta me
irritando j?? D |
| 03:52.58 |
CIA-62 |
BRL-CAD:
16]]": content was: |
| 03:52.58 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_4382.jpg|thumb|]]StumbleUpon
yous a |
| 03:52.59 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] |
| 03:52.59 |
CIA-62 |
BRL-CAD:
th...' (and the only contributor was |
| 03:53.00 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.208.40.36|173.208.40.36]]') |
| 03:53.31 |
starseeker |
hmm,
interesting article:
http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/ |
| 03:54.56 |
CIA-62 |
BRL-CAD:
03173.234.245.28 07http://bz.brlcad.org * r3119
10/wiki/It_s_vintage_social_networking_bro_H_16: New page:
[[Image:social_bookmarking_service_1825.jpg|thumb|]] Tag the
website in keywords to support other buyers identify its content.
The social bookmarking phenomenon started on 1996 together
... |
| 03:55.26 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.245.28]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 03:55.46 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 03:55.46 |
CIA-62 |
BRL-CAD:
deleted "[[It s vintage social networking bro H 16]]": content
was: |
| 03:55.46 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_1825.jpg|thumb|]]Tag the
website in keywords |
| 03:55.46 |
CIA-62 |
BRL-CAD: to
support other buyers identify its content.The social bookmarkin...'
(and the |
| 03:55.46 |
CIA-62 |
BRL-CAD: only
contributor was
'[[Special:Contributions/173.234.245.28|173.234.245.28]]') |
| 04:36.27 |
abhi2011 |
starseeker:
nice article |
| 04:45.33 |
CIA-62 |
BRL-CAD:
03173.234.177.115 07http://brlcad.org * r3120
10/wiki/J%C3%A1_voltei_faz_tempo_me_distra%C3%AD_com_o_The_Sims_Social_85:
New page: [[Image:social_bookmarking_service_5120.jpg|thumb|]]
StumbleUpon can be one essential tool to improve your number of
visitors. StumbleUpon yous a [http://lease-a-seo.com/social-bookmarki... |
| 04:58.11 |
CIA-62 |
BRL-CAD:
03173.234.127.10 07http://www.solidgeometry.org *
r3121
10/wiki/To_resist_anything_yous_to_be_in_the_service_of_it_bashar_53:
New page: [[Image:social_bookmarking_service_4981.jpg|thumb|]]
Tasty yous any [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that is permits buyers to share links
on the... |
| 04:59.05 |
CIA-62 |
BRL-CAD:
03173.234.174.28 07http://www.solidgeometry.org *
r3122
10/wiki/I_have_this_reputation_of_being_this_promiscuous_non_committing_man_29:
New page: [[Image:reputation_management_1051.jpg|thumb|]] Purchaser
confidence plays any crucial rule with the success of any B2C
company. Difficulty: Moderately Challenging Directions 1
Connect... |
| 05:03.10 |
CIA-62 |
BRL-CAD:
03173.234.158.36 07http://bz.brlcad.org * r3123
10/wiki/Have_I_become_anti_social_81: New page:
[[Image:social_bookmarking_service_3704.jpg|thumb|]] Trouble:
Moderately Easy Directions 1 Sign up with some [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] s... |
| 05:12.32 |
CIA-62 |
BRL-CAD:
03173.234.177.115 07http://ist.brlcad.org * r3124
10/wiki/Estou_mt_anti_social_D_20: New page:
[[Image:social_bookmarking_service_676.jpg|thumb|]] Web 2.0
describes the proceed toward collaborative, shared, multimedia
experiences on the Web. Specific sites, such because the wide
op... |
| 05:28.42 |
CIA-62 |
BRL-CAD:
03starseeker * r46567 10/brlcad/trunk/CMakeLists.txt: |
| 05:28.42 |
CIA-62 |
BRL-CAD:
Apparently a default VC 2010 Express install doesn't have all
the |
| 05:28.42 |
CIA-62 |
BRL-CAD:
redistributable dlls CMake is looking for - do as CMake does,
suppress the |
| 05:28.42 |
CIA-62 |
BRL-CAD:
(rather verbose) messages. This may need more investigation, not
clear if a |
| 05:28.42 |
CIA-62 |
BRL-CAD:
valid NSIS installer can be made as-is. |
| 05:35.08 |
CIA-62 |
BRL-CAD:
03173.234.120.97 07http://www.solidgeometry.org *
r3125
10/wiki/Yeah_if_you_want_shitty_service_and_shitty_burgers_95: New
page: [[Image:social_bookmarking_service_2822.jpg|thumb|]]
StumbleUpon remains a [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] with users to discover new web site
b... |
| 05:43.30 |
CIA-62 |
BRL-CAD:
03173.234.167.21 07http://ist.brlcad.org * r3126
10/wiki/I_m_only_social_at_concerts_84: New page:
[[Image:social_bookmarking_service_2486.jpg|thumb|]] Web 2.0 tools
can connect your students together with means around the world. Web
2.0 describes the move toward cooperative, shared, ... |
| 06:10.33 |
CIA-62 |
BRL-CAD:
03173.234.126.69 07http://brlcad.org * r3127
10/wiki/U_sang_well_worship_service_81: New page:
[[Image:social_bookmarking_service_3180.jpg|thumb|]] StumbleUpon is
some [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that is lets you browse via random web
... |
| 06:11.05 |
starseeker |
woo hoo -
early testing suggests that the windows version of xsltproc will
work! |
| 06:31.39 |
CIA-62 |
BRL-CAD:
0364.120.39.21 07http://www.solidgeometry.org *
r3128
10/wiki/Listening_music_to_and_watching_the_social_network_17: New
page: [[Image:social_bookmarking_service_2049.jpg|thumb|]]
StumbleUpon yous any [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that lets you browse via random
websit... |
| 06:32.00 |
CIA-62 |
BRL-CAD:
03173.208.100.10 07http://bz.brlcad.org * r3129
10/wiki/I_barely_have_service_in_here_64: New page:
[[Image:social_bookmarking_service_5522.jpg|thumb|]] StumbleUpon is
some [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] with owners to learn new internet site
... |
| 06:39.31 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 06:41.55 |
CIA-62 |
BRL-CAD:
0364.120.39.21 07http://ist.brlcad.org * r3130
10/wiki/Yeah_with_the_invention_of_social_networking_that_s_an_easy_feat_Lol_10:
New page: [[Image:social_bookmarking_service_1937.jpg|thumb|]]
StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that is allows you browse by means of
rand... |
| 06:43.35 |
starseeker |
http://bzflag.bz/~starseeker/archer_win32_native_built_docs.png |
| 06:47.47 |
CIA-62 |
BRL-CAD:
03173.234.158.36 07http://bz.brlcad.org * r3131
10/wiki/No_shoes_no_shirt_and_I_still_get_service_87: New page:
[[Image:social_bookmarking_service_3631.jpg|thumb|]] StumbleUpon is
some [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] for users to uncover new internet site
... |
| 07:06.18 |
CIA-62 |
BRL-CAD:
03173.234.177.115 07http://brlcad.org * r3132
10/wiki/Social_life_has_plummeted_sgoingon_2: New page:
[[Image:social_bookmarking_service_4197.jpg|thumb|]] Web 2.0 tools
may connect your students by resources around the globe. Web 2.0
explains the progress toward cooperative, shared,
mult... |
| 07:21.54 |
CIA-62 |
BRL-CAD:
03173.234.159.17 07http://ist.brlcad.org * r3133
10/wiki/Benefits_of_Using_an_Attorney_Answering_Service_40: New
page: [[Image:social_bookmarking_service_3324.jpg|thumb|]] Web 2.0
gear may connect your students by resources all over the world. Web
2.0 describes the proceed toward collaborative, shared,
m... |
| 07:22.53 |
CIA-62 |
BRL-CAD:
03173.234.126.69 07http://brlcad.org * r3134
10/wiki/I_swear_my_parents_will_be_the_death_of_me_also_my_social_life_17:
New page: [[Image:social_bookmarking_service_2312.jpg|thumb|]]
Toothsome remains any [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that allows buyers to share links on
... |
| 07:28.58 |
CIA-62 |
BRL-CAD:
03173.234.122.130 07http://www.solidgeometry.org *
r3135 10/wiki/Went_to_a_church_service_today_21: New page:
[[Image:social_bookmarking_service_3486.jpg|thumb|]] Difficulty:
Reasonable 1 Authorize scholars to utilize Web 2.0 social
networking gear like because Facebook, Twitter and YouTube to
f... |
| 07:55.54 |
CIA-62 |
BRL-CAD:
0364.120.116.42 07http://bz.brlcad.org * r3136
10/wiki/Who_would_have_thought_bookmarking_now_Thanks_76: New page:
[[Image:social_bookmarking_service_1481.jpg|thumb|]] StumbleUpon is
a [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that is lets you scan by means of
random i... |
| 08:10.47 |
CIA-62 |
BRL-CAD:
03173.234.142.127 07http://bz.brlcad.org * r3137
10/wiki/Excellent_article_worth_bookmarking_2: New page:
[[Image:social_bookmarking_service_2937.jpg|thumb|]] Difficulty:
Moderate Directions 1 Allow scholars to make use of Web 2.0 social
networking gear such as Facebook, Twitter plus
YouTub... |
| 08:24.34 |
CIA-62 |
BRL-CAD:
0364.120.116.42 07http://www.solidgeometry.org *
r3138
10/wiki/Lol_ppl_alway_making_up_stupid_shit_for_social_networks_its_lame_af_1:
New page: [[Image:social_bookmarking_service_2855.jpg|thumb|]]
Whilst checking your everyday internet site metrics in Google
Analytics, you might be delighted to find that someone has shared
some l... |
| 09:35.53 |
CIA-62 |
BRL-CAD:
03173.208.70.163 07http://brlcad.org * r3139
10/wiki/Gotta_love_when_your_friends_fahk_with_your_public_networks_39:
New page: [[Image:social_bookmarking_service_1624.jpg|thumb|]]
StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] for users to find new websites based on
th... |
| 10:16.06 |
plaes |
there was
spam added to bz.brlcad.org mainpage: http://bz.brlcad.org/w/index.php?title=Main_Page&oldid=3034 |
| 10:19.07 |
plaes |
well, this
user: http://bz.brlcad.org/wiki/Special:Contributions/Martinpaul |
| 11:23.06 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 11:42.22 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 12:15.45 |
CIA-62 |
BRL-CAD:
03173.234.174.28 07http://bz.brlcad.org * r3140
10/wiki/There_administration_picked_fans_to_spend_the_day_with_1Dx_98:
New page: [[Image:reputation_management_2361.jpg|thumb|]] One
estimated 57 percent regarding adults use seek out engines to find
information on themeselves, according to a Pew Research Center
revie... |
| 12:33.35 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 14:51.27 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.177.115]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 14:52.32 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 14:52.33 |
CIA-62 |
BRL-CAD:
deleted "[[J?? voltei faz tempo me distra?? com o The Sims Social
85]]": content |
| 14:52.33 |
CIA-62 |
BRL-CAD: was:
'[[Image:social_bookmarking_service_5120.jpg|thumb|]]StumbleUpon
can be one |
| 14:52.33 |
CIA-62 |
BRL-CAD:
essential tool to improve your number of visitors.StumbleUpon yous
a [h...' (and |
| 14:52.33 |
CIA-62 |
BRL-CAD: the
only contributor was |
| 14:52.33 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.177.115|173.234.177.115]]') |
| 14:54.04 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.127.10]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 14:54.17 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.174.28]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 14:54.34 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 14:54.34 |
CIA-62 |
BRL-CAD:
deleted "[[To resist anything yous to be in the service of it
bashar 53]]": |
| 14:54.34 |
CIA-62 |
BRL-CAD:
content was:
'[[Image:social_bookmarking_service_4981.jpg|thumb|]]Tasty yous
any |
| 14:54.34 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] that |
| 14:54.35 |
CIA-62 |
BRL-CAD:
i...' (and the only contributor was |
| 14:54.35 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.127.10|173.234.127.10]]') |
| 14:54.42 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 14:54.42 |
CIA-62 |
BRL-CAD:
deleted "[[I have this reputation of being this promiscuous non
committing man |
| 14:54.42 |
CIA-62 |
BRL-CAD:
29]]": content was:
'[[Image:reputation_management_1051.jpg|thumb|]]Purchaser |
| 14:54.42 |
CIA-62 |
BRL-CAD:
confidence plays any crucial rule with the success of any
B2C |
| 14:54.43 |
CIA-62 |
BRL-CAD:
company.Difficulty:Moderat...' (and the only contributor
was |
| 14:54.43 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.174.28|173.234.174.28]]') |
| 14:56.42 |
brlcad |
plaes:
thanks |
| 14:57.08 |
brlcad |
looks like
there's some new mediawiki attack vector working |
| 14:57.52 |
starseeker |
brlcad:
should I keep scrubbing? |
| 14:59.53 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.158.36]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:00.33 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.167.21]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:01.09 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.120.97]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:01.38 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:01.38 |
CIA-62 |
BRL-CAD:
deleted "[[I m only social at concerts 84]]": content
was: |
| 15:01.38 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_2486.jpg|thumb|]]Web 2.0 tools
can connect |
| 15:01.38 |
CIA-62 |
BRL-CAD: your
students together with means around the world.Web 2.0 describes...'
(and |
| 15:01.39 |
CIA-62 |
BRL-CAD: the
only contributor was |
| 15:01.39 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.167.21|173.234.167.21]]') |
| 15:02.21 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:02.21 |
CIA-62 |
BRL-CAD:
deleted "[[Yeah if you want shitty service and shitty burgers
95]]": content |
| 15:02.21 |
CIA-62 |
BRL-CAD: was:
'[[Image:social_bookmarking_service_2822.jpg|thumb|]]StumbleUpon
remains a |
| 15:02.21 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service]...' |
| 15:02.21 |
CIA-62 |
BRL-CAD: (and
the only contributor was |
| 15:02.21 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.120.97|173.234.120.97]]') |
| 15:02.22 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:02.22 |
CIA-62 |
BRL-CAD:
deleted "[[Estou mt anti social D 20]]": content was: |
| 15:02.23 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_676.jpg|thumb|]]Web 2.0
describes the |
| 15:02.23 |
CIA-62 |
BRL-CAD:
proceed toward collaborative, shared, multimedia experiences on the
Web. Sp...' |
| 15:02.24 |
CIA-62 |
BRL-CAD: (and
the only contributor was |
| 15:02.24 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.177.115|173.234.177.115]]') |
| 15:02.44 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:02.45 |
CIA-62 |
BRL-CAD:
deleted "[[Have I become anti social 81]]": content
was: |
| 15:02.45 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_3704.jpg|thumb|]]Trouble:Moderately |
| 15:02.45 |
CIA-62 |
BRL-CAD:
EasyDirections1 Sign up with some [http://lease-a-seo.com/social-bookmar...' |
| 15:02.45 |
CIA-62 |
BRL-CAD: (and
the only contributor was |
| 15:02.45 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.158.36|173.234.158.36]]') |
| 15:04.13 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.126.69]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:04.27 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:64.120.39.21]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:04.34 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.208.100.10]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:04.46 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.159.17]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:04.49 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.122.130]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:05.02 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:64.120.116.42]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:05.46 |
archivist |
starseeker,
front page has spam |
| 15:05.59 |
starseeker |
archivist:
working on it - I don't really know what I'm doing |
| 15:06.20 |
starseeker |
is not skilled in mediawiki, but crapflood was too severe, so
I'm trying |
| 15:06.36 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.234.142.127]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:06.51 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:173.208.70.163]] with
an expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 15:08.02 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:08.02 |
CIA-62 |
BRL-CAD:
deleted "[[U sang well worship service 81]]": content
was: |
| 15:08.02 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_3180.jpg|thumb|]]StumbleUpon is
some |
| 15:08.02 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] t...' |
| 15:08.02 |
CIA-62 |
BRL-CAD: (and
the only contributor was |
| 15:08.03 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.126.69|173.234.126.69]]') |
| 15:08.05 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:08.05 |
CIA-62 |
BRL-CAD:
deleted "[[Listening music to and watching the social network
17]]": content |
| 15:08.05 |
CIA-62 |
BRL-CAD: was:
'[[Image:social_bookmarking_service_2049.jpg|thumb|]]StumbleUpon
yous any |
| 15:08.05 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] ...' |
| 15:08.06 |
CIA-62 |
BRL-CAD: (and
the only contributor was |
| 15:08.06 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/64.120.39.21|64.120.39.21]]') |
| 15:08.07 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:08.07 |
CIA-62 |
BRL-CAD:
deleted "[[I barely have service in here 64]]": content
was: |
| 15:08.08 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_5522.jpg|thumb|]]StumbleUpon is
some |
| 15:08.23 |
CIA-62 |
BRL-CAD:
[http://lease-a-seo.com/social-bookmarking.php
social bookmarking service] f...' |
| 15:08.23 |
CIA-62 |
BRL-CAD: (and
the only contributor was |
| 15:08.23 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.158.36|173.234.158.36]]') |
| 15:08.23 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:08.23 |
CIA-62 |
BRL-CAD:
deleted "[[Social life has plummeted sgoingon 2]]": content
was: |
| 15:08.24 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_4197.jpg|thumb|]]Web 2.0 tools
may connect |
| 15:08.24 |
CIA-62 |
BRL-CAD: your
students by resources around the globe.Web 2.0 explains the pro...'
(and |
| 15:08.25 |
CIA-62 |
BRL-CAD: the
only contributor was |
| 15:08.25 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.177.115|173.234.177.115]]') |
| 15:08.26 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:08.26 |
CIA-62 |
BRL-CAD:
deleted "[[Benefits of Using an Attorney Answering Service 40]]":
content was: |
| 15:08.52 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_3324.jpg|thumb|]]Web 2.0 gear
may connect |
| 15:08.52 |
CIA-62 |
BRL-CAD: your
students by resources all over the world.Web 2.0 describes the
p...' (and |
| 15:08.52 |
CIA-62 |
BRL-CAD: the
only contributor was |
| 15:08.52 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.159.17|173.234.159.17]]') |
| 15:08.53 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:08.53 |
CIA-62 |
BRL-CAD:
deleted "[[I swear my parents will be the death of me also my
social life 17]]": |
| 15:08.54 |
CIA-62 |
BRL-CAD:
content was:
'[[Image:social_bookmarking_service_2312.jpg|thumb|]]Toothsome |
| 15:08.54 |
CIA-62 |
BRL-CAD:
remains any [http://lease-a-seo.com/social-bookmarking.php
social bookmarking |
| 15:08.55 |
CIA-62 |
BRL-CAD:
service]...' (and the only contributor was |
| 15:08.55 |
CIA-62 |
BRL-CAD:
'[[Special:Contributions/173.234.126.69|173.234.126.69]]') |
| 15:08.56 |
CIA-62 |
(12 lines
omitted) |
| 15:08.57 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/delete: |
| 15:08.57 |
CIA-62 |
BRL-CAD:
deleted "[[Excellent article worth bookmarking 2]]": content
was: |
| 15:08.58 |
CIA-62 |
BRL-CAD:
'[[Image:social_bookmarking_service_2937.jpg|thumb|]]Difficulty:ModerateDirections1 |
| 15:08.58 |
CIA-62 |
BRL-CAD:
Allow scholars to make use of Web 2.0 social networking gear...'
(and the only |
| 15:08.59 |
CIA-62 |
BRL-CAD:
contributor was
'[[Special:Contributions/173.234.142.127|173.234.142.127]]') |
| 15:11.07 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r3141 10/wiki/Main_Page: Undo revision 3084 by
[[Special:Contributions/Jimblack|Jimblack]] ([[User
talk:Jimblack|Talk]]) - spamming |
| 15:11.36 |
CIA-62 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r0 10/wiki/Special:Log/block: blocked [[User:Jimblack]] with an
expiry time of infinite (account creation disabled): Spamming links
to external sites |
| 15:16.49 |
brlcad |
starseeker:
looks like you're doing just fine to me ... :) |
| 15:17.01 |
brlcad |
block the
ip/user and delete the page is all there is to it |
| 15:17.17 |
starseeker |
the interface
I'm using absolutely sucks - need a "batch delete" UI |
| 15:17.27 |
brlcad |
I sometimes
try to remember to clear out the "comment" when deleting the page
so the spam doesn't get repeated |
| 15:17.34 |
starseeker |
ah,
sorry |
| 15:17.39 |
brlcad |
there
probably is a MW module for that |
| 15:17.55 |
brlcad |
sometimes I
don't remember, no big deal either way |
| 15:18.15 |
starseeker |
on a more
positive note, the windows xsltproc succeeds in building our
docs |
| 15:18.45 |
brlcad |
nods, good to know |
| 15:19.08 |
starseeker |
I don't
suppose there's a mediawiki module that will let us reject posts
based on regex matching of links? (sort of adblock for
wikis?) |
| 15:19.24 |
brlcad |
probably is,
there are hundreds of mw modules |
| 15:19.33 |
brlcad |
many many
related to various blocking vectors |
| 15:20.11 |
brlcad |
i'm looking
at fixing one issue now -- the problem is multiplied right now
because multiple domain names are responding, going to fix
that |
| 15:21.08 |
starseeker |
ah, so that's
what the http://bz.brlcad.org
links were about |
| 15:21.59 |
starseeker |
hmm...
http://www.mediawiki.org/wiki/Extension:SpamBlacklist |
| 15:39.50 |
brlcad |
there,
done |
| 15:42.32 |
starseeker |
brlcad:
awesome, thanks! |
| 15:44.49 |
brlcad |
that's not
going to stop the spam, though |
| 15:45.06 |
starseeker |
every little
bit helps |
| 15:45.52 |
starseeker |
doesn't understand how they're getting by
recaptcha |
| 15:46.05 |
brlcad |
we're already
using a blacklist iirc, but haven't updated the list in a long
while |
| 15:47.18 |
brlcad |
there's been
news about spammers getting more clever |
| 15:47.46 |
starseeker |
growl |
| 15:47.51 |
brlcad |
coupling
their software with other client software that pays people to
answer prompts |
| 15:48.25 |
brlcad |
so the
recaptcha is sent to some kid in india/china/wherever that gets
paid something like 1cent per response |
| 15:48.46 |
starseeker |
yeesh |
| 15:49.34 |
brlcad |
on the
upside, recaptcha's OCR processing is up 3000% :) |
| 15:49.41 |
starseeker |
hehe |
| 15:49.55 |
starseeker |
yeah, I guess
there is that |
| 15:50.52 |
starseeker |
supposes if we're going to have to deal with spam, getting
the world's public domain works OCR'ed for free is at least a
little payback |
| 15:53.22 |
starseeker |
ah, poop.
test is like search, uses globals. here we go again... |
| 15:58.04 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 16:24.44 |
brlcad |
is excited, got ahold of more than 100+ real .step files and
about 25+ iges files |
| 16:25.12 |
brlcad |
starseeker:
make the globals static |
| 16:25.28 |
starseeker |
is working on passing them around in a struct
"properly" |
| 16:25.33 |
brlcad |
ah,
k |
| 16:25.50 |
starseeker |
smaller code
than search, so doable "relatively quickly" |
| 16:26.06 |
starseeker |
factering in
my goober pointing skills, of course |
| 16:26.37 |
starseeker |
brlcad: holy
cow, that's a lot of .step data |
| 16:30.44 |
brlcad |
yeah |
| 16:31.02 |
brlcad |
2.2GB
worth |
| 16:31.31 |
brlcad |
900MB of
iges |
| 16:34.41 |
starseeker |
O.o - does
step-g work on any of it? |
| 16:34.52 |
starseeker |
or iges-g for
that matter? |
| 16:35.09 |
starseeker |
(we really
need to get the iges convertor making new NURBS, not
old...) |
| 16:35.22 |
brlcad |
haven't
tested |
| 16:35.30 |
brlcad |
spent most of
yesterday downloading them all |
| 16:35.36 |
starseeker |
heh |
| 17:03.28 |
starseeker |
pokes CIA-62 |
| 17:14.27 |
CIA-62 |
BRL-CAD:
03starseeker * r46568 10/brlcad/trunk/src/libged/exists.c: will be
bounding box routines and raytracing routines for volume
eventually, so name accordingly. |
| 17:18.12 |
CIA-62 |
BRL-CAD:
03starseeker * r46569 10/brlcad/trunk/src/libged/exists.c: not
hooked up or tested beyond 'it builds', and will need the specific
test functions for each case implemented, but get the basic
expression handling code building for exists. |
| 17:28.47 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:05.31 |
CIA-62 |
BRL-CAD:
03starseeker * r46570 10/brlcad/trunk/src/libged/exists.c: replace
syntax calls with ged result string prints |
| 19:13.44 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 19:13.57 |
jordisayol |
hello |
| 19:14.30 |
jordisayol |
is there an
schedule for the next brlcad release? |
| 19:35.37 |
*** join/#brlcad merzo
(~merzo@91-87-132-95.pool.ukrtel.net) |
| 21:03.51 |
CIA-62 |
BRL-CAD:
03starseeker * r46571 10/brlcad/trunk/src/libged/exists.c: Get
exists using the new code, although the only thing implemented at
the moment is the db_lookup based call. |
| 21:10.28 |
*** join/#brlcad merzo
(~merzo@91-87-132-95.pool.ukrtel.net) |
| 21:14.24 |
CIA-62 |
BRL-CAD:
03starseeker * r46572 10/brlcad/trunk/src/libged/exists.c: oops -
managed to gut the and/or code by mistake. Start putting it back
together, lot more to fix here probably. |
| 22:11.20 |
*** join/#brlcad kunigami
(~kunigami@201.53.206.27) |
| 00:59.23 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 05:37.48 |
CIA-62 |
BRL-CAD:
03brlcad * r46586 10/brlcad/trunk/include/fb.h: these macros aren't
very safe. debugged a crash in rtxray related to dereferencing a
null fbp. add a FIXME to turn them into proper
functions. |
| 05:43.06 |
CIA-62 |
BRL-CAD:
03brlcad * r46587 10/brlcad/trunk/src/rt/viewxray.c: not sure how
we're getting to this point, but prevent fb_write() from crashing
if fbp is NULL. |
| 06:00.12 |
CIA-62 |
BRL-CAD:
03brlcad * r46588 10/brlcad/trunk/ (BUGS src/rt/do.c): rtxray
crashes if you specify rtxray -o any.bw output file as there are
assumptions in the rtuif front-end that assume output will be a pix
file. |
| 06:06.21 |
*** join/#brlcad merzo
(~merzo@244-11-133-95.pool.ukrtel.net) |
| 06:24.45 |
CIA-62 |
BRL-CAD:
03brlcad * r46589 10/brlcad/trunk/TODO: noticed some issues with
pixdiff. doesn't handle bw input correctly and default output is
misleading (and sometimes wrong). |
| 11:37.10 |
CIA-62 |
BRL-CAD:
0391.198.94.86 07http://brlcad.org
* r3146 10/wiki/User:91.198.94.86: New page: [http://www.williamhickswi.com
williamhickswi] Hello, im williamhickswi |
| 11:59.36 |
CIA-62 |
BRL-CAD:
0391.198.94.86 07http://brlcad.org
* r3147 10/wiki/User_talk:91.198.94.86: New page: [http://www.williamhickswi.com
williamhickswi] Hello, im williamhickswi |
| 12:46.21 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted
"[[User:91.198.94.86]]" |
| 12:46.35 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:91.198.94.86]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 12:47.09 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[User
talk:91.198.94.86]]" |
| 13:09.19 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 13:09.32 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 13:46.53 |
CIA-62 |
BRL-CAD:
03109.230.251.132 07http://brlcad.org * r3148
10/wiki/Wiki_syntax_explained: New page: Guide for writing by using
wiki syntax will follow [http://www.mediawiki.com Official
Mediawiki Site] |
| 14:01.42 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Wiki syntax explained]]":
probing |
| 14:01.56 |
CIA-62 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:109.230.251.132]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 14:02.17 |
brlcad |
we're going
to have to do something about that soon ... |
| 14:34.31 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46590 10/brlcad/trunk/src/libged/Makefile.am:
reflect that the bullet integration stuff has moved into a
simulate/ subdir |
| 14:42.20 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46591
10/brlcad/trunk/src/conv/intaval/Makefile.am: need both and , or
libtcl won't be found |
| 14:43.56 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46592 10/brlcad/trunk/src/libged/Makefile.am:
add exists.c |
| 14:44.13 |
``Erik |
huh, vim ate
${WDB} and ${WDB_LIBS} on that commit, whups |
| 14:46.34 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46593 10/brlcad/trunk/ (bench/Makefile.am
src/gtools/beset/Makefile.am): add _LIBS for libtcl
link |
| 14:50.59 |
brlcad |
``Erik: cool,
you testing autotools build on bsd? |
| 14:51.26 |
``Erik |
I'm using
fbsd for autogen, but linux for the build |
| 14:51.48 |
brlcad |
k |
| 14:51.53 |
``Erik |
rweiss
complained that he wasn't updating because it's "always broken", we
steered him to installing cmake |
| 14:52.32 |
``Erik |
(our autoconf
has gotten gamey over detecting system tcl correctly, but it's not
worth the effort with deprecation in effect) |
| 14:52.33 |
brlcad |
if it's
"always broken" for him, then he's doing something
wrong |
| 14:53.01 |
``Erik |
infrequent
updates + wrong build system? :) |
| 14:53.18 |
brlcad |
calls BS |
| 14:53.31 |
``Erik |
but I got a
complete build on rhel5/x86_64 *shrug* |
| 14:53.37 |
brlcad |
the build
system should work, especially if he updates infrequently
:) |
| 14:54.00 |
brlcad |
either way, I
only care because I want to tag release |
| 14:54.25 |
brlcad |
did/can you
check if autotools distchecks clean? |
| 14:54.38 |
``Erik |
running |
| 14:54.41 |
brlcad |
cool |
| 14:54.47 |
``Erik |
and a
fail |
| 14:55.10 |
brlcad |
when that
passes, i'll do a mac build test and sync stable |
| 14:56.23 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46594 10/brlcad/trunk/include/Makefile.am:
config_win_cmake.h went back to having a .in suffix |
| 15:02.36 |
CIA-62 |
BRL-CAD:
03erikgreenwald * r46595
10/brlcad/trunk/src/other/libz/Makefile.am: remove nonexistant
header |
| 15:09.46 |
starseeker |
jabs CIA-62 |
| 15:10.13 |
starseeker |
brlcad: I
think I fixed the togl build to not aways rebuild every time cmake
is run |
| 15:14.15 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 15:14.15 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 15:14.21 |
``Erik |
neat,
http://paste.lisp.org/display/124557
I don't know what exactly to do about that |
| 15:15.02 |
starseeker |
winces |
| 15:15.13 |
starseeker |
that's that
new plugin stuff I put in for libged |
| 15:15.46 |
``Erik |
sh/cmakecheck.sh |
| 15:16.18 |
starseeker |
nods - not sure what to do about it either |
| 15:16.18 |
*** join/#brlcad CIA-133
(~CIA@cia.atheme.org) |
| 15:24.00 |
CIA-133 |
BRL-CAD:
03starseeker * r46598
10/brlcad/trunk/src/other/tktable/CMakeLists.txt: Same deal for
tktable - only rebuild if something actually changes. |
| 15:27.31 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 15:30.29 |
CIA-133 |
BRL-CAD:
03starseeker * r46599
10/brlcad/trunk/src/other/togl/src/CMakeLists.txt: Generating
message is a bit messy for togl stubs, go simple. |
| 15:42.56 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46600 10/brlcad/trunk/src/libged/ (4 files in 3
dirs): |
| 15:42.57 |
CIA-133 |
BRL-CAD:
Hoise subdir build information for CMake build. While the subdir
CMake stuff |
| 15:42.57 |
CIA-133 |
BRL-CAD: does
work, it causes sh/cmakecheck.sh to fail in automakes dist-hook.
Once |
| 15:42.57 |
CIA-133 |
BRL-CAD:
automake is completely removed, we may decide to move the cmake
build logic back |
| 15:42.57 |
CIA-133 |
BRL-CAD: into
the subdirs. |
| 15:43.09 |
``Erik |
hoist,
even |
| 15:43.56 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46601 10/brlcad/trunk/misc/Makefile.am: update
to reflect numerous changes in CMake/ |
| 15:46.49 |
``Erik |
dist
succeeds, doing the subdir build right now |
| 15:48.10 |
starseeker |
brlcad: I
think for the remainder of the issues (relinking everything because
we're updating the count) we're looking at something along these
lines: http://cmake.org/Bug/view.php?id=8655 |
| 15:48.38 |
CIA-133 |
BRL-CAD:
03starseeker * r46602 10/brlcad/trunk/src/libged/CMakeLists.txt:
move the macro to the top to avoid an undefined macro
error. |
| 16:03.57 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46603 10/brlcad/trunk/src/other/Makefile.am: add
missing files to EXTRA_DIST |
| 16:09.08 |
starseeker |
cmake looking
ok here - make regress just passed (gentoo) |
| 16:30.17 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46604 10/brlcad/trunk/src/other/Makefile.am: add
OSL files |
| 16:32.41 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46605 10/brlcad/trunk/src/other/incrTcl/
(itcl/Makefile.am itk/Makefile.am): add
ac_std_funcs.cmake |
| 16:40.06 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46606 10/brlcad/trunk/src/adrt/Makefile.am: add
isst.bat to EXTRA_DIST |
| 17:03.03 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46607 10/brlcad/trunk/src/fbed/ (CMakeLists.txt
sgi_dep.c): eliminate sgi_dep.c |
| 17:09.24 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46608
10/brlcad/trunk/src/tclscripts/archer/Makefile.am: add
PipeEditFrame.tcl |
| 17:17.38 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46609 10/brlcad/trunk/db/ (4 files): convert
cornell-kunigami from .g to .asc with build rules |
| 17:27.42 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46610
10/brlcad/trunk/doc/docbook/system/mann/en/Makefile.am: add
exists.xml |
| 17:35.52 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46611 10/brlcad/trunk/misc/Makefile.am: add
Doxyfile.in |
| 17:41.10 |
CIA-133 |
BRL-CAD:
03erikgreenwald * r46612 10/brlcad/trunk/Makefile.am: add
configure.cmake.sh |
| 17:43.29 |
``Erik |
I think
that's all done O.o |
| 17:43.45 |
``Erik |
first time
we've been able to do a cmake build from an automake dist generated
tarball, to boot |
| 17:59.06 |
starseeker |
awesome |
| 18:05.34 |
brlcad |
excellent |
| 18:06.17 |
brlcad |
so was the
previous source dist from an autotools make dist? there was a post
to the help forum about missing isst.bat in 7.20.2 |
| 18:06.31 |
brlcad |
I thought
7.20.2 was a cmake dist |
| 18:40.03 |
starseeker |
I don't think
so - IIRC, that might have been before we sorted out the zlib
header thing |
| 18:53.19 |
``Erik |
from the
saved timestamps in the tarball, I'd assume something like (svn co
... brlcad-7.20.2 && find brlcad-7.20.2 -name '\.svn' -exec
rm "{}"\; && (cd brlcad-7.20.2 && sh autogen.sh)
&& tar zcvf brlcad.7.20.2.tar.gz brlcad-7.20.2) |
| 18:54.03 |
``Erik |
(mebbe with a
-r to the rm and various fixes like that...) |
| 19:05.56 |
CIA-133 |
BRL-CAD:
03starseeker * r46613 10/brlcad/trunk/ (4 files in 2 dirs): (log
message trimmed) |
| 19:05.56 |
CIA-133 |
BRL-CAD: Take
some steps to mitigate the 'relink everything every cmake run'
issue. Use |
| 19:05.56 |
CIA-133 |
BRL-CAD: the
build types to decide whether we want to increment COUNT - only do
so when |
| 19:05.56 |
CIA-133 |
BRL-CAD:
we're doing a build configuration other than Debug, since it's
those cases where |
| 19:05.56 |
CIA-133 |
BRL-CAD: we
might be concerned how many times CMake has been run. Also change
the way |
| 19:05.56 |
CIA-133 |
BRL-CAD:
we're getting the timestamp (DATE) in Debug configurations - old
method gave the |
| 19:05.57 |
CIA-133 |
BRL-CAD:
to-the-second ascii string conversion that's standard in C. For
Debug cases, |
| 19:25.13 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 19:25.13 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 19:35.11 |
brlcad |
not sure
that's entirely true |
| 19:35.49 |
brlcad |
if someone's
build debug 10 times then release 1, count will be 1 and that's not
useful |
| 19:36.31 |
brlcad |
one of the
critical things the count conveys is "this is not the first/only
time a build was performed on this checkout" |
| 19:38.14 |
brlcad |
the other is
that this is the Nth attempt where a large N indicates a build from
a particularly active checkout, small N but non-1 indicating that
maybe a few tweak passes/rebuilds (maybe cause for concern), and
N=1 .. pristine checkout/build/install |
| 19:39.15 |
brlcad |
whines that scripting maths is hard |
| 19:42.00 |
starseeker |
what about
counting in a non-included file in debug, and then adding in the
result of that (if present) when switching to release? |
| 19:48.46 |
brlcad |
hm, doesn't
sound like it's worth having that kind of specific logic around,
almost seems better to just incr on every cmake like it was and let
it relink because it's simple |
| 19:49.17 |
starseeker |
don't think
it's hard - there was some positive developer response here to the
idea of avoiding relinking |
| 19:49.19 |
brlcad |
the benefit
was really only if it was easy enough to detect a config
change |
| 19:49.29 |
starseeker |
give me a
sec... |
| 19:49.39 |
brlcad |
not that it's
hard or not |
| 19:50.04 |
brlcad |
that it
sounds like the type of quirky logic that one looks back at in a
few years and wonders, wtf, right before ripping it out |
| 19:50.04 |
starseeker |
brlcad: it's
got to be worth avoiding relinking 100+ executables |
| 19:50.33 |
brlcad |
is it not
feasible to do your earlier idea? |
| 19:50.40 |
starseeker |
which earlier
idea? |
| 19:51.05 |
brlcad |
you'd
mentioned being able to detect that something in the config
changed, incrementing then |
| 19:51.21 |
brlcad |
like saving
the previous cache or detecting a cache change or
similar |
| 19:51.56 |
starseeker |
the problem
is, the headers DO change each time you run config if you increment
COUNT |
| 19:51.57 |
brlcad |
i don't
recall the exact mechanism you had in mind, it was getting
late |
| 19:52.02 |
starseeker |
count is
included in the headers |
| 19:52.09 |
brlcad |
riiight |
| 19:52.14 |
starseeker |
if the COUNT
file changes, relinking is guaranteed |
| 19:52.22 |
brlcad |
yes,
understood |
| 19:52.30 |
brlcad |
the idea was
to only incr count if config changed |
| 19:52.43 |
starseeker |
oh, I recall
- diffing the cache files? |
| 19:52.50 |
brlcad |
not every
cmake, but every cmake where something is different from the
previous |
| 19:52.57 |
starseeker |
um... |
| 19:53.08 |
brlcad |
it was your
idea, I liked it ;) |
| 19:53.37 |
brlcad |
that
basically caters to all the cases |
| 19:53.43 |
brlcad |
and keeps
relinking to a useful minimum |
| 19:54.08 |
starseeker |
the difficult
was that a cache file isn't written until the end of the CMake
process - so it's comparing an old cache file with the current "in
memory" state of CMake |
| 19:54.24 |
starseeker |
that sounds
more complex than COUNT trickery |
| 19:54.54 |
brlcad |
not at all
complicated to explain though and no unintended side
effects |
| 19:55.23 |
brlcad |
maybe more
complex to implement, but not more complex to maintain (it doesn't
smell wierd, the other method really does) |
| 19:55.33 |
starseeker |
MUCH more
complex to implement |
| 19:55.41 |
starseeker |
much MUCH
more complex |
| 19:55.52 |
brlcad |
has confidence in starseeker's cmake magic
;) |
| 19:56.18 |
starseeker |
grumble... |
| 19:56.37 |
brlcad |
so leave it
to relink each cmake, I still think that's better than something
that makes the count toggled based on specific parameter
values |
| 19:57.26 |
brlcad |
i.e., more
important that "the value" have a simple definition than the build
system wrapping around it |
| 19:57.39 |
brlcad |
incrementing
every cmake (or make) isn't ideal, but it's bad either |
| 19:57.45 |
starseeker |
thinks the developer time saved avoiding all the useless
relinking is more valuable than the COUNT variable (which, to be
fair, he has NEVER used, so he may not have a good appreciation of
its benefits...) |
| 19:57.48 |
brlcad |
every config
would probably be ideal |
| 19:58.23 |
brlcad |
actually,
what I said earlier -- the original behavior -- was ideal,
incrementing every build pass but only using it every link
:) |
| 19:58.50 |
starseeker |
not possible
in CMake as it exists today, apparently |
| 19:58.59 |
brlcad |
sure, not
possible with autotools either |
| 19:59.48 |
brlcad |
maybe with a
custom make rule .. but not that big an issue |
| 20:01.13 |
brlcad |
I actually
check that number every time I sit down at an unknown install to
see what the user (even if it's just me) is running |
| 20:01.45 |
brlcad |
e.g., right
now: "Compilation 18" |
| 20:01.54 |
brlcad |
definitely a
dev checkout |
| 20:02.45 |
CIA-133 |
BRL-CAD:
03starseeker * r46614
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Snarf environment
variables like we're supposed to, don't ignore the user's
CFLAGS... |
| 20:03.07 |
starseeker |
suspects he is far more included than brlcad to just check
out a clean repo and/or blow away and rebuild... |
| 20:03.09 |
brlcad |
I'd frankly
probably be more inclined to drop the count before changing the
meaning of the number |
| 20:03.20 |
brlcad |
"Compilation
18 (or possibly more)" just isn't useful |
| 20:05.55 |
brlcad |
I do that for
some builds too -- it's not about the dev, it's the code -- that's
what the number tells you |
| 20:06.39 |
brlcad |
*when* it
isn't a clean repo, that can be very useful to know |
| 20:06.58 |
CIA-133 |
BRL-CAD:
03starseeker * r46615 10/brlcad/trunk/CMakeLists.txt: Sean wants
this COUNT to be independent of build type |
| 20:07.02 |
starseeker |
svn status
ftw |
| 20:07.14 |
brlcad |
eh? |
| 20:07.20 |
starseeker |
"not a clean
repo" |
| 20:07.29 |
brlcad |
I don't
necessarily have svn status when I'm running the
binaries |
| 20:07.41 |
starseeker |
oh, you mean
a build from a clean repo |
| 20:07.43 |
brlcad |
I'm running
mged or rt or something else from an install |
| 20:08.10 |
brlcad |
this is all
about having an install let us know what kind of environment it
came from |
| 20:08.19 |
brlcad |
not just
build settings, that's easy |
| 20:09.03 |
starseeker |
brlcad: can I
at least add an advanced developer option to disable the
COUNT? |
| 20:10.51 |
brlcad |
if I
encounter a crash while running rt and I see Compilation 18, the
very first thing that begs (no matter where or who's desk I'm
sitting at) is to not even mess with debugging it -- redo the
install |
| 20:12.20 |
starseeker |
brlcad: I
restored the default behavior (I suppose I should yank the
copy_if_diff logic for that file, since it's now
useless) |
| 20:12.24 |
brlcad |
that would
completely defeat the purpose of the COUNT, back to the same
"Compilation 1 (or possibly more)" situation |
| 20:12.43 |
starseeker |
brlcad: only
if a developer specifically turns it on though |
| 20:12.59 |
starseeker |
I could
locally tweak the CMake logic to do exactly the same
thing |
| 20:13.41 |
brlcad |
how will I
know when I run a random installed rt whether the dev turned it on
or off? |
| 20:13.54 |
brlcad |
good faith
trust? |
| 20:14.21 |
starseeker |
what about
setting the count to -1 or something like that when turned
off? |
| 20:17.33 |
CIA-133 |
BRL-CAD:
03starseeker * r46616 10/brlcad/trunk/CMakeLists.txt:
copy_if_different logic is useless for COUNT, so remove
it |
| 20:17.57 |
brlcad |
this is not a
productive way to continue discussing changes like this |
| 20:18.10 |
brlcad |
might as well
remove it entirely because it's either useful and used or it's
not |
| 20:18.35 |
starseeker |
you use it,
so we'll got with that |
| 20:18.50 |
brlcad |
you obviously
don't use it, so you're asking every question to modify the feature
into the minimalist way to make you not have to care about
it |
| 20:19.03 |
brlcad |
the answer
should be to either use it or have a discussion on the merits to
remove it |
| 20:19.05 |
starseeker |
probably should use it |
| 20:20.25 |
starseeker |
more
productive then... you mentioned the original system incrementing
every build pass but only using it every link |
| 20:20.44 |
brlcad |
I'm not
opposed to removing it, I'd choose removing it over making it only
sometimes a useful value for example |
| 20:20.47 |
starseeker |
what would be
a good way to have CMake generate logic to do that? |
| 20:20.57 |
brlcad |
I have no
idea :) |
| 20:22.19 |
brlcad |
in Make
lingo, it involved putting the version into into a compilation unit
(vers.c), and then specifying vers.o during link but not as a make
rule dependency |
| 20:22.59 |
brlcad |
so it only
compiled and linked vers.c when it was going to link |
| 20:23.11 |
brlcad |
something
like that at least |
| 20:24.03 |
starseeker |
um. you mean
vers.o was linked with the executables directly, or with the
libraries? |
| 20:24.23 |
brlcad |
separate ones
for both |
| 20:24.45 |
brlcad |
I got rid of
all the front-end versioning, not as useful as knowing the
library |
| 20:24.51 |
brlcad |
s/all/most/ |
| 20:29.04 |
starseeker |
erm. We're
agreed that if I can detect whether there was any actual
configuration change, that's the best criteria for incrementing the
count? |
| 20:33.01 |
brlcad |
that sounds
like the best closest useful fit to me |
| 20:33.31 |
starseeker |
ok. I might
be wrong about how tricky that is - let me do some
tests |
| 20:35.18 |
brlcad |
if you can't
figure it out, don't sweat it -- I won't cry if the feature is
removed, it's installation metadata |
| 20:36.01 |
starseeker |
if you do
check it everytime though, it's telling you something useful (/me
has a lot of respect for brlcad's notions of efficiency, if it
wasn't useful you would have optimized it out already
:-P) |
| 20:36.09 |
brlcad |
I find it
useful, but certainly not critical or even worth debate, just
informative when needed |
| 20:45.48 |
brlcad |
I will
conceed that it's probably not worth keeping if it'll relink every
cmake since we're talking about a time savings of approximately 30
minutes a couple times a year to redo an install |
| 20:46.03 |
brlcad |
that's
generously maybe 3 hours throughout the year |
| 20:46.46 |
starseeker |
hang in there
- I just got a parse out of the CMakeCache.txt contents |
| 20:47.36 |
brlcad |
if cmake
changes once a week across half a dozen developers and relinking
takes optimistically 1 minute, that's 52 * 6 or roughly five
hours |
| 20:48.06 |
starseeker |
was just trying to get everything all nice and tidy after
figuring out how to get togl and tktable to stop rebuilding, which
is fundamentally a pretty stupid motivation |
| 20:48.21 |
brlcad |
similarly, if
it takes you more than 3 hours to figure it out, it's not worth it
;) |
| 20:48.28 |
starseeker |
mea
culpa |
| 20:48.46 |
brlcad |
hey, a love
nice and tidy |
| 20:48.52 |
brlcad |
you know
that! :) |
| 20:49.11 |
brlcad |
obsessive
attention to detail ftw |
| 21:37.33 |
*** join/#brlcad nsd_
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 22:27.47 |
starseeker |
brlcad: what
about the date stamp? I cut down the info in it to avoid
seconds/minute changes triggering the same linking issue, should I
just use that stamp for all builds? |
| 22:28.31 |
``Erik |
hm,
kernel.org seems to be down :/ |
| 22:28.48 |
starseeker |
they fixing
their servers? |
| 22:30.20 |
``Erik |
can't get a
dns resolve |
| 22:30.31 |
``Erik |
which sucks,
cuz an updated version of git came out |
| 22:30.33 |
starseeker |
winces |
| 22:30.51 |
starseeker |
is Linus
hosting that on github too? |
| 22:31.02 |
starseeker |
or the git
devs rather? |
| 22:31.05 |
``Erik |
tried several
country resolves, I assume their toplevel dns crapped out a bit
ago, long enough for propogation |
| 22:31.24 |
``Erik |
they have a
git repo and a .zip file, plus old files... but not the tar.bz2
that fbsd/ports wants |
| 22:31.47 |
``Erik |
and I'd kinda
like the signed checksums, y'know? :D |
| 22:31.55 |
starseeker |
ah |
| 22:36.02 |
brlcad |
starseeker:
no entiendo |
| 22:37.02 |
starseeker |
the date
stamp I had been writing out into include/conf/DATE printed the
asciitime string including hours:minutes:seconds, so it got changed
each time cmake ran |
| 22:37.25 |
``Erik |
eigo kudasai
O.o |
| 22:39.48 |
n_reed |
english,
spanish, japanese... doesn't matter to me :) |
| 22:40.02 |
starseeker |
they're all
greek? :-P |
| 22:40.22 |
n_reed |
no, i can
read them all |
| 22:40.47 |
``Erik |
don't make me
dig up translate.google.com to find something incredibly obscure
O.o |
| 22:40.53 |
starseeker |
heh cool
:-) |
| 22:41.03 |
``Erik |
ano bakka
kuso ttare |
| 22:44.43 |
starseeker |
needs to see what autotools does for DATE, come to think of
it |
| 22:45.19 |
``Erik |
probably runs
"date" |
| 22:45.30 |
CIA-133 |
BRL-CAD:
03starseeker * r46617 10/brlcad/trunk/ (4 files in 2 dirs): (log
message trimmed) |
| 22:45.30 |
CIA-133 |
BRL-CAD: Make
a serious stab at incrementing the COUNT variable only when
the |
| 22:45.30 |
CIA-133 |
BRL-CAD:
configuration actually changes. For the moment, this is
accomplished by reading |
| 22:45.30 |
CIA-133 |
BRL-CAD: the
old CMakeCache.txt file (stashed at the beginning of the second
cmake run) |
| 22:45.30 |
CIA-133 |
BRL-CAD: and
comparing values found there to values in the current CMake
enviornment. |
| 22:45.31 |
CIA-133 |
BRL-CAD: It's
not perfect in that new variables in the working environment won't
trigger |
| 22:45.32 |
CIA-133 |
BRL-CAD: the
COUNT increase, but for most reconfiguration situations something
will be |
| 22:45.52 |
starseeker |
yeah, that's
gonna trigger a relinking then - date includes minutes and seconds
of current time |
| 22:47.27 |
starseeker |
brlcad: see
how that looks - if that doesn't look good I can pose the problem
on the CMake list. |
| 22:49.40 |
``Erik |
*look*
autoconf does use date, but with the format string |
| 22:50.00 |
``Erik |
CONFIG_DAY=`date +%d` |
| 22:50.47 |
starseeker |
echo
"\"`LANG=C date -R 2>/dev/null || date +'%a, %d %b %Y %H:%M:%S
%z' 2>/dev/null || date`\"" > $@ |
| 22:53.25 |
starseeker |
%M and %s are
the trick, maybe %H too |
| 22:53.34 |
starseeker |
s/%s/%S |
| 22:54.46 |
``Erik |
when I used
B|X instead of irssi, I was putting logs in seperate dirs by day,
the cron job had mkdir `date +%Y%m%d` |
| 22:55.35 |
``Erik |
and for dump
scripts, I do something like $host-$fs-`date
+%Y%m%d%H%M`.dump.bz2 |
| 22:55.37 |
starseeker |
in CMake I'm
actually generating the date stamp with C code (date available on
all platforms) - I can do a custom string, the issue is that means
not using the "standard" format |
| 22:55.54 |
starseeker |
date ISN'T
available on all platforms |
| 22:55.58 |
starseeker |
sheesh |
| 22:56.27 |
``Erik |
strftime() is
:) |
| 22:56.54 |
starseeker |
ah, didn't
know about that |
| 22:57.07 |
starseeker |
cool, that
will simplify the time.c.in code |
| 22:57.42 |
starseeker |
but that gets
back to whether brlcad wants to have the DATE file do something
different from the standard ascii string |
| 22:57.49 |
starseeker |
isn't going to assume this time |
| 23:01.28 |
*** join/#brlcad merzo
(~merzo@248-122-133-95.pool.ukrtel.net) |
| 23:08.05 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 23:20.47 |
CIA-133 |
BRL-CAD:
03starseeker * r46618 10/brlcad/trunk/CMakeLists.txt: Silly
developer. If detecting config changes, need the copy_if_diff code
again |
| 23:22.00 |
brlcad |
autotools
writes out the date in RFC 2822 format |
| 23:22.04 |
brlcad |
date
-R |
| 23:22.14 |
brlcad |
for gnu date,
or date +'%a, %d %b %Y %H:%M:%S %z' for others |
| 23:22.30 |
brlcad |
ah, you found
it |
| 23:25.28 |
brlcad |
RFC 2822 is
particularly useful because it's easily human readable and computer
parsable without sacrificing info |
| 23:25.36 |
CIA-133 |
BRL-CAD:
03starseeker * r46619 10/brlcad/trunk/CMakeLists.txt: copy/paste
strikes again |
| 23:26.46 |
starseeker |
brlcad: no
argument - the issue is that when cmake re-runs and makes a new
DATE, we've got the linker issue all over again if we include
minutes and seconds |
| 23:26.54 |
starseeker |
(those for
sure - hours may be an issue) |
| 23:28.43 |
brlcad |
couple the
date stamp regeneration to COUNT? |
| 23:28.53 |
starseeker |
hmm, good
idea |
| 23:29.00 |
starseeker |
digs |
| 23:29.14 |
brlcad |
if you need
to generate 2822, this should help: http://inn.eyrie.org/svn/tags/2.4.4/lib/date.c |
| 23:29.24 |
brlcad |
bsd-licensed,
only need one or two functions from it |
| 23:29.30 |
starseeker |
was assuming asciitime did that, but maybe
not... |
| 23:31.04 |
starseeker |
asctime
rather |
| 23:32.02 |
starseeker |
and.... bzzt,
wrong |
| 23:32.06 |
starseeker |
looks at date.c |
| 23:34.37 |
brlcad |
starseeker:
yeah, I don't believe so |
| 23:34.41 |
brlcad |
but
strftime() should |
| 23:34.53 |
brlcad |
since you can
specify the '%a, %d %b %Y %H:%M:%S %z' format string |
| 23:35.12 |
brlcad |
forgot all about asctime() |
| 23:36.19 |
brlcad |
hopefully
shouldn't need that date.c impl .. strftime() is c90 |
| 23:36.33 |
starseeker |
tries that to start |
| 23:36.41 |
brlcad |
http://msdn.microsoft.com/en-us/library/fe06s4ak(v=vs.80).aspx
woot |
| 23:37.11 |
brlcad |
been there
since '95, better than good enough |
| 23:37.46 |
brlcad |
alrighty! ..
finally finished revamping the nurbs test script |
| 23:39.13 |
brlcad |
now with
matching view rendering, better percentage deviation reporting, and
normalized rays/s calculations |
| 23:39.18 |
starseeker |
awesome! |
| 23:40.26 |
brlcad |
haven't been
able to think of a good way to make this script more useful in a
general context .. it does a lot of workhorsing |
| 23:41.12 |
brlcad |
actually
might make for a nice regression test.. ends up invoking about a
dozen different tools |
| 23:42.26 |
starseeker |
cool |
| 23:42.49 |
starseeker |
we could
probably use a NURBS regression test |
| 23:43.14 |
``Erik |
(might wanna
contemplate migrating #!/bin/sh to tclsh or something some
day) |
| 23:45.23 |
starseeker |
we discussed
that once - apparently that comes under the "labor of Hercules"
heading :-/ |
| 23:46.31 |
``Erik |
same category
as cmake, heracles? :) |
| 23:46.44 |
starseeker |
is betting worse, actually... |
| 23:47.09 |
``Erik |
mebbe not,
say, footer, header, indent... but regress, bench... things winderz
folk might want to try |
| 23:48.25 |
``Erik |
'nut' tells
me I should eat pizza :/ (available on bz) |
| 23:51.06 |
starseeker |
``Erik:
brlcad has put a lot of pretty serious work into those sh scripts -
I don't even want to think about what it would take to reach parity
with tclsh |
| 23:54.05 |
starseeker |
probaby
easier to stuff an sh impliementation into src/other and make it
work on Windows - I think brlcad may have mentioned pdksh as a
possibility, but I'm not sure |
| 23:58.52 |
brlcad |
yeah, I'm
pretty adept at tcl, but some of those scripts do things I don't
think I could easily do with tcl (or python or perl
...) |
| 23:59.59 |
brlcad |
some shell
tricks just aren't possible, so you'd end up having to do some
manual expansion of logic into something equivalent |
| 00:00.31 |
starseeker |
is looking, but doesn't see any immediate indication that
anyone has pdksh compiling with MSVC... |
| 00:03.33 |
brlcad |
http://en.wikipedia.org/wiki/Korn_shell
says some versions of windows already include a posix-compliant
ksh, and http://en.wikipedia.org/wiki/UWIN |
| 00:03.43 |
CIA-133 |
BRL-CAD:
03starseeker * r46620 10/brlcad/trunk/ (CMakeLists.txt
misc/CMake/test_srcs/time.c.in): Yay! RFC2822-ify the DATE stamp
code, and go with Sean's idea of linking the DATE regeneration to
the COUNT regeneration. |
| 00:04.23 |
brlcad |
the main
portability issue is getting a pseudo terminal interface, which was
the other part of that equation |
| 00:04.24 |
starseeker |
urm. CPL?
not very familiar with that license |
| 00:04.54 |
brlcad |
you need a
terminal to run a shell, if you have that, porting the underlying
shell is pretty trivial |
| 00:05.25 |
starseeker |
winces |
| 00:05.52 |
starseeker |
so I guess it
boils down to whether implementing a terminal emulator in Windows
is easer than the sh->tclsh port |
| 00:06.18 |
brlcad |
meh |
| 00:06.24 |
brlcad |
the shell
scripts are all developer infrastructure |
| 00:06.56 |
starseeker |
would be nice
to do regress/bench with MSVC |
| 00:07.00 |
brlcad |
not a big
deal if you can't test some parts of the system on Windows, you can
everywhere else |
| 00:07.11 |
brlcad |
bench is a
diff issue, already on it |
| 00:07.51 |
starseeker |
ah, cool
:-) |
| 00:08.27 |
brlcad |
sure it would
be nice to have all of regress on windows, but not "absolutely must
have necessary" .. and there is cygwin/mingw if we really want to
be pedantic, it's pretty trivially possible |
| 00:09.39 |
brlcad |
let a windows
diehard rewrite them :) |
| 00:11.21 |
starseeker |
heh |
| 00:21.46 |
starseeker |
brlcad: how
does that new setup look? |
| 00:22.02 |
starseeker |
seems to be
behaving OK here, so far |
| 00:33.42 |
brlcad |
been working
on getting the final nurbs rerun kicked off again for another 10-20
hours of processing |
| 00:35.30 |
brlcad |
now that it's
done and churning, hopefully it'll be a clean run and the stats can
be distributed as a baseline |
| 00:36.07 |
brlcad |
i'll be
kicking off some builds here in a couple minutes so i'll let you
know how it goes :0 |
| 02:44.46 |
CIA-133 |
BRL-CAD:
03173.234.97.161 07http://brlcad.org * r3149
10/wiki/User:108.62.162.154: New page: [http://www.galeriabali.pl/pl/Ryby
owoce morza] Szeroki wybor w karcie dan spowoduje, ze znajdziesz
cos wyjatkowego a ciekawosc jak smakuja inne dania sprawi, ze nie
beziesz mogl sie docze... |
| 03:17.31 |
CIA-133 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted
"[[User:108.62.162.154]]" |
| 03:17.32 |
CIA-133 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:173.234.97.161]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 03:27.47 |
CIA-133 |
BRL-CAD:
03starseeker * r46621 10/brlcad/trunk/src/libged/CMakeLists.txt:
need to ignore the simulate files if we're not building
them |
| 03:32.13 |
starseeker |
brlcad: I'm a
bit confused about how to approach an aspect of the distcheck rule
- I can ignore files that the build logic doesn't know about and
not include them in the tarball, but how do I distinguish between
"junk" files that should be ignored and files that the developer
genuinely forgot to include? (like the simulate files if bullet
isn't found) |
| 03:41.38 |
CIA-133 |
BRL-CAD:
03starseeker * r46622
10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in:
Improvements to the distcheck logic - haven't quite got to
activting the CPack tweaking logic, but close. In the meantime,
better error reporting. |
| 03:54.30 |
CIA-133 |
BRL-CAD:
03starseeker * r46623
10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: more TODO
notes for dist |
| 04:02.02 |
brlcad |
starseeker:
the autotools build checks the svn manifest -- if they're in svn,
then they should be in the dist |
| 04:02.51 |
starseeker |
urm. So I
need to parse the svn manifests. |
| 04:04.00 |
brlcad |
12-liner
coming: |
| 04:04.03 |
brlcad |
dist-hook: |
| 04:04.03 |
brlcad |
<PROTECTED> |
| 04:04.07 |
brlcad |
<PROTECTED> |
| 04:04.09 |
brlcad |
<PROTECTED> |
| 04:04.12 |
brlcad |
<PROTECTED> |
| 04:04.14 |
brlcad |
<PROTECTED> |
| 04:04.17 |
brlcad |
<PROTECTED> |
| 04:04.19 |
brlcad |
<PROTECTED> |
| 04:04.22 |
brlcad |
<PROTECTED> |
| 04:04.24 |
brlcad |
<PROTECTED> |
| 04:04.27 |
brlcad |
<PROTECTED> |
| 04:04.29 |
brlcad |
<PROTECTED> |
| 04:04.55 |
brlcad |
that's how
autotools does it -- gets the list of names from the ".svn/entries"
files, then looks to see if they're in the source dist that was
built |
| 04:05.10 |
brlcad |
if missing,
reports then halts |
| 04:05.39 |
brlcad |
that
script-fu should convert pretty simply to cmake funcs |
| 04:06.31 |
starseeker |
those entries
files are per .svn directory? |
| 04:06.40 |
brlcad |
yes |
| 04:07.04 |
brlcad |
they're
simple text, pop one up |
| 04:07.52 |
brlcad |
basically xml
blocks with name="filename" identifiers |
| 04:08.18 |
starseeker |
what does it
do without the .svn directories then? |
| 04:09.06 |
brlcad |
no manifest,
no way to know what's actually missing |
| 04:09.09 |
brlcad |
so it does
nothing |
| 04:09.12 |
starseeker |
ah |
| 04:09.24 |
starseeker |
that's
actually the case I have implemented then :-/ |
| 04:09.38 |
brlcad |
it could
report what files were found, but meh .. 99% of the time, we have
the list |
| 04:10.10 |
starseeker |
nods - I'll leave what I have for that case (no .svn entities
files found) and figure out the .svn manifest
part |
| 04:10.30 |
brlcad |
yeah, that's
probably very reasonable behavior -- no svn files, report and could
even halt |
| 04:10.56 |
brlcad |
but if there
is a manifest, it probably shouldn't halt on the
unknowns |
| 04:11.29 |
starseeker |
nods |
| 04:11.38 |
CIA-133 |
BRL-CAD:
03starseeker * r46624 10/brlcad/trunk/CMakeLists.txt: Echo some
messages to identify various stages of distcheck. |
| 04:11.39 |
brlcad |
arguably
useful to even report them since our actual "correctness" rule is
only to make sure what's in svn is in the dist |
| 04:11.41 |
starseeker |
that's what I
was figuring - with svn manifests, it's sane to
continue |
| 04:12.04 |
brlcad |
but even
reporting them could be good sanity too |
| 04:12.18 |
starseeker |
<shrugs> at least flags the trouble
spot |
| 04:12.28 |
brlcad |
the biggest
catch is finding things you *know* are in svn but are
missing |
| 04:12.31 |
brlcad |
yeah |
| 04:13.15 |
starseeker |
I doubt I'll
be ready with an svn based distcheck for this release
:-( |
| 04:13.36 |
brlcad |
that's
fine |
| 04:13.45 |
brlcad |
planning on
distchecking with both anyways |
| 04:13.57 |
brlcad |
if you want
to get fancy -- one thing I never got around to fixing is if you
svn delete a file, the entry remains (with a deleted flag in the
entries record) |
| 04:14.45 |
starseeker |
nods - sounds worth doing |
| 04:14.55 |
brlcad |
rarely hit it
in practice so not a big deal, but one more place to knock the
autotools build down a notch |
| 04:15.24 |
brlcad |
would be a
bigger issue if we deleted/renamed files more frequently between
releases (and not just whole dirs) |
| 04:16.17 |
starseeker |
nods |
| 04:16.29 |
brlcad |
oh wow, so I
thought it was still relinking everything .... |
| 04:17.04 |
brlcad |
but turns out
it's just that slow to walk over all 400+ targets to evaluate and
print "Built target ..." |
| 04:17.24 |
starseeker |
O.o |
| 04:17.41 |
brlcad |
cool, so
looks like it works |
| 04:17.47 |
brlcad |
to do
nothing: |
| 04:17.48 |
brlcad |
Elapsed
compilation time: 1 minute 7 seconds |
| 04:18.07 |
starseeker |
what's the
autotools time to do nothing? |
| 04:18.39 |
starseeker |
actually,
with all the docbook targets present (even without pdf) I think
it's over a thousand targets... |
| 04:18.57 |
brlcad |
yeah, it
is |
| 04:19.08 |
starseeker |
that was fun
in Visual Studio |
| 04:19.14 |
brlcad |
good
question, I don't recall off the top of my head but was
less |
| 04:19.38 |
brlcad |
counts the number of targets |
| 04:19.40 |
starseeker |
bets it's about 50-60%, mostly due to faster
docbook |
| 04:20.14 |
CIA-133 |
BRL-CAD:
03108.62.166.91 07http://brlcad.org
* r3150 10/wiki/User:108.62.173.114: New page: [http://www.willa-sloneczna.euroadres.pl
noclegi kazimierz dolny] .Kiedy mysli sie nad slowami dluzszy pobyt
to prawdopodobnie rozwazasz o kilku tygodniach lub miesiacach. W
rzeczywistosc... |
| 04:20.22 |
brlcad |
sunufa! |
| 04:20.38 |
brlcad |
looks like I
know what I'm doing tomorrow |
| 04:20.56 |
CIA-133 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted
"[[User:108.62.173.114]]" |
| 04:21.03 |
starseeker |
oddly enough,
I'll be doing something similar (cleaning bathrooms ;-) |
| 04:21.06 |
CIA-133 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:108.62.166.91]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 04:21.48 |
brlcad |
good thing is
that it takes less than 30 seconds to revert and block .. but
still, pita! |
| 04:21.52 |
brlcad |
1175 targets
:) |
| 04:22.32 |
starseeker |
<evil
laugh>MWA_HAHAHAHAHA</evil laugh> |
| 04:23.09 |
starseeker |
hmm - time to
do nothing on my Linux box here - 4 seconds |
| 04:24.04 |
starseeker |
can't wait to post a table somewhere with Linux, Mac and
Windows build times side by side |
| 04:25.03 |
starseeker |
brlcad:
you're feeding it the make -j# for the empty case? |
| 04:26.22 |
starseeker |
tries on a mac once... |
| 04:26.35 |
brlcad |
I had the
first time, but not that timed one |
| 04:27.00 |
starseeker |
it should
make a difference |
| 04:27.43 |
brlcad |
probably, but
not a huge one .. this laptop only has two procs and the disks are
too fast and os x is an i/o bottleneck |
| 04:27.52 |
starseeker |
ah |
| 04:27.53 |
brlcad |
1min9sec |
| 04:28.02 |
starseeker |
phooy |
| 04:28.03 |
brlcad |
so .. bout
the same |
| 04:33.16 |
starseeker |
brlcad: so it
looks like we're closing in - svn manifests for distcheck and
turning the MSVC stuff into tests are the two biggies I know
about |
| 04:33.28 |
starseeker |
oh, and
finishing updating the docs |
| 04:33.38 |
brlcad |
msvc into
tests? |
| 04:33.46 |
starseeker |
config_win
going byebye |
| 04:33.55 |
brlcad |
ah
great |
| 04:35.17 |
brlcad |
should
probably hit the docs first, the sooner the deprecation statements
get added, the sooner we can remove the build in a couple
months |
| 04:35.17 |
starseeker |
is considering making a small convenience NSIS installer for
the Windows xsltproc |
| 04:36.39 |
starseeker |
knows you had a list of things to add statements to -
configure obviously, and autogen.sh |
| 04:36.50 |
starseeker |
is that in a
TODO somewhere? |
| 04:37.01 |
starseeker |
(just so I
know what to hit) |
| 04:37.41 |
brlcad |
those two are
the main ones |
| 04:38.22 |
starseeker |
did you want
to add notes in the current documentation files, or just swap them
out when the time comes? |
| 04:38.46 |
brlcad |
just swap, if
it's deprecated then there's no need to educate on the old
system |
| 04:39.07 |
brlcad |
the
statements are just added to the remnants visible for those that
did learn the old way |
| 04:39.09 |
starseeker |
nods - oh, is the new Bundled/System/Auto option setup to
your liking? |
| 04:39.23 |
brlcad |
haven't dove
that deep again |
| 04:39.31 |
starseeker |
ah,
k |
| 04:39.37 |
brlcad |
hm, libpc
bustage |
| 04:41.52 |
starseeker |
probably the
new boost |
| 04:41.57 |
brlcad |
yep |
| 04:42.26 |
starseeker |
grim? |
| 04:43.09 |
brlcad |
trivial |
| 04:43.13 |
CIA-133 |
BRL-CAD:
03brlcad * r46625 10/brlcad/trunk/configure.ac: reflect new
location of boost headers |
| 04:43.37 |
starseeker |
ah
:-) |
| 04:45.07 |
brlcad |
the new
normalized rays/s is pretty cool |
| 04:45.52 |
starseeker |
oh, in your
benchmark? |
| 04:46.04 |
brlcad |
yeah |
| 04:46.25 |
starseeker |
tries clang as long as he's on the mac... |
| 04:46.42 |
starseeker |
how're nurbs
stacking up? |
| 04:47.03 |
brlcad |
pulls rays/s
from the summary for a given trace, but then also calculates how
many pixels actually involved geometry and weights the rtfm
value |
| 04:47.25 |
starseeker |
sweet |
| 04:47.32 |
starseeker |
was that the
math you were scripting earlier? |
| 04:48.00 |
brlcad |
related, but
that was actually for the projected area and volume
cases |
| 04:48.12 |
starseeker |
yow |
| 04:48.47 |
brlcad |
they have to
do something a bit more tricky since I'm trying to report a
relative deviation as percentage error |
| 04:49.00 |
starseeker |
kinda sounds
like stuff mged should have had tools for |
| 04:49.44 |
brlcad |
mmm,
dunno |
| 04:49.52 |
brlcad |
not seeing
general utility |
| 04:50.01 |
brlcad |
for the pix
comparisons, sure |
| 04:51.00 |
brlcad |
but there the
math is easy, just 1 - (num_pixels_wrong / num_pixels) |
| 04:51.33 |
starseeker |
ah - guess I
was thinking something like having rt report the "pixels involving
geometry" metric |
| 04:51.56 |
brlcad |
ah, maybe but
that was also pretty easy to script |
| 04:52.01 |
brlcad |
with existing
tools |
| 04:52.18 |
starseeker |
cool |
| 04:52.18 |
brlcad |
the hard one
is the volume and error |
| 04:52.48 |
starseeker |
hmm:
src/conv/g-vrml.c:99:21: warning: using extended field designator
is an extension [-pedantic] |
| 04:52.50 |
brlcad |
amount_vol_wrong / amount_vol doesn't give
what you want |
| 04:53.20 |
brlcad |
well, at
least doesn't give what *I* want :) .. that just reports the %
difference |
| 04:53.27 |
starseeker |
nods |
| 04:53.39 |
starseeker |
sounds like a
problem for our resident math genius ;-) |
| 04:53.58 |
brlcad |
ended up with
this little bit of goodness: dc -e "1k 100.0 $bvol $vol - d * v
$bvol / 100.0 * - d [0] sa 0.0 >a p" |
| 04:54.08 |
starseeker |
O.o |
| 04:55.25 |
starseeker |
watches SdaiCONFIG_CONTROL_DESIGN.h barf warnings and
reflects that he REALLY needs to try the newer SCL
code... |
| 04:57.00 |
brlcad |
which is
basically: 100.0 - abs(actual_volume - real_volume) / actual_volume
* 100.0 but then clamping the value to 0.0 if it goes
negative |
| 04:57.30 |
starseeker |
nods |
| 04:57.47 |
brlcad |
actual is
tiny and real is huge, then the "difference factor" is going to be
huge |
| 04:58.28 |
starseeker |
so it's
amplifying the difference? |
| 04:58.29 |
brlcad |
basically
means objects that are smaller than the baseline will have an error
value that is the percentage of the actual volume |
| 04:58.49 |
brlcad |
an object
half as big as it's supposed to be is going to report a volume
error of 50% |
| 04:58.59 |
starseeker |
ah,
gotcha |
| 05:00.43 |
brlcad |
but then for
objects larger than they're supposed to be, it'll report 50% when
it's 50% larger and 100% error when it's double (*or* more) in
size |
| 05:00.58 |
brlcad |
that's the
case that was hard to figure out |
| 05:01.13 |
brlcad |
since it can
be unboundedly larger than the baseline |
| 05:01.46 |
brlcad |
good
stuff |
| 05:01.52 |
starseeker |
are you
seeing cases much larger than baseline? |
| 05:02.00 |
starseeker |
is curious how that could come about... |
| 05:02.37 |
brlcad |
there are
some clear failures, but most are slight larger/smaller
deviations |
| 05:02.42 |
brlcad |
bots |
| 05:02.58 |
brlcad |
the calcs
will work for any case though |
| 05:03.10 |
starseeker |
nods - that's cool :-) |
| 05:04.44 |
starseeker |
aw - clang
build busted on obj-g_new.c |
| 05:05.26 |
starseeker |
ok, I gotta
get out of here |
| 05:05.59 |
starseeker |
brlcad: let
me know if you see an problems with the new COUNT setup, but I
think that will do the trick for most situations we're likely to
see |
| 05:11.10 |
CIA-133 |
BRL-CAD:
03starseeker * r46626 10/brlcad/trunk/src/conv/obj-g_new.c: size_t
-> size_t * for comparison |
| 05:11.20 |
starseeker |
and we build
with clang again :-) |
| 05:11.27 |
starseeker |
hits the road |
| 05:12.09 |
brlcad |
it's looking
great |
| 07:43.37 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 07:43.37 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 09:07.01 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 09:50.29 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 12:07.35 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl) |
| 13:28.28 |
starseeker |
oh, beautiful
- apparently a Makefile doesn't know what N is in make -j
N |
| 13:28.33 |
starseeker |
http://old.nabble.com/MAKEFLAGS-var-does-not-show-%22-j%22-param-----td15983337.html |
| 13:36.33 |
brlcad |
starseeker:
that's not what that thread says |
| 13:38.55 |
brlcad |
says make-w32
doesn't implement the parallel build with the "job server"
mechanism, so it redoes the parameter for some other mechanism on
windows |
| 13:45.14 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 14:02.59 |
*** join/#brlcad abhi2011_
(~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl) |
| 14:06.32 |
starseeker |
brlcad: not
the windows part, the part where $(MAKEFLAGS) will never show the
-jN option in parallel |
| 14:07.09 |
starseeker |
needs to introspect in the Makefile what the -j option passed
in was, and it apparently can't be accessed at
all |
| 14:08.25 |
starseeker |
just gives
back the --jobserver-fds=3,4 -j contents regardless |
| 14:08.29 |
starseeker |
confirms that in tests here |
| 14:16.16 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 14:20.01 |
brlcad |
starseeker:
ah, I see what you're getting at |
| 14:20.12 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 14:20.38 |
brlcad |
that's
undoubtedly because the jobserver is being entrusted with that
detail |
| 14:25.08 |
brlcad |
starseeker:
couldn't you just set it up so that it just toggles off a cmake
variable? cmake -DJOBS=3 |
| 14:25.38 |
brlcad |
then you can
access that to add -j$JOBS during dist or wherever |
| 14:27.01 |
starseeker |
that would
mean doing something like cmake -P distcheck.cmake -DJOBS=3 instead
of make -j3 distcheck |
| 14:27.18 |
starseeker |
workable, but
it takes distcheck outside the make system |
| 14:27.39 |
brlcad |
not
necessarily |
| 14:28.30 |
brlcad |
so you could
run "cmake -DJOBS=3 path/to/src" during setup, but it doesn't
actually do anything with it other than stash it |
| 14:28.56 |
starseeker |
oh, set the
job count at cmake configure time instead of make time? |
| 14:29.04 |
brlcad |
then "make
distcheck" would use the stashed value, or at worst maybe "make
distcheck JOBS=3" instead |
| 14:29.18 |
brlcad |
to override
at make-time |
| 14:29.28 |
starseeker |
isn't sure the override would work... |
| 14:29.33 |
brlcad |
another
options is just "-j" |
| 14:29.46 |
brlcad |
-j without a
number means "go hog wild" |
| 14:29.50 |
starseeker |
heh |
| 14:30.30 |
starseeker |
even that's
tricky though - accessing make values to feed to CMake isn't really
something the CMake generated scripts are set up for |
| 14:30.47 |
starseeker |
has an email into the CMake list to ask about
it |
| 14:31.31 |
starseeker |
ideal case
would be to add the ability to CMake generated make files to
respect some variable (JOBS or CPUS) passed in at make
time |
| 14:32.53 |
starseeker |
maybe have a
${CMAKE_CPU_COUNT} variable at CMakeLists.txt level that could be
added to the --build line, e.g. ${CMAKE_COMMAND} --build
-j${CMAKE_CPU_COUNT} and then have the CMake makefiles do the right
thing |
| 14:35.51 |
brlcad |
that's kind
of what I mean, just s/CMAKE_CPU_COUNT/JOBS/ |
| 14:36.15 |
starseeker |
nods - that would take support on the CMake generator
backend |
| 14:36.46 |
brlcad |
CMAKE_NCPU
would be a "proper" prefixed form I guess :) |
| 14:36.52 |
starseeker |
hehe |
| 14:36.57 |
starseeker |
will suggest that |
| 14:37.26 |
starseeker |
make NCPU=3
isn't make -j3, but it is probably as close as make will let us
get |
| 15:04.07 |
CIA-133 |
BRL-CAD:
03brlcad * r46630 10/brlcad/trunk/ (include/bu.h
src/libbu/fnmatch.c src/librt/search.c): |
| 15:04.08 |
CIA-133 |
BRL-CAD:
expose the documented minmum inteface for bu_fnmatch() including
the various |
| 15:04.08 |
CIA-133 |
BRL-CAD:
flags that a caller might set as well as the nomatch return value.
remove the |
| 15:04.08 |
CIA-133 |
BRL-CAD:
other BU_-prefixed symbols from the implementation since they're
not public api. |
| 15:04.08 |
CIA-133 |
BRL-CAD:
renamed BU_CASEFOLD to BU_FNMATCH_CASEFOLD in the process for bu
api |
| 15:04.08 |
CIA-133 |
BRL-CAD:
consistency. |
| 15:18.35 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 15:33.54 |
brlcad |
starseeker:
do you remember why you made the plans in librt/search.c void*
instead of db_plan_t* ? |
| 15:35.25 |
starseeker |
might have
had something to do with how I was calling things from
libged |
| 15:37.58 |
CIA-133 |
BRL-CAD:
03starseeker * r46631 10/brlcad/trunk/ (CMakeLists.txt autogen.sh
configure.ac): Make the depends explicit for these initial commands
- looks like ninja actually caught one out. |
| 15:38.04 |
starseeker |
ah
crud |
| 15:38.24 |
starseeker |
brlcad: well,
how do those look for autogen.sh and configure.ac deprecation
warnings? |
| 15:40.00 |
CIA-133 |
BRL-CAD:
03brlcad * r46632 10/brlcad/trunk/src/librt/search.c: lets not add
50 new functions to librt's API. mark all of the implementation
functions as HIDDEN. |
| 15:44.05 |
CIA-133 |
BRL-CAD:
03brlcad * r46633 10/brlcad/trunk/src/librt/search.c: ws indent
consistency cleanup |
| 15:44.38 |
CIA-133 |
BRL-CAD:
03brlcad * r46634 10/brlcad/trunk/include/raytrace.h: migrated
command doc from impl to header for
db_search_formplan() |
| 15:53.30 |
CIA-133 |
BRL-CAD:
03brlcad * r46635 10/brlcad/trunk/include/common.h: better document
why we use HIDDEN, emphasize that it's not really appropriate for
front-end code but is expected for libraries. |
| 15:53.55 |
CIA-133 |
BRL-CAD:
03brlcad * r46636 10/brlcad/trunk/src/libged/search.c: mark the
private functions as HIDDEN |
| 15:55.26 |
CIA-133 |
BRL-CAD:
03starseeker * r46637 10/brlcad/trunk/ (autogen.sh configure.ac):
these got sucked in by mistake |
| 15:56.28 |
brlcad |
starseeker:
good start, but a few changes -- s/may be/will be/ |
| 15:56.39 |
starseeker |
ah,
right |
| 15:56.44 |
brlcad |
and "Please
use .." doesn't really say anything |
| 15:57.14 |
brlcad |
they're using
what they know, so we should tell them what the new command is AND
where to read for more info |
| 15:57.39 |
starseeker |
k |
| 16:33.50 |
CIA-133 |
BRL-CAD:
03starseeker * r46638 10/brlcad/trunk/CMakeLists.txt: Try a
recommendation from Dave Cole of CMake - this is (more or less)
what they do in their ExternalProject code to handle
subbuilding |
| 16:44.25 |
brlcad |
starseeker:
is ninja one of the cmake devs or some system?? |
| 17:02.12 |
CIA-133 |
BRL-CAD:
03brlcad * r46639 10/brlcad/trunk/src/libbu/ (argv.c vls.c): move
bu_argv_from_string() from vls.c to argv.c |
| 17:06.12 |
starseeker |
oh, sorry -
new CMake generater for this: http://martine.github.com/ninja/manual.html |
| 17:06.45 |
brlcad |
ah |
| 17:07.05 |
starseeker |
in
development at the moment |
| 17:11.33 |
starseeker |
http://www.cmake.org/pipermail/cmake/2011-September/046145.html |
| 17:11.53 |
brlcad |
nods |
| 17:12.11 |
starseeker |
faster
building ftw, if it actually works |
| 17:15.37 |
CIA-133 |
BRL-CAD:
03brlcad * r46640 10/brlcad/trunk/ (include/bu.h src/libbu/argv.c):
make bu_argv_from_string() work with size_t instead of int for the
size parameters. move the decl over with the other argv functions.
need ctype.h header for isspace() too. |
| 17:31.19 |
CIA-133 |
BRL-CAD:
03bob1961 * r46641 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl:
Added a -singleSelectCallback option. If specified this essentially
puts the table widget into a mode where only one row at a time can
be selected. |
| 17:35.03 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl) |
| 18:06.25 |
CIA-133 |
BRL-CAD:
03173.234.121.94 07http://brlcad.org * r3151
10/wiki/Haha_Spoil_her_reputation_81: New page:
[[Image:reputation_management_1273.jpg|thumb|]] ya estamos listas
pa salir al shows miados aki en Tijuana, agarrensen poke este pedo
va a estar mamalon x 1 vez "las you you" !!!! NCBI
ROF... |
| 18:12.34 |
CIA-133 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Haha Spoil her reputation
81]]" |
| 18:12.45 |
CIA-133 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:173.234.121.94]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 18:32.37 |
*** join/#brlcad abhi2011_
(~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl) |
| 18:37.23 |
brlcad |
so there are
now a couple new wiki extensions installed |
| 18:38.16 |
brlcad |
one is a new
blacklist extension that pulls the massive lists maintained by
mediawiki and wikipedia folks (they are separate lists) that block
posts that contain blacklisted url/content |
| 18:39.06 |
brlcad |
another is a
Q&A tension -- anyone care to suggest some good hard
cad/math-related questions? |
| 18:44.40 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 18:45.45 |
n_reed |
not sure i
understand the notion of a Q&A extension |
| 18:45.56 |
n_reed |
is the idea
to post questions and answers |
| 18:46.04 |
n_reed |
or to get
people to answer questions |
| 18:47.12 |
brlcad |
we pose a
question, they have to answer it correctly to modify the
wiki |
| 18:47.40 |
brlcad |
like "What is
the name of this software?" answer: BRL-CAD |
| 18:48.21 |
n_reed |
so like a
captcha, but harder |
| 18:49.14 |
brlcad |
what is the
square root of 1000-100? |
| 18:49.15 |
brlcad |
sure |
| 18:50.25 |
n_reed |
are you
asking for suggesstions because you want to populate a list of
options? |
| 18:53.29 |
brlcad |
that is the
idea |
| 18:54.52 |
n_reed |
i'll ask the
obvious math person to send you some |
| 18:56.15 |
brlcad |
mere (CAD)
mortals should be able to answer them |
| 18:56.38 |
brlcad |
I already
have about 10, probably enough -- more just whether others wanted
to add a couple |
| 19:22.31 |
CIA-133 |
BRL-CAD:
0368.34.98.23 07http://brlcad.org *
r3152 10/wiki/Testing_something_bogus: New page: This is a
test. |
| 19:23.26 |
CIA-133 |
BRL-CAD:
0368.34.98.23 07http://brlcad.org *
r3153 10/wiki/Testing_something_bogus: |
| 19:28.22 |
starseeker |
phew -
parallel distcheck |
| 19:28.55 |
CIA-133 |
BRL-CAD:
03bob1961 * r46642 10/brlcad/trunk/ (11 files in 5 dirs): Added
more editing support for pipes (i.e. append, prepend, delete, move,
select and scale). |
| 19:31.18 |
starseeker |
re-enables the "make your life miserable" parts until he gets
proper svn manifest checking working |
| 19:40.42 |
CIA-133 |
BRL-CAD:
03bob1961 * r46643 10/brlcad/trunk/src/libged/Makefile.am: Added
edpipe.c to libged/Makefile.am |
| 19:41.02 |
CIA-133 |
BRL-CAD:
0368.34.98.23 07http://brlcad.org *
r3154 10/wiki/Testing_something_bogus: |
| 19:42.14 |
CIA-133 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Testing something bogus]]":
just testing |
| 19:44.36 |
brlcad |
so we'll see
if that helps -- recaptcha is no longer enabled and logged in users
still have no captcha |
| 19:49.33 |
starseeker |
brlcad: nice,
thanks! |
| 19:52.40 |
starseeker |
pwd |
| 19:52.42 |
starseeker |
whoops |
| 20:03.26 |
starseeker |
hmm:
http://www.opencascade.org/about/news/issue173/ |
| 20:03.40 |
starseeker |
wonders if that constitutes a glimmer of hope or
not |
| 20:05.49 |
CIA-133 |
BRL-CAD:
03starseeker * r46644 10/brlcad/trunk/CMakeLists.txt: turn back on
the repo checks. distcheck will need to become its own CMake file I
think - this is getting too complex for one custom
target. |
| 20:10.23 |
brlcad |
probably in
response to OCE |
| 20:11.15 |
starseeker |
almost
certainly - question will be whether it's just words or if they
actually change |
| 20:11.33 |
brlcad |
they need to
start with the license itself |
| 20:11.37 |
starseeker |
would be
awesome if they went LGPL |
| 20:11.59 |
brlcad |
or
better |
| 20:13.32 |
starseeker |
dunno how
technically compatible we would be even if the license were ironed
out, but they do have some bits we don't right now... |
| 20:41.23 |
brlcad |
and vice
versa, but cleanly integrating pieces from two large codebases is
arguably more work than implementing from scratch for
each |
| 20:41.54 |
brlcad |
better to
collaborate on the pieces that can be fully abstracted from both
(like SCL) |
| 20:42.19 |
CIA-133 |
BRL-CAD:
03r_weiss * r46645 10/brlcad/trunk/include/bn.h: |
| 20:42.19 |
CIA-133 |
BRL-CAD:
Updated include file 'bn.h' to enable the prototype versions of
functions |
| 20:42.19 |
CIA-133 |
BRL-CAD:
bn_isect_lseg3_lseg3, bn_isect_line3_line3, and bn_isect_line_lseg
and remove |
| 20:42.19 |
CIA-133 |
BRL-CAD: the
original versions. This change is the first of three. The remaining
changes |
| 20:42.19 |
CIA-133 |
BRL-CAD: will
be to files 'plane.c' and 'nmg_tri.c'. |
| 20:44.27 |
CIA-133 |
BRL-CAD:
03r_weiss * r46646 10/brlcad/trunk/src/libbn/plane.c: Updated file
'plane.c' to enable the prototype versions of functions
bn_isect_lseg3_lseg3, bn_isect_line3_line3, and bn_isect_line_lseg.
The original functions are removed. |
| 20:47.28 |
CIA-133 |
BRL-CAD:
03r_weiss * r46647
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: Updated file
'nmg_tri.c' to change function calls from the prototype names of
functions bn_isect_lseg3_lseg3, and bn_isect_line3_line3 back to
their original names. |
| 21:04.07 |
brlcad |
http://vim.wikia.com/wiki/Remove_unwanted_spaces |
| 21:04.07 |
brlcad |
http://vim.wikia.com/wiki/Highlight_unwanted_spaces |
| 21:04.23 |
brlcad |
possibly of
interest to some of the vimragers in here |
| 21:08.09 |
CIA-133 |
BRL-CAD:
03brlcad * r46648 10/brlcad/trunk/src/ (70 files in 70 dirs): ws
consistency removing trailing ws and much more (see
sh/ws.sh) |
| 21:21.36 |
CIA-133 |
BRL-CAD:
03brlcad * r46649 10/brlcad/trunk/src/ (12 files in 12 dirs): more
ws consistency cleanup |
| 21:22.09 |
brlcad |
starts to see a pattern |
| 21:33.21 |
CIA-133 |
BRL-CAD:
03bob1961 * r46650 10/brlcad/trunk/src/libged/edpipe.c: Collapse
the functionality of ged_append_pipept() and ged_prepend_pipept()
into _ged_append_pipept_common(). |
| 21:36.33 |
CIA-133 |
BRL-CAD:
03r_weiss * r46651 10/brlcad/trunk/src/librt/primitives/nmg/ (8
files): Updated files nmg_class.c, nmg_fuse.c, nmg_info.c,
nmg_inter.c, nmg_mk.c, nmg_mod.c, nmg_rt_isect.c and nmg_tri.c to
turn on the prototype triangulation code of nmg
primitives. |
| 21:38.48 |
CIA-133 |
BRL-CAD:
03bob1961 * r46652
10/brlcad/trunk/src/libtclcad/tclcad_obj.c: |
| 21:38.48 |
CIA-133 |
BRL-CAD:
Collapse the functionality of to_mouse_append_pipept()
and |
| 21:38.48 |
CIA-133 |
BRL-CAD:
to_mouse_prepend_pipept() into to_mouse_append_pipept_common().
Added a call to |
| 21:38.48 |
CIA-133 |
BRL-CAD:
ged_snap_to_grid() in to_mouse_append_pipept_common for
snap-to-grid behavior |
| 21:38.48 |
CIA-133 |
BRL-CAD: when
adding/inserting pipe points. |
| 21:40.38 |
CIA-133 |
BRL-CAD:
03r_weiss * r46653 10/brlcad/trunk/include/raytrace.h: Updated
raytrace.h to turn on the prototype triangulation of nmg
primitives. |
| 21:40.50 |
brlcad |
r_weiss'
change really begs for some thorough retesting with the conversion
script |
| 21:48.33 |
CIA-133 |
BRL-CAD:
03r_weiss * r46654 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
Updated ars.c to turn on changes which were disabled until the
prototype version of nmg triangulation was enabled. |
| 21:52.00 |
CIA-133 |
BRL-CAD:
03n_reed * r46655 10/brlcad/trunk/src/external/CMakeLists.txt:
syntax error |
| 21:59.04 |
starseeker |
brlcad: the
pattern being my files having busted whitespace? |
| 22:00.05 |
starseeker |
hides |
| 22:02.26 |
starseeker |
tried to set his editors to behave, really he
did... |
| 22:08.29 |
starseeker |
winces - did Richard see your source release
announcement? |
| 22:09.47 |
starseeker |
makes a note to look into astyle sometime http://astyle.sourceforge.net/ |
| 22:35.12 |
CIA-133 |
BRL-CAD:
03r_weiss * r46656 10/brlcad/trunk/src/librt/primitives/tor/tor.c:
Updated file tor.c to enable removing of zero length edges from
torus primitives. This was disabled until the prototype nmg
triangulation was made available. |
| 23:09.00 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 23:45.57 |
starseeker |
huh - of
course it's not quite the same since the tcl pkgIndex building
macros aren't firing, but if I turn off docbook and
compare: |
| 23:46.50 |
starseeker |
make: 7m8s,
ninja: 6m13s to build all of BRL-CAD on my gentoo box |
| 23:47.13 |
starseeker |
(debug
config) |
| 00:04.01 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 00:04.49 |
brlcad |
mm e-mail
troll |
| 00:35.44 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 00:51.23 |
abhi2011 |
brlcad , is
there a way to change the rt resolution from the default 512 by
512 |
| 00:56.24 |
abhi2011 |
ok got
it |
| 00:56.28 |
abhi2011 |
the -s
option |
| 01:00.14 |
abhi2011 |
hmm trying
with -s1024, seems like have to leave the rendering job overnight
:P |
| 01:10.42 |
CIA-133 |
BRL-CAD:
03abhi2011 * r46679 10/brlcad/trunk/src/libged/simulate/
(simphysics.cpp simulate.c simulate.h): Added code to simulate
command for showing bounding boxes and rigid body activation
state |
| 01:24.01 |
CIA-133 |
BRL-CAD:
03starseeker * r46680 10/brlcad/trunk/ (6 files in 4 dirs): More
distcheck progress, although there's still at least one bug to iron
out. |
| 03:17.59 |
brlcad |
abhi2011: the
number of pixels increases quadratically as you increase the image
size |
| 03:18.27 |
brlcad |
so going from
512x512 to 1024x1024 is a 4x increase in the number of pixels being
rendered |
| 03:21.08 |
brlcad |
usually
better to get your scene set up exactly how you want it at 256x256
or similar without materials for a quick preview, then render high
at some much higher resolution (I tend to like 4096x4096 with
jitter and hypersampling) with materials and custom light
sources |
| 03:21.37 |
brlcad |
but then
those usually beg for some quick distributed rendering with lots of
computers :) |
| 03:27.44 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 05:18.45 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 05:18.45 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 11:38.52 |
CIA-133 |
BRL-CAD:
03starseeker * r46681
10/brlcad/trunk/src/libged/simulate/simulate.c: comment out rv
until it's actually used, breaks strict building as the code
currently stands. |
| 12:00.34 |
CIA-133 |
BRL-CAD:
03starseeker * r46682 10/brlcad/trunk/ (CMakeLists.txt
misc/CMake/BRLCAD_Util.cmake): fix paths that are appended to
cmakefiles.cmake and cmakedirs.cmake |
| 12:25.03 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 12:56.07 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46683 10/brlcad/trunk/doc/docbook/Makefile.am:
correct XSLTPROC options; add new document to tree |
| 13:17.26 |
CIA-133 |
BRL-CAD:
03starseeker * r46684 10/brlcad/trunk/ (28 files in 5 dirs): (log
message trimmed) |
| 13:17.26 |
CIA-133 |
BRL-CAD:
Variety of distcheck fixes, including a nifty problem where a
directory named |
| 13:17.26 |
CIA-133 |
BRL-CAD:
'off' was causing a logic failure in the path building logic. dist
files are |
| 13:17.26 |
CIA-133 |
BRL-CAD: now
actual cmake files that are included - this allows CMake to re-run
after one |
| 13:17.26 |
CIA-133 |
BRL-CAD: is
edited, which is the correct behavior. directories that are
specified (as |
| 13:17.27 |
CIA-133 |
BRL-CAD:
opposed to recognized as parents of files specfied) use svn info to
build the |
| 13:17.28 |
CIA-133 |
BRL-CAD: list
of files below the ignored directory, which means temporary files
should be |
| 13:41.14 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46685 10/brlcad/trunk/doc/docbook/presentations/ (13
files in 3 dirs): new document added to tree |
| 14:08.24 |
CIA-133 |
BRL-CAD:
03brlcad * r46686 10/brlcad/trunk/doc/docbook/Makefile.am: fully
sort the list |
| 14:08.56 |
CIA-133 |
BRL-CAD:
03Tbrowder 07http://brlcad.org *
r3158 10/wiki/FAQ: add a new bit of trivia from the
old-timers |
| 14:17.39 |
CIA-133 |
BRL-CAD:
03starseeker * r46687
10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: |
| 14:17.39 |
CIA-133 |
BRL-CAD: OK.
First rule if building a dist tarball from a tarball or other
non-svn |
| 14:17.39 |
CIA-133 |
BRL-CAD:
checkout source, don't. CPack has no way of knowing what to exclude
in the |
| 14:17.39 |
CIA-133 |
BRL-CAD:
fully ignored sub-directories. If you must, distcheck will do what
it can where |
| 14:17.39 |
CIA-133 |
BRL-CAD: it
can to spot files that don't belong, and warn you of your
peril. |
| 14:20.59 |
CIA-133 |
BRL-CAD:
03Tbrowder 07http://brlcad.org *
r3159 10/wiki/SVN: add link to some more SVN info |
| 14:27.42 |
CIA-133 |
BRL-CAD:
03Tbrowder 07http://brlcad.org *
r3160 10/wiki/SVN: |
| 14:29.52 |
CIA-133 |
BRL-CAD:
03Tbrowder 07http://brlcad.org *
r3161 10/wiki/SVN: add link to more svn info |
| 14:50.24 |
CIA-133 |
BRL-CAD:
03starseeker * r46688
10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: |
| 14:50.24 |
CIA-133 |
BRL-CAD: Be
nice to the users, if the ignored file count gets too large refer
them to a |
| 14:50.24 |
CIA-133 |
BRL-CAD: file
instead of dumping thousands of lines to the terminal. Need to
do |
| 14:50.24 |
CIA-133 |
BRL-CAD:
something more intelligent for in-src distcheck building, which is
what prompted |
| 14:50.24 |
CIA-133 |
BRL-CAD: the
change, but might as well handle this for cases with lots of stray
files |
| 14:50.25 |
CIA-133 |
BRL-CAD:
too. |
| 14:56.06 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 15:07.45 |
CIA-133 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3162 10/wiki/User:Abhijit: /* Log */ |
| 15:16.21 |
CIA-133 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3163 10/wiki/User:Abhijit: /* Development timeline */ |
| 15:32.20 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46689 10/brlcad/trunk/doc/docbook/Makefile.am: more
file name sorting |
| 16:16.37 |
brlcad |
interesting,
http://www.cs.washington.edu/research/constraints/cassowary/ |
| 16:32.02 |
brlcad |
secondary
lead if spirit work ever hits a roadblock |
| 16:51.07 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46690 10/brlcad/trunk/doc/docbook/README: added blub
on new presentations directory |
| 16:52.50 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46691 10/brlcad/trunk/doc/docbook/ (Makefile.am
system/man1/en/Makefile.am): renamed build variable to better track
file tree name |
| 16:53.13 |
*** join/#brlcad Stattrav
(~Stattrav@61.12.114.82) |
| 16:53.13 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 16:55.36 |
starseeker |
brlcad: does
it do floating point? |
| 16:56.45 |
starseeker |
ah, I think
I've run across that before |
| 16:57.29 |
starseeker |
that also
needs GTL:
http://www.fim.uni-passau.de/en/fim/faculty/chairs/theoretische-informatik/projects.html |
| 16:58.53 |
starseeker |
O.o am I
seeing that right, Apple is using it? |
| 17:00.48 |
starseeker |
perhaps I
underestimated it |
| 17:05.19 |
starseeker |
looks like it
also wants guile |
| 17:29.58 |
brlcad |
nods |
| 17:30.29 |
brlcad |
it's also
dead/unsupported along with GTL, but an interesting lib
nonetheless |
| 17:31.24 |
brlcad |
i'd be a
little surprised if guile was actually required |
| 17:31.30 |
brlcad |
there's lots
of bindings to various languages, I suspect that's where it's
used |
| 17:35.04 |
starseeker |
nods - yeah, most of it looks like demos |
| 17:35.21 |
starseeker |
probably not
too hard to get the interesting subset building |
| 17:35.57 |
starseeker |
nifty:
http://www.badros.com/greg/cassowary/js/quaddemo.html |
| 17:36.55 |
starseeker |
is quite intrigued by Apple's use |
| 17:43.53 |
starseeker |
doesn't see any code from Apple on the cassowary site...
wonder if they just used it as-is? |
| 17:44.02 |
starseeker |
would be
surprising for code that old |
| 17:46.34 |
starseeker |
brlcad: was
that the academic library you were thinking of? |
| 17:47.26 |
starseeker |
vaguely remembers getting as far as determining it needed GTL
and that GTL still exists before, but I didn't follow up since
gecode looked more modern and maintained |
| 17:48.20 |
starseeker |
wasn't fully
aware of gecode's lack of floating point solver support at the
time |
| 18:00.26 |
brlcad |
starseeker:
it might have been, don't remember for certain |
| 18:01.14 |
starseeker |
will play with it later - struggling to convince CPack not to
include build files in its tarballs |
| 18:01.18 |
brlcad |
still,
greener pastures and all -- it's just a good thought to keep in
mind's back pocket, maybe wire up to the libpc test cases to see
how it does |
| 18:01.51 |
starseeker |
may have to
at least require a subdirectory within the source tree - the
source=build case is a nightmare |
| 18:02.12 |
brlcad |
nightmare in
what sense? |
| 18:02.37 |
starseeker |
I have to
tell CPack to exclude files, but the simple act of RUNNING cpack
within the build tree creates more files |
| 18:03.07 |
starseeker |
which I can't
list for CPack because they don't exist ahead of time |
| 18:03.22 |
brlcad |
you mean for
distcheck? |
| 18:03.24 |
starseeker |
yeah |
| 18:04.05 |
brlcad |
if it's
*only* for distchecking, not a big deal -- or even let cpack pack
them, it'll just warn on them down the line |
| 18:04.33 |
starseeker |
as long as
it's smart enough to not be recursive, I guess... |
| 18:04.34 |
brlcad |
in practice
for proper dist building, it can be out of dir no
worries |
| 18:05.11 |
brlcad |
in source
build support is really only needed to support simple
compilation/install |
| 18:05.30 |
brlcad |
distchecking
is "in-house stuff, in-house rules" |
| 18:05.54 |
starseeker |
I thought one
of the points though was to verify the tarball had everything we
wanted it to |
| 18:06.01 |
brlcad |
sure |
| 18:06.13 |
starseeker |
(admittedly
that works a little different now, with that verification happening
up front, sorta...) |
| 18:06.35 |
brlcad |
so it has too
much if someone built in-dir and ran distcheck, but it could warn
and still run all the tests |
| 18:07.03 |
starseeker |
nods... true |
| 18:07.28 |
brlcad |
checking the
tarball is only half the picture, and the lesser-utilized half at
that |
| 18:07.41 |
brlcad |
the other
half of the distcheck is all the testing |
| 18:07.54 |
brlcad |
that is
desirable to run and re-run as often as possible |
| 18:08.16 |
brlcad |
so is
distcheck ready to go now? |
| 18:08.26 |
brlcad |
I'm going
through commits now to see if everything is documented |
| 18:08.43 |
starseeker |
close, but I
wouldn't consider it properly hooked in yet |
| 18:10.31 |
CIA-133 |
BRL-CAD:
03brlcad * r46692 10/brlcad/trunk/NEWS: tom converted traNese's
intro to Tcl/Tk presentation into the docbook format. that means
it'll get installed in html form (and potentially as
pdf). |
| 18:10.42 |
brlcad |
close enough
for me to distcheck a source release tarball? :) |
| 18:10.55 |
starseeker |
urm. from
out of dir build, maybe |
| 18:11.13 |
brlcad |
was hoping for better than maybe :D |
| 18:11.32 |
starseeker |
brlcad: I've
totally rewritten it twice in the last two days :-P |
| 18:11.36 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 18:11.38 |
starseeker |
it's hard to
be definitive just yet |
| 18:11.41 |
brlcad |
I know,
that's why I'm asking |
| 18:12.47 |
brlcad |
abhi2011:
how's that render coming along? |
| 18:13.06 |
brlcad |
wants to set up his own scene here real soon
now... |
| 18:24.29 |
jordisayol |
brlcad: I see
that "sh/make-deb.sh" was modified by tbrowder2 |
| 18:25.28 |
jordisayol |
brlcad: is
there some problem with my maintenance? |
| 18:25.44 |
piksi |
are there
screenshots or feature lists of the current archer ui? |
| 18:26.29 |
CIA-133 |
BRL-CAD:
03brlcad * r46693
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: if the code
added to quiet compiler warnings has to also be quieted (with #if
0), then it should just be removed... |
| 18:30.18 |
starseeker |
piksi: this
is fairly current: http://bzflag.bz/~starseeker/archer_win32_native_built_docs.png |
| 18:30.58 |
starseeker |
this is still
fairly close appearance wise: http://bzflag.bz/~starseeker/archer_latest.png |
| 18:31.41 |
brlcad |
jordisayol:
not at all, at least not that I'm aware of -- were the changes
significant/controversial? |
| 18:31.55 |
brlcad |
I think he
was just trying to help |
| 18:32.29 |
brlcad |
tom's a
relatively new committer, communicates via mailing list |
| 18:32.49 |
jordisayol |
brlcad: I'm
just checking, it appear that only added a "test dependency only"
ability |
| 18:33.55 |
jordisayol |
brlcad: is
just to know if I have to continue to build new deb/rpm
packages |
| 18:33.59 |
piksi |
starseeker:
thanks. last time i tried modeling something with MGED i found it
extremely cumbersome compared to e.g. current versions of autocad
or autodesk revit. archer ui looks pretty much like autocad circa
2004. what kind of an ui philosophy is being used with
archer? |
| 18:34.12 |
brlcad |
jordisayol:
oh, please! :) |
| 18:34.46 |
brlcad |
you don't
"have to" but it's greatly helpful and appreciated (as seen by the
loads and loads of downloads) |
| 18:35.13 |
starseeker |
piksi: um.
"make it not suck?" not sure what you mean by a ui
philosophy |
| 18:35.30 |
piksi |
jordisayol is
responsible for rpm packaging? |
| 18:35.40 |
jordisayol |
brlcad: no
no, it's ok. i just want to know |
| 18:35.45 |
piksi |
then i have
to thank you, i was pleasantly surprised to find a fedora package
for my system :-) |
| 18:36.12 |
jordisayol |
piksi: i do
my best, and yes i buils rpm packages |
| 18:36.18 |
jordisayol |
build* |
| 18:36.45 |
jordisayol |
piksi: is
there some problem with them? |
| 18:36.54 |
brlcad |
piksi: my
goal is towards a completely modeless redesigned ui but we're not
going to get there in one jump |
| 18:37.18 |
piksi |
jordisayol:
no, i was just very happy that there was an rpm and i didn't have
to compile :-) |
| 18:37.33 |
jordisayol |
piksi:
;-) |
| 18:37.36 |
piksi |
starseeker:
ui philosophy, i.e. all tools working in a consistent manner,
designing the tools from the viewpoint of a designer (for example
having good 3d snapping capabilities, versatile
extruding/lofting/revolving tools etc) |
| 18:37.50 |
brlcad |
archer is
already a huge stepping stone as it is, even if it just brings us
into the 90's ;) .. to do more would increase risk of delays (or
outright failure) |
| 18:39.26 |
piksi |
brlcad: if by
mode you mean the command line type interface of autocad, i find it
extremely fast compared to many of the recent autodesk ui changes
that move towards clicking (without being "in a command
state") |
| 18:39.43 |
brlcad |
a lot of the
nifty UI features you mention require extensive backend support,
too -- which has little if anything to do with the overarching ui
design |
| 18:39.57 |
jordisayol |
brlcad: as a
main developer, can You tell tbrowder2 to communicate me just ins
deb/rpm modifications? just for a better building
result |
| 18:40.22 |
brlcad |
piksi: that
is not what is meant by mode, http://en.wikipedia.org/wiki/Mode_(computer_interface) |
| 18:40.25 |
piksi |
brlcad: yes,
i understand that the ui features i'm longing for require an
*extensive* framework which is not easy to do at all |
| 18:41.11 |
piksi |
brlcad: ah
now i understood. yes, that is a good thing to avoid |
| 18:41.17 |
brlcad |
jordisayol:
hm? didn't understand the "just ins" |
| 18:42.02 |
brlcad |
jordisayol:
if you see something undesirable, you can revert it from the
deb/rpm files -- that merely begs a dev-dev discussion |
| 18:42.04 |
jordisayol |
brlcad:
sorry, is a typo. just for files directly involved in deb/rpm
building packages |
| 18:42.37 |
piksi |
brlcad: is
any kind of an input/suggestions/feature requests for the upcoming
ui features needed or accepted from users? my background is in
architecture but i've used brl from time to time to model csg-stuff
instead of autocad |
| 18:43.01 |
jordisayol |
well, I've
modified "sh/make_debsh" to disable source build, and now i find
this modification, that's all |
| 18:43.05 |
brlcad |
fwiw, a
commit effectively is a means of communication -- and one that's
guaranteed to reach everyone |
| 18:43.22 |
brlcad |
otherwise
it's a bit tricky with him on the mailing list and you on irc --
the discussions shouldn't be in private |
| 18:44.23 |
starseeker |
brlcad: yep,
though so - new docbook stuff sets off cmake distcheck |
| 18:44.26 |
starseeker |
one
sec... |
| 18:45.28 |
jordisayol |
brlcad:
ok |
| 18:47.00 |
brlcad |
piksi:
input/suggestions/feature requests are always welcome but with
heeded caution that we've probably heard/thought of it too (we have
a TODO list that probably represents a 1000-staff years of effort
and that still wouldn't get us all the features of the "big
five") |
| 18:47.11 |
piksi |
:-) |
| 18:47.44 |
piksi |
brlcad: yeah
i wasn't expecting to introduce anything groundbreaking in terms of
design. is the todo list public? |
| 18:47.55 |
brlcad |
piksi: more
constructive is the suggestions that have real productive effort
tied to them -- like coming up with a detailed use case or a real
prototype mock up |
| 18:48.07 |
piksi |
yeah i always
try to provide mockups |
| 18:49.25 |
brlcad |
even better
is to relate it to the current state of the software, like looking
at MGED or Archer's horrid menu hierarchy and detailing exactly
what a new/better hierarchy would look like, etc |
| 18:50.09 |
brlcad |
as for the
3rd generation interface, a good bit of mock-up design effort has
already happened (in a non-CAD/agnostic way to help with the
underlying usability concepts) |
| 18:51.58 |
brlcad |
one prototype
video is here: http://brlcad.org/design/gui/ |
| 18:52.17 |
CIA-133 |
BRL-CAD:
03starseeker * r46694 10/brlcad/trunk/ (CMakeLists.txt
misc/CMake/distcheck_buildsys.cmake.in): |
| 18:52.17 |
CIA-133 |
BRL-CAD:
Deduce the in-source build directory rather than hardcode one devs
typical |
| 18:52.17 |
CIA-133 |
BRL-CAD:
defaults. Have the distcheck routine use the variable as well to
clean up its |
| 18:52.17 |
CIA-133 |
BRL-CAD:
output. Looks like this is helpful, but not clear yet if it is a
full solution. |
| 18:53.03 |
brlcad |
jordisayol:
to reiterate, if he modified one of the scripts your using and it
affects your ability to prepare a release, there is ABSOLUTELY no
problem reverting that change |
| 18:53.30 |
brlcad |
if it doesn't
affect what you're doing or can be accommodated, then great .. just
ignore it or accommodate or ask him to make it optional or whatever
works ;) |
| 18:53.52 |
brlcad |
if you reply
to the commit e-mail, it'll go to the brlcad-devel mailing list and
reach him |
| 18:54.26 |
jordisayol |
brlcad:
well,the only two files out of /misc/debian dir that I modified are
make_deb.sh and make_rpm.sh |
| 18:54.42 |
jordisayol |
brlcad: and
he modified make_deb.sh |
| 18:55.01 |
starseeker |
jordisayol:
the changes conflict? |
| 18:55.33 |
jordisayol |
is not a bit
modification, just added a new option to just test is dependencies
are present in system and exit |
| 18:55.51 |
jordisayol |
is =>
if |
| 18:56.14 |
brlcad |
modifications
are to be expected anywhere in the source tree, part of
collaborative development |
| 18:56.42 |
brlcad |
what's really
cool is having three devs all working in the same file at the same
time, frequently updating, and just seeing the code flow
:) |
| 18:57.00 |
brlcad |
i've only
seen it a couple times in my career, but it's a thing of beauty
:D |
| 18:57.29 |
brlcad |
hyperproductivity! |
| 18:58.19 |
CIA-133 |
BRL-CAD:
03starseeker * r46695 10/brlcad/trunk/doc/docbook/ (3 files in 3
dirs): Fix up the presentations CMakeLists.txt logic |
| 18:59.04 |
jordisayol |
brlcad: I
apologize, I was surprised for this modification, that's
all |
| 18:59.28 |
starseeker |
jordisayol:
generally, that's a good thing - it means people are taking an
interest in your work :-) |
| 19:00.26 |
jordisayol |
brlcad: yes,
shure, but it can means to that i'm not doing it so good too
:-) |
| 19:01.54 |
brlcad |
it didn't
even occur to me to think that it meant you were doing something so
good :) |
| 19:02.59 |
brlcad |
what
starseeker said, just someone else taking an interest in the
scripts, in what you'd done .. that's usually a "really good"
thing |
| 19:03.57 |
jordisayol |
brlcad: You
and starseeker have a couple of beers payed ;-) |
| 19:05.37 |
starseeker |
brlcad
actually went to some trouble to remove individual authorship
entries from the various source files and instead record them in
the AUTHORS file - we don't want to wind up with a situation where
people don't want to touch code because "it's somebody
else's" |
| 19:06.53 |
starseeker |
so no worries
- we're all trying to Make Things Better :-) |
| 19:08.46 |
CIA-133 |
BRL-CAD:
03brlcad * r46696 10/brlcad/trunk/NEWS: bob has initial support in
for editing pipe primitives within archer. support for appending,
prepending, deleting, moving, selecting, and scaling. |
| 19:13.23 |
CIA-133 |
BRL-CAD:
03starseeker * r46697 10/brlcad/trunk/CMakeLists.txt: |
| 19:13.23 |
CIA-133 |
BRL-CAD: Be
sure we don't do anything in the case where the build and the
source |
| 19:13.23 |
CIA-133 |
BRL-CAD:
directories are the same directory - unless I'm missing some CPack
option or |
| 19:13.23 |
CIA-133 |
BRL-CAD:
feature (possible) that case is just not going to mix well with
CPack's approach |
| 19:13.23 |
CIA-133 |
BRL-CAD: to
archive creation. |
| 19:15.33 |
starseeker |
brlcad: cmake
distcheck now succeeds |
| 19:18.05 |
CIA-133 |
BRL-CAD:
03starseeker * r46698 10/brlcad/trunk/CMakeLists.txt: fix if
location |
| 19:25.59 |
jordisayol |
brlcad: there
are some errors on tbrowder2 make_deb.sh modifications. He treat
some packages names as executable files names, and this will cause
the script failure |
| 19:29.56 |
piksi |
brlcad:
thanks, i'll look into it |
| 19:31.31 |
brlcad |
piksi: the
TODO file in any source distribution contains several hundred items
(some huge, some tiny) |
| 19:31.48 |
piksi |
:-) |
| 19:32.30 |
brlcad |
the
documentation section at the bottom is particularly ripe for
getting involved in a useful way, but that extends to (unlisted)
developer documents (aforementioned mockups etc) too |
| 20:05.31 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 20:05.31 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 20:05.31 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
| 20:05.31 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 20:05.31 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 20:05.31 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 20:05.31 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 20:05.31 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 20:05.31 |
*** join/#brlcad plaes
(~plaes@gn237.zone.eu) |
| 20:05.31 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 20:05.31 |
*** join/#brlcad kunigami1
(~kunigami@loco-gw.ic.unicamp.br) |
| 20:05.31 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 20:05.31 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 20:05.31 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 20:05.31 |
*** join/#brlcad CIA-133
(~CIA@cia.atheme.org) |
| 20:19.05 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 20:45.23 |
CIA-133 |
BRL-CAD:
03starseeker * r46699 10/brlcad/trunk/ (4 files in 2 dirs): Make a
stab at consolidation of all distcheck logic into one
file. |
| 21:12.00 |
CIA-133 |
BRL-CAD:
03starseeker * r46700 10/brlcad/trunk/ (4 files in 2 dirs): Hmm.
$(MAKE) isn't working as expected in EXECUTE_PROCESS - revert the
one file solution. |
| 21:14.18 |
starseeker |
oh, duh -
right, $(MAKE) is specific to make files |
| 21:21.17 |
CIA-133 |
BRL-CAD:
03starseeker * r46701 10/brlcad/trunk/CMakeLists.txt: Fix numbers
on distcheck stages. |
| 21:24.35 |
CIA-133 |
BRL-CAD:
03starseeker * r46702 10/brlcad/trunk/CMakeLists.txt: try searching
for cpack rather than hardcoding it. |
| 21:31.40 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 21:32.09 |
CIA-133 |
BRL-CAD:
03starseeker * r46703 10/brlcad/trunk/ (3 files in 2 dirs):
completed distcheck does not necessarily imply distribution ready
files, so don't assert that. No need for distcheck message file,
and not using the old svncheck anymore. |
| 22:20.42 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 22:57.26 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46704
10/brlcad/trunk/doc/docbook/resources/docbook-5.0/ (36 files in 8
dirs): add DocBook schemas for validation |
| 22:58.30 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46705 10/brlcad/trunk/doc/docbook/Makefile.am: add
make target for DocBook validation |
| 23:18.43 |
CIA-133 |
BRL-CAD:
03jordisayol * r46706 10/brlcad/trunk/sh/make_deb.sh: Correct some
minor erros. |
| 23:58.28 |
CIA-133 |
BRL-CAD:
03r_weiss * r46707
10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Updated
function nmg_isect_two_face2p_jra within file nmg_inter.c. Improved
the logic for determining where edges should be cut. |
| 00:02.17 |
*** join/#brlcad kunigami
(~kunigami@loco-gw.ic.unicamp.br) |
| 01:41.26 |
abhi2011 |
starseeker:
is the header simphysics.h not required to be mentioned in the
CMakeLists.txt file for libged ? |
| 01:42.18 |
abhi2011 |
I am trying
to add a new source and header in the simulate command, and I think
only the cpp file needs to be included in the libged/CMakeLists.txt
file |
| 01:42.23 |
abhi2011 |
at
SET(ged_ignore_files simulate/simphysics.cpp
simulate/simulate.c) |
| 01:43.50 |
abhi2011 |
so I ll
change it to SET(ged_ignore_files simulate/simphysics.cpp
simulate/simulate.c simulate/simcollisionalgo.cpp
simulate/simcollisionalgo.h) |
| 03:14.02 |
brlcad |
abhi2011:
how'd that new render animation turn out? |
| 03:14.26 |
brlcad |
was showing a
bunch of folks your previous animation earlier this week, they love
it! :) |
| 03:14.39 |
abhi2011 |
yes it turned
out fine |
| 03:14.49 |
abhi2011 |
I ll make a
movie over the night today :) |
| 03:15.42 |
abhi2011 |
pentium dual
core :P |
| 03:25.14 |
``Erik |
abhi: if you
have something scriptable you can give us, we can throw a LOT of
cpu into making you up a movie |
| 03:26.23 |
``Erik |
like a stack
of 16 core xeons :) |
| 03:54.14 |
abhi2011 |
oh
wow! |
| 03:54.25 |
abhi2011 |
umm but u wud
need bullet installed and working too |
| 03:54.50 |
abhi2011 |
which reminds
me, does the simulate command work on any other system
correctly |
| 03:55.21 |
abhi2011 |
also I have
got a database and 2 tcl scripts |
| 03:55.45 |
abhi2011 |
so I ll put
these in the samples and tclscripts folders if i want to share it
? |
| 03:59.43 |
abhi2011 |
well database
not needed actually, since the script can be run from a new
database and creates everything |
| 04:00.23 |
abhi2011 |
right, so i
ll give clean up the script and pastebin it for now |
| 05:02.56 |
CIA-133 |
BRL-CAD:
03abhi2011 * r46728 10/brlcad/trunk/src/libged/simulate/
(simcollisionalgo.cpp simcollisionalgo.h): Added 2 files for
containing a RT based contact manifold generator |
| 05:26.35 |
abhi2011 |
ok here is
the tcl script for generating the scene : http://bin.cakephp.org/view/350938158 |
| 05:35.14 |
abhi2011 |
:= |
| 05:36.08 |
abhi2011 |
and here is
the shell script |
| 05:40.17 |
abhi2011 |
http://bin.cakephp.org/view/572543350 |
| 06:07.42 |
CIA-133 |
BRL-CAD:
03abhi2011 * r46729 10/brlcad/trunk/src/libged/ (CMakeLists.txt
simulate/simphysics.cpp simulate/simulate.c): Began rt integration
into the bullet collision pipeline, added callback to show aabb
overlaps and contact points |
| 06:27.02 |
CIA-133 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3164 10/wiki/User:Abhijit: /* Log */ |
| 06:28.47 |
CIA-133 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3165 10/wiki/User:Abhijit: /* Log */ |
| 06:38.56 |
abhi2011 |
the minute i
submit the shell script the laptop fan ramps up a few
notches |
| 06:38.58 |
abhi2011 |
:P |
| 12:47.28 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 13:04.43 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 13:23.00 |
brlcad |
senses a big remrt session in his near
future |
| 13:45.43 |
``Erik |
abhi: is it
possible to run a bullet simulation and export a series of
'geometry at time X' definitions? so a single machine can generate
the 2000 or so 'states' to be farmed out for
raytracing? |
| 13:48.23 |
brlcad |
pretty
impressive scripting |
| 13:49.16 |
brlcad |
``Erik: he's
not here right now, but it is possible -- his script could just
call clone before running simulate |
| 13:50.35 |
brlcad |
then his rt
script could be issued for all 2000 frames at once for remrt
instead of one at a time (which will kick rt into multi-frame
render mode to make sure there isn't temporal tearing across
frames) |
| 13:57.41 |
``Erik |
cool (didn't
think he was here, but y'know, post and wait) |
| 14:21.00 |
CIA-133 |
BRL-CAD:
03d_rossberg * r46730 10/brlcad/trunk/CMakeLists.txt: |
| 14:21.00 |
CIA-133 |
BRL-CAD: a
non visible function prototype yields a warning "warning C4013:
'hypot' undefined; assuming extern returning int" => turned the
warnings into errors |
| 14:21.00 |
CIA-133 |
BRL-CAD: a
possible consequence of missing prototypes is a floating point
stack overflow (as it happened in this case) |
| 14:54.59 |
brlcad |
ouch |
| 15:17.24 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46731
10/brlcad/trunk/doc/docbook/presentations/en/intro-to-tcltk.xml:
corrected image file references for cuurent file
structure |
| 15:27.44 |
*** join/#brlcad b0ef
(~b0ef@166.195.251.212.customer.cdi.no) |
| 15:29.20 |
CIA-133 |
BRL-CAD:
03Sean 07http://brlcad.org * r3166
10/wiki/ESA_Summer_of_Code_in_Space: update with post-selection
details -- link to abhijit's log |
| 15:45.24 |
brlcad |
where's the
b0ef! |
| 15:59.05 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46732 10/brlcad/trunk/doc/docbook/fop.xconf.in: get
the base URL for fop back to its rightful place |
| 16:23.48 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 17:04.37 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46733 10/brlcad/trunk/README.cmake: some more
details for newbies |
| 17:32.28 |
brlcad |
hm, not so
fond of so much irrelevant info before getting to the heart of the
readme .. |
| 17:35.19 |
brlcad |
jordisayol:
thx for being patient :) |
| 17:35.25 |
brlcad |
he's
learning |
| 17:35.40 |
jordisayol |
brlcad: I
see |
| 17:35.44 |
jordisayol |
:-) |
| 18:22.22 |
abhi2011 |
any luck
running those scripts on the server |
| 18:25.43 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46734
10/brlcad/trunk/doc/docbook/articles/en/pipes.xml: adding unicode
point for two symbols |
| 18:26.46 |
brlcad |
abhi2011: was
looking them over earlier today while you were out |
| 18:27.19 |
*** join/#brlcad yukonbob
(~bch@S0106002191d1591c.ok.shawcable.net) |
| 18:27.24 |
yukonbob |
hello,
#brlcad |
| 18:27.29 |
brlcad |
abhi2011:
nice work, btw .. impressive scripting pulling things together
exactly the way they're supposed to be |
| 18:27.34 |
brlcad |
howdy
yukonbob |
| 18:27.58 |
yukonbob |
hey brlcad --
how're things? |
| 18:28.34 |
brlcad |
abhi2011:
with only a few modifications, those two scripts will work pretty
well for setting up a completely distributed rendering |
| 18:29.29 |
brlcad |
yukonbob:
good as ever, lots of skewers in the fire |
| 18:29.40 |
brlcad |
what are you
working on these days? |
| 18:30.13 |
abhi2011 |
brlcad: yep
learning :) |
| 18:30.43 |
yukonbob |
head-down in
Tcl/C whenever I can, and started w/ Apache working on Tcl bindings
for search-engine-in-development |
| 18:30.55 |
yukonbob |
<-- bch@apache.org :) |
| 18:30.57 |
abhi2011 |
so what
modifications would u do for distributed rendering ? |
| 18:31.03 |
brlcad |
abhi2011: for
the distributed render, you'd want to clone each object before
running simulate so that you keep all timestep revisions, then make
the rt script one *mega* script that renders all frames in sequence
with only one call to rt |
| 18:31.30 |
yukonbob |
poking at my
local brlcad/tcl/nbsd integration when I get chances... |
| 18:31.56 |
brlcad |
that will
kick rt into a video-rendering mode where it becomes frame-aware
and can apply tricks to make the frame-by-frame output
better |
| 18:32.23 |
yukonbob |
and actually
stumbled on an omission on my part that should help push that ahead
-- took a while to get a version a few months old up/running, and
now need to do a smaller leap fwd and getting running w/ latest
brlcad code again... |
| 18:32.52 |
brlcad |
then it's as
simple as copying the db to your render clients, replacing 'rt'
with 'rtsrv' and running remrt some place to collect all of the
results |
| 18:33.00 |
abhi2011 |
oh ok, so as
I understand you generate all the different position the objects
are in by running simulate for 1 step, 2 steps , 3steps.....300
steps and record them in different dbs |
| 18:33.12 |
abhi2011 |
so 300
dbs |
| 18:33.14 |
brlcad |
they can be
in the same db |
| 18:33.21 |
abhi2011 |
ah yes
right |
| 18:33.25 |
abhi2011 |
but with
different names |
| 18:33.26 |
brlcad |
scene.001
scene.002 .. whatever |
| 18:33.41 |
abhi2011 |
oh the db
supports scenes too |
| 18:33.45 |
abhi2011 |
didnt know
that |
| 18:33.56 |
yukonbob |
<PROTECTED> |
| 18:34.37 |
brlcad |
abhi2011:
you'll notice in rt script that it has a bunch of lines starting
with viewsize, then start 0; clean; |
| 18:34.51 |
abhi2011 |
yes
right |
| 18:34.58 |
brlcad |
that actually
is a command to start frame 0 .. |
| 18:35.15 |
abhi2011 |
ok |
| 18:35.17 |
brlcad |
so after
clean, you can load the next object, start 1, etc |
| 18:35.27 |
abhi2011 |
ok |
| 18:35.55 |
brlcad |
pretty much
exactly what you have, just pulling the rt command outside that for
loop |
| 18:35.56 |
abhi2011 |
and by
default..the way I have been working with mged so far, that just
creates 1 scene : scene 0 and puts everyting there |
| 18:36.02 |
brlcad |
and building
up the command inside the for loop |
| 18:36.38 |
abhi2011 |
ok |
| 18:37.05 |
brlcad |
abhi2011:
another thing I noticed is the hard-coded hack you have in there
for knowing what is what in the db :) |
| 18:37.25 |
abhi2011 |
in the c code
? |
| 18:37.33 |
brlcad |
for starters,
you should pass the list of objects to be simulated as a parameter
to the simulate command :) |
| 18:37.37 |
brlcad |
yeah |
| 18:37.41 |
abhi2011 |
ok |
| 18:37.52 |
abhi2011 |
ah yes
right |
| 18:38.01 |
brlcad |
sim_gp.r
:) |
| 18:38.19 |
abhi2011 |
yeah that
needs more flexibility :P |
| 18:38.21 |
brlcad |
that way you
know which object(s) to work on |
| 18:38.42 |
abhi2011 |
so all the
objects to be simulated get passed as paramters |
| 18:39.03 |
abhi2011 |
but then i
would need to know which one of the passed objects is the ground
plane |
| 18:39.21 |
brlcad |
maybe Usage:
simulate timestep(s) object0 [object1 ...] |
| 18:39.31 |
brlcad |
right |
| 18:39.37 |
abhi2011 |
ok |
| 18:39.39 |
brlcad |
that brings
me to my next suggestion :) |
| 18:40.09 |
brlcad |
so there's
two concepts that I think bullet represents, correct me if I'm
wrong |
| 18:40.18 |
brlcad |
one is this
concept of a ground plane |
| 18:40.29 |
brlcad |
which is
defined by a plane equation vector |
| 18:40.47 |
brlcad |
then it's
marked immutable (i.e., with 0 volume) |
| 18:41.39 |
brlcad |
that being
the second concept |
| 18:41.43 |
brlcad |
yes? |
| 18:41.55 |
abhi2011 |
welll almost
, actually its more general, there can be 2 types of objects in
bullet : static objects (with mass 0) and dynamic objects (with non
zero mass) |
| 18:41.58 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46735 10/brlcad/trunk/TODO: add tasks to be done to
clean up DocBook source |
| 18:42.08 |
brlcad |
s/volume/mass/ .. that's what I meant
;) |
| 18:42.24 |
abhi2011 |
yes
right |
| 18:42.31 |
abhi2011 |
so I can
actually mark any object as static |
| 18:42.33 |
brlcad |
but a ground
plane isn't just a mass 0 entity iirc, no? |
| 18:42.41 |
abhi2011 |
true |
| 18:42.41 |
brlcad |
you have to
say "this is ground" too, no? |
| 18:42.51 |
abhi2011 |
no there is
no need to say so |
| 18:42.55 |
abhi2011 |
i just have
to make it static |
| 18:43.00 |
abhi2011 |
that is fixed
in space |
| 18:43.07 |
brlcad |
otherwise if
I put an immutable box above your boxes, they'd have gravity
pulling them in two directions |
| 18:43.08 |
abhi2011 |
there is no
separate concept of ground |
| 18:43.40 |
abhi2011 |
no becuase
the gravity is specified independently for the entire
world |
| 18:43.45 |
abhi2011 |
there is no
concept of ground |
| 18:43.54 |
abhi2011 |
if i have a
plane that is rigid |
| 18:43.55 |
brlcad |
so gravity is
global |
| 18:44.00 |
abhi2011 |
then it
appears as the ground |
| 18:44.11 |
abhi2011 |
but its not
specfied as such |
| 18:44.21 |
brlcad |
mm,
okay |
| 18:44.39 |
brlcad |
so then all
you need is some means to designate or calculate an object's
mass |
| 18:44.57 |
abhi2011 |
yes, right
now i use the volume of the objects bb and density of 0 |
| 18:44.58 |
brlcad |
we have a
tool that does that (gqa) calculating mass, but it's not yet an API
function |
| 18:45.00 |
abhi2011 |
sorry
1 |
| 18:45.05 |
brlcad |
nods |
| 18:45.05 |
abhi2011 |
oh
ok |
| 18:45.07 |
abhi2011 |
cool |
| 18:45.21 |
brlcad |
so how about
this |
| 18:46.00 |
brlcad |
you assume
all regions specified for simulation (via specifying a given
scene/combination/group) have a mass of 1 |
| 18:46.10 |
brlcad |
unless a
mass-value is set |
| 18:46.22 |
abhi2011 |
ok |
| 18:46.26 |
abhi2011 |
yes |
| 18:46.35 |
brlcad |
that way all
you need is some means to set an object's mass |
| 18:46.46 |
abhi2011 |
however a
larger object may appear to have the same mass as a smaller
object |
| 18:46.54 |
abhi2011 |
yes , the
mass can be set |
| 18:46.56 |
abhi2011 |
true |
| 18:47.04 |
brlcad |
which
fortunately there is a system already in place for :D |
| 18:47.06 |
abhi2011 |
if the user
want more realistic simulation |
| 18:47.12 |
abhi2011 |
yes
:) |
| 18:47.46 |
abhi2011 |
so i guess i
can call upon the code in the gqa thingie to get me the
mass |
| 18:48.00 |
brlcad |
nah, that'd
be hell |
| 18:48.12 |
abhi2011 |
ok
:P |
| 18:48.27 |
brlcad |
it's not API
yet and it'd take a week or more to make it proper API |
| 18:48.47 |
brlcad |
your time is
better spent getting collisions working ;) |
| 18:48.51 |
abhi2011 |
right ok, so
i ll make it trhe way we dicusssed then |
| 18:48.57 |
abhi2011 |
assume mass
of 1 |
| 18:49.03 |
abhi2011 |
unoless
specified |
| 18:49.12 |
brlcad |
right, but
then you need a way to specify mass :) |
| 18:49.18 |
abhi2011 |
yes |
| 18:49.23 |
abhi2011 |
so a -m
flag |
| 18:49.24 |
brlcad |
do you know
how already? :) |
| 18:49.30 |
brlcad |
no
no |
| 18:49.31 |
abhi2011 |
with the
masses in order |
| 18:49.45 |
brlcad |
object-oriented, you want objects to
specify themselves |
| 18:50.06 |
abhi2011 |
ok but the
user is going to pass the mass right |
| 18:50.29 |
brlcad |
pass the mass
.. hehe |
| 18:50.29 |
brlcad |
yes
:) |
| 18:50.45 |
abhi2011 |
ok |
| 18:50.51 |
brlcad |
so the
missing piece of this puzzle... |
| 18:50.55 |
brlcad |
perhaps a new
brl-cad concept, we have an attribute system where you can store
key=value on arbitrary db objects |
| 18:51.10 |
abhi2011 |
ok |
| 18:51.17 |
brlcad |
that will
probably work perfect for this |
| 18:51.22 |
abhi2011 |
right |
| 18:51.26 |
abhi2011 |
like the avs
thing |
| 18:51.35 |
abhi2011 |
for the
attributes of an object |
| 18:51.38 |
brlcad |
what avs
thing? |
| 18:51.47 |
abhi2011 |
there is this
avs variable all over the c code |
| 18:51.52 |
brlcad |
ah,
yes |
| 18:51.53 |
brlcad |
that's
this |
| 18:51.59 |
abhi2011 |
its used to
access the attributes |
| 18:52.00 |
brlcad |
avs ==
attribute value system |
| 18:52.04 |
abhi2011 |
yes |
| 18:52.06 |
abhi2011 |
:) |
| 18:52.10 |
abhi2011 |
so not so new
after all |
| 18:52.12 |
abhi2011 |
:P |
| 18:52.26 |
abhi2011 |
well yeah but
i understand what you are saying |
| 18:52.28 |
brlcad |
yeah, so just
need to use it for your own settings :) |
| 18:52.28 |
abhi2011 |
:) |
| 18:52.57 |
abhi2011 |
ok |
| 18:53.06 |
abhi2011 |
now about
passing the mass while invoking the command |
| 18:53.06 |
brlcad |
attr set
ground.r simulate:mass=0 |
| 18:53.17 |
abhi2011 |
oh
ok |
| 18:53.19 |
abhi2011 |
ah now i get
it |
| 18:53.19 |
brlcad |
then in the
code, just look up the "simulate:mass" attribute and use the
value |
| 18:53.26 |
abhi2011 |
right |
| 18:53.28 |
abhi2011 |
cool |
| 18:53.40 |
brlcad |
can use that
for a whole slew of things then :) |
| 18:53.45 |
abhi2011 |
so its like
any other attribute of the object, like radius etc |
| 18:53.47 |
abhi2011 |
yes |
| 18:53.51 |
abhi2011 |
we can
specfiy friction |
| 18:53.54 |
abhi2011 |
for custom
materials |
| 18:53.58 |
abhi2011 |
or
density |
| 18:54.13 |
brlcad |
just prefix
your variables so they can be conceptually grouped
together |
| 18:54.19 |
abhi2011 |
ok |
| 18:54.40 |
brlcad |
but you
should always have a "default" too .. so if nothing is set, it'll
do something sane |
| 18:54.49 |
abhi2011 |
ok |
| 18:54.55 |
abhi2011 |
now about the
ground plane thing |
| 18:55.19 |
abhi2011 |
see the user
will invoke the command like : simulate a.r b.r |
| 18:55.22 |
brlcad |
like maybe if
there is no immutable mass=0 objects being simulated, it defaults
to making the biggest one be mass=0 |
| 18:55.33 |
abhi2011 |
ok |
| 18:55.42 |
brlcad |
simulate 10
scene |
| 18:55.54 |
brlcad |
or simulate
10 grp1 grp2 grp3 ... |
| 18:56.10 |
brlcad |
not
necessarily just the region objects |
| 18:56.13 |
abhi2011 |
ok |
| 18:56.19 |
abhi2011 |
1 more
question |
| 18:56.21 |
brlcad |
trivial to
walk the object(s) specified, get a list of all regions |
| 18:56.30 |
abhi2011 |
right |
| 18:56.37 |
abhi2011 |
i guess a
scene's objects can be accessed |
| 18:56.44 |
abhi2011 |
not yet
worked with scenes |
| 18:56.45 |
brlcad |
if there are
no regions, maybe treat the object specified as a region or error
out if you have to have a region |
| 18:56.59 |
brlcad |
db_walk_tree() is your friend |
| 18:57.02 |
abhi2011 |
cool |
| 18:57.52 |
abhi2011 |
umm so about
scenes, if i want to create a new scene |
| 18:57.58 |
abhi2011 |
there is an
mged comand for it ? |
| 18:58.01 |
brlcad |
that way your
code doesn't even need to know the name(s) of anything |
| 18:58.14 |
brlcad |
'g'
? |
| 18:58.25 |
brlcad |
scenes are
just logical groupings of objects |
| 18:58.41 |
abhi2011 |
oh
ok |
| 18:58.46 |
brlcad |
you can group
a bunch of regions and groups together with the 'g'
command |
| 18:59.00 |
abhi2011 |
yes of course
:) |
| 18:59.08 |
abhi2011 |
thought they
were a new kinda thing |
| 18:59.16 |
abhi2011 |
:P |
| 18:59.17 |
brlcad |
they're
implicit |
| 18:59.20 |
abhi2011 |
ok |
| 18:59.44 |
abhi2011 |
ok there is 1
other thing |
| 18:59.53 |
abhi2011 |
about custom
forces |
| 19:00.07 |
abhi2011 |
so suppose i
want some impulse applied on a specfic object |
| 19:00.08 |
brlcad |
objects above
the region level are groups, groups are "assemblies" in CAD
terminology -- a scene is just another assembly |
| 19:00.16 |
abhi2011 |
can be used
to shoot a sphere at a cube stack for example |
| 19:01.52 |
abhi2011 |
ok about the
assemblies, so about the custom forces should I consider at this
stage , something liek this : simulate 10 -f{obj, 10,0,0} grp1 grp2
.... |
| 19:02.33 |
abhi2011 |
so that would
apply a force of 10 newtons on the region/group named as 'obj'
only |
| 19:02.43 |
abhi2011 |
the remainign
objects stay the same |
| 19:02.52 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46736
10/brlcad/trunk/doc/docbook/articles/en/mgedrc.xml: adding unicode
point for two symbols; lifting XInclude namespace to root
element |
| 19:02.59 |
abhi2011 |
obj should
appear somewhere in grp1, grp2 etc |
| 19:03.03 |
brlcad |
abhi2011: I'd
probably still use the attributes for that |
| 19:03.11 |
abhi2011 |
ah yes of
course |
| 19:03.13 |
brlcad |
because you
need to persist the force across frames |
| 19:03.31 |
abhi2011 |
yes true,
that would be much easier then parsing comples flags |
| 19:03.43 |
abhi2011 |
yes |
| 19:04.06 |
abhi2011 |
interesting
and very useful this attributes thing :) |
| 19:04.13 |
brlcad |
granted, that
means you'll have to read all objects to see if any have forces
applied, run the simulation step, then write out any
remaining/residual forces (for the next timestep) |
| 19:04.29 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46737 10/brlcad/trunk/TODO: add another task to be
done to clean up DocBook source |
| 19:04.43 |
brlcad |
becomes a
persistent database for any values you need during the
sim |
| 19:04.52 |
abhi2011 |
yes |
| 19:04.53 |
CIA-133 |
BRL-CAD:
03starseeker * r46738 10/brlcad/trunk/README.cmake: Toplevel readme
probably isn't the place for these details. Also, if the
environment variables may cause a problem, the thing to do is to
have CMake check them as part of the configure process and warn
about them. |
| 19:06.15 |
abhi2011 |
yes, that is
another thing which was bothering me actually, see there are 2
options, to run all the simulation timesteps without any thing
else happening. or run 1 timestep, do overlp checks then run the
next steps |
| 19:06.26 |
brlcad |
starseeker:
if CMake is a faithful conversion of configure, there should
already be a big honking warning about BRLCAD_ROOT being set
;) |
| 19:06.44 |
abhi2011 |
but if there
is break between the steps and i have to recreate the entire scene
again , then all the dynamic foce and acceleration info would need
to be persisted |
| 19:06.53 |
abhi2011 |
can use the
attributes for that |
| 19:06.58 |
brlcad |
sure |
| 19:07.28 |
abhi2011 |
right so a
whole slew of new attributes to be added |
| 19:07.39 |
abhi2011 |
for all
objects in brl-cad |
| 19:07.54 |
abhi2011 |
force ,
mass, |
| 19:07.56 |
brlcad |
all regions
objects |
| 19:08.02 |
abhi2011 |
yes
ok |
| 19:08.15 |
abhi2011 |
yes
true |
| 19:08.17 |
abhi2011 |
only
regions |
| 19:08.40 |
brlcad |
pretty
limited subset, and only after simulate has run once (and there are
forces remaining) or as part of scene setup to override
defaults |
| 19:09.21 |
brlcad |
e.g., you
wouldn't want to write out simulate:force=0.0 .. you'd delete the
attribute |
| 19:09.31 |
abhi2011 |
yes |
| 19:09.41 |
brlcad |
(assumes
default force==0.0 of course) |
| 19:09.57 |
abhi2011 |
yes, so all
these attributes are listed in a header, and i just go add to
them |
| 19:10.29 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46739
10/brlcad/trunk/doc/docbook/articles/en/projection_shader.xml:
adding unicode point for two symbols; lifting XInclude namespace to
root element |
| 19:10.53 |
abhi2011 |
and maybe
increase a counter which currently tracks the number of attributes
that can exist for a region |
| 19:10.53 |
starseeker |
brlcad: yeah,
yeah... :-P |
| 19:11.08 |
starseeker |
is catching up on backlog... |
| 19:18.08 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46740
10/brlcad/trunk/doc/docbook/articles/en/build_region.xml: lifting
XInclude namespace to root element |
| 19:22.16 |
abhi2011 |
on thinking
more about it, the velocity of the objects, both rotational and
translational needs to be persisted for the next frame, and if any
custom force should still to be applied in the next frame(since
there is no concept of a residual force as such like 10 newtons
force is applied and 5 newtons is left for next frame, that would
result in wrong physics ) |
| 19:25.01 |
abhi2011 |
ok so I ll
proceed with adding the new attributes : translational velocities
in x y, z directions and rotational velocities for the 3 axes , and
see if I can store then after 1 frame and reload them at the
beginning of the next frame and see if physics continues
properly |
| 19:26.08 |
abhi2011 |
this can then
be extended to calling rt at the end of a frame to create the
contact manifolds , which can then be inserted into the collision
pipeline befpre starting the next frame, so collision proceeds
according to rt output |
| 19:26.41 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46741
10/brlcad/trunk/doc/docbook/articles/en/build_pattern.xml: adding
unicode point for one symbols; lifting XInclude namespace to root
element |
| 19:31.56 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46742
10/brlcad/trunk/doc/docbook/lessons/en/mged01_creating_primitive_shapes.xml:
lifting XInclude namespace to root element |
| 19:56.17 |
brlcad |
starseeker:
if you knew the support hell that was when BRLCAD_ROOT was the
norm, it probably would have been one of the first things you
added |
| 19:57.30 |
brlcad |
how many
times I'd spend half a day debugging some really bizzare bug or
crash only to discover they were running a 7.4 binary but using 7.0
libraries |
| 19:58.50 |
CIA-133 |
BRL-CAD:
03starseeker * r46743 10/brlcad/trunk/CMakeLists.txt: Get a version
of the warnings about BRLCAD_ROOT into CMake, as well as
(reluctantly) using the environment variable if it's
defined. |
| 20:00.56 |
brlcad |
abhi2011:
couldn't you have a situation like where you'd have an
electromagnetic field applying some force but then the force on the
next frame would be different because of the different position in
the field? |
| 20:01.23 |
brlcad |
the idea
being that you'd have some sort of force emitter objects, of
course, with some sort of parametric force being
applied |
| 20:01.30 |
brlcad |
not just
impulse or load |
| 20:02.27 |
brlcad |
abhi2011: I'd
suggest combining the xyz velocities into one attribute (one for
linear, one for rotational) |
| 20:02.49 |
brlcad |
should limit
the number of writes if values naturally group together |
| 20:04.17 |
CIA-133 |
BRL-CAD:
03starseeker * r46744 10/brlcad/trunk/CMakeLists.txt: /usr is bad
whether or not it came from BRLCAD_ROOT, adjust
warning. |
| 20:06.11 |
brlcad |
starseeker:
you missed the warning part |
| 20:06.46 |
brlcad |
"if test !
"x$BRLCAD_ROOT" = "x" ; then" ... |
| 20:07.11 |
brlcad |
that's the
important part |
| 20:07.15 |
starseeker |
that's
IF(BRLCAD_ROOT) |
| 20:07.47 |
starseeker |
SET(BRLCAD_ROOT "$ENV{BRLCAD_ROOT}") get's
it from the environment variable - if that variable is empty, the
if test fails. otherwise, the warning proceeds |
| 20:08.15 |
brlcad |
not
following |
| 20:08.33 |
starseeker |
we're warning
if BRLCAD_ROOT is set, correct? |
| 20:08.39 |
brlcad |
correct |
| 20:08.44 |
starseeker |
this will do
that |
| 20:09.03 |
abhi2011 |
brlcad :
about the electro magnetic fields, yes true |
| 20:09.41 |
brlcad |
ah, I see
it.. the logic is further down .. I was expecting statement parity,
or close to it |
| 20:10.00 |
brlcad |
a quiet
little "BRLCAD_ROOT is not necessary and may cause unexpected
behavior" is not parity at all... |
| 20:10.00 |
CIA-133 |
BRL-CAD:
03starseeker * r46745 10/brlcad/trunk/CMakeLists.txt: comment
first, then code |
| 20:10.37 |
starseeker |
has tested it - seems to do the trick |
| 20:11.20 |
brlcad |
that's
probably the distinction |
| 20:11.30 |
brlcad |
there's no
indication on the severity of the messages being
printed |
| 20:11.40 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46746 10/brlcad/trunk/HACKING: add reference to more
DocBook details |
| 20:12.31 |
brlcad |
configure had
something like four output levels, regular print message, warning,
severe warning, and error (halting) |
| 20:12.48 |
starseeker |
yeah, I don't
think cmake has warning vs. severe warning |
| 20:12.53 |
brlcad |
otherwise the
messages will just get lost in the noise |
| 20:13.31 |
brlcad |
the
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} markers screamed
out "this is really bad" .. and it worked |
| 20:13.33 |
starseeker |
heh - I'm
calling sleep on the first one, and flat out exiting with failure
on /usr (with a message that tells them how to get it to go forward
if they're really that stubborn) |
| 20:13.40 |
starseeker |
ah,
k |
| 20:13.51 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46747 10/brlcad/trunk/doc/docbook/README: add more
details on DB character code requirements |
| 20:15.15 |
brlcad |
the only
half-severe }}} message I think we ever reported was about the IEEE
encoding, which I'm just not sure what it means in terms of valid
calculations |
| 20:15.28 |
CIA-133 |
BRL-CAD:
03tbrowder2 * r46748 10/brlcad/trunk/doc/docbook/README: correct
typo |
| 20:22.40 |
CIA-133 |
BRL-CAD:
03starseeker * r46749 10/brlcad/trunk/CMakeLists.txt: Make warnings
noiser, also complain about BRLCAD_DATA |
| 20:23.45 |
brlcad |
starseeker:
er, BRLCAD_ROOT doesn't set prefix in configure ... |
| 20:24.35 |
starseeker |
ah, my
mistake |
| 20:24.39 |
starseeker |
wasn't
parsing the m4 logic right |
| 20:25.25 |
brlcad |
it pulls the
value from prefix (setting BRLCAD_ROOT) .. but that's os we set
BRLCAD_ROOT as a define in the config header (so things like
bu_brlcad_root() work correctly) |
| 20:25.33 |
brlcad |
s/os/so/ |
| 20:26.19 |
starseeker |
nods - I never use BRLCAD_ROOT as a variable at all in CMake
- it gets set to CMAKE_INSTALL_PREFIX in the config
header |
| 20:27.00 |
brlcad |
"it" being
BRLCAD_ROOT? |
| 20:27.06 |
starseeker |
yes |
| 20:27.40 |
brlcad |
yeah, I
wouldn't have expected you to use it as a var |
| 20:29.44 |
CIA-133 |
BRL-CAD:
03starseeker * r46750 10/brlcad/trunk/CMakeLists.txt: My mistake,
we're not setting CMAKE_INSTALL_PREFIX to BRLCAD_ROOT. Tweak the
logic and warnings accordingly |
| 20:31.19 |
brlcad |
it was needed
for the m4 logic because BRLCAD_ROOT exists as a shell variable, an
m4 variable, a make variable, and a #define -- cmake effectively
eliminates the m4+make cases (unless you allow the same make-time
override) |
| 20:31.21 |
CIA-133 |
BRL-CAD:
03starseeker * r46751 10/brlcad/trunk/CMakeLists.txt: match closing
tag |
| 20:31.29 |
brlcad |
does miss the various make-time overrides |
| 20:34.05 |
brlcad |
e.g., make
TCLDIR= TKDIR= (skip rebuilding tcl/tk even if dependency tracking
wants to rebuild them) |
| 20:34.34 |
starseeker |
winces - not sure how I'd make that work |
| 20:34.40 |
brlcad |
make
CPPFLAGS=-w (skip strict for this pass) |
| 20:34.56 |
brlcad |
no worries,
not a major feature |
| 20:35.08 |
brlcad |
just one of
those things :) |
| 20:35.53 |
brlcad |
overriding
the dependency tracking system wasn't something universal, there
had to be a make variable defined for the directory |
| 20:36.01 |
brlcad |
getting that
in cmake terms would probably suck |
| 20:36.39 |
brlcad |
because it'd
probably take some round-about checking mechanism instead of just
letting make do what it does |
| 20:37.02 |
CIA-133 |
BRL-CAD:
03starseeker * r46752
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: That's actually
CXXFLAGS, not CXX_FLAGS... |
| 20:37.18 |
brlcad |
one of the
merits of automake+make .. but not one that trumps the windows
portability aspect of cmake |
| 20:37.22 |
starseeker |
probably
mattered more when build times were slower |
| 20:37.41 |
brlcad |
nah, still
matters .. I used it just last week :) |
| 20:38.13 |
starseeker |
shakes his head - I think my developer skills are going to
forever remain at the "midrange" level |
| 20:38.40 |
starseeker |
can get there eventually, usually... |
| 20:39.00 |
brlcad |
think if
you're working on building a proc-db or something simple, find out
you need to add a libbu function that begs for a new
configure/cmake header test, .. it's going to rightly want to
rebuild everything |
| 20:39.47 |
starseeker |
make -j9
procdb_target would build only what that proc-db needs, I'd
probably call that close enough... |
| 20:40.07 |
brlcad |
you don't
care about rebuilding everything in that moment, whether it's 2min
or 10min .. your procdb builds and links in 2 milliseconds and
that's what you're focusing on :) |
| 20:40.31 |
starseeker |
make
procdb_target/FAST I think might do what you want there |
| 20:40.43 |
brlcad |
maybe |
| 20:40.51 |
brlcad |
but I *did*
need libbu rebuilt :) |
| 20:41.12 |
brlcad |
just not
every f'n thing that uses libbu, and certainly not all of src/other
:) |
| 20:41.40 |
starseeker |
nods |
| 20:41.51 |
brlcad |
like I said,
not a huge deal .. just something different |
| 20:41.57 |
starseeker |
maybe if you
describe the scenario to the CMake devs they could come up with
something... |
| 20:42.10 |
brlcad |
not even that
important |
| 20:42.49 |
brlcad |
might even be
something similar in cmake terms that will work "good enough", like
make libbu/FAST && make my_proc/FAST |
| 20:43.20 |
starseeker |
thought about suggesting that, but assumed it would be
rejected for "too much typing" reasons :-P |
| 20:44.17 |
brlcad |
it's better
than waiting 2-10min :) |
| 21:30.59 |
starseeker |
tcl/tk 2011
schedule is up: http://www.tcl.tk/community/tcl2011/schedule.html |
| 22:02.19 |
brlcad |
looks like
Cliff F. is all over the place in the schedule this
year |
| 22:02.32 |
brlcad |
quirky funny
guy :) |
| 22:03.33 |
brlcad |
at least in a
geek humor kind of way :) |
| 22:03.38 |
brlcad |
bets $20 that he says "Any questions? Any answers?" at least
a few times during the week |
| 22:57.25 |
brlcad |
oh
snap! |
| 22:57.33 |
brlcad |
thank you tom
browder! |
| 22:58.01 |
brlcad |
looks like
sourceforge folks made ideatorret an option, that's
outstanding! |
| 00:35.41 |
louipc |
whoa |
| 02:27.00 |
brlcad |
102480
surface edges, 27195 edge loops, 51393 edge curves, 18359 advanced
faces, 10015 cylindrical surfaces, 2691 bspline surfaces,
... |
| 02:56.31 |
CIA-63 |
BRL-CAD:
03brlcad * r46858 10/brlcad/trunk/src/librt/db_match.c: get rid of
the stupid BU_ASSERTING, they're really just UNUSED. |
| 02:56.50 |
CIA-63 |
BRL-CAD:
03brlcad * r46859 10/brlcad/trunk/src/librt/prep.c: client_data
isn't actually UNUSED.. |
| 02:58.15 |
CIA-63 |
BRL-CAD:
03brlcad * r46860 10/brlcad/trunk/src/librt/ (db_match.c prep.c):
ws consistency cleanup |
| 03:11.28 |
CIA-63 |
BRL-CAD:
03brlcad * r46861
10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: hit_count is
potentially used prior to initialization, account for it and all of
his friends by initializing to zero/null. |
| 03:15.19 |
CIA-63 |
BRL-CAD:
03brlcad * r46862 10/brlcad/trunk/src/librt/primitives/ (ehy/ehy.c
epa/epa.c hyp/hyp.c rpc/rpc.c submodel/submodel.c): remove a slew
of BU_ASSERT hacks that were only added to quell use warnings. use
the UNUSED() macro for betterness. |
| 03:15.57 |
CIA-63 |
BRL-CAD:
03brlcad * r46863 10/brlcad/trunk/src/libgcv/bottess.c: someone was
just kidding, tol isn't really unused |
| 03:44.09 |
CIA-63 |
BRL-CAD:
03brlcad * r46864 10/brlcad/trunk/src/libged/push.c: curtree is
actually used. hard to miss it. |
| 04:11.21 |
CIA-63 |
BRL-CAD:
03brlcad * r46865 10/brlcad/trunk/include/nmg.h: not your
responsibility to define NULL and it's a crappy definition
anyways. |
| 05:12.06 |
CIA-63 |
BRL-CAD:
03brlcad * r46866 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: more
unused LIARS |
| 05:14.57 |
CIA-63 |
BRL-CAD:
03brlcad * r46867 10/brlcad/trunk/src/liboptical/ (sh_air.c
sh_light.c): and a few more checks added for quellage, but they're
really UNUSED |
| 05:28.59 |
CIA-63 |
BRL-CAD:
03brlcad * r46868 10/brlcad/trunk/src/ (mged/dodraw.c
remrt/remrt.c): couple more UNUSED tricksters |
| 05:32.28 |
CIA-63 |
BRL-CAD:
03brlcad * r46869 10/brlcad/trunk/include/common.h: |
| 05:32.28 |
CIA-63 |
BRL-CAD: add
a new IGNORE() macro for use by all of the various macros that turn
into |
| 05:32.28 |
CIA-63 |
BRL-CAD:
'nothing' if the right compilation flags are set. for now, go with
a simple |
| 05:32.28 |
CIA-63 |
BRL-CAD:
'(void)param' to quell unused usage warnings but begs testing on
msvc2010. |
| 05:32.28 |
CIA-63 |
BRL-CAD:
while we're at it, mangle parameters marked as UNUSED() with a
prefix so we can |
| 05:32.28 |
CIA-63 |
BRL-CAD:
catch failings in both directions, catching instances where
UNUSED() was |
| 05:32.29 |
CIA-63 |
BRL-CAD:
erroneously set yet the parameter is actually used. |
| 05:34.39 |
CIA-63 |
BRL-CAD:
03brlcad * r46870 10/brlcad/trunk/include/ (bu.h magic.h
raytrace.h): |
| 05:34.39 |
CIA-63 |
BRL-CAD: put
the new IGNORE() macro to use in place of (void)0 since we were
still |
| 05:34.39 |
CIA-63 |
BRL-CAD:
getting strict warnings about parameters not being used because
they were only |
| 05:34.39 |
CIA-63 |
BRL-CAD:
being used in ifdef sections or CK macros. IGNORE() shouldn't be
used in |
| 05:34.39 |
CIA-63 |
BRL-CAD:
application code, but these bombing/checking macros are perfect use
cases. |
| 05:37.06 |
brlcad |
whew, finally
got all of them |
| 05:43.38 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 07:13.28 |
brlcad |
boo, hiss ..
step import churned and churned but only a few things came
in |
| 07:13.42 |
brlcad |
and the few
that did come in aren't looking so hot |
| 07:13.56 |
brlcad |
wanders |
| 08:24.42 |
*** join/#brlcad dli_
(~dli@dsl-173-248-196-72.acanac.net) |
| 09:43.08 |
*** join/#brlcad dli_
(~dli@dsl-173-248-235-17.acanac.net) |
| 12:54.32 |
abhi2011 |
i have been
getting this stranger error whenever I try to include raytrace.h in
simphysics.cpp |
| 12:55.30 |
abhi2011 |
the error is
: /home/abhi/socis/brlcad/include/brep.h:36:23: fatal error:
opennurbs.h: No such file or directory |
| 12:56.21 |
abhi2011 |
raytrace.h:47
> rtgeom.h:42:0, > brep.h |
| 12:56.53 |
abhi2011 |
this is
because now I am trying to do librt stuff inside the cpp
file |
| 12:57.33 |
abhi2011 |
I need to use
rt for detecting overlaps and generate contact points, but I do
not want to that in the simulate.c file |
| 12:58.08 |
abhi2011 |
so I am going
to transforms the objects into their new position in the db and
then shoot rays within functions defined in the cpp
file |
| 12:58.46 |
abhi2011 |
but it seems
that the minute i try to include raytrace.h in the cpp file the
build breaks :( |
| 13:00.39 |
abhi2011 |
i of course
need raytrace.h included to have access to rt_matrix_transform() to
position the simulated objects, after each physics step |
| 13:40.39 |
``Erik |
probably
means an omission from the cmake/automake file about legitimage
paths... though this does expose something; rt_matrix_transform
might be better placed as bn_matrix_transform O.o |
| 14:12.10 |
brlcad |
rt_matrix_transform isn't just a general
matrix function |
| 14:12.23 |
brlcad |
it applies
that matrix and writes it out on specified geometry |
| 14:13.10 |
brlcad |
the db
internal geometry is transformed, not the matrix |
| 14:19.12 |
brlcad |
abhi2011: so
you're somehow missing a common include directory
(src/other/opennurbs) |
| 14:19.42 |
brlcad |
what does
"make VERBOSE=1" output (pastebin)? |
| 14:27.30 |
``Erik |
rt_write_matrix(bn_matrix_transform(m));
? |
| 14:29.47 |
``Erik |
(symbol
documentation, I spew what I assume as a reasonably knowledgeable
codemonkey) |
| 14:31.32 |
brlcad |
that's my
point, there is no transform being done on a matrix |
| 14:31.46 |
brlcad |
so it's just
be a rename to rt_write_matrix perhaps |
| 14:32.05 |
brlcad |
rt_apply_matrix() is probably more
apt |
| 14:32.17 |
brlcad |
since it
won't necessarily "write" anything |
| 14:33.38 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
| 14:35.30 |
``Erik |
I'm in favor
of renaming that function, fwiw |
| 14:39.07 |
CIA-63 |
BRL-CAD:
03starseeker * r46871 10/brlcad/trunk/src/libged/CMakeLists.txt:
Add the opennurbs include dir to libged's include list |
| 14:40.32 |
starseeker |
abhi2011:
give that a shot |
| 14:42.05 |
brlcad |
starseeker:
it seems backwards (and it's not your fault, autotools is also to
blame) to have to list include dirs like that |
| 14:44.20 |
brlcad |
think there
should be top-level BU_CPPFLAGS, RT_CPPFLAGS, etc or
BU_INCLUDE_DIRS, RT_INCLUDE_DIRS, etc that have those interface
paths defined, then lower-level CMakeLists.txt files would just use
them if they use the library |
| 14:44.50 |
brlcad |
otherwise
we're just going to end up with "include everything all the time"
and that's not very useful or safe |
| 14:45.38 |
starseeker |
disagrees - i never liked those vars in autotools, it made it
difficult to see where a particular directory was coming from in
the logic |
| 14:45.50 |
starseeker |
too much
obfuscation |
| 14:46.13 |
brlcad |
the
alternative is excessive replication |
| 14:46.41 |
starseeker |
how bad is
that, really though? |
| 14:46.51 |
starseeker |
once set up,
the changes aren't too bad |
| 14:47.00 |
starseeker |
(this one was
a straightforward one-liner) |
| 14:47.24 |
brlcad |
short term
gain, long term cost (like any code duplication) |
| 14:47.30 |
brlcad |
change one of
them |
| 14:47.35 |
starseeker |
if this had
happened with toplevel vars, I would have had to track back through
to see what the toplevel vars contained and which one might be a
logica candidate for this dir... |
| 14:47.49 |
brlcad |
you have to
find the 400+ instances it's used (or dozens if it's per
dir) |
| 14:48.04 |
brlcad |
doesn't have
to be top-level vars |
| 14:48.24 |
brlcad |
in terms of
encapsulation, it's make more sense for the libs to define their
needs |
| 14:49.21 |
brlcad |
think of
libbu as its own product, it'd declare cppflags that included tcl,
for example .. but users of libbu just use libbu's declared
interface |
| 14:50.10 |
brlcad |
that wasn't
done for autotools because it wasn't easily doable with our
recursive automake setup, so the variables propagated up to the
top |
| 14:50.17 |
brlcad |
for cmake,
that's not the case |
| 14:50.58 |
starseeker |
concedes the point, but still doesn't like the idea of "what
gets included" being buried so deep - it feels like C++, digging
through layers to find an int at the bottom of the type
pile... |
| 14:54.16 |
starseeker |
but I always
lose these arguments ;-), so let's see... how to do it... probably
the BU_INCLUDE_DIRS approach would be best... |
| 14:54.24 |
brlcad |
another way
to look at it -- just about every app (400+) uses librt which uses
libbu which results in *always* needing paths for zlib, regex, tcl,
opennurbs, .. always needing to include ${ZLIB_INCLUDE_DIR},
${REGEX_INCLUDE_DIR}, ${TCL_INCLUDE_DIRS},
${OPENNURBS_INCLUDE_DIR} |
| 14:54.58 |
starseeker |
nods - yeah, it would be a LoC reduction, no
question |
| 14:55.08 |
brlcad |
there are
minimally about 50 source dirs where those have to be
specified |
| 14:55.36 |
brlcad |
add one more,
rename one, remove one ... that's 50+ edits |
| 14:55.47 |
brlcad |
massive DRY
fail :) |
| 14:58.18 |
starseeker |
I'm going to
do one additional thing though, if I introduce the BU_INCLUDE_DIRS
style mechanisms - I'm going to build a list of dirs and then
remove duplicates before the actual include command, to try and
keep the command line verbosity down... |
| 15:08.24 |
brlcad |
yeah, that'd
be awesome |
| 15:08.35 |
starseeker |
blinks in surprise - apparently libbu doesn't use
regex |
| 15:09.25 |
brlcad |
librt |
| 15:09.35 |
starseeker |
nods |
| 15:10.01 |
starseeker |
I knew it was
in there, just a little startled it hasn't crept down to the libbu
level yet |
| 15:10.23 |
starseeker |
would have thought some sort of regex something or other
would have been packaged up for general consumption by now
;-) |
| 15:10.31 |
brlcad |
another
benefit of the encapsulation, catch issues like that more obviously
so you don't include regex by default everywhere bu is
used |
| 15:11.06 |
brlcad |
regex it is
needed, but indirect |
| 15:11.09 |
brlcad |
bu -> tcl
-> regex |
| 15:11.28 |
brlcad |
so tcl should
have it specified in tcl's include dirs |
| 15:11.35 |
starseeker |
nods |
| 15:12.18 |
brlcad |
last night
was a good coding night, trying to get some new libbu interfaces in
place |
| 15:12.34 |
starseeker |
sweet |
| 15:13.24 |
brlcad |
better string
management to help with processing object names and lists of
objects (which all of libged could use) |
| 15:13.47 |
brlcad |
basic things
that makes one slap the forehead and ask why they weren't there 10
years ago |
| 15:14.04 |
brlcad |
but some more
complex ones too, like globbing |
| 15:14.16 |
starseeker |
something
beyond fnmatch? |
| 15:14.21 |
brlcad |
yep |
| 15:15.01 |
starseeker |
that would be
awesome - I'd love to be able to do per-command globbing on mged
command line to avoid having to quote the bejeezus out of search
commands... |
| 15:15.03 |
brlcad |
basically a
corollary to glob(3) |
| 15:15.16 |
brlcad |
including a
mechanism for iterating |
| 15:28.32 |
CIA-63 |
BRL-CAD:
03starseeker * r46872 10/brlcad/trunk/src/ (3 files in 3 dirs):
Start figuring out how to wrap includes needed for a directory into
a variable and use that variable in other CMakeLists.txt files that
are including the library |
| 15:48.38 |
brlcad |
hm, careful
use there -- BU_INCLUDE_DIRS only needs to include headers used by
the public headers |
| 15:49.00 |
brlcad |
implementation headers don't need to be
included, they're still just regular include_dirs() |
| 15:49.24 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 15:50.11 |
brlcad |
uce-dirent,
png being the two examples not publicly used |
| 15:50.47 |
brlcad |
zlib too,
hm! |
| 15:51.09 |
brlcad |
those are
INCLUDE_DIRS like regex, needed by src/other stuff |
| 15:52.20 |
brlcad |
opennurbs,
png, and tkpng use zlib |
| 15:55.48 |
brlcad |
doesn't look
like anything uses png publicly |
| 15:56.20 |
brlcad |
bu, fb, dm,
ged, tclcad, and a few util tools use it privately |
| 16:53.22 |
abhi2011 |
brlcad: here
is the verbose build output : http://bin.cakephp.org/view/1626192759 |
| 16:54.17 |
abhi2011 |
ah ok, just
saw starseeker's update, will try it |
| 17:04.50 |
CIA-63 |
BRL-CAD:
03bob1961 * r46873
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Set zclip
flag to 0 in ArcherCore::doLighting. |
| 17:13.00 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 17:25.50 |
abhi2011 |
cool, now the
raytrace.h related errors are gone, however I also need to pass
gedp to the functions in simphysics.cpp, so I have included
../ged_private.h in the simulate.h file(as that file declares
struct ged in ged.h) |
| 17:26.24 |
abhi2011 |
i get this
warning : /home/abhi/socis/brlcad/include/ged.h:2289:78: warning:
‘int ged_view(ged*, int, const char**)’ hides constructor for
‘struct ged_view’ |
| 17:27.37 |
starseeker |
so... once we
get tcl out of libbu, we'll have no need for
BU_INCLUDE_DIRS? |
| 17:32.12 |
CIA-63 |
BRL-CAD:
03n_reed * r46874 10/brlcad/trunk/src/ (conv/obj-g_new.c
libgcv/wfobj/tri_face.c): plugged a few leaks |
| 17:36.49 |
abhi2011 |
hmm I think
the warning is coming because ged.h is being compiled by the c++
component of gcc |
| 17:37.09 |
abhi2011 |
otherwise no
constructor stuff should have been seen |
| 17:39.08 |
abhi2011 |
i do need the
gedp as i get the internal representation of a object using
GED_DB_GET_INTERNAL(gedp,.... |
| 17:39.17 |
abhi2011 |
in the cpp
file |
| 17:39.38 |
abhi2011 |
however I ll
see if I can use just librt instead, so all gedp references can be
removed |
| 17:45.13 |
CIA-63 |
BRL-CAD:
03starseeker * r46875 10/brlcad/trunk/src/ (4 files in 2 dirs):
Swap in the new obj-g for the old, stop building both. |
| 17:54.51 |
starseeker |
didn't realize the current installed layout wasn't ideal...
I'm not really sure how much logic would have to be reworked to
suport another layout, I was assuming the current layout was *the*
layout... |
| 17:56.36 |
starseeker |
thought the version number in the share subdirectory was to
allow for warnings/wipeouts running one version of brlcad and
having the root directory set to another version's location... then
attempts to get "version x.y.z" data from that direcory would fail
despite being set to the wrong directory... |
| 17:58.32 |
starseeker |
seemed like a
nice way to avoid subtle "almost working but it failed"
situations... |
| 19:17.24 |
brlcad |
abhi2011: you
should only include ged_private.h if you use something that header
provides -- just include ged.h directly |
| 19:18.27 |
brlcad |
starseeker:
there's still a need for BU_INCLUDE_DIRS -- it's presently just the
top-level include dir |
| 19:19.04 |
brlcad |
your logic
that eliminates duplicates will take care of keeping only one
instance, while letting bu-only and rt-only apps to behave
correctly |
| 19:20.47 |
brlcad |
starseeker:
having the versioned sub-directory does help with multi-version
installs, that was also intentional |
| 19:21.50 |
brlcad |
but the fact
that it's only the datadir wasn't -- the goal was fully versioned
installs into a NON-VERSIONED root directory (like
/usr) |
| 19:25.09 |
brlcad |
having
separation of BRLCAD_DATA and BRLCAD_ROOT provides similar
multi-redundancy protections from using the wrong data |
| 19:25.23 |
brlcad |
should probably just write this all up on the
wiki |
| 19:36.20 |
brlcad |
n_reed: a
cleanup chare, should mark all of the non-public functions as
static in wfobj |
| 19:36.59 |
n_reed |
consider it
done |
| 19:37.58 |
n_reed |
although
HIDDEN would be better right? |
| 19:38.16 |
brlcad |
if there is
value in being able to debug into that function, sure |
| 19:38.38 |
brlcad |
not for
front-end code, that should use static |
| 19:38.58 |
brlcad |
but library
funcs can use either -- HIDDEN for public API and discretion for
non-public |
| 19:42.58 |
n_reed |
trying to
understand... so the point of HIDDEN is just to allow toggling
static-ness |
| 19:49.42 |
CIA-63 |
BRL-CAD:
03n_reed * r46876 10/brlcad/trunk/
(doc/docbook/system/man1/en/obj-g.xml src/conv/obj-g.c): some
updates to obj-g documentation |
| 19:56.39 |
starseeker |
erm. the top
level include dir I've been including in *all* of src via the
src/CMakeLists.txt file... |
| 19:58.55 |
brlcad |
n_reed:
basically |
| 19:59.50 |
brlcad |
some
compilers will fully inline static functions at their discretion,
making it impossible to set a breakpoint for debugging |
| 20:00.56 |
brlcad |
so if there
is any value at any time to be able to debug into that function as
a breakpoint (which there is for most public API, by definition),
then HIDDEN should be used instead of static |
| 20:03.05 |
brlcad |
coincidentally, it also helps to avoid
function name ambiguity by not allowing implementation-detail
functions to have the same name as front-end application
functions |
| 20:03.43 |
brlcad |
helps ensure
functions are properly named with some non-conflicting prefix or
other name convention |
| 20:09.22 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 20:30.21 |
CIA-63 |
BRL-CAD:
03starseeker * r46877 10/brlcad/trunk/src/ (7 files in 7 dirs):
Make another try at include_dirs updates... |
| 20:30.42 |
starseeker |
brlcad: that
more what you had in mind? (before I go any
further...) |
| 20:34.40 |
brlcad |
starseeker:
yeah, that's looking great |
| 20:36.01 |
starseeker |
k. actually
kinda handy that I was including the toplevel include in src -
taking it out makes for a very simple "fail because I'm not
converted yet" situation :-) |
| 20:36.16 |
brlcad |
also makes a
couple low-lying fruit obvious, things that should get
fixed |
| 20:36.31 |
brlcad |
like libfb
needing to include pkg.h .. stupid |
| 20:36.52 |
brlcad |
should be
hidden in the impl or passed by the caller |
| 20:37.10 |
brlcad |
it's for just
one pointer |
| 20:40.31 |
starseeker |
I realize
it's a bit premature, but with the "every command in libged being a
plugin" approach, will the policy be that headers included by the
individual commands not be part of the required includeds at the
toplevel? Or, put another way, can we require that any include dir
needed for ged users be specified at the toplevel ged
CMakeLists.txt and not in the command subdirectories? |
| 20:45.21 |
CIA-63 |
BRL-CAD:
03starseeker * r46878 10/brlcad/trunk/src/ (3 files in 3 dirs):
Convert a few more directories to new include_dir
scheme |
| 20:52.26 |
starseeker |
man liborle
is so small it's hardly even there... |
| 20:53.23 |
starseeker |
wonders if that could fold entirely into something else like
libicv... |
| 21:28.43 |
brlcad |
that's just
sad.. |
| 21:29.22 |
brlcad |
came across
some old tcl code in some old directory in my data
archive |
| 21:30.27 |
brlcad |
my
fingerprints are all over it .. naming conventions, code structure,
style .. and sure enough my name is in one of the files as the
author |
| 21:31.02 |
brlcad |
but it took a
solid 10 minutes of actually running the code, seeing the gui that
pops up, poking on it to even have a glimmer of memory doing
that |
| 21:33.07 |
brlcad |
(it was an
inteface for shooting rays at geometry, plotting the hit points
(similar to nirt), and providing the option to create actual
geometry for the hit points (spheres) and path segments
(cylinders/arb8s) .. which someone had requested at some
point) |
| 21:35.38 |
starseeker |
hmm,
nifty |
| 21:35.45 |
brlcad |
starseeker:
liborle and the two tools that use it can be deprecated, but
they've just not been a maintenance burden to even
bother |
| 21:35.46 |
starseeker |
surprised it
didn't get rolled into mged |
| 21:35.53 |
brlcad |
it wasn't
completed |
| 21:35.58 |
starseeker |
ah |
| 21:36.15 |
starseeker |
brlcad: is
code tidiness a sufficient motive to depricate? :-P |
| 21:36.19 |
brlcad |
the gui is
actually pretty far along |
| 21:36.21 |
starseeker |
deprecate
even |
| 21:37.50 |
brlcad |
*shrug*, if
you want to both go for it, but there are *hundreds* of code
tidiness issues like that such that it's been plenty enough as-is
to just deprecate when they incur some cost (like a build failure
that might take more than 10 seconds to fix) |
| 21:38.30 |
brlcad |
deprecating
has a cost too .. those little 10 minute activities add up with
context switching :) |
| 21:38.32 |
starseeker |
<snort>
in this case, it's just rewriting the CMake logic for liborle
everytime a paradigm change takes place - once that stops, I
suppose i twon't matter |
| 21:38.46 |
brlcad |
that's a
maintenance cost actually |
| 21:39.14 |
brlcad |
so if you
deprecate now, they could go when autotools goes |
| 21:39.33 |
brlcad |
then you
don't even have to worry, let autotools build and yank the
cmake |
| 21:39.40 |
starseeker |
nods - let me check which tools those are... - src/util I
presume? |
| 21:39.48 |
brlcad |
fb and
util |
| 21:41.10 |
brlcad |
that goes
MUCH farther back than my tcl discovery today, but i *think* it
used to be a hand-rolled rle library that was replaced when
urtoolkit's librle came out |
| 21:42.08 |
CIA-63 |
BRL-CAD:
03starseeker * r46879 10/brlcad/trunk/doc/deprecation.txt: list
liborle and corresponding tools for deprecation |
| 21:42.15 |
brlcad |
new tools
were written but the old ones were kept around for some reason
that's been lost in time (probably out-perform) |
| 21:42.22 |
starseeker |
nods |
| 21:42.47 |
starseeker |
has yet to use *any* of the rle utils at all... guess I just
haven't needed 'em yet |
| 21:42.53 |
brlcad |
should put
the version too |
| 21:43.05 |
starseeker |
hmm? |
| 21:43.22 |
starseeker |
oh |
| 21:43.32 |
starseeker |
7.20? |
| 21:43.35 |
brlcad |
nods |
| 21:44.05 |
CIA-63 |
BRL-CAD:
03starseeker * r46880 10/brlcad/trunk/doc/deprecation.txt: add
version |
| 21:44.51 |
brlcad |
that's so
deprecations can be cherry-picked into the obsolete section with
just a copy-paste |
| 21:46.00 |
CIA-63 |
BRL-CAD:
03starseeker * r46881 10/brlcad/trunk/src/ (8 files in 8 dirs): Add
a few more to the 'converted' list for include dirs - got a ways to
go, pretty far reaching change. |
| 21:46.39 |
brlcad |
starseeker:
since there are binaries going away, they get a statement too (see
src/util/dbcp.c) |
| 21:47.04 |
starseeker |
each one gets
a statement? |
| 21:47.27 |
brlcad |
so a message
is printed when run |
| 21:47.34 |
starseeker |
oh,
gotcha |
| 21:47.42 |
starseeker |
not in
doc/deprecation, but in the C code itself |
| 21:47.43 |
brlcad |
doesn't have
to be the same message as dbcp's, but should be something
similar |
| 21:47.47 |
brlcad |
right |
| 21:48.11 |
brlcad |
doc/deprecation is meant to let devs know
-- if a tool is going to disappear, we just put a statement in the
tool |
| 21:48.58 |
brlcad |
(and in
doc/deprecation, but users just aren't likely to or expected to
look there .. they just use the tools they know) |
| 21:49.04 |
brlcad |
would be good
to point them to the new tools |
| 21:49.09 |
CIA-63 |
BRL-CAD:
03starseeker * r46882 10/brlcad/trunk/src/fbserv/CMakeLists.txt:
that was easy... convert fbserv to new includes |
| 21:49.16 |
brlcad |
"Use rle-fb
instead!" |
| 21:51.10 |
brlcad |
been
consistently using the marker DEPRECATED for both dev code comments
and user printing statements |
| 21:51.17 |
brlcad |
so they're
all easy to find |
| 21:51.36 |
starseeker |
do I need to
support the D option? |
| 21:52.40 |
starseeker |
interesting -
fb-orle's usage statement says fb-rle |
| 21:55.35 |
CIA-63 |
BRL-CAD:
03n_reed * r46883 10/brlcad/trunk/src/libgcv/wfobj/ (6 files):
interface cleanup, including hiding local functions |
| 21:57.27 |
CIA-63 |
BRL-CAD:
03starseeker * r46884 10/brlcad/trunk/src/ (fb/fb-orle.c
fb/orle-fb.c util/orle-pix.c util/pix-orle.c): Add deprecation
warning messages to the fb and pix tools pertaining to
orle. |
| 21:59.40 |
*** join/#brlcad dli
(~dli@dyn-157-046.wireless.concordia.ca) |
| 22:14.48 |
CIA-63 |
BRL-CAD:
03starseeker * r46885 10/brlcad/trunk/src/ (5 files in 5 dirs):
Convert a few more include dir lists. |
| 23:10.58 |
*** join/#brlcad dli
(~dli@dyn-157-046.wireless.concordia.ca) |
| 23:16.57 |
CIA-63 |
BRL-CAD:
03abhi2011 * r46886 10/brlcad/trunk/src/libged/simulate/
(simphysics.cpp simulate.c simulate.h): Moved position
transformation functions into simphysics.cpp and rearranged some
code to fit in a call to rt |
| 23:42.56 |
*** join/#brlcad dli
(~dli@dyn-157-046.wireless.concordia.ca) |
| 00:50.03 |
starseeker |
brlcad: yow,
there's a lot of perl code for the docbook stuff |
| 00:50.24 |
starseeker |
do we go with
that or did you want it translated into CMake+xml? |
| 00:51.48 |
starseeker |
wonders how much of this generation of pages can be done
using templates and configure_file... |
| 00:54.00 |
starseeker |
sets up the autotools build to see what is being
done... |
| 00:55.01 |
starseeker |
prefers not to rely on perl if we don't have to... don't
think there's anywhere else we need it... |
| 00:57.58 |
starseeker |
brlcad:
http://www.cmake.org/pipermail/cmake/2011-September/046475.html |
| 01:00.10 |
starseeker |
no dice
:-/ |
| 02:22.33 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 03:15.23 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r46978
10/brlcad/trunk/doc/docbook/create-book-covers.pl: allow for both
xml and fo suffixes to be recognized for generation to
work |
| 03:16.26 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r46979 10/brlcad/trunk/doc/docbook/fop.xconf.in:
correct font data to cover font substitution warnings |
| 03:18.38 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r46980 10/brlcad/trunk/doc/docbook/Makefile.am: add
targets for testing book covers\nexectute create-book-covers for
bot fo and pdf due to files changes with color changes for each
volume |
| 04:01.13 |
brlcad |
starseeker:
installing perl on windows wouldn't be an unreasonable requisite if
we want to make building the pdfs on windows possible |
| 04:01.21 |
brlcad |
so it's
really about converting the Makefile.am logic into cmake
terms |
| 04:02.48 |
brlcad |
if perl isn't
detected, it doesn't try |
| 04:02.52 |
brlcad |
just like
fop |
| 04:06.07 |
brlcad |
starseeker:
as for the find_library reply, he sets it up for you right there at
the end... "job is to find library files" |
| 04:36.45 |
brlcad |
starseeker:
sent you what I'd reply, not that you have to use it.. but his
response was a particularly heavy stuffed straw-man |
| 04:37.17 |
starseeker |
was trying to
figure out how to continue the discussion without pissing him
off |
| 04:37.46 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
| 04:38.02 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 04:38.05 |
brlcad |
he's
intentionally trolling for some reason (or is just a bit of a
jerk) |
| 04:38.38 |
brlcad |
reminds me of
one of the bz devs, hyperbole overload |
| 04:41.24 |
brlcad |
left to
implement tools like 'ls', you'd not actually get a current listing
of files because, well, you can't actually detect if the disk drive
failed or if the filesystem is corrupted, so it's better if it just
returns the listing that was there at boot-up |
| 04:44.05 |
*** join/#brlcad dtidrow_desk
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 04:52.42 |
starseeker |
brlcad: he
mentioned /usr/lib/x86_64-linux-gnu/libc.so on ubuntu is a linker
script - would that be all <128 characters? |
| 04:56.40 |
brlcad |
starseeker:
yep that would be, though that's actually one of the points I'm
claiming -- that's not a library, it's a gnu linker
script |
| 04:57.18 |
``Erik |
<PROTECTED> |
| 04:57.19 |
brlcad |
basically a
gnu-ld-specific symbolic link of sorts |
| 04:58.11 |
brlcad |
it's not a
libtool archive .. they actually gang up and use the same
filename/suffix pattern -- ld reads the file and recognizes it as
an ld script |
| 04:58.19 |
brlcad |
f'd
up |
| 04:58.29 |
``Erik |
that's...
very.... linuxy. |
| 04:58.43 |
``Erik |
sorry,
gnu/linuxy |
| 04:59.41 |
brlcad |
"special" is
the word |
| 04:59.53 |
brlcad |
needs-a-helmet "special" |
| 05:00.20 |
``Erik |
meh,
synonymous O:-) |
| 05:00.44 |
brlcad |
starseeker:
that gets back to the original point that the only real way to tell
it to try and link it |
| 05:01.17 |
brlcad |
if you're
cross-compiling, you just don't halt/fail/test/whatever .. though
presumably I have a cross-compiler and cross-compilation libs
somewhere that will work! |
| 05:02.37 |
``Erik |
that'd be an
interesting experiment... install a cross compiler from
/usr/ports/, try to build BRL-CAD, then try to run it in an
emulator for that platform O.o |
| 05:06.38 |
starseeker |
has never tangled with cross-compilation - scary sounding
stuff from the early days of bootstrapping computers is where I
know the phrase from |
| 05:08.17 |
``Erik |
I used to do
it on linux to target win32, and have fairly recently done it to
generate an arm fbsd tftp/nfsboot |
| 05:09.41 |
``Erik |
as far as the
compiler, it's no big deal, just CC=/usr/local/bin/gcc-mingw32
make... figuring out how to set all the right config options and
flags can expose a lot in an automatic configuration system, though
:) |
| 05:20.16 |
starseeker |
once more
unto the breach dear friends... http://www.cmake.org/pipermail/cmake/2011-September/046478.html |
| 05:48.27 |
brlcad |
thinks the glorified fnmatch() comparison was warranted, but
not too shabby |
| 05:48.54 |
brlcad |
left yourself
open to attack in a few places, but the point was in
there |
| 06:19.34 |
starseeker |
is a rather straightforward sort, not too good at this sort
of manuvering |
| 06:45.42 |
brlcad |
not that
straighforward .. very wordy reply :) |
| 06:47.27 |
brlcad |
my tort
respones were direct, you're timidly beating around the bush trying
to be polite while skirting around your point before getting to
it |
| 06:47.38 |
brlcad |
at least
that's my take, it's still good |
| 06:49.30 |
brlcad |
I just
suspect he'll nit pick something minor, hemhaw on some irrelevant
detail, and ignore your points (like how he basically ignored your
earlier reference to AC_CHECK_LIB) |
| 06:52.42 |
kanzure |
hi
brlcad |
| 06:52.49 |
kanzure |
thanks for
the scl/step update |
| 07:39.13 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 08:08.45 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 08:26.56 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 10:06.54 |
*** join/#brlcad kunigami_
(~kunigami@201.82.92.180) |
| 10:10.56 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 10:14.23 |
*** part/#brlcad kunigami_
(~kunigami@201.82.92.180) |
| 10:44.18 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 11:37.46 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-170-216.wlan.tudelft.nl) |
| 11:44.59 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 12:19.30 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r46981 10/brlcad/trunk/doc/docbook/README: added
scribus as a program for DB authors for converting eps to svg
format |
| 12:22.12 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r46982
10/brlcad/trunk/doc/docbook/README.DB_authors_notes: add info on
pdf graphics and eps conversions |
| 12:29.52 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r46983 10/brlcad/trunk/doc/docbook/Makefile.am:
trimmed some fat; added missing tools to dist list |
| 12:49.20 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-196-228.wlan.tudelft.nl) |
| 13:36.32 |
brlcad |
kanzure: no
problem |
| 13:41.21 |
starseeker |
yawns |
| 13:42.46 |
brlcad |
yawns |
| 13:49.15 |
starseeker |
http://www.cmake.org/pipermail/cmake/2011-September/046479.html |
| 13:49.23 |
starseeker |
even better,
http://www.cmake.org/pipermail/cmake/2011-September/046481.html |
| 13:52.58 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 14:04.39 |
CIA-48 |
BRL-CAD:
03d_rossberg * r46984 10/brlcad/trunk/CMakeLists.txt: |
| 14:04.39 |
CIA-48 |
BRL-CAD: the
current setting of compiler flags does not work for the MSVC
compiler, it results in a broken build |
| 14:04.39 |
CIA-48 |
BRL-CAD: (The
CMake standard for MSVC is linking with the C-runtime-DLL, which is
OK. The ridiculous gcc flags force MSVC to use its own standards:
Linking every DLL statically with a separate
C-runtime.) |
| 14:05.18 |
starseeker |
d_rossberg:
hmm. I just built with MSVC a day or two ago... |
| 14:05.49 |
starseeker |
you mean MSVC
is mis-interperting a gcc flag? |
| 14:07.10 |
d_rossberg |
i'm afraid it
misinterprets every gcc flag (see the compiler
warnings) |
| 14:08.20 |
d_rossberg |
the gcc flags
will only be set for the choosen build type |
| 14:09.25 |
d_rossberg |
i.e. if you
have choosen release for CMake but compiling Debug with your Visual
Studio the build could work |
| 14:10.20 |
starseeker |
winces |
| 14:10.20 |
d_rossberg |
but otherwise
asc2g will crash many time during the build |
| 14:11.13 |
starseeker |
that business
of allowing MSVC and/or XCode to have multiple configs is a real
pain |
| 14:11.15 |
d_rossberg |
btw: i
couldn't find a way to build libitcl.dll |
| 14:11.48 |
starseeker |
you mean it
crashes? |
| 14:11.52 |
d_rossberg |
the CMake
defaults are doing a good job for MSVC |
| 14:12.29 |
d_rossberg |
there are
undefined symbols in itcl |
| 14:12.55 |
starseeker |
brlcad:
what's your take - should we let the MSVC defaults
ride? |
| 14:13.20 |
starseeker |
d_rossberg:
can you post a build log for itcl? (also, which Visual Studio? I
recently built with 10...) |
| 14:23.16 |
d_rossberg |
do you mean
something like this: http://brlcad.org/~rossberg/BuildLog.htm |
| 14:24.35 |
d_rossberg |
MSVC 2008
(German :) |
| 14:25.28 |
starseeker |
that looks
right... |
| 14:30.22 |
d_rossberg |
all i did was
making a svn checkout and choosing an "aBuild" subdirectory as
cmake working directory |
| 14:30.51 |
starseeker |
what library
implements sprintf in MSVC2008? |
| 14:31.20 |
starseeker |
that looks
like we need another MSVC library in the linker line, but I'm not
sure which one |
| 14:33.36 |
starseeker |
this might
pertain to one of those linker errors... http://support.microsoft.com/kb/894573 |
| 14:35.15 |
d_rossberg |
sprintf is
part of the c-runtime library |
| 14:35.31 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 14:35.38 |
starseeker |
what do we
feed to the linker list to get the c-runtime? |
| 14:41.31 |
starseeker |
is there a
/GS or /Gs flag in the build somewhere? |
| 14:42.09 |
d_rossberg |
i think
saying /MD or /MDd does it, /NODEFAULTLIB would remove all defaults
(in this case one had to set the libraries all by hand) |
| 14:43.53 |
starseeker |
d_rossberg:
go ahead and add what you need - I'll try it on 2010
later |
| 14:53.08 |
d_rossberg |
1st: it looks
like its a problem with the debug configuration, release is ok (at
least at the moment) |
| 14:53.41 |
brlcad |
starseeker:
they're obsessing over symbolic links, but that's still ignoring
the elephant in the room to me -- just looking at the file name
makes it a glorified fnmatch() wrapper |
| 14:54.34 |
d_rossberg |
then i could
compile and link the debug too by changing the c-runtime to
debug-dll in the compiler settings |
| 14:55.01 |
d_rossberg |
it looks like
the is somewhere a /MD instead of /MDd ... |
| 15:03.09 |
brlcad |
how are gcc
flags getting added to the msvc build? a simple compile test
should ensure that they're detected as non-functional |
| 15:03.20 |
brlcad |
if they're
not, sounds like the compile test is flawed |
| 15:03.25 |
starseeker |
hah, cool:
http://www.evilmadscientist.com/article.php/visdiff |
| 15:04.24 |
starseeker |
brlcad: if I
understood him correctly, it's when you tell CMake one thing for
build configuration and then do the other thing in MSVC |
| 15:04.42 |
starseeker |
XCode
probably has similar issues |
| 15:04.58 |
brlcad |
how would
that result in it thinking that -pipe is a valid flag? |
| 15:05.34 |
starseeker |
d_rossberg:
what were the specific errors you were seeing? (and what compile
flags were getting passed in?) |
| 15:05.59 |
brlcad |
there should
have been a -pipe test (which fails), and both debug and release
configs would use $PIPE_FLAG or whatever so it'd never get
added |
| 15:06.30 |
starseeker |
I don't know
if it was pipe specifically |
| 15:06.39 |
brlcad |
his error log
lists a -pipe |
| 15:07.03 |
brlcad |
if pipe got
through, they all would probably get through |
| 15:07.13 |
starseeker |
d_rossberg:
do you happen to have your CMake log handy? |
| 15:08.52 |
starseeker |
that's the
itcl build, it's probably a lot dumber than our mail BRL-CAD
build |
| 15:09.44 |
starseeker |
main
even |
| 15:10.27 |
starseeker |
did he post a
build log for the original gcc compile failure? |
| 15:10.45 |
brlcad |
not that I
saw |
| 15:10.51 |
starseeker |
that'd be the
one we need |
| 15:11.38 |
brlcad |
or examine
the build log on our end with that action, cmake as debug, change
to release in studio, compile |
| 15:11.44 |
d_rossberg |
unknown
compile flags are ignored (what you can see in the log) |
| 15:12.07 |
starseeker |
ignored and
the compile succeeds? (crud) |
| 15:13.00 |
d_rossberg |
the problem
arise when you replace the reasonable cmake defaults by
garbage |
| 15:13.32 |
d_rossberg |
then you have
the msvc defaults, which are not optimal bor brl-cad |
| 15:13.39 |
starseeker |
clang has
that same issue - it'll cheerfully ignore unknown flags and
succeed |
| 15:14.15 |
starseeker |
the cmake
defaults shouldn't be getting replaced by garbage
though |
| 15:14.19 |
d_rossberg |
adding
garbage is no problem, replacing the right settings is |
| 15:14.44 |
starseeker |
if we need to
add MSVC specific compiler tests to make sure the right MSVC
settings are there, then we should do that in
CompilerFlags.cmake |
| 15:16.00 |
d_rossberg |
btw, i think
i found the place to chage in the itcl configuration; there are
similar settings in other tcl/tk libraries; need some time to test
it out |
| 15:16.15 |
starseeker |
cool,
thanks |
| 17:29.32 |
brlcad |
yay, search
crashed |
| 17:40.16 |
CIA-48 |
BRL-CAD:
03brlcad * r46985 10/brlcad/trunk/src/librt/search.c: prevent
search from crashing if we can't get a directory pointer to a
specified path. encountered this with an object erroneously
containing slashes in the name. |
| 17:50.23 |
CIA-48 |
BRL-CAD:
03brlcad * r46986 10/brlcad/trunk/src/librt/ (db_anim.c db_tree.c
prep.c tcl.c tree.c wdb.c): check other callers of
DB_FULL_PATH_CUR_DIR() to make sure we don't try to dereference a
NULL pointer. |
| 17:56.45 |
CIA-48 |
BRL-CAD:
03brlcad * r46987 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: don't use
the file path as the toplevel object name. use its basename instead
since the slashes cause hell. |
| 18:10.13 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r46988 10/brlcad/trunk/doc/docbook/README: add info
on the saxon-he xslt 2.0 processor and news of the recent release
of the DB xslt 2.0 stylesheets |
| 18:49.36 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r46989 10/brlcad/trunk/doc/docbook/Makefile.am:
current process for DB book covers does not allow parallel make
processes so using special .NOTPARALLEL target; also requires
having book pdf generation in one recipe from xml to fo to
pdf |
| 18:50.48 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r46990 10/brlcad/trunk/doc/docbook/README: reword;
add release date of new DB stylesheets for XSLT 2.0 |
| 20:23.56 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 20:59.02 |
CIA-48 |
BRL-CAD:
03starseeker * r46991
10/brlcad/trunk/src/librt/comb/comb.c: |
| 20:59.02 |
CIA-48 |
BRL-CAD: Gah.
Older versions of BRL-CAD are hard-coded to look for oshader in
the |
| 20:59.02 |
CIA-48 |
BRL-CAD:
attributes when importing combs. This makes the particular label
oshader an |
| 20:59.02 |
CIA-48 |
BRL-CAD:
actual part of the .g file format itself, and NOT writing it out
was breaking |
| 20:59.02 |
CIA-48 |
BRL-CAD:
import of shaders when a .g file is created in a new version of
BRL-CAD and |
| 20:59.03 |
CIA-48 |
BRL-CAD:
subsequently opened in an older version. Need to check what other
hard-coded |
| 20:59.04 |
CIA-48 |
BRL-CAD:
assumptions got accidently messed with. |
| 22:17.08 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 22:26.44 |
CIA-48 |
BRL-CAD:
03bob1961 * r46992
10/brlcad/trunk/src/tclscripts/archer/images/component_select.png:
Update component_select image. |
| 00:01.58 |
brlcad |
basically
should always be clean, even if temporary code or works in progress
-- not a huge deal but it becomes more and more important as code
tends to hang around much longer than the original author and
becomes paramount as a codebase grows and ages |
| 00:03.20 |
brlcad |
it's a "clean
house all the time" not just when you have guests (because it's a
huge hotel and there are always guests) |
| 00:09.15 |
brlcad |
nice,
tessellation of 5th level sphflake is still going (4+
days) |
| 00:09.27 |
brlcad |
the 6th level
might be impractical.. :) |
| 00:15.03 |
starseeker |
if it's
exponential... how long did the 4th level take? |
| 00:36.26 |
CIA-48 |
BRL-CAD:
03n_reed * r47039 10/brlcad/trunk/ (2 files in 2 dirs): seems lemon
requires real type name in type declaration |
| 01:02.07 |
*** join/#brlcad _pseudonym
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 01:02.31 |
*** part/#brlcad _pseudonym
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 01:03.11 |
*** join/#brlcad pacman87
(~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) |
| 01:13.31 |
*** join/#brlcad pacman87
(~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) |
| 01:13.31 |
*** join/#brlcad DarkCalfz
(DC@173.231.40.98) |
| 01:13.31 |
*** join/#brlcad merzo
(~merzo@40-197-132-95.pool.ukrtel.net) |
| 01:13.31 |
*** join/#brlcad n_reed
(~nicholas@c-68-55-142-136.hsd1.md.comcast.net) |
| 01:13.31 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 01:13.31 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 01:13.31 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 01:13.31 |
*** join/#brlcad CIA-48
(~CIA@cia.atheme.org) |
| 01:13.31 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 01:13.31 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
| 01:13.31 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 01:13.31 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
| 01:14.18 |
*** part/#brlcad n_reed
(~nicholas@c-68-55-142-136.hsd1.md.comcast.net) |
| 01:50.14 |
starseeker |
glowers at all these perl routines generating xml pages...
I'm kinda wondering if this shouldn't be some .xml.in
files |
| 01:50.23 |
starseeker |
feels like
overkill |
| 01:54.36 |
*** join/#brlcad pacman87
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 02:41.08 |
brlcad |
starseeker:
dunno, few hours maybe or a half a day or something |
| 02:41.52 |
brlcad |
undoubtedly
overkill but if it works, it's definitely great progress .. can't
wait to see everything getting regenerated nightly |
| 02:42.33 |
brlcad |
so the build
worked for you? I'm seeing the previous error still but haven't
done a clean rebuild to see if it's some other issue |
| 02:42.37 |
brlcad |
doc
build |
| 02:45.06 |
starseeker |
had to
manually run the perl script to create that catalog file, then
change the APACHEFOP invocation |
| 02:45.19 |
starseeker |
he hardcoded
the fop path |
| 02:46.46 |
starseeker |
my sense is
we can do most of what he's doing with .in files, and the little
bit that can't be (e.g. pulling subversion revision number) can be
handled without perl |
| 02:46.54 |
starseeker |
sounds like
he may agree |
| 02:49.59 |
starseeker |
I'll poke at
it more tomorrow - need to run the wife in to work, she's got car
trouble |
| 02:50.40 |
starseeker |
since I have
to go exactly the wrong way in the morning anyway, might as well
come back here and do fop stuff :-) |
| 02:54.45 |
starseeker |
here's what
got generated for volume 1: http://bzflag.bz/~starseeker/BRL-CAD_Tutorial_Series-VolumeI.pdf |
| 02:57.31 |
brlcad |
the svn
revision number doesn't really belong -- it should be using the
include/conf files with good ol' revision numbers or a date stamp
ala 20110412 |
| 02:58.19 |
starseeker |
even easier
then |
| 02:59.24 |
starseeker |
looks like at
least one extra title page, and probably we need some way to tell
it not to do things like figure lists when n=1... |
| 02:59.50 |
starseeker |
'course,
"volume 1" isn't properly a book at all... |
| 02:59.53 |
starseeker |
not now,
anyway |
| 05:46.42 |
starseeker |
brlcad:
http://www.cmake.org/pipermail/cmake/2011-October/046553.html |
| 05:46.58 |
starseeker |
http://www.cmake.org/pipermail/cmake/2011-October/046554.html |
| 06:12.54 |
*** join/#brlcad pacman87
(~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) |
| 06:28.14 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 06:45.47 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 07:09.27 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 08:05.12 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 08:10.38 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 10:15.47 |
*** join/#brlcad mattS_
(792cfb6c@gateway/web/freenode/ip.121.44.251.108) |
| 10:16.26 |
mattS_ |
Hi! Is
anyone around here? |
| 10:17.42 |
pacman87 |
~ask |
| 10:17.43 |
ibot |
Questions in
the channel should be specific, informative, complete, concise, and
on-topic. Don't ask if you can ask a question first. Don't ask if
a person is there; just ask what you intended to ask them. Better
questions more frequently yield better answers. We are all here
voluntarily or against our will. |
| 10:18.34 |
mattS_ |
Hm, the bot
is telling me to ask better questions... |
| 10:19.18 |
mattS_ |
OK, I am
interested in getting the sweep / revolve feature working, and may
have the time to do it these days. |
| 10:19.35 |
mattS_ |
Not so sure
about the programming skills, but that's to be
determined. |
| 10:19.57 |
pacman87 |
Ah, I was the
one who suggested you come here |
| 10:20.07 |
mattS_ |
Indeed. |
| 10:20.31 |
mattS_ |
So, where
should I look? |
| 10:21.15 |
pacman87 |
From what I
remember, the revolve uses a "sketch" as its base, and only
straight line segments are supported for the revolve |
| 10:21.29 |
pacman87 |
do you have
the code checked out? |
| 10:21.37 |
pacman87 |
~brlsvn |
| 10:21.37 |
ibot |
try ~cadsvn
instead |
| 10:21.42 |
pacman87 |
~cadsvn |
| 10:21.42 |
ibot |
To obtain
BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 10:22.10 |
mattS_ |
ack. no svn
client on this particular computer... |
| 10:22.16 |
pacman87 |
what
OS? |
| 10:22.20 |
mattS_ |
OK, lemme put
one on. |
| 10:22.23 |
mattS_ |
OSX. |
| 10:22.24 |
mattS_ |
yuck |
| 10:23.08 |
pacman87 |
try
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/librt/primitives/ |
| 10:23.53 |
mattS_ |
That's rather
a lot for a browser based approach. |
| 10:24.00 |
mattS_ |
lemme find an
svn client. |
| 10:24.16 |
pacman87 |
specifically,
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/librt/primitives/revolve/ |
| 10:24.28 |
pacman87 |
revolve.c,
revolve.h, and revolve_brep.cpp |
| 10:25.46 |
mattS_ |
kk |
| 10:25.56 |
mattS_ |
u+p for svn
checkout? |
| 10:26.31 |
pacman87 |
try
blank |
| 10:27.29 |
pacman87 |
if not, try
your sourceforge user/pass |
| 10:28.09 |
mattS_ |
blank it
is. |
| 10:28.11 |
mattS_ |
got
it. |
| 10:28.25 |
pacman87 |
yeah, you
should only need user/pass for commit access |
| 10:28.38 |
mattS_ |
Makes
sense. |
| 10:30.27 |
mattS_ |
so in a
sentence or two, how far did you get with this project? |
| 10:33.29 |
pacman87 |
I think it
should work for sketches with only straight-line
segments |
| 10:33.58 |
mattS_ |
Great! |
| 10:34.33 |
pacman87 |
since
straight line + revolve axis = cone/cylinder/plane |
| 10:34.41 |
pacman87 |
so the
intersection calculation wasn't too hard |
| 10:35.35 |
pacman87 |
the next step
would probably be to look up what other segment types are supported
by the sketch primitive, and start adding those |
| 10:35.51 |
mattS_ |
Indeed. Ah
yes, I recall now that you were taking a different approach to this
than what I had first thought of... |
| 10:36.13 |
pacman87 |
probably
circular arcs would be easiest, since that's a toroid |
| 10:36.21 |
mattS_ |
Any chance
you have a document somewhere outlining your approach? |
| 10:36.28 |
pacman87 |
http://brlcad.org/wiki/Revolve_Primitive |
| 10:36.49 |
mattS_ |
Circular arcs
would be next logical step, yes. |
| 10:38.24 |
mattS_ |
OK, I need
some sleep. I will have a look + think about this
tomorrow. |
| 10:38.32 |
mattS_ |
Thanks for
your help! |
| 10:38.46 |
pacman87 |
from
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/librt/primitives/sketch/sketch.c
, it looks like the sketch can have line segments, circular arcs,
nurb, and bezier curves |
| 10:39.03 |
pacman87 |
re: sleep, me
too |
| 10:40.03 |
*** part/#brlcad mattS_
(792cfb6c@gateway/web/freenode/ip.121.44.251.108) |
| 10:44.39 |
pacman87 |
brlcad: looks
like the revolve primitive may be getting some work soon (see
above) |
| 10:59.27 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 12:56.52 |
CIA-48 |
BRL-CAD:
03n_reed * r47040 10/brlcad/trunk/src/other/step/src/express/
(CMakeLists.txt expscan.re): Added disabled macros to build temp
fedex_new target for development. Added expscan.re to build
against, but it has not yet been converted to re2c. |
| 13:31.25 |
CIA-48 |
BRL-CAD:
03bob1961 * r47041
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: |
| 13:31.26 |
CIA-48 |
BRL-CAD:
bot_split2, if the specified bot was split, now returns a list
containing the |
| 13:31.26 |
CIA-48 |
BRL-CAD: name
of the original bot and the backup name. The original name is used
for the |
| 13:31.26 |
CIA-48 |
BRL-CAD:
group containing the new bots resulting from the split. The backup
name |
| 13:31.26 |
CIA-48 |
BRL-CAD:
references the original bot. |
| 13:33.59 |
CIA-48 |
BRL-CAD:
03bob1961 * r47042
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added
bot_split_all, bot_sync_all and bot_fix_all. Updated bot_flip_check
to return a built up string instead of spewing things directly to
the command window. |
| 13:55.49 |
``Erik |
http://gcc.gnu.org/wiki/CompileFarm |
| 15:33.21 |
CIA-48 |
BRL-CAD:
03bob1961 * r47043 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Ripped out Archer's undo mechanism in
preparation for using transactions. |
| 15:38.54 |
brlcad |
``Erik:
nifty, going to set us up the bomb? |
| 15:40.35 |
brlcad |
mm, that
might explain why my revolve sketch performance test case was
crashing if it only supports straight line segments... |
| 15:46.29 |
``Erik |
I sent a
request for an account just before linking it |
| 15:50.35 |
CIA-48 |
BRL-CAD:
03starseeker * r47044 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt
resources/brlcad/brlcad-xml-catalog.xml.in): |
| 15:50.35 |
CIA-48 |
BRL-CAD:
First baby steps towards more advanced Docbook processing with
CMake. Make the |
| 15:50.35 |
CIA-48 |
BRL-CAD:
catalog file a CMake configure template, and add the environment
variables |
| 15:50.35 |
CIA-48 |
BRL-CAD:
needed for xsltproc to the custom command invocations. Lot more and
lot tricker |
| 15:50.36 |
CIA-48 |
BRL-CAD: to
come, but this is a start. |
| 16:15.32 |
CIA-48 |
BRL-CAD:
03starseeker * r47045 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt
resources/brlcad/brlcad-xml-catalog.xml.in): switch a couple of the
xsl stylesheet targets, fix paths. |
| 16:54.04 |
CIA-48 |
BRL-CAD:
03starseeker * r47046 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt
books/CMakeLists.txt): Getting closer to getting pdf working, but
not finding fonts... missing something. |
| 16:58.22 |
CIA-48 |
BRL-CAD:
03starseeker * r47047 10/brlcad/trunk/doc/docbook/
(articles/en/CMakeLists.txt presentations/en/CMakeLists.txt):
Couple stray leftover variables. |
| 17:16.48 |
*** join/#brlcad pacman87
(~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) |
| 17:29.56 |
CIA-48 |
BRL-CAD:
03starseeker * r47048 10/brlcad/trunk/doc/docbook/CMakeLists.txt:
fix typo. Try and get the fop command line to match that from
autotools |
| 17:41.00 |
*** join/#brlcad n_reed
(~nreed1@ool-457cb1ab.dyn.optonline.net) |
| 17:47.23 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47049 10/brlcad/trunk/src/libged/simulate/
(simcollisionalgo.cpp simphysics.cpp simulate.c simulate.h): Added
more code to check the generated manifolds |
| 18:16.06 |
CIA-48 |
BRL-CAD:
03bob1961 * r47050 10/brlcad/trunk/src/libged/ (bot_flip.c
bot_split.c bot_sync.c): Modify bot_split, bot_sync and bot_flip to
accept arguments containing full paths to bots. |
| 18:20.46 |
CIA-48 |
BRL-CAD:
03brlcad * r47051 10/brlcad/trunk/src/libged/simulate/simulate.h:
separate out struct members into one per line so they can be
individually documented; revert the ws changes. |
| 18:21.16 |
brlcad |
abhi2011:
your previous commit just undid all of the whitespace corrections
applied yesterday |
| 18:24.40 |
brlcad |
the only way
that would occur is if either a) you got a conflict and resolved it
incorrectly or b) ran a source formatter before committing and
applied the wrong style |
| 18:26.56 |
CIA-48 |
BRL-CAD:
03bob1961 * r47052
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Simplify
ArcherCore::redrawObj. |
| 18:28.38 |
CIA-48 |
BRL-CAD:
03brlcad * r47053 10/brlcad/trunk/src/libged/simulate/simulate.c:
use vmath macros where appropriate, reduces line count. restore
indent for the affected functions. |
| 18:31.55 |
abhi2011 |
brlcad: I
just applied the sh/ws.sh and sh/indent.sh on all the files in
simulate/* files |
| 18:32.06 |
abhi2011 |
before
committing |
| 18:32.28 |
abhi2011 |
is only one
of them supposed to be run and not both ? |
| 18:39.50 |
abhi2011 |
hmm the
indentation should be 4 spaces, however after i ran indent.sh it
indented everything by 2 spaces |
| 18:43.06 |
CIA-48 |
BRL-CAD:
03brlcad * r47054 10/brlcad/trunk/src/libbu/ (11 files): trailing
ws and indent cleanup |
| 18:43.11 |
brlcad |
abhi2011:
yeah, something didn't go right with the indent |
| 18:43.31 |
brlcad |
for what it's
worth, you should always separate ws/indent commits from logic
changes |
| 18:43.38 |
brlcad |
otherwise you
can't tell what the changes were |
| 18:44.00 |
abhi2011 |
ok |
| 18:44.10 |
brlcad |
something
apparently went wrong with the indent.sh script -- do you use
emacs? |
| 18:44.13 |
abhi2011 |
hmm i just
ran indent again and its indented everything by 2
spaces |
| 18:44.15 |
abhi2011 |
yes |
| 18:44.20 |
abhi2011 |
i instaled
emacs today |
| 18:44.28 |
brlcad |
do you have a
C hook registered? |
| 18:44.30 |
abhi2011 |
does it
require configuration |
| 18:44.32 |
abhi2011 |
no |
| 18:44.53 |
abhi2011 |
i do not have
a C hook registered |
| 18:45.00 |
brlcad |
it shouldn't
require configuration, but if you have an existing config it can
override the file settings |
| 18:45.20 |
brlcad |
try running
indent.sh on one file and see what it does |
| 18:45.31 |
brlcad |
pastebin the
output |
| 18:46.33 |
abhi2011 |
http://bin.cakephp.org/view/530534711 |
| 18:46.44 |
abhi2011 |
i ran :
sh/indent.sh src/libged/simulate/simulate.c |
| 18:47.26 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47055 10/brlcad/trunk/doc/docbook/resources/other/:
start of resources restructuring |
| 18:47.50 |
abhi2011 |
i think after
installation, emacs needs to be told to indent by 4 spaces, else it
defaults to 2 |
| 18:47.56 |
brlcad |
I meant the
output from indent.sh :) |
| 18:47.58 |
abhi2011 |
hmm maybe
something missing in the trailer |
| 18:48.00 |
abhi2011 |
ok |
| 18:48.51 |
abhi2011 |
http://bin.cakephp.org/view/2025222878 |
| 18:49.08 |
abhi2011 |
i think the
trailer needs to contain the indentation info in the c
file |
| 18:49.12 |
abhi2011 |
i ll add it
and see |
| 18:49.43 |
abhi2011 |
though I
would have thought that the one already there will work |
| 18:50.33 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47056 10/brlcad/trunk/doc/docbook/resources/
(docbook/ docbook-5.0/): rename to remove version |
| 18:50.34 |
brlcad |
abhi2011:
c-file-style: "stroustrup" sets an indentation of 4 |
| 18:50.39 |
abhi2011 |
hmm trailer
in the simulate.c file is same as any other file |
| 18:50.41 |
abhi2011 |
yes |
| 18:51.11 |
abhi2011 |
emacs messing
around with my code :P |
| 18:51.17 |
brlcad |
what version
of emacs? |
| 18:51.32 |
abhi2011 |
GNU Emacs
23.2.1 |
| 18:52.17 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47057 10/brlcad/trunk/doc/docbook/resources/
(docbook/ docbook-schema/): rename for clarity; avoid confusion
with stylesheets |
| 18:53.12 |
abhi2011 |
something
needs to be put in .emacs |
| 18:53.25 |
brlcad |
hm, yours is
slightly newer than mine, what does M-x describe-variable
c-file-style report? |
| 18:53.41 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47058 10/brlcad/trunk/doc/docbook/resources/
(docbook-schema/ other/docbook-schema/): segregate external
resources |
| 18:54.41 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 18:54.59 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47059 10/brlcad/trunk/doc/docbook/resources/
(other/standard/ standard/): segregate external
resources |
| 18:55.14 |
brlcad |
I have
nothing in my .emacs |
| 18:55.32 |
brlcad |
the only
thing that might be affecting this is if local variable parsing is
off by default in 23.2.1 |
| 18:55.43 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47060 10/brlcad/trunk/doc/docbook/resources/ (fonts/
other/fonts/): segregate external resources |
| 18:55.58 |
brlcad |
do you know
how to run M-x describe-variable c-file-style ? |
| 18:56.22 |
brlcad |
(run that
with a buffer open to src/libged/simulate/simulate.c |
| 18:56.22 |
abhi2011_ |
brlcad: no I
dont |
| 18:56.45 |
brlcad |
M-x is the
starting key binding, usually "ESC x" or "ALT+x" |
| 18:56.58 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47061
10/brlcad/trunk/doc/docbook/resources/other/offo/: restucturing
external resources |
| 18:57.03 |
brlcad |
then type
"describe-variable[ENTER]" |
| 18:57.21 |
brlcad |
it'll prompt
you for a variable name, type "c-file-style[ENTER]" |
| 18:57.27 |
abhi2011_ |
ok |
| 18:57.34 |
brlcad |
if should
split the buffer and show you the value |
| 18:57.52 |
brlcad |
saying
something like "Its value is 'stroustrup'" |
| 18:57.57 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47062 10/brlcad/trunk/doc/docbook/resources/ (4
files in 4 dirs): segregate external resources |
| 18:58.09 |
abhi2011_ |
ok got it,
alt x |
| 18:58.36 |
abhi2011_ |
hmm No
match |
| 18:58.39 |
brlcad |
ctrl-g ctrl-g
if you mess up :) |
| 18:58.52 |
abhi2011 |
for
c-file-style |
| 18:58.56 |
abhi2011 |
i ll have to
set it |
| 18:59.14 |
brlcad |
no you
don't |
| 18:59.21 |
abhi2011 |
yeah its thr
in the file |
| 18:59.41 |
brlcad |
M-x
describe-mode |
| 19:00.26 |
brlcad |
should be
something like "C/l mode" |
| 19:01.00 |
abhi2011 |
no match
there either |
| 19:01.15 |
abhi2011 |
though i did
get lot of messages |
| 19:03.20 |
brlcad |
then you're
doing something wrong :0 |
| 19:03.22 |
brlcad |
:) |
| 19:03.27 |
brlcad |
there's
always a mode |
| 19:03.32 |
abhi2011 |
http://bin.cakephp.org/view/916412370 |
| 19:03.56 |
brlcad |
ah,
Fundamental mode |
| 19:04.01 |
abhi2011 |
:P |
| 19:04.02 |
brlcad |
that's
wrong |
| 19:04.14 |
brlcad |
or you were
in the wrong buffer |
| 19:05.08 |
abhi2011 |
ok
wait |
| 19:05.24 |
abhi2011 |
i think i did
not open a buffer to simulate.c |
| 19:05.27 |
abhi2011 |
thats
why |
| 19:05.35 |
brlcad |
ah,
yes |
| 19:05.42 |
brlcad |
*before*
running M-x .. make sure your cursor is in the buffer for
simulate.c |
| 19:06.07 |
brlcad |
"C-x o" will
jump to the "other"/next buffer |
| 19:06.30 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47063
10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/stix-v1.0.0/README:
document version of the STIX fonts |
| 19:06.51 |
abhi2011 |
ok c file
style is strousup |
| 19:07.07 |
abhi2011 |
*stroustrup |
| 19:07.20 |
brlcad |
so last thing
to check.. |
| 19:07.38 |
brlcad |
and that's
"good" because it means it read the local vars block |
| 19:07.53 |
abhi2011 |
mode is C/l
mode |
| 19:08.20 |
brlcad |
M-x
describe-variable c-indentation-style |
| 19:08.24 |
brlcad |
great |
| 19:09.10 |
abhi2011 |
stroustrup |
| 19:09.23 |
abhi2011 |
next must
check indetation value |
| 19:10.05 |
abhi2011 |
c-indentation-style's value is
"stroustrup" |
| 19:10.08 |
abhi2011 |
Local in
buffer simulate.c; global value is nil |
| 19:12.04 |
brlcad |
that's
right |
| 19:12.57 |
abhi2011 |
it indents
c++ files correctly |
| 19:13.02 |
abhi2011 |
4
spaces |
| 19:13.25 |
brlcad |
now the big
one: M-x describe-variable c-style-alist |
| 19:13.58 |
brlcad |
pastebin the
whole thing or at least the section where "stroustrup"
begins |
| 19:14.27 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47064
10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/ (stix/
stix-v1.0.0/): rename to remove version |
| 19:15.54 |
abhi2011 |
http://bin.cakephp.org/view/1824577032 |
| 19:16.11 |
abhi2011 |
(c-basic-offset . 2) |
| 19:16.42 |
abhi2011 |
hmm no for
stroustrup its correct at 4 |
| 19:16.59 |
brlcad |
exactly,
something else is going on |
| 19:17.31 |
brlcad |
go to the
first function in simulate.c and press tab down each line starting
at the beginning of the function |
| 19:17.40 |
brlcad |
does it
indent the lines to 4 or leave them at 2 ? |
| 19:18.14 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47065
10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/
(dejavu-lgc/ dejavu-lgc-fonts-ttf-2.33/): rename to remove
version |
| 19:20.27 |
*** join/#brlcad merzo
(~merzo@137-237-132-95.pool.ukrtel.net) |
| 19:20.44 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47066
10/brlcad/trunk/doc/docbook/resources/other/fonts/ (dejavu-lgc/
stix/ truetype/dejavu-lgc/ truetype/stix/): restructure external
resources |
| 19:20.50 |
abhi2011 |
hmm no matter
what i insert : spaces or tab at the beginning of each line of the
1st function, its forcing it all back to 2 spaces
indent |
| 19:21.15 |
abhi2011 |
maybe i can
try running the formatting command from inside emacs |
| 19:21.26 |
abhi2011 |
as soon as I
know wat it is :P |
| 19:23.59 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47067
10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/: remove
unused dir |
| 19:24.23 |
brlcad |
abhi2011: if
tab isn't indenting to column 4, something else is still
overriding |
| 19:24.52 |
brlcad |
with mode C/l
and style stroustrup, indent shoudl be 4 |
| 19:25.04 |
brlcad |
do you have a
.emacs file? |
| 19:25.09 |
abhi2011 |
yes |
| 19:25.14 |
brlcad |
pastebin? |
| 19:26.13 |
abhi2011 |
http://bin.cakephp.org/view/994500422 |
| 19:26.20 |
starseeker |
never could get emacs to indent right... |
| 19:26.38 |
brlcad |
starseeker:
or vim :P |
| 19:27.10 |
starseeker |
brlcad: what
about using astyle? can it do what we need? That would avoid
requiring any specific editor (or version of that
editor...) |
| 19:27.27 |
starseeker |
http://astyle.sourceforge.net/ |
| 19:27.53 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47068
10/brlcad/trunk/doc/docbook/resources/other/offo/README: document
what version of offo this is |
| 19:28.19 |
brlcad |
starseeker:
are you offering to set up the style file? :) |
| 19:28.46 |
brlcad |
a tool is a
tool, you'd still have to spell out the style in detail to astyle
just like is being done here |
| 19:28.50 |
starseeker |
if it would
resolve all of this and give us a consistent, editor independent
way to proceed it would be worth it |
| 19:29.00 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47069
10/brlcad/trunk/doc/docbook/resources/other/offo/ (binary/
offo-hyphenation-binary-v2.0/): rename to remove
version |
| 19:29.01 |
starseeker |
nods - I can give it a go |
| 19:29.14 |
abhi2011 |
hmm there is
a .gnu-emacs file too |
| 19:29.16 |
brlcad |
from
indent.sh's pespective, it isn't an editor -- it might as well be
running astyle |
| 19:29.21 |
abhi2011 |
in
/etc/skel |
| 19:29.30 |
abhi2011 |
thats probaly
loaded |
| 19:29.35 |
brlcad |
abhi2011: but
is there a .gnu-emacs in your home dir? |
| 19:29.46 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47070
10/brlcad/trunk/doc/docbook/resources/other/offo/
(offo-hyphenation-source-v2.0/ source/): rename to remove
version |
| 19:29.49 |
abhi2011 |
no |
| 19:30.16 |
starseeker |
brlcad:
right. I just mean it's probably a better bet to get astyle doing
the exact same thing consistently than an editor (I'm clearly not
the only one having emacs troubles...) |
| 19:30.16 |
brlcad |
what's in the
one in skel? |
| 19:30.57 |
starseeker |
grabs astyle for a look while tbrowder2 is
organizing... |
| 19:31.11 |
brlcad |
starseeker: I
don't disagree, it's just actually at least a solid days work to
get the style spelled out correctly |
| 19:31.50 |
abhi2011 |
saw this in
the gnu-emacs file: http://bin.cakephp.org/view/89434569 |
| 19:31.59 |
starseeker |
<snort>
considering the number of times I barf all over ws/indenting, I'll
probably make up the time in fairly short order (or save you
cleaning it up, anyway :-P) |
| 19:32.06 |
brlcad |
and last I
checked, astyle had some significant bugs that made it parse either
macros or C++ files poorly .. been a while |
| 19:32.49 |
brlcad |
abhi2011:
that looks benign |
| 19:34.42 |
brlcad |
basically
saying that it "should" be a better bet to get something like
astyle going, but five years ago emacs was the only one that
actually got it right for both our C and C++ files by just saying
"use stroustrup style" plus a few pedantic tweaks |
| 19:35.37 |
starseeker |
nods - well, it looks like astyle has been developed since
then so perhaps worth anothe rlook |
| 19:35.44 |
brlcad |
if it does
better now, that'd be great but it'll beg for some careful
testing |
| 19:36.12 |
brlcad |
for example,
libbu is pretty clean right now -- should be able to run it on the
files there and basically have nothing change |
| 19:36.47 |
abhi2011 |
i wrote a *
c-basic-offset: 4 in the trailer :P |
| 19:36.53 |
abhi2011 |
it worked
now |
| 19:37.15 |
brlcad |
except maybe
for a few nicities that astyle can manage that emacs cannot, like
making sure there is curlies on the if clause there are curlies on
the else clause and vice-versa |
| 19:37.21 |
abhi2011 |
beginners can
get really silly :P |
| 19:37.33 |
brlcad |
abhi2011:
that's still *highly* suspect |
| 19:37.45 |
brlcad |
that means
it's not necessarily applying stroustrup style |
| 19:37.47 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47071
10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: rename dirs for
new structure |
| 19:37.52 |
abhi2011 |
hmm
yeah |
| 19:38.31 |
brlcad |
indent them
and commit, I can retest on my end to see if anything else
changes |
| 19:44.04 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47072 10/brlcad/trunk/doc/docbook/fop.xconf.in: make
more general - absolute file path for out-of-directory
build |
| 19:45.41 |
abhi2011 |
hmm, the
indenting seems to have a number of passes , it indented the
simulate.h correctly while doing these passes (i reloaded the file
while it was indenting) then in some subsequent pass it indented
back to 2 |
| 19:45.50 |
abhi2011 |
the
simulate.c file is still correct |
| 19:46.01 |
abhi2011 |
says its
Loading vc-svn... |
| 19:47.56 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47073 10/brlcad/trunk/doc/docbook/fop.xconf.in:
update font path for restucturing |
| 19:48.25 |
abhi2011 |
will do a
build then commit |
| 19:49.22 |
brlcad |
vc-svn is to
be expected, it knows the file is from svn |
| 19:49.57 |
brlcad |
abhi2011:
another thing you can try, use this .emacs file: http://brlcad.org/wiki/Emacs |
| 19:50.08 |
brlcad |
you'll have
to restart emacs in order for it to be loaded properly |
| 19:50.43 |
brlcad |
shouldn't
affect anything but it might turn off some hook that was being
registered by default |
| 19:51.57 |
abhi2011 |
ok, btw I
dont use emacs for normal editing, eclipse is kinda easier
:P |
| 19:54.58 |
CIA-48 |
BRL-CAD:
03brlcad * r47074 10/brlcad/trunk/src/libged/bot_flip.c: instead of
manually searching down path elements, just use bu_basename(). it
does exactly that and is the well defined reusable
interface. |
| 20:00.29 |
abhi2011 |
hmm that
.emacs didnt make a difference |
| 20:02.32 |
CIA-48 |
BRL-CAD:
03brlcad * r47075 10/brlcad/trunk/src/libged/ (bot_split.c
bot_sync.c): |
| 20:02.32 |
CIA-48 |
BRL-CAD: more
reuse of bu_baseame() instead of replicating the same strrchr()
code. |
| 20:02.32 |
CIA-48 |
BRL-CAD:
probably deserves a librt routine for getting a basename from a
path so we can |
| 20:02.32 |
CIA-48 |
BRL-CAD:
avoid dynamic memory but this is still a reuse improvement for
now. |
| 20:02.53 |
brlcad |
abhi2011:
well that's good to hear -- it shouldn't have made a difference
:) |
| 20:03.36 |
brlcad |
so there's
basically just something else going on that is perhaps specific to
emacs 23, which I don't have handy to test on |
| 20:04.18 |
abhi2011 |
brlcad: time
to upgrade :) |
| 20:05.29 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47076 10/brlcad/trunk/src/libged/simulate/
(simulate.c simulate.h): Corrected indenting by adding
c-basic-offset: 4 to file trailer and running indent.sh
only |
| 20:06.12 |
brlcad |
abhi2011: and
emacs is notorious for it's learning curve -- it takes a solid week
to get the basics fluent -- but definitely pays off in the long run
with the usability and programmability efficiencies it affords (at
least in my experience and everyone I've known that made it over
the learning curve) |
| 20:10.38 |
CIA-48 |
BRL-CAD:
03brlcad * r47077 10/brlcad/trunk/misc/batch-indent-region.el: set
the c-basic-offset forcibly in case there's something specific
about batch mode in emacs23 |
| 20:11.16 |
brlcad |
abhi2011: you
said it was working sometimes indenting correctly and other times
not? |
| 20:13.14 |
abhi2011 |
well no, i
reloaded the file in gedit while the indentation was going on, and
then i noticed that the lines in simulate.h only were indented by 4
spaces |
| 20:13.40 |
abhi2011 |
but when the
indent script finished, i reloaded again and it was 2 spaces
again |
| 20:14.13 |
abhi2011 |
that made me
think that maybe it was doing it correctly, but later on something
over rode the default indenting |
| 20:18.02 |
brlcad |
if you remove
the local variable (the line in the footer) and re-run indent.sh
after r47077, does it correctly indent to 4? |
| 20:30.27 |
abhi2011 |
brlcad: nope,
its back to 2 again |
| 20:31.52 |
*** join/#brlcad _pseudonym
(~tvanruite@yoshi.ece.utexas.edu) |
| 20:34.20 |
brlcad |
abhi2011: k,
researching |
| 20:34.40 |
abhi2011 |
brlcad:
thanks :) |
| 20:35.01 |
brlcad |
pretty
awesome.. fully svg website: http://emacsformacosx.com/ |
| 20:35.55 |
CIA-48 |
BRL-CAD:
03brlcad * r47078 10/brlcad/trunk/misc/batch-indent-region.el:
no-go, remove the basic offset since files are supposed to define
it via their style. |
| 20:38.07 |
n_reed |
brlcad: nice.
if i scale the page in my browser, i can see the fallback msg for
people with ie |
| 20:39.53 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47079 10/brlcad/trunk/doc/docbook/Makefile.am:
correct path for new offo hyphenation binary |
| 20:43.44 |
starseeker |
ah, phooey -
astyle --style=stroustrup isn't a no-op on vls.c |
| 20:44.03 |
brlcad |
abhi2011:
bah, 23.3 is working just fine here... |
| 20:44.51 |
brlcad |
starseeker:
stroustrup might be the same word but doesn't necessarily mean the
same thing to those two apps |
| 20:45.07 |
starseeker |
nods |
| 20:45.22 |
brlcad |
you'd hope it
meant something close to similar |
| 20:45.44 |
brlcad |
but to
astyle's credit, they have a lot more knobs to worry about when it
comes to formatting |
| 20:45.51 |
starseeker |
whitespace
didn't agree, other than that just a few bracket
placements |
| 20:46.07 |
starseeker |
will poke at it some more |
| 20:46.08 |
abhi2011 |
hmm |
| 20:46.25 |
brlcad |
starseeker:
like I said, it's going to take nearly a full day at best to get
right |
| 20:46.44 |
brlcad |
useful to
have, but it is a distraction |
| 20:46.44 |
starseeker |
nods |
| 20:47.09 |
starseeker |
so is trying
to figure out why emacs is being quirky :-P |
| 20:47.34 |
brlcad |
only because
I don't have access to his box to poke at it myself |
| 20:48.12 |
brlcad |
until I
updated, could only assume it was something 23-specific, but even
that isn't proving to be the case |
| 20:48.58 |
brlcad |
abhi2011: so
don't worry about style for now -- but ws.sh should still
work |
| 20:49.08 |
brlcad |
it uses
manual regexps |
| 20:49.25 |
brlcad |
if you're
going to use emacs, I can send you some lines to put in your .emacs
file that will make it work |
| 20:49.58 |
brlcad |
otherwise
you'll just have to follow convention on braces and internal
spacing |
| 20:51.18 |
abhi2011 |
brlcad: yes
please send me the lines, I ll be using emacs to format it ,
through the indent.sh script |
| 20:52.51 |
starseeker |
here's what
astyle is doing with vls.c by default: http://bzflag.bz/~starseeker/vls_astyle.c |
| 20:53.13 |
starseeker |
actually
doesn't look bad, at a glance... |
| 20:55.24 |
abhi2011 |
so is there
an easy way to draw a line in the mged window |
| 20:55.29 |
abhi2011 |
I need to
draw some normals |
| 20:55.40 |
starseeker |
some of the
stuff it indented, I'm almost wondering why it wasn't indented that
way initially... |
| 20:56.18 |
abhi2011 |
otherwise i
ll use a bot, with 1 triangle |
| 20:57.10 |
*** join/#brlcad mattS_
(cb3af1be@gateway/web/freenode/ip.203.58.241.190) |
| 20:59.02 |
mattS_ |
Hi there,
looking for some background info on the "revolve" project; is there
anyone here who knows a bit about it? Specifically, I'm looking
for some fundamental background details, as opposed to questions
about the current code. |
| 21:03.07 |
brlcad |
starseeker:
yeah, I'm seeing lots of undesirableness already |
| 21:03.24 |
brlcad |
at least,
rather drastic style changes |
| 21:03.41 |
mattS_ |
Or, for that
matter, anyone familiar with the projective geometry employed in
most any raytrace alg. in brlcad. |
| 21:03.45 |
brlcad |
eliminated
all tabs, unindented case statements |
| 21:03.48 |
brlcad |
mattS_:
howdy |
| 21:04.02 |
mattS_ |
brlcad:
Hi. |
| 21:04.27 |
brlcad |
mattS_: I saw
your thread with pacman87 earlier, sounds fantastic |
| 21:04.49 |
brlcad |
hopefully can
help, what are your questions? |
| 21:05.14 |
brlcad |
"<starseeker> some of the stuff it
indented, I'm almost wondering why it wasn't indented that way
initially" such as? |
| 21:05.24 |
mattS_ |
well, the
thing I'm struggling with at the moment is *why* everything
involves a hyperbolic transformation. |
| 21:05.57 |
brlcad |
you'll have
to point me at some code, what are you referring to
specifically? |
| 21:06.19 |
mattS_ |
Hm, hang
on... |
| 21:07.20 |
brlcad |
otherwise,
I'm not sure that's a true statement .. some of the primitives are
cubit, quadratic, quartic, ... |
| 21:07.30 |
mattS_ |
This is from
an old correspondence with pacman that I left hanging: |
| 21:07.33 |
mattS_ |
There are two
parts to a sweep: the sketch (2d surface outline), and the path (3d
spline). For a revolve, the path is a circle. My basic algorithm
for shot() is: 1. Calculate a transformation to make the sweep path
a straight line. 2. Apply the transformation to the ray. 3. Project
the transformed ray onto the sketch plane. 4. Find all intersection
points between the ray and the sketch. The ray is given in terms
of a point, vector |
| 21:08.08 |
mattS_ |
<PROTECTED> |
| 21:08.17 |
starseeker |
brlcad: line
57 - the bu_bomb |
| 21:08.28 |
mattS_ |
The sketch
uses 4 types of lines: line segments, circular arcs, bezier
splines, and nurbs. If the 3d spline is piece-wise define, then
the transformation will also be piecewise defined, and the
intersection check in (4) will have to check each ray piece with
each sketch piece. |
| 21:08.41 |
mattS_ |
For the
specific case of a revolve, the transformed ray will be a hyperbola
in 2d, so steps 1-3 can be condensed into finding the hyperbola
given the point and vector of the ray, and the point and vector
about which to revolve. |
| 21:09.01 |
mattS_ |
<end
quote> |
| 21:09.03 |
brlcad |
starseeker:
it didn't change the indent on that line, it removed the
tab |
| 21:09.20 |
starseeker |
ah |
| 21:09.30 |
starseeker |
tries with tabs turned on... |
| 21:09.37 |
mattS_ |
So, what I'm
missing is where the hyperbola comes from in the
transformation... |
| 21:09.55 |
mattS_ |
Or, more
specifically, what the transformation is, I guess. |
| 21:10.33 |
mattS_ |
I'm assuming
that something similar is done elsewhere in the software, hence the
approach. |
| 21:11.21 |
mattS_ |
But, in order
to attempt to finish things off, I need to "get" what it is that is
going on. |
| 21:12.01 |
brlcad |
mattS_:
actually, I don't believe that approach is taken elsewhere in the
software (because it doesn't need to) |
| 21:12.15 |
brlcad |
except for
maybe the hyperbola primitive ;) |
| 21:12.24 |
brlcad |
hyperboloid |
| 21:12.42 |
mattS_ |
OK, so if I
were to try something different, that wouldn't mess things up
elsewhere? |
| 21:13.00 |
brlcad |
which
actually may be where he's got the idea from -- he implemented the
hyperboloid of one sheet primitive |
| 21:13.20 |
mattS_ |
Yes, I saw
that. |
| 21:15.52 |
mattS_ |
OK, I'll try
putting something together then, and if I can get it working at
all, then I'll hope that somebody here with better programming
skills than me (I'm an engineer with a strong mathematics
background) can help me clean things up. |
| 21:16.28 |
mattS_ |
But I really
would like to understand the logic behind what he's
done... |
| 21:16.30 |
brlcad |
I'm not
exactly seeing how it's a hyperboloid myself, but then I've only
been thinking about it all of 2 minutes now |
| 21:16.51 |
mattS_ |
Yeah, that's
where I' |
| 21:16.59 |
brlcad |
things make
much more sense to me in code form ;) |
| 21:17.13 |
mattS_ |
I'm stuck.
The steps are all fairly straightforward, I just don't get why he's
done them. |
| 21:17.55 |
mattS_ |
OK, have a
look at
brlcad/trunk/src/librt/primitives/revolve/revolve.c |
| 21:18.20 |
brlcad |
mattS_: I
assume you have a general understanding of the transformations
being aplied to the ray in general, yes? |
| 21:18.42 |
mattS_ |
I thought I
did... |
| 21:18.46 |
brlcad |
even for
something as simple as the sphere, it's not just plugging in values
into the quadratic formulat |
| 21:19.03 |
mattS_ |
Yes, I know
that. |
| 21:19.13 |
brlcad |
it transforms
the sphere into an idealized unitized sphere at the origin, then
transforms the ray to match |
| 21:19.20 |
brlcad |
in order to
give stable numerics |
| 21:20.38 |
mattS_ |
Yup, based
around a mapping of the surface onto the plane. |
| 21:21.36 |
mattS_ |
So there
would be a transformation of the g_{ij} metric based
on... |
| 21:21.42 |
mattS_ |
some sort of
projection. |
| 21:21.44 |
mattS_ |
? |
| 21:22.30 |
mattS_ |
I'm assuming
it's this projection that leads to the hyperbolic transform, which
is where I guess my question lies. |
| 21:23.00 |
brlcad |
hm,
maybe |
| 21:23.18 |
brlcad |
that'd
actually be a great question to pose to the mailing list or to
d_rossberg if you can catch him in here |
| 21:23.34 |
mattS_ |
Do you know
where I could read up on this sort of stuff? |
| 21:23.36 |
brlcad |
he was
pacman's gsoc mentor so he's a lot more familiar with the project
and approach taken |
| 21:23.54 |
brlcad |
mailing list:
brlcad-devel on sourceforge |
| 21:24.02 |
mattS_ |
OK, I could
try emailing him as well... |
| 21:24.11 |
mattS_ |
do you know
if that's possible? |
| 21:24.37 |
brlcad |
that'd be the
mailing list |
| 21:24.56 |
mattS_ |
I'm new to
this; how do I access the mailing list? |
| 21:25.00 |
brlcad |
easiest way
to reach him and maybe get some input from other devs
too |
| 21:25.23 |
brlcad |
mailing lists
are all listed here: https://sourceforge.net/mail/?group_id=105292 |
| 21:25.36 |
brlcad |
you'll want
to subscribe to at least this one: https://lists.sourceforge.net/lists/listinfo/brlcad-devel |
| 21:26.16 |
brlcad |
a source code
reference that *may* be of reference that goes into extensive math
detail is the elliptical hyperboloid primitive |
| 21:26.31 |
brlcad |
it documents
the algorithm in nicedetail |
| 21:26.39 |
brlcad |
src/librt/primitives/ehy/ehy.c |
| 21:27.31 |
brlcad |
if pacman is
somehow approaching the surface as some sort of hyperboloid
transformation, he may be using similar techniques that would be
documented in the hyp primitive |
| 21:27.37 |
brlcad |
er ehy
primitive |
| 21:27.53 |
mattS_ |
Could
be. |
| 21:28.37 |
brlcad |
starseeker:
also note that case statements should be indented from switches, as
should case body lines |
| 21:29.47 |
mattS_ |
OK,
subscribed. I'll have a look at ehy.c, and post question(s) to the
mailing list. |
| 21:29.53 |
mattS_ |
Thanks for
the help! |
| 21:29.57 |
starseeker |
brlcad: I'm
emailing the astyle author - not immediately clear to me if he
supports the mixed spaces and tabs style we're using |
| 21:30.24 |
starseeker |
when I turn
on tabs, it replaces our 4 space indents with tabs too |
| 21:32.10 |
starseeker |
might be a
bug, more probably I'm doing something wrong |
| 21:32.14 |
mattS_ |
OK, back to
work for now... |
| 21:32.48 |
brlcad |
mattS_: a
much simpler algorithm explanation of a quadratic is in
src/librt/primitives/ell/ell.c |
| 21:33.03 |
brlcad |
pacman would
have also have gone over that as a foundation |
| 21:33.14 |
brlcad |
starseeker:
definitely does |
| 21:33.55 |
brlcad |
it's one of
only three common indent styles |
| 21:34.02 |
brlcad |
only
spaces |
| 21:34.03 |
brlcad |
only
tabs |
| 21:34.07 |
brlcad |
and
mixed |
| 21:34.43 |
brlcad |
then you have
the concept of indent levels and tabstops to get what you
want |
| 21:35.33 |
starseeker |
so far has yet to find a combination of options that doesn't
rejigger our whitespace |
| 21:39.08 |
*** part/#brlcad n_reed
(~nreed1@ool-457cb1ab.dyn.optonline.net) |
| 21:41.25 |
brlcad |
starseeker:
what about "-s4 -t" |
| 21:41.49 |
brlcad |
or -s4
-T4 |
| 21:42.26 |
starseeker |
shakes his head - neither one |
| 21:42.45 |
starseeker |
was thinking along those same lines - that's why I emailed
him, one of those ought to have worked |
| 21:44.04 |
starseeker |
brlcad: might
be able to add -S and -K to address some of the switch/case
concerns |
| 21:44.15 |
starseeker |
if we can get
the whitespace to behave |
| 21:44.37 |
brlcad |
on the
offchance it doesn't, I'd shelve the project for the time-being
since changing the indent is going to affect every file and is a
bit more of a major change |
| 21:44.47 |
starseeker |
nods |
| 21:45.04 |
starseeker |
yeah, I have
no desire to tangle with it |
| 21:45.21 |
starseeker |
just thought
I'd check and see if the problem could be solved once and for
all |
| 21:46.55 |
*** join/#brlcad merzo
(~merzo@137-237-132-95.pool.ukrtel.net) |
| 21:49.41 |
brlcad |
starseeker:
what about -s4 -t8 |
| 22:03.56 |
starseeker |
nope
:-/ |
| 22:05.29 |
starseeker |
author just
replied - "currently no way to do this with astyle" |
| 22:12.53 |
*** join/#brlcad pacman87
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 22:27.11 |
brlcad |
starseeker:
wow, that's surprising |
| 22:27.25 |
brlcad |
oh
well |
| 22:29.31 |
brlcad |
we could
update our style to the next best compromise, but it'd probably be
better to hold off for a planned minor |
| 23:02.14 |
starseeker |
nods - yeah, change on that scale'd be a minor for
sure |
| 23:02.50 |
starseeker |
grins - maybe we could plan it for the same time as the
copyright update - as long as we're touching so many files anyhow,
kill two birds with one stone |
| 23:04.13 |
starseeker |
ooo,
interesting: http://code.google.com/p/chibi-scheme/ |
| 23:27.52 |
*** join/#brlcad bhinesley
(~bhinesley@99.144.92.88) |
| 01:00.47 |
CIA-48 |
BRL-CAD:
03brlcad * r47080 10/brlcad/trunk/src/libged/simulate/
(simcollisionalgo.cpp simphysics.cpp): minor alignment |
| 02:39.49 |
CIA-48 |
BRL-CAD:
03starseeker * r47081 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt
resources/brlcad/brlcad-xml-catalog.xml.in): Accomidate new
directory locations |
| 03:05.51 |
CIA-48 |
BRL-CAD:
03brlcad * r47082 10/brlcad/trunk/src/librt/comb/comb.c: leave a
NOTE about the anamoly so it's documented and so someone doesn't
accidentally remove it later without understanding the
implications. |
| 03:18.36 |
CIA-48 |
BRL-CAD:
03brlcad * r47083 10/brlcad/trunk/src/libged/simulate/simulate.h:
include vmath. headers need to include the headers they
require. |
| 03:25.59 |
CIA-48 |
BRL-CAD:
03brlcad * r47084 10/brlcad/trunk/src/libged/simulate/ (4 files):
header cleanup. helps to identify redundant and avoid cyclic
includes. |
| 03:48.50 |
CIA-48 |
BRL-CAD:
03brlcad * r47085 10/brlcad/trunk/NEWS: |
| 03:48.50 |
CIA-48 |
BRL-CAD:
richard improved the g-vrml exporter so that it no longer halts
conversion on |
| 03:48.50 |
CIA-48 |
BRL-CAD: the
first bomb encountered, but now keeps track of the failure count
and |
| 03:48.50 |
CIA-48 |
BRL-CAD:
continues processing (similar to the other converters). this
feature was |
| 03:48.50 |
CIA-48 |
BRL-CAD:
requested by tim mallory and has been mentioned by other
users. |
| 04:00.57 |
CIA-48 |
BRL-CAD:
03brlcad * r47086 10/brlcad/trunk/NEWS: |
| 04:00.57 |
CIA-48 |
BRL-CAD: I
implemented a new g-dot exporter for exporting to the Graphviz DOT
format, |
| 04:00.57 |
CIA-48 |
BRL-CAD:
allowing for impressive visualization of geometry structure's DAG.
intended as |
| 04:00.57 |
CIA-48 |
BRL-CAD: a
plugin piece for the GCV/GS and new geometry editor (way) down the
road. |
| 04:07.54 |
CIA-48 |
BRL-CAD:
03brlcad * r47087 10/brlcad/trunk/NEWS: (log message
trimmed) |
| 04:07.55 |
CIA-48 |
BRL-CAD:
richard also added new options to the g-vrml exporter. to quote:
Significate |
| 04:07.55 |
CIA-48 |
BRL-CAD:
updates to the 'g-vrml' converter. Some logic bugs were fixed.
Triangulation was |
| 04:07.55 |
CIA-48 |
BRL-CAD:
changed to use 'nmg_triangulate_model' instead of its own function
which was |
| 04:07.55 |
CIA-48 |
BRL-CAD: very
limited. Added two new options. A '-b' option to perform a bot dump
(all |
| 04:07.55 |
CIA-48 |
BRL-CAD: csg
geometry is ignored) and '-e' to perform an evaluation or all
opjects |
| 04:07.56 |
CIA-48 |
BRL-CAD:
including bots. By default bots are dumped and csg evaluation is
perform |
| 06:39.32 |
*** join/#brlcad pacman87
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 06:40.34 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 06:40.53 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 09:42.16 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 11:01.31 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47088 10/brlcad/trunk/src/libged/simulate/simulate.c:
Added code to display the normals generated at each
manifold |
| 11:48.05 |
CIA-48 |
BRL-CAD:
03tbrowder2 * r47089 10/brlcad/trunk/HACKING: add comma |
| 12:24.16 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47090 10/brlcad/trunk/src/libged/simulate/simutils.c:
Number of functions hitting the roof, moving utility stuff out to
seperate file |
| 12:24.47 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47091 10/brlcad/trunk/src/libged/simulate/simutils.h:
Number of functions hitting the roof, moving utility stuff out to
separate file |
| 12:26.15 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47092 10/brlcad/trunk/src/libged/ (CMakeLists.txt
simulate/simulate.c): Modified simulate.c to use the the utils from
the utility files now and some related cmake changes |
| 13:20.42 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47093 10/brlcad/trunk/src/libged/simulate/
(simulate.c simutils.c simutils.h): Corrected some code related to
prefixing names |
| 13:46.48 |
CIA-48 |
BRL-CAD:
03bob1961 * r47094
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added
ArcherCore::redrawWho. |
| 13:52.04 |
CIA-48 |
BRL-CAD:
03bob1961 * r47095
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: |
| 13:52.04 |
CIA-48 |
BRL-CAD:
Added a tool panel to the attributes view panel and initially
populated it with |
| 13:52.04 |
CIA-48 |
BRL-CAD: a
set of component pick mode radiobuttons and a few bot related
buttons for |
| 13:52.04 |
CIA-48 |
BRL-CAD:
splitting, syncing and/or flipping bots. Added a radiobutton to the
attribute |
| 13:52.04 |
CIA-48 |
BRL-CAD:
view's toolbar and updated the images associated with the
buttons. |
| 13:56.28 |
CIA-48 |
BRL-CAD:
03bob1961 * r47096 10/brlcad/trunk/src/tclscripts/archer/images/ (5
files): Added tools.png and option_edit.png. Removed
option_tree.png. Updated option_text.png |
| 14:30.22 |
brlcad |
abhi2011: you
have a series of memory leaks in the simulate code |
| 14:31.11 |
brlcad |
if you know
how to run valgrind or some other memory debugger, it'd probably be
a good time to clean up memory management |
| 14:31.35 |
brlcad |
basically for
every bu_malloc/bu_calloc there needs to be a corresponding bu_free
call |
| 14:32.03 |
brlcad |
and for every
bu_vls, there needs to be a bu_vls_free() call |
| 14:32.36 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 14:37.06 |
CIA-48 |
BRL-CAD:
03brlcad * r47097 10/brlcad/trunk/NEWS: |
| 14:37.06 |
CIA-48 |
BRL-CAD: bob
added a new panel (and menu) of edit pick options to archer for
cleaning up |
| 14:37.06 |
CIA-48 |
BRL-CAD:
non-solid BoT geometry. initially populated it with a set of
component pick |
| 14:37.06 |
CIA-48 |
BRL-CAD: mode
radiobuttons and a few bot related buttons for splitting, syncing
and/or |
| 14:37.06 |
CIA-48 |
BRL-CAD:
flipping bots. |
| 14:40.59 |
brlcad |
starseeker:
browder's latest reminds me that cmake should be doing a test for
perl existence if it's not already, and disabling docs if it
doesn't exist (assuming perl is used in any fashion) |
| 15:13.13 |
starseeker |
brlcad: I
just this second (literally, within the minute ;-) got a pdf build
with the covers using just CMake and templates :-) |
| 15:13.43 |
starseeker |
let me commit
and we'll see what he thinks |
| 15:21.47 |
CIA-48 |
BRL-CAD:
03starseeker * r47098 10/brlcad/trunk/doc/docbook/ (3 files in 2
dirs): Add CMake logic to support the covers on the Tutorial
volumes. |
| 15:30.53 |
abhi2011 |
brlcad: yes,
i was trying pinpoint them using valgrind yesterday |
| 15:31.22 |
abhi2011 |
haven't quite
figured out which functions exactly yet |
| 15:34.13 |
abhi2011 |
any easier
tool that can be used to detect the region of code whr leaks are
happening |
| 15:40.51 |
CIA-48 |
BRL-CAD:
03brlcad * r47099 10/brlcad/trunk/NEWS: |
| 15:40.51 |
CIA-48 |
BRL-CAD: the
obj-g importer has gotten lots of love and attention from nick and
richard |
| 15:40.51 |
CIA-48 |
BRL-CAD: over
the past year. none of it was user-visible until very recently, so
begin |
| 15:40.51 |
CIA-48 |
BRL-CAD:
documenting the changes. bigger announcement will get added on the
next minor |
| 15:40.51 |
CIA-48 |
BRL-CAD: bump
summarizing the new importer. |
| 15:44.46 |
brlcad |
abhi2011:
valgrind is about as good as it gets :) |
| 15:45.08 |
brlcad |
it tells you
exactly where the allocation occurred that wasn't
released |
| 15:45.46 |
brlcad |
one place,
for example, is a function you wrote that adds a prefix -- it
creates a vls, prints into it, then returns the char * to that
vls |
| 15:46.04 |
CIA-48 |
BRL-CAD:
03starseeker * r47100 10/brlcad/trunk/doc/docbook/CMakeLists.txt:
handle brlcad.css |
| 15:46.06 |
brlcad |
once you
leave that function, you no longer have access to that vls, so you
cannot call bu_vls_free() to properly release the memory
allocated |
| 15:47.20 |
brlcad |
best is to
probably return the vls* instead of a char* so you can free it
later |
| 15:47.28 |
abhi2011 |
yes |
| 15:47.51 |
brlcad |
or just start
with a vls beforehand |
| 15:47.56 |
brlcad |
then you
don't even need that function |
| 15:47.57 |
abhi2011 |
was thinking
something might be wrong with that, due to the cha*
inside |
| 15:48.07 |
brlcad |
it's
basically a one-liner print |
| 15:48.30 |
abhi2011 |
yes, that
would be better |
| 15:48.44 |
abhi2011 |
the linked
lists should be ok though |
| 15:48.48 |
abhi2011 |
there is 1
big list |
| 15:48.50 |
starseeker |
woo
hoo! |
| 15:48.53 |
abhi2011 |
for the rigd
bodies |
| 15:49.01 |
abhi2011 |
and another
for the manifolds |
| 15:49.36 |
brlcad |
starseeker:
what was the last/current status on the exists command? is it in
there usable now, or not yet? |
| 15:49.37 |
abhi2011 |
i think the
last iteration , causes the manifold list to not be
freed |
| 15:50.03 |
starseeker |
um, iirc it's
usable but still very basic |
| 15:50.05 |
brlcad |
manual linked
list or a bu_list ? |
| 15:50.13 |
brlcad |
starseeker:
that's fine - but it's there? |
| 15:50.18 |
starseeker |
nods |
| 15:50.20 |
abhi2011 |
manual linked
list |
| 15:50.21 |
brlcad |
ok |
| 15:50.43 |
starseeker |
man page is a
lier at the moment because I was trying to outline all the eventual
planned features |
| 15:51.04 |
brlcad |
what was the
original command name from bob? was it test? |
| 15:51.07 |
starseeker |
*might* have
basic boolean operations going, but not sure how robust that'll
be |
| 15:51.18 |
starseeker |
urm |
| 15:51.29 |
starseeker |
don't recall
- I can ask him later today |
| 15:51.33 |
brlcad |
'urm' is a
funny command name :) |
| 15:51.38 |
starseeker |
hehe |
| 15:51.44 |
starseeker |
good alias
for help |
| 15:52.04 |
starseeker |
is at home at the moment - needed the flexible setup for
Apache FOP stuff |
| 15:52.27 |
brlcad |
nods, no worry -- just getting a commit message worded
right |
| 15:52.45 |
starseeker |
I think it's
in the commit history |
| 15:53.06 |
starseeker |
LOL -
"Ubuntu" - an African word meaning "Gentoo is too hard for
me". |
| 15:53.28 |
CIA-48 |
BRL-CAD:
03brlcad * r47101 10/brlcad/trunk/NEWS: |
| 15:53.28 |
CIA-48 |
BRL-CAD:
sparked by a new testing command added by bob parker, cliff stubbed
in initial |
| 15:53.29 |
CIA-48 |
BRL-CAD:
functionality for a new 'exists' command. this command is intended
to be a |
| 15:53.29 |
CIA-48 |
BRL-CAD:
corollary to the unix 'test' command with features for detecting
various |
| 15:53.29 |
CIA-48 |
BRL-CAD:
geometry conditions and expressions |
| 15:56.25 |
CIA-48 |
BRL-CAD:
03brlcad * r47102 10/brlcad/trunk/BUGS: make a note, exists
documentation claims more than is possible |
| 16:09.25 |
CIA-48 |
BRL-CAD:
03brlcad * r47103 10/brlcad/trunk/BUGS: bot bbox routine isn't
calculating the bbox correctly |
| 16:12.13 |
CIA-48 |
BRL-CAD:
03brlcad * r47104 10/brlcad/trunk/NEWS: by converting the
flex/bison logic to re2c/lemon, that effectively ported the obj-g
importer to windows since it can now be compiled without the
flex/bison dependency. |
| 16:17.31 |
CIA-48 |
BRL-CAD:
03brlcad * r47105 10/brlcad/trunk/NEWS: |
| 16:17.31 |
CIA-48 |
BRL-CAD: a
lot of fingers have been in the obj-g pie. document the new obj
parser |
| 16:17.31 |
CIA-48 |
BRL-CAD:
engine, originally written by mike tegtmeyer, integrated by richard
weiss, and |
| 16:17.31 |
CIA-48 |
BRL-CAD:
rewritten/translated by nicholas reed. the fact that it's a
structured parser |
| 16:17.31 |
CIA-48 |
BRL-CAD:
improves parsing robustness. |
| 16:18.29 |
brlcad |
whew.. only
218 to go |
| 16:22.23 |
CIA-48 |
BRL-CAD:
03brlcad * r47106 10/brlcad/trunk/NEWS: abhijit nandy (abhi2011)
fixed an mged crash where bad things happened if you killed an
object that was illuminated for editing. no longer crashes by
testing for NULL. |
| 16:23.22 |
abhi2011 |
naaaaece
:) |
| 16:25.17 |
CIA-48 |
BRL-CAD:
03brlcad * r47107 10/brlcad/trunk/NEWS: |
| 16:25.17 |
CIA-48 |
BRL-CAD:
abhijit nandy added a new 'simulate' command to mged/archer that
allows applying |
| 16:25.17 |
CIA-48 |
BRL-CAD:
physical interactions such as gravity, friction, and
linear/angular |
| 16:25.17 |
CIA-48 |
BRL-CAD:
accelleration forces. this is anticipatory documentation for the
next minor |
| 16:25.17 |
CIA-48 |
BRL-CAD:
release bump, but warrants a paragraph highlight with additional
detail. |
| 16:27.00 |
abhi2011 |
*acceleration |
| 16:56.35 |
CIA-48 |
BRL-CAD:
03brlcad * r47108 10/brlcad/trunk/src/librt/db_path.c: add common
footer, update style |
| 17:03.31 |
brlcad |
abhi2011:
heh, noted |
| 17:15.57 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47109 10/brlcad/trunk/src/libged/simulate/
(simulate.c simutils.c simutils.h): Got rid of the prefix_name
function which was hogging memory, directly using bu_vls
instead |
| 17:32.59 |
brlcad |
abhi2011:
heh, looks much better .. though you could have just named your vls
strings prefixed_reg_name or whatever instead of having a separate
pointer for the char* |
| 17:33.39 |
brlcad |
vls ARE
strings |
| 17:34.37 |
abhi2011 |
yeah I can do
that, since I only need the actual pointer when passing command
arguments |
| 17:34.44 |
abhi2011 |
the char* I
mean |
| 17:35.03 |
brlcad |
nods |
| 17:39.20 |
CIA-48 |
BRL-CAD:
03brlcad * r47110 10/brlcad/trunk/src/librt/ (CMakeLists.txt
Makefile.am parse.c): wow, duplicate file ignored (yet updated and
maintained) for many years that doesn't even belong in here any
longer. the struct parsing functions were migrated to libbu a long
time ago, so delete this remnant file. |
| 18:04.15 |
CIA-48 |
BRL-CAD:
03brlcad * r47111 10/brlcad/trunk/src/librt/uvpoints.cpp: add
missing footer, update style and ws |
| 18:08.21 |
CIA-48 |
BRL-CAD:
03brlcad * r47112 10/brlcad/trunk/src/librt/ (26 files): comment
cleanup, remove F U N C T I O N _ N A M E S written out in comments
since the reasoning becomes moot with the migration of comments
into headers and automatic doxygen parsing. |
| 18:09.32 |
CIA-48 |
BRL-CAD:
03brlcad * r47113 10/brlcad/trunk/src/librt/ (23 files): sweepting
ws style indent and comment cleanup |
| 18:56.23 |
*** join/#brlcad pacman87
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 19:30.12 |
CIA-48 |
BRL-CAD:
03bob1961 * r47114
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Minor tweak to
Archer::handleTreeSelect. |
| 19:35.23 |
``Erik |
brlcad: bob
is reporting issues with libged bot_* stuff on windows, it's doing
bu_basename() on db stuff, which uses / on all
platforms |
| 19:55.06 |
brlcad |
``Erik: ahhh,
yes... that's because bu_basename() was changed to NOT use / on all
platforms ... |
| 19:55.25 |
brlcad |
it was / ..
and my mod would have worked |
| 19:55.53 |
brlcad |
but I think
he changed it to the platform's dir separator a while back, forgot
about that |
| 19:55.56 |
brlcad |
I'll
revert |
| 20:01.45 |
``Erik |
bu_db_basename() ? |
| 20:04.34 |
CIA-48 |
BRL-CAD:
03bob1961 * r47115
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Tweaked
Archer::pluginLoader to accomodate spaces in a
filename. |
| 20:05.15 |
CIA-48 |
BRL-CAD:
03brlcad * r47116 10/brlcad/trunk/src/libged/ (bot_flip.c
bot_split.c bot_sync.c): revert the bu_basename() modification,
back to r47050, since that function was updated to not only handle
'/' but whatever the platform separator is. sorry bob. |
| 20:11.48 |
starseeker |
or just
db_basename, since it's for .g files? |
| 20:23.27 |
``Erik |
<-- fond
of the library prefix munge |
| 20:39.10 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47117 10/brlcad/trunk/src/libged/simulate/
(simcollisionalgo.cpp simulate.c simulate.h simutils.c): Converted
some strings to vls |
| 21:00.45 |
*** join/#brlcad mattS_
(cb3af1be@gateway/web/freenode/ip.203.58.241.190) |
| 21:05.26 |
brlcad |
hm, it might
be as simple as keeping support for '/' in basename |
| 21:06.21 |
brlcad |
it would
basically mean we wouldn't allow windows files with a / in the file
name, which I don't think windows allows either |
| 21:29.40 |
``Erik |
dos used / as
a mandatory switch, "dir/w" |
| 21:29.47 |
``Erik |
d'no about nt
variants |
| 21:43.26 |
brlcad |
sure, but
still wouldn't be in a path |
| 21:44.06 |
brlcad |
this is
isolated to places that would call basename()/dirname() feeding a
path |
| 21:45.38 |
brlcad |
given we're
not implementing dir with /switches, should be a safe
assumption |
| 22:22.39 |
CIA-48 |
BRL-CAD:
03brlcad * r47118 10/brlcad/trunk/src/libbu/test_basename.c: add a
few more tests to make sure we get reasonable (dos-style) drive
prefix behavior |
| 22:36.10 |
CIA-48 |
BRL-CAD:
03brlcad * r47119 10/brlcad/trunk/ (include/bu.h
src/libbu/basename.c): (log message trimmed) |
| 22:36.10 |
CIA-48 |
BRL-CAD:
enhanced bu_basename(), now with more slashy flavor. always
interprets '/' as a |
| 22:36.10 |
CIA-48 |
BRL-CAD: path
separator in addition to whatever the native separator is so that
we can |
| 22:36.10 |
CIA-48 |
BRL-CAD: use
libbu for geometry paths as well as filesystem paths. also added a
quick |
| 22:36.11 |
CIA-48 |
BRL-CAD:
check to make sure drive paths are removed if this is windows so we
don't get |
| 22:36.11 |
CIA-48 |
BRL-CAD: the
drive letter returned as a path. also started to add code to
recognize |
| 22:36.12 |
CIA-48 |
BRL-CAD:
escaped paths but it turns out that the system basename() (bsd/mac)
doesn't |
| 22:36.15 |
brlcad |
there, now it
should work |
| 22:38.50 |
CIA-48 |
BRL-CAD:
03brlcad * r47120 10/brlcad/trunk/src/libged/ (bot_flip.c
bot_split.c bot_sync.c): unrevert the r47116 revert of r47050,
making the routines use bu_basename() for path trimming instead of
rolling custom. does that fix it, bob? |
| 23:24.00 |
starseeker |
growls... the hacked up hv3 tcl/tk html browsers we've been
using aren't going to cut it when we add .css files into the mix,
looks like |
| 23:24.16 |
starseeker |
should just get the full browser
working... |
| 23:24.48 |
brlcad |
or a Qt HTML
window/app for down the road |
| 23:25.11 |
starseeker |
eventually
sure, but right now we don't want to add Qt as a requirement for
help... |
| 23:25.42 |
starseeker |
has had the full hv browser running in the past - thought I
could "streamline" it down to just what we need but apparently
that's not so simple |
| 23:25.51 |
CIA-48 |
BRL-CAD:
03brlcad * r47121 10/brlcad/trunk/src/libbu/basename.c: simplify,
just call bu_strdup() like bu_dirname() does |
| 23:26.59 |
starseeker |
I suppose
there's no particular reason *not* to have http
support... |
| 23:28.49 |
starseeker |
oh, well - I
guess this is a good time to move the hv3 code back into src/other
too |
| 23:57.39 |
CIA-48 |
BRL-CAD:
03brlcad * r47122 10/brlcad/trunk/src/libbu/test_basename.c: couple
more test cases, make sure escaping behavior works as expected
(more important on windows where it becomes a dir
separator). |
| 00:02.12 |
CIA-48 |
BRL-CAD:
03brlcad * r47123 10/brlcad/trunk/src/libbu/ (Makefile.am
test_dirname.c): add in a new unit test for bu_dirname() similar to
bu_basename(). |
| 00:03.40 |
CIA-48 |
BRL-CAD:
03brlcad * r47124 10/brlcad/trunk/src/libbu/CMakeLists.txt: enable
logic for new test_dirname binary. also removing what should be
unnecessary link libraries (htond doesn't use libpng) and comment
on bad MSVC platform toggle. |
| 00:06.07 |
CIA-48 |
BRL-CAD:
03brlcad * r47125 10/brlcad/trunk/src/libbu/dirname.c: |
| 00:06.07 |
CIA-48 |
BRL-CAD:
similar to bu_basename(), make bu_dirname() also always treat
unix-style '/' |
| 00:06.07 |
CIA-48 |
BRL-CAD:
forward slashes as path separators even on platforms that use a
different |
| 00:06.07 |
CIA-48 |
BRL-CAD:
directory separator (windows). that will make the function continue
to be |
| 00:06.07 |
CIA-48 |
BRL-CAD:
useful for geometry paths, which are always url/unix-style. fixed a
bug |
| 00:06.08 |
CIA-48 |
BRL-CAD:
detected during unit testing while at it, collapsing sequences of
trailing path |
| 00:06.09 |
CIA-48 |
BRL-CAD:
separators to just one. |
| 00:18.30 |
CIA-48 |
BRL-CAD:
03brlcad * r47126 10/brlcad/trunk/include/bu.h: document the new
bu_dirname() particulars as well as cleaning up the wording on
bu_basename() too to be consistent. |
| 00:19.23 |
CIA-48 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3174 10/wiki/User:Abhijit: /* Log */ |
| 00:20.54 |
CIA-48 |
BRL-CAD:
03brlcad * r47127 10/brlcad/trunk/include/bu.h: how about an
informative parameter name |
| 00:21.14 |
*** join/#brlcad pacman87
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 00:25.09 |
CIA-48 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3175 10/wiki/User:Abhijit: /* Updated Development Time line(Sept
14th) */ |
| 00:26.03 |
CIA-48 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3176 10/wiki/User:Abhijit: /* Updated Development Time line(Sept
14th) */ |
| 00:27.32 |
CIA-48 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3177 10/wiki/User:Abhijit: /* Detailed project description
*/ |
| 00:30.22 |
abhi2011 |
Normals and
contact manifolds getting drawn ok now : http://postimage.org/image/2dqu5964k/full/ |
| 00:30.42 |
CIA-48 |
BRL-CAD:
03brlcad * r47128 10/brlcad/trunk/NEWS: minor code, but technically
user-visible -- archer will now load plugins with spaces in the
name. |
| 00:30.54 |
abhi2011 |
These are
still bullet output, have to convert to raytrace yet |
| 01:01.26 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47129 10/brlcad/trunk/src/libged/simulate/ (simrt.c
simrt.h): Began implementing a raytrace based manifold
generator |
| 01:07.34 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47130 10/brlcad/trunk/src/libged/ (CMakeLists.txt
simulate/simulate.c simulate/simulate.h): Related changes to
simulate command to use the raytraced manifolds |
| 01:33.59 |
brlcad |
cool |
| 02:12.36 |
*** join/#brlcad mattS_
(cb3af1be@gateway/web/freenode/ip.203.58.241.190) |
| 02:48.49 |
CIA-48 |
BRL-CAD:
03brlcad * r47131 10/brlcad/trunk/NEWS: |
| 02:48.49 |
CIA-48 |
BRL-CAD:
richard fixed a bug which caused a seg fault if a loopuse contained
a single |
| 02:48.49 |
CIA-48 |
BRL-CAD:
vertex instead of an edgeuse. presumably this improves a tess case
where |
| 02:48.49 |
CIA-48 |
BRL-CAD:
invalid geometry ends up in a loopuse that would later result in a
bomb or |
| 02:48.49 |
CIA-48 |
BRL-CAD:
crash. |
| 03:10.26 |
CIA-48 |
BRL-CAD:
03brlcad * r47132 10/brlcad/trunk/TODO: need to rerun previous
conversion comparison to see how things have changed with all of
the recent NMG changes |
| 03:23.16 |
starseeker |
hmm:
http://www.xmailserver.org/xdiff-lib.html |
| 03:29.28 |
starseeker |
http://code.google.com/p/dtl-cpp/ |
| 03:32.50 |
CIA-48 |
BRL-CAD:
03brlcad * r47133 10/brlcad/trunk/TODO: need to test the new edit
command. |
| 04:13.55 |
CIA-48 |
BRL-CAD:
03brlcad * r47134 10/brlcad/trunk/NEWS: richard fixed a bug in
mged's mater command (in r45415) where the inheritance could not be
changed unless the color is changed at the same. should affect
archer too, but only tested with mged. |
| 04:16.56 |
CIA-48 |
BRL-CAD:
03brlcad * r47135 10/brlcad/trunk/NEWS: |
| 04:16.56 |
CIA-48 |
BRL-CAD:
richard also committed a fix to a bug in the rm/erase command
affecting at least |
| 04:16.56 |
CIA-48 |
BRL-CAD: mged
and presumably archer too. A segmentation fault would occur when a
region |
| 04:16.56 |
CIA-48 |
BRL-CAD: is
displayed in 'mged' and the 'rm' command is used to remove a member
of the |
| 04:16.56 |
CIA-48 |
BRL-CAD:
displayed region and the member occurs in the region more than
once. |
| 04:28.10 |
CIA-48 |
BRL-CAD:
03brlcad * r47136 10/brlcad/trunk/src/libgcv/bottess.c: there's no
need to call rt_bot_ifree2() directly. create an rt_db_internal
with the right juju and we can call rt_bot_ifree() which will call
ifree2 for us. no more wet shoes. |
| 04:29.24 |
CIA-48 |
BRL-CAD:
03brlcad * r47137 10/brlcad/trunk/src/libgcv/ (bottess.c
region_end_mc.c): ws |
| 04:34.32 |
CIA-48 |
BRL-CAD:
03brlcad * r47138 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
And lead us not into temptation, but deliver us from evil. rename
rt_bot_ifree2() to bot_ifree2() so it's not considered public api.
in fact, mark it hidden too. |
| 04:38.22 |
CIA-48 |
BRL-CAD:
03brlcad * r47139 10/brlcad/trunk/NEWS: |
| 04:38.23 |
CIA-48 |
BRL-CAD:
richard made a slew of changes to improve NMG processing which have
been |
| 04:38.23 |
CIA-48 |
BRL-CAD:
enabled, but not yet independently validated so schedule their
announcement in |
| 04:38.23 |
CIA-48 |
BRL-CAD: the
next minor bump. one specific example is r45358 where he improved
the |
| 04:38.23 |
CIA-48 |
BRL-CAD:
success of boolean ops when there coplanar faces. this affects
mged |
| 04:38.23 |
CIA-48 |
BRL-CAD:
tessellation commands (facetize, E, ev) as well as most of our
exporters. |
| 04:40.22 |
CIA-48 |
BRL-CAD:
03brlcad * r47140 10/brlcad/trunk/NEWS: another category of changes
richard made centered around improving boolean evaluation and NMG
processing performance. don't yet have specific numbers, but
document the changes anyways (see r45319) |
| 04:46.01 |
CIA-48 |
BRL-CAD:
03brlcad * r47141 10/brlcad/trunk/src/librt/CMakeLists.txt: is this
why autotools is still catching more errors that cmake build?
remove the -Wno-error flag from non-static compilation. |
| 04:52.58 |
CIA-48 |
BRL-CAD:
03brlcad * r47142 10/brlcad/trunk/NEWS: cliff improved the
mged/archer 'attr' command to only halt on read-only databases if
it's a write attr action. allow get/list/show |
| 04:55.36 |
CIA-48 |
BRL-CAD:
03brlcad * r47143 10/brlcad/trunk/NEWS: cliff improved the
mged/archer 'attr' command to only halt on read-only databases if
it's a write attr action. allow get/list/show. credited to the .0
release. |
| 04:58.04 |
CIA-48 |
BRL-CAD:
03brlcad * r47144 10/brlcad/trunk/NEWS: |
| 04:58.04 |
CIA-48 |
BRL-CAD: bob
worked around some glitches with the windows gl display manager by
copying |
| 04:58.04 |
CIA-48 |
BRL-CAD:
display list data into a GLdouble array before sending to opengl
(r44645) |
| 04:58.04 |
CIA-48 |
BRL-CAD:
remedying strange behavior on windows where arrows were sometimes
being drawn |
| 04:58.04 |
CIA-48 |
BRL-CAD:
incorrectly. sounds like corrupt memory, but this works around the
issue |
| 04:58.05 |
CIA-48 |
BRL-CAD:
successfull. |
| 05:07.26 |
CIA-48 |
BRL-CAD:
03brlcad * r47145 10/brlcad/trunk/NEWS: keith improved the step-g
importer fixing some issues importing ellipse and circle conics.
another user-visible change that didn't make the .0 release
notes. |
| 05:09.55 |
CIA-48 |
BRL-CAD:
03brlcad * r47146 10/brlcad/trunk/NEWS: keith also improved the
step-g importer presumably preventing it from crashing or otherwise
doing bad things where it was overrunning an array during cubit
interpolation. another undocumented change to the .0
release. |
| 05:12.24 |
brlcad |
starseeker:
r44618 looks no good. if we don't have a void* then the void* test
is flawed... that's kinda important to just gloss over it with a
conditional.. |
| 05:16.34 |
brlcad |
starseeker:
hm, looks like that was later fixed? (apologies, reading commits in
reverse) |
| 05:17.47 |
brlcad |
i think what
triggered caution is that I think I've seen the fallback case where
it spits out "CMAKE_SIZEOF_VOID_P is not defined - assuming 32 bit
platform" and that just shouldn't happen for any platform less than
two decades old |
| 05:24.49 |
brlcad |
wasn't even
you that made the original patch .. so that's probably a cue that
my eyes are getting tired and need a walkabout break |
| 05:32.53 |
CIA-48 |
BRL-CAD:
03brlcad * r47147
10/brlcad/trunk/misc/CMake/BRLCAD_CompilerFlags.cmake: ffast-math
is never a good option for our code because the math that results
is extremely unstable an unreliable for useful
calculations. |
| 05:58.43 |
CIA-48 |
BRL-CAD:
03brlcad * r47148 10/brlcad/trunk/src/librt/uvpoints.cpp: big
cleanup. remove 'using namespace std' abomination, quell warnings,
fix shadowings, and more. |
| 06:03.35 |
*** join/#brlcad pacman87
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 06:08.33 |
brlcad |
pacman87: you
still on the dev mailing list? question posed by the guy you
referred in here about how exactly the ray path is
hyperbolic |
| 06:09.26 |
brlcad |
starseeker:
better question, r44413 .. curious that black is not being written
out. the default color is actually white, so does that mean I
can't create black objects? :) |
| 06:10.16 |
brlcad |
starseeker:
and AGAIN.. I see that you noticed the err in r44414! .. okay, I'll
stop :) |
| 06:11.11 |
brlcad |
needs to learn that there's probably a follow-up commit that
addresses the red flag |
| 06:35.07 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 06:40.43 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 08:25.26 |
pacman87 |
brlcad: it
looks like d_rossberg has answered it fairly well, were there any
specific points that still need to be addressed? |
| 08:27.30 |
pacman87 |
http://en.wikipedia.org/wiki/Skew_lines#Skew_lines_and_ruled_surfaces
might also be useful |
| 10:47.33 |
abhi2011 |
is it
possible to specify a rectangular grid of rays to be shot in a
specific direction |
| 10:47.58 |
abhi2011 |
rather than
shooting the rays one by one, translating the direction across and
up/down |
| 11:23.30 |
*** join/#brlcad pawleeq
(~pawleeq@212-96-188-229.cust.selfnet.cz) |
| 11:23.46 |
pawleeq |
hello |
| 11:24.58 |
pawleeq |
I am building
current svn check and make ended with errors: http://pastebin.com/jrejqagB |
| 11:49.16 |
CIA-48 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3178 10/wiki/User:Abhijit: /* Log */ |
| 12:03.42 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47149 10/brlcad/trunk/src/libged/simulate/ (simrt.c
simrt.h simutils.c simutils.h): Added initial code to create the
AABB overlap regions |
| 12:33.31 |
d_rossberg |
pawleeq:
Makefile.am is out of date in src/tclscripts/archer/images but
CMake should work |
| 12:39.33 |
pawleeq |
d_rossberg: i
tried cmake brlcad, but cmake also failed, result is here: http://pastebin.com/GPfiMqXs |
| 12:46.32 |
d_rossberg |
i may only
guess what's wrong: sometimes cmake needs to run twice; i've no
*nix brl-cad at hand to test it |
| 12:56.24 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47150 10/brlcad/trunk/src/libged/simulate/ (simrt.c
simrt.h simulate.c simutils.c): Finished creating the AABB overlap
regions |
| 13:37.23 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47151 10/brlcad/trunk/src/libged/simulate/ (5 files):
Merged bullet and rt manifold info in 1 structure, easier that
way |
| 13:49.37 |
CIA-48 |
BRL-CAD:
03n_reed * r47152
10/brlcad/trunk/src/other/step/src/express/expparse_new.y: working
through type-mismatch compile errors |
| 13:54.19 |
abhi2011 |
pawleeq: you
need to install ITK |
| 13:54.34 |
abhi2011 |
thats the
object oriented extension to tcl/tk |
| 13:55.02 |
abhi2011 |
then the
ITK_LIBRARY path will be set to the .so files which implements that
library |
| 13:56.08 |
brlcad |
except we
bundle itk so something else seems to be going wrong, unless it's
using an incompatible system tcl/tk |
| 13:56.17 |
starseeker |
binks - that shouldn't happen... |
| 13:56.35 |
starseeker |
pawleeq: can
you post your configure log? |
| 13:57.39 |
starseeker |
we really
really really really need to get package require Itk working from
bwish and friends |
| 13:58.03 |
abhi2011 |
hmm then
maybe he is not building itk during make |
| 13:58.20 |
starseeker |
no, it's not
finding the ITK library |
| 13:58.39 |
starseeker |
but it must
be finding the Itk package itself, othewise it should have been
turned on |
| 13:59.53 |
starseeker |
my best guess
is that line 339 in src/other/CMakeLists.txt isn't
succeeding |
| 14:00.55 |
starseeker |
pawleeq:
where is the libitk.so on your system? |
| 14:01.29 |
starseeker |
if they stuck
it in a weird place, that would explain the ITK_LIBRARY
issue |
| 14:02.27 |
starseeker |
we're not set
up for it right now, but I suppose what I should be doing in those
special cases is to build the local one in the case of ITCL_LIBRARY
or ITK_LIBRARY not being found |
| 14:03.13 |
starseeker |
it breaks the
paradigm being used for all the other Tcl/Tk packages, but it looks
like I may not have a choice since the ITK_LIBRARY issue has
appeared in the wild |
| 14:03.34 |
starseeker |
pawleeq: if
you want to work around it, you can just feed cmake
-DBRLCAD_BUNDLED_LIBS=Bundled |
| 14:04.36 |
CIA-48 |
BRL-CAD:
03erikgreenwald * r47153
10/brlcad/trunk/src/libgcv/wfobj/tri_face.c: common.h needs to come
before bu.h |
| 14:14.24 |
CIA-48 |
BRL-CAD:
03starseeker * r47154 10/brlcad/trunk/src/other/CMakeLists.txt:
Make a stab at turning Itcl/Itk back on if we can't find the
libraries. |
| 14:14.38 |
starseeker |
ew |
| 14:14.44 |
starseeker |
pawleeq: see
if that helps... |
| 14:16.36 |
starseeker |
might end up
having to build both Itcl and Itk if ITK_LIBRARY doesn't show
up... |
| 14:39.14 |
pawleeq |
starseeker: I
will give it try and report back, but right now I am babysittter
rather than brlcad enthusiast :) |
| 14:46.05 |
CIA-48 |
BRL-CAD:
03erikgreenwald * r47155 10/brlcad/trunk/ (NEWS
src/tclscripts/mged/reid.tcl): return last assigned id value from
reid command |
| 15:28.16 |
CIA-48 |
BRL-CAD:
03erikgreenwald * r47156 10/brlcad/trunk/ (NEWS
src/tclscripts/mged/reid.tcl): Added a -n <val> arg to reid
for incrementing by a specified value. |
| 15:48.08 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 16:56.53 |
CIA-48 |
BRL-CAD:
03n_reed * r47157 10/brlcad/trunk/src/other/step/src/express/
(CMakeLists.txt expparse_new.y): got lemon source compiling; not
yet operational |
| 17:04.51 |
pawleeq |
starseeker:
so the workaround with cmake -DBRLCAD_BUNDLED_LIBS=Bundled failed
this way: http://pastebin.com/VmDaFq7L |
| 17:09.13 |
pawleeq |
starseeker:
pastebin does not accept my, so I uploaded it here:
www.pawleeq.com/config.log |
| 18:10.43 |
abhi2011 |
whats is the
use of the ap.a_uptr = (genptr_t)a_tab.attrib; while initializing
the struct application ap; in nirt |
| 18:10.57 |
abhi2011 |
is it used to
specifiy some special attributes |
| 18:11.25 |
abhi2011 |
was wondering
if I can NOT set it and just use the rest of the application
structure |
| 18:26.33 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47158 10/brlcad/trunk/src/libged/simulate/ (simrt.c
simrt.h simulate.c): Added initial code to shoot rays during
manifold generation |
| 18:30.06 |
*** join/#brlcad pacman87
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 19:36.54 |
*** join/#brlcad pacman87
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 21:11.06 |
CIA-48 |
BRL-CAD:
03abhi2011 * r47159 10/brlcad/trunk/src/libged/simulate/ (simrt.c
simrt.h simutils.c): Trying to get the overlap points by shooting
raysat the AABB overlap region |
| 21:39.03 |
abhi2011 |
that is
strange, just compiled bullet to use double precision , and bullet
compiled fine |
| 21:39.12 |
abhi2011 |
the demos of
bullet are also running |
| 21:39.17 |
abhi2011 |
however mged
crashes |
| 21:39.26 |
abhi2011 |
inside the
bullet related code |
| 21:39.44 |
abhi2011 |
specifically
when allocating memory for a particular bullet object |
| 21:41.08 |
abhi2011 |
http://bin.cakephp.org/view/1090178448 |
| 21:41.24 |
abhi2011 |
the crash
seems to be in malloc |
| 21:52.03 |
abhi2011 |
hmm tried a
clean build but that didnt work either, I ll switch bullet back to
single precision, maybe malloc is unable to allocate 64
bits |
| 21:52.19 |
abhi2011 |
though I dont
know how the demos work then |
| 22:09.23 |
abhi2011 |
now it works
fine again after switching back to single precision! |
| 22:36.54 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 23:53.56 |
*** join/#brlcad pacman87
(~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) |
| 01:23.21 |
*** join/#brlcad Otto_
(~Otto@cpe-24-210-25-11.columbus.res.rr.com) |
| 01:26.38 |
*** part/#brlcad Otto_
(~Otto@cpe-24-210-25-11.columbus.res.rr.com) |
| 02:16.29 |
CIA-48 |
BRL-CAD:
03brlcad * r47299 10/brlcad/trunk/ (configure.ac
src/other/Makefile.am): turn off our libpng subbuild entirely by
default, even for enable-all, just so we're closer to a clean
autotool distcheck for release |
| 02:40.07 |
CIA-48 |
BRL-CAD:
03brlcad * r47300 10/brlcad/trunk/doc/docbook/Makefile.am: typo,
should be CatalogManager.properties |
| 07:26.20 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 12:09.45 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 14:56.06 |
CIA-48 |
BRL-CAD:
03brlcad * r47301 10/brlcad/trunk/doc/docbook/Makefile.am: this
looks like the last problem remaining with the autotools distcheck.
there are two files being generated in resources/brlcad that do not
belong in the dist that were causing a problem. have to
itemize. |
| 15:01.07 |
CIA-48 |
BRL-CAD:
03brlcad * r47302 10/brlcad/trunk/doc/docbook/Makefile.am:
uncomment, was just for debugging |
| 15:01.45 |
brlcad |
abhi2011:
how's it going? been a while since checked in on
progress |
| 15:01.52 |
brlcad |
been watching
the commits |
| 15:03.26 |
abhi2011 |
well brl-cad
I am just putting up some pictures in web log explaining my work
so far :) |
| 15:03.39 |
brlcad |
excellent
:) |
| 15:03.51 |
abhi2011 |
so basically
I have inserted a custom algorithm for collision detection between
2 boxes |
| 15:04.09 |
abhi2011 |
and this
algorithm inserts manifold points |
| 15:04.13 |
CIA-48 |
BRL-CAD:
03erikgreenwald * r47303 10/brlcad/trunk/src/libgcv/bottess.c: fix
bad comparison in 5 face split |
| 15:04.24 |
abhi2011 |
generated by
raytracing in the overlap region(aabb overlap region) |
| 15:04.51 |
abhi2011 |
however when
I do this I am not able to make a smaller box lie still on a
thinner but bigger one |
| 15:05.31 |
abhi2011 |
so I am
trying to figure out why bullet is not keeping the smaller box
stable, even though I insert manifold points exactly as bullet
does |
| 15:06.03 |
abhi2011 |
it involves
investigating the dynamics part of bullet |
| 15:06.18 |
abhi2011 |
which is not
the easiest thing I have done so far :P |
| 15:06.37 |
abhi2011 |
so I have
posted the issue in the bullet forums |
| 15:06.40 |
brlcad |
lie
still? |
| 15:06.45 |
abhi2011 |
yes |
| 15:06.56 |
abhi2011 |
if a box is
lying on a plane |
| 15:07.04 |
abhi2011 |
it will stay
as it is |
| 15:07.21 |
abhi2011 |
that is what
I meant by lying still...stationery |
| 15:07.22 |
brlcad |
because the
bb's don't overlap |
| 15:07.44 |
abhi2011 |
well,
actually they overlap very slightly |
| 15:07.51 |
abhi2011 |
about 0.00001
m |
| 15:07.53 |
brlcad |
k |
| 15:08.06 |
abhi2011 |
thats allowed
for smooth physics |
| 15:08.15 |
brlcad |
so that
creates a contact interface, presumably |
| 15:08.16 |
abhi2011 |
some
interpenetration is necesssary |
| 15:08.34 |
abhi2011 |
yes
correct |
| 15:08.59 |
brlcad |
so can you
explain the general algorithm to me? or is it written down
somewhere? |
| 15:09.08 |
brlcad |
given two
arbitrary bb's |
| 15:09.11 |
abhi2011 |
yes sure, its
quite simple |
| 15:09.12 |
abhi2011 |
yes |
| 15:09.56 |
abhi2011 |
so given 2
bounding boxes I calculate where they overlap |
| 15:10.06 |
abhi2011 |
that will
also be a cuboidal volume |
| 15:10.10 |
brlcad |
giving some
smaller intersection box |
| 15:10.20 |
brlcad |
smaller or
equal, rather |
| 15:10.55 |
abhi2011 |
yes thats
right |
| 15:11.25 |
abhi2011 |
the volume
where the 2 aabbs intersect will of course be smaller than the 2
aabbs we are intersecting |
| 15:11.34 |
abhi2011 |
or equal of
they exactly overlap |
| 15:11.43 |
abhi2011 |
*if
they |
| 15:11.47 |
brlcad |
nods |
| 15:12.30 |
abhi2011 |
so there is a
function called get_overlap() in simrt.c which does
this |
| 15:12.55 |
abhi2011 |
so once i
have the overlap volume |
| 15:13.07 |
abhi2011 |
then I shoot
rays along the x axis |
| 15:13.32 |
abhi2011 |
specifically
from the minimum X towards the maximum X |
| 15:13.47 |
abhi2011 |
so if the
overlap box is from -1,-1,-1 to 1,1,1 |
| 15:13.58 |
abhi2011 |
then I shoot
rays from -1 to 1 parallel to x axis |
| 15:14.13 |
abhi2011 |
the rays will
be perpendicular to the yz plane |
| 15:14.17 |
brlcad |
that will
likely be insufficient (but can be fixed later) |
| 15:14.25 |
brlcad |
shooting down
just one axis |
| 15:14.37 |
abhi2011 |
yes I intend
to shoot along the y and z too |
| 15:14.53 |
abhi2011 |
but for the
simple case that I am testing with |
| 15:15.00 |
abhi2011 |
its
sufficient |
| 15:15.07 |
brlcad |
okay, though
.. so you shoot a grid of rays (presumably with one_hit turned
off?) |
| 15:15.20 |
abhi2011 |
so
Iyes |
| 15:15.22 |
abhi2011 |
*yes |
| 15:15.36 |
brlcad |
so then you
have partitions |
| 15:15.38 |
abhi2011 |
so the rays
shoot though the overlap region |
| 15:15.40 |
abhi2011 |
yes |
| 15:15.41 |
brlcad |
segments |
| 15:15.46 |
abhi2011 |
I have a
overlap callback |
| 15:15.59 |
abhi2011 |
which records
the overlap partitions in a structure |
| 15:16.29 |
abhi2011 |
and I later
analyze them to see the maximum X, min X etc when the ray is
passing through a overlap region |
| 15:16.51 |
abhi2011 |
all goed so
far :) |
| 15:17.51 |
abhi2011 |
so the place
where say a ray enters a overlap region is a single point in 3D
space |
| 15:17.59 |
abhi2011 |
so i make
this one of the contact points |
| 15:19.41 |
brlcad |
what does
bullet want? |
| 15:19.53 |
abhi2011 |
the contact
points and the penetration depth |
| 15:20.07 |
abhi2011 |
so if a body
A is penetrating body B |
| 15:20.08 |
brlcad |
do you just
provide contact points, or points and vectors based on thickness of
overlap? |
| 15:20.13 |
brlcad |
or a
surface? |
| 15:20.40 |
abhi2011 |
I provide
only the contact points for body B , the depth upto which body B
has penetrated into body A and the normal from body B to
A |
| 15:20.44 |
abhi2011 |
so 3
things |
| 15:21.00 |
abhi2011 |
so if we have
a box lying on a ground plane |
| 15:21.12 |
abhi2011 |
and say the
box is body A and the ground is B |
| 15:21.20 |
abhi2011 |
then A will
slight penetrate B |
| 15:22.15 |
abhi2011 |
then I
generate contact points for B, which will be slightly inside
it |
| 15:22.25 |
abhi2011 |
the extent of
penetration is the depth |
| 15:22.44 |
abhi2011 |
and the
normal will simple be 0,0,1 (positive Z axis) |
| 15:23.02 |
brlcad |
abhi2011:
hold up, gotta run out for a second .. very interesting, to be
continued... :) |
| 15:23.14 |
abhi2011 |
yeah sure,
will get some pics up meanwhile :) |
| 15:23.22 |
brlcad |
this is
getting into meat and I'm sure I'll have more questions
:) |
| 15:23.33 |
abhi2011 |
hehe |
| 15:30.30 |
abhi2011 |
right so
since geometry is involves it will be easier to be on the same page
(so to speak :P) :
https://docs.google.com/drawings/d/1FVUPyeoq6YWHKPzlDadrZch8qOw0jBjeFgJ3FHtL1SE/edit?hl=en_GB |
| 15:52.58 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 15:58.13 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 16:00.19 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 16:39.19 |
abhi2011 |
more
discussion here :
http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=7517&p=25901#p25901 |
| 16:39.33 |
abhi2011 |
no replies
however :( |
| 17:07.29 |
brlcad |
abhi2011:
your message was trimmed :) |
| 17:07.52 |
abhi2011 |
in the forum
? |
| 17:07.55 |
brlcad |
yeah |
| 17:07.56 |
abhi2011 |
I am still
updating it |
| 17:08.08 |
abhi2011 |
too much text
to put in |
| 17:08.09 |
brlcad |
aha! i
see |
| 17:08.24 |
abhi2011 |
the basic
thing i want to convey is |
| 17:08.33 |
abhi2011 |
if i look at
the bullet points |
| 17:08.43 |
abhi2011 |
i see A
penetrate B initially |
| 17:08.53 |
abhi2011 |
but its
gradually pushed out after iteration 12 |
| 17:09.00 |
abhi2011 |
and by 20 its
quite stable |
| 17:09.09 |
abhi2011 |
however for
me it justs keeps on sinking |
| 17:09.40 |
brlcad |
you mean some
example that bullet provides? |
| 17:09.42 |
abhi2011 |
so the
constraint solver is not constraining the contact points , which
would have held the box foxed in 3d space |
| 17:10.04 |
abhi2011 |
no the
example that I am discussing in that thread |
| 17:10.06 |
brlcad |
or just
allowing the regular collision detection to work |
| 17:10.21 |
abhi2011 |
regular
collision detection |
| 17:10.32 |
brlcad |
you're
discussing a LOT of points in that thread |
| 17:10.45 |
abhi2011 |
if i allow
regular collision detection to work then it holds the box stable on
the plane |
| 17:11.16 |
brlcad |
might be part
why there's no response .. there are lots of questions and they all
probably warrant a fair bit of discussion :) |
| 17:11.37 |
brlcad |
you mean it's
stable after 20 iterations |
| 17:11.51 |
abhi2011 |
hmm yeah, yet
I am focussing on 1 very simple case, just that there is a lot to
it |
| 17:12.07 |
abhi2011 |
injecting
custom contact points takes some changes to the code |
| 17:12.21 |
abhi2011 |
yes its
stable after 20 iterations |
| 17:12.32 |
abhi2011 |
using regular
collision detection |
| 17:13.02 |
abhi2011 |
however if I
start to inject my own contact points, then its not stable , the
box passes right through the plane |
| 17:13.07 |
abhi2011 |
as gravity is
acting |
| 17:13.43 |
brlcad |
so there's
something happening with the default collision detection that
you're not doing |
| 17:14.45 |
abhi2011 |
exactly |
| 17:14.54 |
abhi2011 |
i have been
seaching for that |
| 17:15.14 |
abhi2011 |
the only
interface is the addcontactpoints() function |
| 17:16.32 |
brlcad |
have you
looked at the code for the default? |
| 17:16.46 |
brlcad |
or do they
have an example that calls addcontactpoints() |
| 17:17.18 |
abhi2011 |
yes they have
code that calls addcontactpoints() in their default box-box
collider |
| 17:17.57 |
abhi2011 |
I dont see
anything else being set, but its possible that some global member
of derived member gets set in the 800 lines+ of code |
| 17:18.05 |
abhi2011 |
*or
derived |
| 17:18.05 |
brlcad |
I'm thinking
that you may have to not only provide the contact points and
normals, but also invoke some callback to apply the
forces |
| 17:18.29 |
abhi2011 |
yes that will
happen automatically after the points are put in |
| 17:18.37 |
abhi2011 |
its all in 1
flow |
| 17:18.48 |
abhi2011 |
i just inject
the points at the right point in the flow |
| 17:18.53 |
brlcad |
i'm saying
maybe it's not automatic |
| 17:19.09 |
brlcad |
unless you
set something that says "do it automatically" |
| 17:19.18 |
abhi2011 |
hmm, but the
forces do act as otherwise the top box wouldnt move |
| 17:19.19 |
brlcad |
that would
explain it |
| 17:19.33 |
brlcad |
there's still
a global gravity force |
| 17:19.44 |
abhi2011 |
yes |
| 17:19.51 |
brlcad |
it's not
applying the new force from the collision interaction |
| 17:20.05 |
abhi2011 |
yep, its
pretty certain I am not doing something like that |
| 17:20.20 |
brlcad |
but then
you've defined a cusom collision handler, so I could easily see
them adding a callback or state value that lets you
override/ignore/modify the force too |
| 17:20.40 |
brlcad |
the
*collision/interaction* force |
| 17:20.49 |
brlcad |
force(s) |
| 17:21.16 |
abhi2011 |
yes, the
thing is there is no callbacks in the force-application part of the
pipeline |
| 17:21.40 |
abhi2011 |
only in the
collision point generation part there is some callbacks and the
possiblity to inject points |
| 17:21.53 |
abhi2011 |
so I ll go
ahead with gdb |
| 17:22.16 |
abhi2011 |
and step
through the force-application part and see whats
happemning |
| 17:22.18 |
brlcad |
doesn't have
to be a callback, could just be a bullet function that gets called
(recalculateForcesBasedOnNewContactPoints()) |
| 17:22.41 |
abhi2011 |
yes |
| 17:22.46 |
brlcad |
or, like I
said, some global environment set up that happens
earlier |
| 17:23.20 |
abhi2011 |
yes |
| 17:23.49 |
abhi2011 |
but apart
from that the algorithm is as shown in that google doc |
| 17:24.36 |
abhi2011 |
the rays are
shot and the entry points can be converted to contact points ...and
some extra logic of course for the depth and normals(VCROSS the
points) |
| 17:25.31 |
brlcad |
nods (though I can't get to google docs until
later) |
| 17:25.58 |
abhi2011 |
ok, yeah its
the same picture as the one on the thread, the white colored
background |
| 17:30.10 |
abhi2011 |
the last post
summarizes it all |
| 17:36.42 |
abhi2011 |
wish there
was a irc for Bullet too :) |
| 17:37.49 |
brlcad |
you mean like
#bulletphysics? |
| 17:38.37 |
abhi2011 |
hehe clicked
on it and got hopeful for a second :P |
| 17:38.52 |
brlcad |
hm? |
| 17:39.21 |
abhi2011 |
#bulletphysics is not an actual channel ,
I hoped it was |
| 17:39.31 |
brlcad |
it
is |
| 17:39.39 |
abhi2011 |
oh wait the
question mark came |
| 17:39.42 |
abhi2011 |
:P |
| 17:39.46 |
abhi2011 |
i ll try
again |
| 17:39.57 |
brlcad |
just type
/join #bulletphyics |
| 17:40.01 |
abhi2011 |
ah |
| 17:40.03 |
abhi2011 |
yes |
| 17:40.05 |
abhi2011 |
am
in |
| 17:40.13 |
abhi2011 |
thanks
:P |
| 17:41.25 |
brlcad |
abhi2011:
have you read
http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=5365&p=19270&hilit=+contact+pair+#p19270
? |
| 17:41.59 |
abhi2011 |
no not yet,
will have a look |
| 17:43.18 |
brlcad |
might not be
related, but speaks some about contact pairs with a couple
responses |
| 17:43.42 |
abhi2011 |
hmm it seems
to add points over multiple iterations, I however add them in 1
shot as every iteration is a cold start |
| 17:43.58 |
abhi2011 |
that is from
the beginning with world setup an everthing |
| 17:44.27 |
brlcad |
you using a
btGImpactMeshShape ? |
| 17:44.34 |
abhi2011 |
no |
| 17:44.36 |
abhi2011 |
only
boxes |
| 17:44.40 |
abhi2011 |
btBoxShape |
| 17:44.45 |
brlcad |
k |
| 17:45.24 |
abhi2011 |
for all
BRL-CAD shapes (the actual shapes are of course resolved based on
rt etc etc as dicussed before) |
| 17:46.07 |
brlcad |
hm,
http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=7498&hilit=custom+collision
implies there is a callback for adding contacts |
| 17:46.19 |
brlcad |
so perhaps
the default is simply "do nothing" when you override |
| 17:46.35 |
brlcad |
or
setCollisionFlags() needs some magic |
| 17:48.09 |
brlcad |
interesting
snippet that uses ray casting for collision detection (car
demo) |
| 17:48.09 |
brlcad |
http://code.google.com/p/game-ws/source/browse/branches/cardemo/src/raycast_car.cpp |
| 17:48.32 |
abhi2011 |
oh
awesome |
| 17:48.34 |
abhi2011 |
:) |
| 17:52.30 |
brlcad |
calculateCombinedRestitution() looks
somewhat important |
| 17:53.09 |
brlcad |
along with
the CF_CUSTOM_MATERIAL_CALLBACK collision flag |
| 17:53.28 |
abhi2011 |
yes, I think
those will be called anyway as those parts are
unchanged |
| 17:53.48 |
brlcad |
the example I
was looking at called them directly |
| 17:53.54 |
abhi2011 |
hmm will
verify that though |
| 17:54.00 |
abhi2011 |
yes |
| 18:07.36 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 18:13.23 |
CIA-48 |
BRL-CAD:
03n_reed * r47304
10/brlcad/trunk/src/other/step/src/express/express.c: add token
printing debug routine |
| 18:17.18 |
CIA-48 |
BRL-CAD:
03brlcad * r47305 10/brlcad/trunk/doc/docbook/Makefile.am: DO need
the catalogs to be listed as BUILT_SOURCES so that they're properly
cleaned up for distclean. hopefully the last dist
issue. |
| 18:18.27 |
abhi2011 |
hmm I think
I see a way out of this mess :p |
| 18:18.56 |
abhi2011 |
so there are
basically 2 approaches possible for supporting arbitrary shapes
inside Bullet |
| 18:19.53 |
brlcad |
yes? |
| 18:19.57 |
abhi2011 |
1. The more
'low level' one , where , whenever a body touches another body , I
let them penetrate a bit so I can detect the overlap using rays and
generate contact points |
| 18:20.29 |
abhi2011 |
these contact
points are injected into the bullet physics pipeline and are kept
fixed in space by the constraint solver |
| 18:20.37 |
abhi2011 |
thus fixing
the body they belong to, also in space |
| 18:20.49 |
abhi2011 |
2. The more
higher level approach |
| 18:21.00 |
abhi2011 |
which the
raycast vehicle appears to use |
| 18:21.10 |
abhi2011 |
detect
overlap using raycast as usual |
| 18:21.18 |
abhi2011 |
however apply
the force yourself |
| 18:21.28 |
abhi2011 |
at the
contact point |
| 18:21.46 |
abhi2011 |
instead of
hoping-against-hope that bullet will do it for you :P |
| 18:22.02 |
abhi2011 |
which it wont
:) |
| 18:22.35 |
abhi2011 |
so I think
this should work for convex shapes too and any arbitrary
shape |
| 18:23.29 |
abhi2011 |
except that
the force at the contact point has to applied in the right
direction : normal to the surface, and also on both
bodies |
| 18:23.42 |
abhi2011 |
but then
there is the question of how much force to apply |
| 18:24.29 |
abhi2011 |
that has to
be calculated using restitution etc and then there is friction, so
basically doing a lot of the stuff that bullet should
do |
| 18:26.16 |
abhi2011 |
hmm guess I
ll take the second approach for now since it seems to offer some
control over the restitution etc too |
| 18:30.37 |
abhi2011 |
for
calculating the magnitude of force to be applied at the point of
contact, I would need to acceleration of the body in the previous
frame |
| 18:32.20 |
abhi2011 |
concave
objects can have multiple overlap regions(eg wine goblet lying on
its side on the floor), but that can be dealt with
later |
| 18:50.19 |
brlcad |
abhi2011:
whichever path you plough down, handling the concave case is going
to be critical |
| 18:50.52 |
brlcad |
it won't be
usable for anything except very simple demos if it only supports
convex shapes |
| 18:51.18 |
brlcad |
fun and neat,
but not practical |
| 18:57.10 |
CIA-48 |
BRL-CAD:
03brlcad * r47306 10/brlcad/trunk/TODO: rtcheck within mged seems
to be working just fine |
| 19:00.55 |
CIA-48 |
BRL-CAD:
03brlcad * r47307 10/brlcad/trunk/TODO: couldn't get red to crash
with multiple/any blanks lines, so shoould be good to go for
release. did notice that the mac input bug seems to be back,
though. |
| 19:03.56 |
``Erik |
hm, tesla
lost the libel case against top gear |
| 19:04.03 |
CIA-48 |
BRL-CAD:
03brlcad * r47308 10/brlcad/trunk/doc/docbook/Makefile.am: define a
creation rule for FOP_XML_CATALOG too since it's also a dep on
all |
| 19:28.29 |
CIA-48 |
BRL-CAD:
03bob1961 * r47309
10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: This is an
implementation in Itcl/Itk of an Accordian widget. Internally it
uses ttk widgets. |
| 19:29.25 |
CIA-48 |
BRL-CAD:
03bob1961 * r47310
10/brlcad/trunk/src/tclscripts/lib/CMakeLists.txt: Added an entry
for Accordian.tcl |
| 19:49.21 |
abhi2011 |
brlcad: yes i
think concave objects will generally cause forces acting at various
distances from the body's center leading to torques |
| 19:49.39 |
abhi2011 |
if these
torques cancel each other out, the body will be stable |
| 19:51.06 |
abhi2011 |
like if we
take the case of a marble dropping inside a cup |
| 19:51.56 |
abhi2011 |
then the
forces acting on the bottom points of the marble as it makes
contact with the base of the cup will stop its fall |
| 19:52.17 |
abhi2011 |
but contact
with inside edges of the cup will cause it to roll about for some
time |
| 19:57.33 |
abhi2011 |
i have 1
question though |
| 19:58.02 |
abhi2011 |
wlll the rays
report the normals to the surfaces of objects |
| 19:58.42 |
abhi2011 |
even if the
rays themsleves are entering the targetted object at an angle to
the surface |
| 20:08.54 |
brlcad |
you can get
the surface normals for all hit points |
| 20:09.20 |
brlcad |
RT_GET_NORMAL() as well as other
means |
| 20:12.36 |
CIA-48 |
BRL-CAD:
03bob1961 * r47311
10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: Added the
togglePanel method to cadwidgets::Accordian |
| 23:36.47 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 02:09.21 |
brlcad |
starseeker:
if you always do a build the exact same way every time, nothing is
likely going to ever change |
| 02:09.27 |
brlcad |
s/change/fail/ |
| 02:09.45 |
brlcad |
but then
that's not very flexible either, akin to coding with blinders
on |
| 02:51.16 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 03:07.47 |
starseeker |
will be curious what you did
differently... |
| 03:08.22 |
jordisayol |
hello |
| 03:09.13 |
starseeker |
howdy |
| 03:09.25 |
jordisayol |
when will be
the 7.20.4 release out? |
| 03:09.45 |
starseeker |
within a
couple days would be my guess |
| 03:10.01 |
jordisayol |
aha,
thanks! |
| 03:22.58 |
brlcad |
starseeker:
I've long since moved on with all of the other release
testing |
| 03:23.02 |
brlcad |
jordisayol:
within a couple hours |
| 03:23.15 |
brlcad |
last round of
distchecking now |
| 03:23.30 |
jordisayol |
good! |
| 03:23.34 |
starseeker |
brlcad: ah -
was figuring there was busted CMake stuff I would have to look
at... |
| 03:23.48 |
brlcad |
starseeker:
fyi, I seem to consistently run into that fontconfig failure on
10.6 |
| 03:24.11 |
brlcad |
something
wrong with the X11 search logic |
| 03:24.28 |
starseeker |
k. |
| 03:24.42 |
starseeker |
will see if a test machine is available |
| 03:25.11 |
brlcad |
it ends up
not searching in /usr/X11/include where fontconfig/fontconfig.h
lives, no -I/usr/X11/include on the compile line either |
| 03:25.21 |
starseeker |
growls |
| 03:25.31 |
starseeker |
why did trunk
succeed and stable fail? |
| 03:25.50 |
starseeker |
or was that a
separate issue? |
| 03:26.02 |
brlcad |
curiously,
through all my mods of misc/CMake/FindX11.cmake, it didn't even
seem to be using that macro/file |
| 03:26.19 |
starseeker |
nods - it probably was using one of the src/other
copies |
| 03:26.22 |
brlcad |
separate
issue I think |
| 03:26.27 |
brlcad |
I updated all
the src/other copies too |
| 03:26.42 |
brlcad |
(can see in
the commit history) |
| 03:26.46 |
starseeker |
that's one of
the drawbacks of doing src/other configures before ours - we get
their Find*.cmake files running first |
| 03:26.53 |
starseeker |
k |
| 03:27.42 |
starseeker |
all the more
reason to try and get maintainership of the ones we care about in
CMake |
| 03:27.44 |
brlcad |
in fact,
curiously -- it's finding /usr/X11R6 during cmake .. and I removed
ALL of our cmake file references to /usr/X11R6 and it still
found/used it |
| 03:27.53 |
starseeker |
O.o |
| 03:28.24 |
starseeker |
darn Mac
anyway... |
| 03:29.13 |
starseeker |
needs to make another try at Aqua support... heck with X11 on
Mac... |
| 03:29.17 |
brlcad |
the mac X11
dirs are actually set up very sane on 10.6 |
| 03:29.46 |
brlcad |
autotools
passes no problem, something is wrong in the logic |
| 03:29.55 |
starseeker |
nods |
| 03:29.59 |
starseeker |
I believe
it |
| 03:30.12 |
starseeker |
I'll try to
take a look tomorrow |
| 03:31.31 |
brlcad |
as it's the
last remaining release issue, I'm going to tag the release with
that issue unresolved so some users might get bitten |
| 03:31.53 |
starseeker |
nods - yeah, CMake isn't "official" yet so I'd say
go |
| 03:32.27 |
starseeker |
does X11R6
*exist* on your Mac? |
| 03:32.50 |
brlcad |
yes, it is a
symlink to X11 |
| 03:33.09 |
starseeker |
hmm |
| 03:33.38 |
starseeker |
and yet
-I/usr/X11R6/include doesn't work for fontconfig.h? |
| 03:33.58 |
brlcad |
sure that'd
work, but it's not on the compile line |
| 03:34.08 |
starseeker |
confound
it |
| 03:34.32 |
starseeker |
alright, I'll
have to debug it |
| 03:34.55 |
brlcad |
that's why I
started trying to just debug the find macro, but couldn't seem to
get it to do anything useful |
| 03:35.04 |
brlcad |
spent a day
working on various angles |
| 03:35.12 |
starseeker |
winces - sorry about that |
| 03:35.18 |
brlcad |
not you,
cmake just was not cooperating |
| 03:35.20 |
starseeker |
was rather
fried after the last week |
| 03:35.59 |
starseeker |
has done various surgeries on the FindX11.cmake file to try
and account for one issue or another, may have really messed it up
somehow |
| 03:36.33 |
brlcad |
uncovered a
rather extensive bit of scary differences on the tk command
line... |
| 03:36.46 |
starseeker |
snorts - not surprised, actually |
| 03:37.02 |
starseeker |
I was trying
to get it working, not shooting for command line parity |
| 03:37.07 |
brlcad |
i'm almost
surprised that tk even works... |
| 03:37.11 |
brlcad |
http://brlcad.org/tmp/cmake_fail.patch |
| 03:37.32 |
brlcad |
don't show
the tk guys that :) |
| 03:38.06 |
starseeker |
oh, I doubt
they'll care either way - when I talked to Andreas, he didn't sound
especially interested in changing the existing system |
| 03:38.23 |
starseeker |
(unfortunately, he was making Tcl/Tk usb
drives and didn't see my talk :-( |
| 03:39.15 |
brlcad |
package name
isn't right, features off that should be on, features on that
should be off, worrisome threading settings, incorrect symbol
import/export settings, .. :) |
| 03:40.21 |
brlcad |
subtleties
for sure, but definitely enough "cause for concern" if/when tk ever
crashes or has odd behavior |
| 03:40.55 |
brlcad |
first thing
I'd want to do if we ran into a serious bug is try again with stock
tk |
| 03:41.06 |
brlcad |
(or get
closer to parity) |
| 03:41.07 |
starseeker |
nods - I pretty much reached burn-out trying to unwind their
existing build settings |
| 03:41.45 |
starseeker |
that stupid
thing they have to do with putting all their settings on the
command line instead of a config.h file made it tough |
| 03:42.05 |
brlcad |
I would have
thought that makes things easier |
| 03:42.49 |
brlcad |
always have
the command line, and then "sometimes"
compile_line+some_unknown_number_of_files_with_magical_#defines |
| 03:43.03 |
brlcad |
that just
eliminates the latter, one list to worry about matching |
| 03:43.10 |
starseeker |
prefers diffing the resulting config.h files between old and
new builds |
| 03:43.28 |
brlcad |
but then even
the compile flags don't match |
| 03:44.31 |
brlcad |
I *think*
they're all benign, but not sure |
| 03:44.37 |
brlcad |
especially
about __attribute__\(\(__visibility__\(\"hidden\"\)\)\) |
| 03:44.48 |
starseeker |
didn't know what to make of that one |
| 03:45.23 |
starseeker |
it was bad
enough trying to figure out all the tests for the stuff I *knew* I
needed - pretty much if it wasn't clearly essential it got
ignored |
| 03:45.47 |
starseeker |
remember the
original effort was a side issue, a distraction from BRL-CAD
itself |
| 03:46.21 |
brlcad |
a distraction
to you perhaps :) |
| 03:46.30 |
brlcad |
to me, it's
all part of the effort |
| 03:46.43 |
starseeker |
<snort>
I was worried about being called to the carpet as it
was |
| 03:46.43 |
brlcad |
if it's worth
doing at all ... |
| 03:46.49 |
brlcad |
knows |
| 03:47.11 |
brlcad |
it's fine, it
obviously works fairly well enough as it is |
| 03:48.01 |
starseeker |
oh, I agree
it's worth doing right - maybe it's a side-effect of the
conference, but I do think Tcl/Tk is a nice combination of
features, license and small size compared to it's
feature-set |
| 03:48.12 |
brlcad |
there are
just so many rough edges that there are going to be numerous
long-term maintenance and debugging costs, obscure errors down the
road that take forever to dig into |
| 03:48.36 |
starseeker |
unfortunately, my compiling foo is
relatively weak compared to the complexities of the
build |
| 03:49.30 |
starseeker |
half the time
I didn't know if a particular flag was a hold-over from ancient
history I could ignore |
| 03:49.52 |
starseeker |
or a flag I
would need on some platform other than the current one |
| 03:50.51 |
starseeker |
that
__attribute__ flag being one case in point |
| 03:51.07 |
brlcad |
that's gcc
linker hinting |
| 03:52.38 |
brlcad |
a quick
google search would have answered that one :P |
| 03:52.45 |
brlcad |
most of them,
really |
| 03:53.27 |
brlcad |
http://gcc.gnu.org/wiki/Visibility |
| 03:53.28 |
starseeker |
maybe *what*
they were, but not whether they actually mattered for thing things
we care about |
| 03:53.55 |
brlcad |
basically,
it's gcc's way to hide a symbol that needs to be extern but you
don't want to be public api |
| 03:54.09 |
brlcad |
very similar
to dll_import/dll_export in msvc |
| 03:54.16 |
starseeker |
retches |
| 03:54.28 |
starseeker |
that has
caused more grief... |
| 03:55.15 |
brlcad |
to whom?
pretty straightforward linking concepts (and not unique to
msvc) |
| 03:55.38 |
brlcad |
most
compilers have the notion, some are through much more archane
methods like explicit lists of symbols in text files |
| 03:56.04 |
brlcad |
gcc was
actually a bit late to the game, but most commercial compilers have
that feature |
| 03:58.23 |
starseeker |
nods - OK, looking over this article I can see why it might
be useful in some situations... |
| 03:58.27 |
brlcad |
it lets you
write a function "secret_special_sauce()" used by public API in
several places, say rt_brilliant() and rt_awesome(), but not
actually have to expose that function in the library |
| 03:59.10 |
starseeker |
do we use
such a mechanism? I don't recall seeing it in our own build
logic... |
| 03:59.41 |
brlcad |
we do not, it
takes a little bit of API awareness and best practice to keep
things clean |
| 03:59.53 |
brlcad |
libged is a
prime example, though .. |
| 04:00.28 |
brlcad |
lots of
functions bob keeps adding that need to be reusable within the
library .. but make for HORRIBLE public api functions, completely
inconsistent with the rest of the ged api |
| 04:01.09 |
brlcad |
been
resorting to simple naming conventions to at least remove the ged_
prefix, helps |
| 04:01.39 |
brlcad |
but then they
still need to be declared in ged's private header, not
ged.h |
| 04:01.46 |
brlcad |
and that
takes awareness, restraint, etc |
| 04:02.01 |
starseeker |
nods |
| 04:02.21 |
brlcad |
yay, final
builds completed |
| 04:02.45 |
starseeker |
if I ever
feel like tinkering with our build system again, sit on me 'til the
urge passes |
| 04:02.50 |
brlcad |
cept cmake of
course, |
| 04:03.43 |
brlcad |
doing
something I probably shouldn't .. comparing the two distfiles from
cmake and autotools |
| 04:03.44 |
starseeker |
will look into that tomorrow if he can get access to a 10.6
system |
| 04:04.10 |
brlcad |
I can post
any files you think might help |
| 04:04.12 |
starseeker |
I believe
there is at least one step that autotools has that I haven't put in
CMake |
| 04:04.31 |
starseeker |
brlcad: I
need to do some configure-time debugging, to check what is and
isn't being set at various steps |
| 04:04.44 |
starseeker |
basically a
bunch if MESSAGE calls at various points in the file |
| 04:04.50 |
starseeker |
s/if/of |
| 04:05.13 |
starseeker |
brlcad: your
CMakeCache.txt file might be informative |
| 04:06.25 |
brlcad |
http://brlcad.org/tmp/cmake_build_fail.txt
and http://brlcad.org/tmp/CMakeCache.txt |
| 04:06.26 |
starseeker |
is disturbed that editing the FindX11.cmake files didn't do
squat - did you erase your CMakeCache.txt file between each CMake
run? (or at least clear out the X variables in
it?) |
| 04:06.48 |
brlcad |
yep, started
out just wiping out the cache |
| 04:07.04 |
brlcad |
then was
eventually blowing away the whole dir, trying to get some
changes |
| 04:08.00 |
brlcad |
build dir out
of src dir only, parallel |
| 04:08.11 |
starseeker |
hmm - is
there a /usr/include/X11 dir? |
| 04:09.35 |
starseeker |
is wondering why there seems to be both a /usr/X11/include
and a /usr/include/X11 - one one a symlink to the
other? |
| 04:09.43 |
brlcad |
there is a
/usr/include/X11 symlink to /usr/X11/include/X11 |
| 04:10.03 |
starseeker |
and
fontconfig.h is where? |
| 04:10.16 |
brlcad |
/usr/X11/include/fontconfig/fontconfig.h |
| 04:10.28 |
starseeker |
that may be
what's happening |
| 04:10.34 |
starseeker |
/usr/include
is getting checked first |
| 04:10.35 |
brlcad |
/usr/X11/include is the "proper" one-stop
shop for X11 |
| 04:10.38 |
starseeker |
right |
| 04:10.50 |
starseeker |
but I'll bet
the find routines are looking in /usr/include |
| 04:10.57 |
brlcad |
so #include
<X11/Xlib.h> works, as well as #include
<fontconfig/fontconfig.h> |
| 04:11.18 |
starseeker |
your cache
file reports: X11_X11_INCLUDE_PATH:PATH=/usr/include |
| 04:11.39 |
starseeker |
and
/usr/include/fontconfig doesn't exist |
| 04:11.43 |
brlcad |
which is true
for that specific test |
| 04:12.56 |
starseeker |
let me
check... it's now looking like there needs to be a specific
fontconfig_include_dir var set... |
| 04:13.16 |
brlcad |
fontconfig is
one of a half-dozen entities in /usr/X11/include |
| 04:13.29 |
brlcad |
GL, cairo,
freetype2, ... |
| 04:14.02 |
starseeker |
yeah, but
unless we convince the FindX11 routines to not look in /usr/include
(or at least, not until after /usr/X11/include) the X11 includes
aren't going to get fontconfig |
| 04:14.55 |
brlcad |
the problem
isn't fontconfig -- the failure is 1) assuming that the dir
containing X11 also contains those deps and 2) not checking
/usr/X11/include first .. and maybe 3) not having the equivalent
of --with-x=/usr/X11 :) |
| 04:15.47 |
starseeker |
did you try
moving /usr/include below /usr/X11/include in the
X11_INC_SEARCH_PATH variable in FindX11.cmake? |
| 04:17.05 |
brlcad |
so here's
another mystery .. when I first started editing FindX11.cmake ..
/usr/include was at the BOTTOM of the X11_INC_SEARCH_PATH list ..
which is why my commit comments asserted that the list seemed to be
processed in reverse order |
| 04:17.26 |
brlcad |
I had trouble
believing that, even with the evidence, so I reverted and resorted
back |
| 04:17.52 |
brlcad |
that's what I
meant about not getting that list to make one bit of
difference |
| 04:18.28 |
starseeker |
what about
reducing that list to *just* /usr/X11/include - does that
work? |
| 04:18.38 |
starseeker |
(take the
order out of it, for the moment) |
| 04:19.06 |
brlcad |
I'll give
that a quick test |
| 04:19.41 |
brlcad |
my earlier
test was to remove X11R6 since that's what most of the X11-related
tests actually detect/use |
| 04:19.55 |
brlcad |
and even
after removing all instances of it, still would only detect/use
X11R6 |
| 04:20.27 |
brlcad |
like maybe
some system Find* was getting called first and our list was
pointless |
| 04:20.31 |
starseeker |
that's
strange... it almost sounds like it's getting the system
FindX11.cmake and not our local copies |
| 04:20.34 |
starseeker |
er, yeah
:-) |
| 04:21.24 |
starseeker |
iirc, one of
the src/other instances (tk, I think) ends up called first, the way
our toplevel currently works |
| 04:21.42 |
starseeker |
(with all
bundled libs on - otherwise of course it depends) |
| 04:22.25 |
starseeker |
I had that
problem earlier. But since you changed 'em all and cleared the
cache, it can't be that |
| 04:22.46 |
brlcad |
well, like I
said, I thought of that too and diligently overwrote all
FindX11.cmake on each edit attempt |
| 04:22.56 |
starseeker |
knows |
| 04:22.58 |
brlcad |
as well as
FindGL.cmake since it has some X11 tests of it's own |
| 04:23.31 |
brlcad |
edit made,
re-cmaking |
| 04:23.51 |
starseeker |
only other
thing I can think of (what I would be doing) is to put some MESSAGE
statements into the FindX11.cmake files to see what is set
when. |
| 04:24.43 |
brlcad |
so that
reminds me of another bitching point .. what is up with ccmake not
giving the "g"enerate files option most of the time? |
| 04:24.50 |
starseeker |
something
like MESSAGE("X11 include path with FindX11.cmake in
${CMAKE_CURRENT_SOURCE_DIR}: ${X11_X11_INCLUDE_PATH
X11}") |
| 04:25.27 |
starseeker |
uh - if it's
acting like the gui, you need to do the configure twice before
generate is available... |
| 04:25.45 |
starseeker |
recalls a complaint about that on the CMake list a while
back... |
| 04:26.50 |
brlcad |
it annoyingly
starts up with EMPTY CACHE in an empty/new build dir, I run
'c'onfigure, I wait... get list of options, make my edits,
'c'onfigure *again* .. and sometimes it'll give me the 'g'enerate
option, but usually I have to exit and "cmake ." to generate the
makefiles for that last config |
| 04:27.11 |
starseeker |
O.o |
| 04:27.33 |
starseeker |
as far as I
know, it's supposed to give you the generate option once no new
variables have been added to the var list |
| 04:27.42 |
starseeker |
which is
typically after the second configure |
| 04:28.04 |
brlcad |
well I have
no list the first time, so presumably they all get
added |
| 04:28.08 |
starseeker |
if your
option edits prompt more variables to appear, you'll have to do it
again |
| 04:28.13 |
starseeker |
yes |
| 04:28.31 |
starseeker |
in the gui,
the first configure never allows the geerate button to
activate |
| 04:28.40 |
brlcad |
then the
second time, I usually do BUNDLED on the all deps option, turn on
debugging, turn on opt, 'c'onfigure |
| 04:28.53 |
starseeker |
the second
does, provided no new variables are added as a result of opition
changes between the first and the second |
| 04:29.16 |
starseeker |
ah - yeah,
that'll add new options as it runs the src/other configures it
didn't run the first time |
| 04:29.34 |
starseeker |
a third
configure (with no option changes) should get you the generate
button |
| 04:29.40 |
starseeker |
(or 'g'
option) |
| 04:31.00 |
brlcad |
blech |
| 04:31.38 |
starseeker |
once the
configure emulation script is done it should feel like autotools on
the command line |
| 04:31.46 |
starseeker |
then you
won't have to mess with the guis |
| 04:32.26 |
brlcad |
yeah, I'm
really not digging ccmake |
| 04:33.07 |
starseeker |
usually does the command line: cmake
-DBRLCAD_BUNDLED_LIBS=Bundled |
| 04:33.52 |
brlcad |
the options
aren't usefully grouped/sorted, can't see the curses cursor without
color, no description/help for options (which you'd think would be
a prime benefit of having a fancy curses gui) |
| 04:35.18 |
starseeker |
cmake-gui
probably isn't much better then (I prefer it personally, but that's
just me...) |
| 04:35.28 |
starseeker |
drop-down
options are kinda cool though |
| 04:37.36 |
brlcad |
of course,
patches welcome ;) |
| 04:37.54 |
brlcad |
so yeah,
no-go on the path change |
| 04:38.16 |
starseeker |
*bleep* |
| 04:38.33 |
brlcad |
removed all
except /usr/X11/include in all FindX11 and FindGL files, still
detecting /usr/include for headers and /usr/X11R6/lib for
libs |
| 04:38.36 |
starseeker |
is this a
machine I can remotely access? |
| 04:39.10 |
brlcad |
i could
probably set up access in a couple min |
| 04:39.19 |
starseeker |
is willing to give it a go... |
| 04:53.00 |
CIA-109 |
BRL-CAD:
03brlcad * r47371 10/brlcad/tags/rel-7-20-4/: retagging release
7.20.4 now that most of the build and distcheck issues have been
cleaned up. tested numerous configurations on debian and mac
10.6 |
| 04:55.36 |
starseeker |
brlcad: take
a look at: cmake --help-command find_path |
| 04:56.05 |
starseeker |
#5 in the
search list is a list of pre-defined paths for each
Platform |
| 04:56.28 |
starseeker |
that could be
interfering |
| 04:57.18 |
brlcad |
maybe, or the
path being searched for isn't useful |
| 04:57.32 |
brlcad |
looking for
an X11 dir seems a bit of a weak test, for example |
| 04:58.04 |
brlcad |
you generally
look for X11/Xlib.h or some other primary header |
| 05:00.50 |
CIA-109 |
BRL-CAD:
03brlcad * r47372 10/brlcad/trunk/src/librt/CMakeLists.txt:
shouldn't be any reason to disable strict mode on librt. change the
code, not the messenger. |
| 05:02.34 |
CIA-109 |
BRL-CAD:
03brlcad * r47373 10/brlcad/trunk/CMakeLists.txt: match the
original autotools logic, detect all the way back to 8-bit
architectures so we might have a prayer's chance of working out of
the box on an embedded platform. |
| 05:26.50 |
CIA-109 |
BRL-CAD:
03starseeker * r47374 10/brlcad/trunk/ (6 files in 6 dirs): Tweak
FindX11.cmake for Mac OSX 10.6 |
| 05:26.58 |
starseeker |
brlcad: give
that a go |
| 05:34.52 |
brlcad |
hey, I
believe you -- if you say it works :) |
| 05:35.08 |
starseeker |
is finishing the compile now - at 89% |
| 05:35.09 |
brlcad |
is there an
option that says "try these first, THEN try system"? |
| 05:35.21 |
brlcad |
oh, it
wouldn't have gotten that far |
| 05:35.27 |
brlcad |
failed in tk
early |
| 05:35.47 |
starseeker |
not to my
knowledge - I could achieve that behavior, but only by doing so
"manually" |
| 05:36.08 |
brlcad |
so if the
list is now being walked in order, /usr/include should probably
come last |
| 05:37.18 |
brlcad |
and any
system dirs being searched by default should probably get
added |
| 05:37.57 |
starseeker |
bets that's where the X11R6 stuff was coming from though -
the Developer SDKs have multiple copies of usr/X11R6
dirs |
| 05:37.59 |
brlcad |
rather, dirs
that WERE being searched by that default logic |
| 05:38.04 |
brlcad |
nods |
| 05:38.16 |
brlcad |
makes sense,
fits the symptoms |
| 05:39.00 |
starseeker |
nods - we could play with it some - if you want to do that,
we'd have to investigate where the platform specific dirs are
listed and append those variables |
| 05:39.18 |
brlcad |
I suspected
as much very early into the testing, but didn't know an fix and it
took a while to isolate the problem |
| 05:39.59 |
starseeker |
nods - I experimented with something like this once before,
but didn't (quite) need to go all the way to the no cmake system
path option |
| 05:40.09 |
starseeker |
this time
it's legit - we need it |
| 05:40.27 |
brlcad |
given how
critical proper detection of X11 is to our ability to even compile
in a useful manner on most platforms, it warrants making it as
robust as possible |
| 05:40.46 |
starseeker |
nods - probably will have to add FindGL to this mix,
too |
| 05:41.15 |
starseeker |
that is isn't
technically as necessary as X11 at the moment, but I don't expect
that to last much longer |
| 05:41.24 |
brlcad |
even better
would probably be to find what the autotools logic is, and *also*
use that since it's more likely to be more exhaustive |
| 05:41.54 |
brlcad |
yeah, we're
to the point of needing GL for anything serious .. we need to fix
our gl problems |
| 05:42.13 |
brlcad |
if we can't
even detect gl cleanly, we certainly can't dev reliably with
it |
| 05:42.30 |
starseeker |
*ding* *ding*
*ding* - build complete on your mac. logging off now |
| 05:42.36 |
brlcad |
awesome,
thanks |
| 05:43.11 |
starseeker |
np - thank
you! that would have been a toughie without the system itself to
test on |
| 05:43.40 |
brlcad |
if you want
to sync that to stable and branch, and regenerate the tarballs, go
for it ;) |
| 05:44.06 |
brlcad |
otherwise,
I'll go with the ones already tagged since they're also tested on
linux and don't want to do that whole round of retesting
again |
| 05:44.39 |
starseeker |
votes for leaving it - autotools will work for this
round |
| 06:43.41 |
brlcad |
source
tarballs uploading now, release notes hopefully sometime
tomorrow |
| 07:38.02 |
jordisayol |
brlcad:
congratulations for the new release! |
| 07:39.15 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 07:39.34 |
jordisayol |
brlcad: I see
that the package size is bigger than the previous ones. What's the
cause of this size difference? |
| 07:50.02 |
CIA-109 |
BRL-CAD:
03d_rossberg * r47375 10/rt^3/tags/rel-7-20-4/: tag the C++ core
interface with the corresponding BRL-CAD version (i.e.
7.20.4) |
| 12:44.16 |
CIA-109 |
BRL-CAD:
03indianlarry * r47376 10/brlcad/trunk/src/conv/iges/treecheck.c:
Change Treecheck() return from void to int |
| 13:42.29 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 14:05.46 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.81.53) |
| 14:38.52 |
starseeker |
jordisayol:
which packages are you building? RPM? |
| 14:39.52 |
jordisayol |
yes, RPM for
Fedora/Centos, RPM for OpenSUSE and DEB for
Debian/Ubuntu/LinuxMint/... |
| 14:41.02 |
starseeker |
jordisayol:
we have more docbook stuff (more advanced html and pdf is being
generated thanks to Tom Browder) |
| 14:41.10 |
starseeker |
awesome |
| 14:41.49 |
starseeker |
tries to remember if this last release is the one that will
have the upgraded Boost - that might have upped the size
too |
| 14:43.26 |
jordisayol |
aha, but what
is needed to compile brlcad with docbook? |
| 14:44.13 |
jordisayol |
...in linux
(ubuntu) |
| 14:51.06 |
jordisayol |
I got
this: |
| 14:51.06 |
jordisayol |
Generate
extra docs ...................: ON (man/html |
| 14:51.38 |
jordisayol |
with "fop"
installed |
| 14:52.20 |
jordisayol |
Generate
extra docs ...................: ON (man/html only) |
| 14:54.41 |
CIA-109 |
BRL-CAD:
03erikgreenwald * r47377 10/brlcad/trunk/src/libgcv/bottess.c:
change double ptrs to explicit point_t ptrs. |
| 16:23.30 |
jordisayol |
starseeker:
so, do you think that pdf files must be included in linux
packages? |
| 16:39.22 |
jordisayol |
starseeker:
deb package w/o pdf (until now), 50 Mb. with pdf 80 Mb. |
| 16:40.17 |
jordisayol |
starseeker:
please tell me what do you think |
| 16:41.10 |
jordisayol |
you too
brlcad |
| 16:41.29 |
jordisayol |
i've to
go |
| 16:41.52 |
jordisayol |
please leave
your opinion here |
| 16:41.54 |
jordisayol |
bye |
| 16:55.15 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.85.105) |
| 17:28.59 |
starseeker |
jordisayol:
no, pdf's shouldn't be included (IMO) |
| 17:29.37 |
starseeker |
you have to
explicitly turn on PDF building - it's another option |
| 17:29.58 |
starseeker |
(that option
won't even appear unless fop is around) |
| 17:30.44 |
starseeker |
pdf building
is expensive and (unlike the html output) isn't directly used by
any of the editing environments |
| 17:37.15 |
brlcad |
jordisayol:
since the pdf files are not yet in the final desired form (layout,
images, structure), it's not necessary that they be included in
binary distributions but not a problem if they're included
either |
| 17:37.45 |
brlcad |
requiring fop
to build brl-cad is a huge requirement, so I wouldn't make it a
.deb build dependency (pulls in all of fop+java) |
| 17:38.51 |
brlcad |
jordisayol:
as for the size of the download, the size tends to increase with
every release because the size of the code tends to increase every
release (ohloh has graphs) |
| 17:41.23 |
jordisayol |
ok, many
thanks starseeker and brlcad. i'l keep as they are |
| 17:41.26 |
brlcad |
most cad
distros are 10x our binary size due to docs and metadata, so I
won't really be concerned until we cross the max CD-size barrier
(about 860MB) |
| 17:42.17 |
brlcad |
even then,
that'll just to a good audit point to make sure we're not being too
wasteful and inefficient with 3rd party deps and data, real
practical limit is dvd capacity |
| 17:47.08 |
jordisayol |
another
question. can i switch archer as default graphic app, or is i still
in pre-alfa state? |
| 17:47.15 |
abhi2011 |
I am trying
to do a windows build and I read README.windows |
| 17:47.35 |
abhi2011 |
but there is
no brlcad.sln file in brlcad\misc\win32-msvc |
| 17:48.09 |
abhi2011 |
is the cmake
approachm the only approach at the moment ? |
| 17:51.23 |
brlcad |
jordisayol:
it's still pre-alpha, I'm hoping we push out an alpha before the
new year |
| 17:51.55 |
brlcad |
abhi2011: the
readme is out of date, cmake is THE approach at the moment, install
it on windows and the build should go pretty smoothly |
| 17:52.06 |
jordisayol |
brlcad: ok,
mani thanks. i'll keep everything as is |
| 17:52.07 |
abhi2011 |
ok |
| 18:01.20 |
abhi2011 |
so I have
visual studio 2008 express edition installed but i get errors with
cmake |
| 18:01.30 |
abhi2011 |
I guess the
best option then is to go with mingw |
| 18:01.43 |
brlcad |
what
errors? |
| 18:02.54 |
abhi2011 |
http://bin.cakephp.org/view/611912235 |
| 18:04.05 |
abhi2011 |
support for
platforms, hmm |
| 18:07.22 |
abhi2011 |
seems like a
bug :
http://social.msdn.microsoft.com/Forums/en-US/vssmartdevicesnative/thread/88685f18-11a0-469f-902d-08a00aa01554/ |
| 18:07.34 |
abhi2011 |
maybe i ll
get vc express 2010 and try |
| 18:10.38 |
abhi2011 |
hmm ok, I had
chosen the win64 compiler |
| 18:10.48 |
abhi2011 |
choosing the
normal 32 bit build , works |
| 18:14.28 |
abhi2011 |
though there
are a large number of libs that were not found : http://bin.cakephp.org/view/1966265968 |
| 18:15.46 |
abhi2011 |
its probably
looking for the DLLs in Windows/SysWOW64 and not finding them,
maybe I should install them |
| 18:17.00 |
abhi2011 |
oh wait , its
going to compile them, so its probably ok |
| 18:18.20 |
abhi2011 |
ok got the
sln file |
| 18:25.52 |
brlcad |
abhi2011:
yeah, no worries |
| 18:26.04 |
abhi2011 |
:) |
| 18:26.08 |
brlcad |
the lib
detection is just to decide whether or not we need to use our
bundled versions |
| 18:26.33 |
brlcad |
on windows,
where pretty much nothing exists already, it's to be expected that
most of the tests will result in using the bundled lib |
| 18:28.14 |
brlcad |
you might
still run into a compilation failure, windows doesn't get tested
very often |
| 18:31.04 |
brlcad |
if you do,
though, post it so someone can fix it .. or fix it yourself
;) |
| 18:35.04 |
abhi2011 |
yes
sure |
| 18:35.30 |
abhi2011 |
i cant find
the my simulate project under libged though :P |
| 18:35.40 |
abhi2011 |
*simulate
folder |
| 18:36.32 |
abhi2011 |
probably
removed from the files in the solution, due to bullet not being
detected, by cmake |
| 18:37.49 |
abhi2011 |
yeah , hav to
move to windows for a few days, as I am unable to access the svn
from linux suddenly, probably some isp issue |
| 18:43.47 |
starseeker |
is sorry, but will be a Good Thing if you can get things
working on Windows as well |
| 18:44.22 |
starseeker |
yeah, if it
can't find bullet it won't try building things needing
it |
| 18:46.11 |
abhi2011 |
starseeker:
hehe , np, yeah will compile bullet dynamic libs now
:) |
| 18:49.39 |
starseeker |
makes a note to try out tileQt and check its
license... |
| 18:52.44 |
abhi2011 |
ok, the build
completed smoothly, now its saying to run 'make install', I think
that would need make to be installed, which is only in
linux |
| 18:53.32 |
abhi2011 |
hmm maybe i
ll just run the INSTALL target |
| 18:53.59 |
abhi2011 |
right that
did it |
| 19:09.49 |
starseeker |
grins - tileQt already has a CMake build
:-) |
| 19:09.51 |
starseeker |
awesome |
| 19:30.04 |
abhi2011 |
strange, I
have just pointed the system environment variables
BULLET_DYNAMICS_LIBRARY BULLET_COLLISION_LIBRARY
BULLET_MATH_LIBRARY BULLET_SOFTBODY_LIBRARY
BULLET_INCLUDE_DIR |
| 19:30.22 |
abhi2011 |
and set them
to the proper paths where bullet .libs are installed |
| 19:30.31 |
abhi2011 |
still I get
the Bullet missing error |
| 19:30.54 |
abhi2011 |
arent the
variables supposed to be system variables ? |
| 19:31.32 |
starseeker |
abhi2011: try
setting them in CMake |
| 19:31.39 |
abhi2011 |
ah
ok |
| 19:33.47 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 19:43.44 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.80.3) |
| 19:52.14 |
abhi2011 |
starseeker:
that does not seem to work either |
| 19:52.32 |
starseeker |
what's the
error? |
| 19:52.54 |
abhi2011 |
i defined all
5 variables in cmake, but it says : Could NOT find Bullet (missing:
BULLET_DYNAMICS_LIBRARY BULLET_COLLISION_LIBRARY
BULLET_MATH_LIBRARY BULLET_SOFTBODY_LIBRARY
BULLET_INCLUDE_DIR) |
| 19:53.05 |
abhi2011 |
then it
removes them after configuring |
| 19:53.18 |
starseeker |
hmm. Where
did you define them? |
| 19:53.49 |
abhi2011 |
by adding an
entry with the add entry button in the cmake-gui |
| 19:55.22 |
starseeker |
OK. you
might try editing the CMakeCache.txt file... |
| 19:55.33 |
abhi2011 |
ok |
| 19:58.26 |
abhi2011 |
i guess the
path should only mention the folder name, and not include the
filename, as in :
F:\Code\libraries\bullet-build\lib\Debug |
| 20:00.52 |
starseeker |
right |
| 20:01.05 |
starseeker |
for the
includes anyway |
| 20:01.14 |
starseeker |
the libs will
want the full name |
| 20:02.23 |
starseeker |
so the 5
variables you listed include 4 libs - those are full path with
filename |
| 20:02.37 |
abhi2011 |
ok |
| 20:02.57 |
starseeker |
BULLET_INCLUDE_DIR should be just the
directory with the .h files, or possibly a parent directory
depending on the includes |
| 20:32.20 |
abhi2011 |
ok, now it
found it |
| 20:32.44 |
abhi2011 |
I think
setting them as enviromment vars should now also work as long as
the full files names are given where needed |
| 21:06.05 |
abhi2011 |
Bullet
running fine in windows now, linked against the static
libs |
| 21:06.25 |
abhi2011 |
starseeker:
thanks! |
| 21:09.37 |
starseeker |
hah -
awesome! |
| 21:10.48 |
starseeker |
abhi2011: I
know you've posted links before, but I don't recall - where are you
stashing the various videos of your progress? |
| 21:15.10 |
abhi2011 |
starseeker:
they are here : http://brlcad.org/wiki/User:Abhijit#Log |
| 21:15.18 |
abhi2011 |
there is just
1 video currently |
| 21:15.41 |
abhi2011 |
another
requires the server as its a large scene with glass affects, so its
not been done yet |
| 21:16.06 |
abhi2011 |
*glass
shaders |
| 21:19.36 |
abhi2011 |
has anyone
noticed that ws-indent and other scripts which format the code,
format it for the older editors like emacs, the code appears
misaligned in eclipse and visual studio |
| 21:20.11 |
abhi2011 |
code aligned
in eclipse and vs appears misaligned in emacs :P |
| 01:31.51 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
| 04:11.16 |
*** join/#brlcad dtidrow_desk
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 04:40.55 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.89.98) |
| 05:31.21 |
*** join/#brlcad hackrat
(~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 06:43.57 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.80.54) |
| 06:44.01 |
CIA-109 |
BRL-CAD:
0323.19.56.171 07http://brlcad.org
* r3191 10/wiki/Talk:Main_Page: |
| 06:50.53 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 07:10.23 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.89.69) |
| 08:15.19 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.86.172) |
| 08:31.34 |
*** join/#brlcad merzo
(~merzo@109-45-133-95.pool.ukrtel.net) |
| 11:07.28 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.89.50) |
| 11:41.38 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:22.00 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.85.236) |
| 12:40.08 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:46.32 |
*** join/#brlcad merzo
(~merzo@72-3-133-95.pool.ukrtel.net) |
| 13:31.16 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.84.105) |
| 13:54.23 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3192
10/wiki/Talk:Main_Page: Reverted edits by
[[Special:Contributions/23.19.56.171|23.19.56.171]] ([[User
talk:23.19.56.171|Talk]]); changed back to last version by [[User:X
Tin Basher|X Tin Basher]] |
| 13:54.36 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:23.19.56.171]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 14:15.35 |
brlcad |
abhi2011:
funny coincidence, someone on the bullet channel was bitching just
yesterday about bullet's internal ray tracing sucking |
| 14:16.00 |
brlcad |
told them
about your efforts to integrate with librt, excitedness
;) |
| 14:27.27 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 14:29.58 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.91.35) |
| 14:30.07 |
abhi2011 |
brlcad: cool
:) |
| 14:30.19 |
abhi2011 |
so there is
someone replying in that channel :P |
| 14:31.00 |
abhi2011 |
I have been
trying to figure out a algorithm that uses all the normal and
curvature info to generate the points |
| 14:31.22 |
abhi2011 |
guess I ll
first go with the box-box case |
| 14:31.50 |
abhi2011 |
a important
thing to figure out is the direction in which an object is
penetrating another object |
| 14:32.08 |
abhi2011 |
as the normal
has to point along that direction |
| 14:33.36 |
abhi2011 |
currently I
ll just check to see which ever dimension is the least in the
overlapping volume , i.e. if the object is penetrating another
along the z axis, then the dimension of the overlap region along
the z axis will be least |
| 14:35.14 |
abhi2011 |
of course the
best way would be to make the normal point according to the
curvature of the 2nd body |
| 14:39.16 |
abhi2011 |
like so :
https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit |
| 14:40.23 |
abhi2011 |
but then rays
hitting the curving surface would give many normals, so the proper
normal has to be chosen, which can be got by vector summing I
guess |
| 14:45.59 |
abhi2011 |
funny warning
about the IGNORE symbol being redefined : http://bin.cakephp.org/view/1298213576 |
| 14:46.24 |
brlcad |
yeah, that
channel is quite most of the time, but every now and then a
discussion sparks up |
| 14:47.39 |
brlcad |
good to know
about the IGNORE redefinition |
| 14:52.10 |
brlcad |
abhi2011: we
actually include measures to define our IGNORE macro without
conflicting with the windows macro |
| 14:52.23 |
brlcad |
so somewhere
a windows header is getting included without our usual
protections |
| 14:53.44 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.84.102) |
| 14:53.45 |
brlcad |
abhi2011: AHA
... I think I found the problem -- you must include common.h before
any/all *system* headers |
| 14:54.01 |
abhi2011_ |
ok |
| 14:54.25 |
brlcad |
you saw my
other comments? |
| 14:55.52 |
brlcad |
irc
problems? |
| 15:03.30 |
abhi2011 |
brlcad: yes ,
yes I saw them till : good to know about the IGNORE redefinition
and then AHA |
| 15:03.47 |
abhi2011 |
yeah,
disconnected in between |
| 15:05.44 |
abhi2011 |
yep I ll move
up common.h |
| 15:10.34 |
abhi2011 |
hmm ,warning
is still there though |
| 15:11.54 |
abhi2011 |
I think the
issues is that a similar macro has been defined in both
places |
| 15:11.57 |
abhi2011 |
not the
order |
| 15:12.14 |
abhi2011 |
winbase.h
& common.h |
| 15:20.11 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47378 10/brlcad/trunk/src/libged/simulate/ (9
files): |
| 15:20.33 |
abhi2011 |
ok hope the
commit went through fine, committing from windows with tortoise svn
for the 1st time |
| 15:35.38 |
abhi2011 |
so is there a
function already, which lets me check if a solid is present in the
tree of a comb |
| 15:36.26 |
abhi2011 |
I can write
one to recursively check the tree of a comb, and if it find the
solid, then return true, but perhaps one already exists |
| 15:37.03 |
abhi2011 |
I need it for
checking which comb, a solid belongs to , when rt gives me a solid
at the point where a ray exits |
| 15:37.26 |
abhi2011 |
I then need
to sum the normal only for that comb(rigid body) |
| 15:38.46 |
abhi2011 |
dbfind is
there I see |
| 15:46.49 |
abhi2011 |
yep,
ged_find, does exactly that , traversing in LNR order, will modify
it a bit(in my own file) :P |
| 16:42.13 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47379 10/brlcad/trunk/src/libged/simulate/
(simutils.c simutils.h): Added a function to check if a solid is
present in a comb, required for checking which rigid body(a comb),
a particular solid belongs to , while raytracing. |
| 18:04.29 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 18:52.50 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47380 10/brlcad/trunk/src/libged/simulate/ (simrt.c
simrt.h simulate.h): |
| 18:54.23 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47381 10/brlcad/trunk/src/libged/simulate/simrt.c:
Added code for normals |
| 19:10.11 |
*** join/#brlcad Forth
(~Forth@92.242.118.253) |
| 19:11.55 |
*** part/#brlcad Forth
(~Forth@92.242.118.253) |
| 19:16.19 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47382 10/brlcad/trunk/src/libged/simulate/simrt.c:
More supporting code to test if the normals are being recorded
correctly during the ray trace |
| 19:18.11 |
brlcad |
abhi2011: of
course the macro is defined in both places, but the places we
include windows headers takes care of that |
| 19:18.40 |
brlcad |
so if that
conflict is encountered, some assumption is failing or the header
inclusion ordering is wrong or the wrong headers are being
included |
| 19:19.35 |
brlcad |
winbase.h
shouldn't be directly included anywhere, so you have to look at the
header includes to recursively see who includes
winbase.h |
| 19:19.36 |
abhi2011 |
ok |
| 19:20.44 |
brlcad |
abhi2011:
what was r47378? |
| 19:21.14 |
brlcad |
commit
message got left off, not clear what changed since it was a fairly
big commit .. wondering what it was |
| 19:21.25 |
abhi2011 |
it was an
update of the source code to use contact pairs again |
| 19:21.33 |
brlcad |
ah,
okay |
| 19:21.39 |
abhi2011 |
new svn
software :P |
| 19:21.44 |
abhi2011 |
forgot to add
message |
| 19:21.46 |
brlcad |
yep, realized
that |
| 19:22.01 |
abhi2011 |
so I have an
awesome idea now about how to generate normals |
| 19:22.22 |
abhi2011 |
basically
summing the normals in the surface inside the overlap
region |
| 19:23.03 |
brlcad |
sounds good
:) |
| 19:23.20 |
abhi2011 |
the vector
sum of the normals on the outer surface of the body gives the
direction of the force that the body would apply on anything
touching it |
| 19:23.28 |
abhi2011 |
as is the
case in the real world |
| 19:23.54 |
abhi2011 |
once I have
the normal, I ll shoot rays in that direction to get the depth of
penetration |
| 19:24.27 |
abhi2011 |
and then the
contact points (which should be on the surface of the body always),
are the points where these rays leave the object |
| 19:24.33 |
brlcad |
could you use
the velocity vector of the object in motion too? |
| 19:24.49 |
abhi2011 |
yes I can
vectgr sum that to the normal too |
| 19:24.56 |
abhi2011 |
or just use
the velocity vector |
| 19:25.08 |
abhi2011 |
but the point
is no matter what the velocity vectpr |
| 19:25.19 |
brlcad |
why wouldn't
you just use the velocity vector, shoot rays in the direction of
the velocity, calculate the depth of penetration? |
| 19:25.20 |
abhi2011 |
the force
will be based on the surface |
| 19:25.41 |
abhi2011 |
well because
it depeds on both |
| 19:26.01 |
abhi2011 |
the angle of
the surface and the velocity direction at which the object
strikes |
| 19:26.09 |
abhi2011 |
that
surface |
| 19:26.18 |
brlcad |
okay |
| 19:26.36 |
abhi2011 |
like a ray
reflecting off a glass at an angle |
| 19:26.43 |
brlcad |
nods, makes sense |
| 19:26.46 |
brlcad |
misunderstood |
| 19:26.47 |
abhi2011 |
so hav to
think about how to account for the velocity |
| 19:26.52 |
abhi2011 |
ah |
| 19:27.00 |
abhi2011 |
the angle
between normal and velocity |
| 19:27.13 |
abhi2011 |
law of
reflection calculation maybe |
| 19:27.45 |
abhi2011 |
but hmm, I
think bullet will take care of that |
| 19:27.56 |
abhi2011 |
the fnal
velocity direction i mean |
| 19:28.04 |
abhi2011 |
all I need to
give it is the normal |
| 19:28.12 |
abhi2011 |
at the point
of contact |
| 19:29.34 |
abhi2011 |
here are some
sample cases :
https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit |
| 19:30.49 |
abhi2011 |
so the lower
left case, shows that the concave case should also be possible to
calculate correctly |
| 19:31.27 |
abhi2011 |
if this works
out then I can check how to insert multiple manifolds, which I have
read somewhere , is possible |
| 19:52.51 |
brlcad |
can't get to
gdocs at the moment, will have to take a look later |
| 19:54.54 |
CIA-109 |
BRL-CAD:
03bob1961 * r47383
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: When opening
a database also change the current working directory to the
directory where the database lives. |
| 20:02.17 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.81.190) |
| 20:15.49 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.81.155) |
| 20:46.01 |
CIA-109 |
BRL-CAD:
03starseeker * r47384
10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-xml-catalog.xml.in:
I don't think this variable needs to be specific to BRL-CAD in this
case... |
| 20:52.33 |
CIA-109 |
BRL-CAD:
03starseeker * r47385 10/geomcore/trunk/ (12 files in 5 dirs): Turn
on docbook documentation for geomcore. Stub in a geometry protocol
doc, but nothing much there at the moment. |
| 20:56.01 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47386 10/brlcad/trunk/src/libged/simulate/ (simrt.c
simrt.h simutils.c simutils.h): Now the entry and exit solids of a
ray passing through an overlap region are checked to see if they
belong to the comb of rigid body B |
| 20:59.16 |
brlcad |
deadline is
today -- feel free to fill out quick/easy tasks that could be
completed in 1-3 days at http://brlcad.org/wiki/Contributor_Quickies |
| 20:59.40 |
brlcad |
I'm crafting
together our proposal now |
| 20:59.58 |
brlcad |
ideally we
need 10 topics for each of the 8 categories |
| 21:00.49 |
``Erik |
'separate out
libnmg' O.o I have vague recollection of libnmg not too long ago
:) |
| 21:00.55 |
brlcad |
well, 5-10
tasks per topic |
| 21:01.37 |
``Erik |
think
simd/sse vmath might be worth an entry? |
| 21:03.02 |
brlcad |
iirc,
include/vector_*.h was (as anticipated) an attempt at
that |
| 21:03.04 |
brlcad |
and it
failed |
| 21:03.53 |
brlcad |
test harness
for vmath.h might be something though |
| 21:04.28 |
brlcad |
example of
gnome tasks https://live.gnome.org/GoogleCodeIn/Tasks |
| 21:04.55 |
brlcad |
I'm inclined
to direct all students to either IRC or the mailing list, thoughts
on which? |
| 21:05.12 |
brlcad |
keeping in
mind that it might be a lot of students 24-7 |
| 21:05.13 |
``Erik |
in looking at
that a while back, the choice to go with typedef point_t
fastf_t[3]; instead of typedef point_t struct { fastf_t f[3]; }; or
something was ... critical |
| 21:06.16 |
brlcad |
it wasn't a
fail in terms of being a drop-in replacement -- that would have
been the technical issue there |
| 21:06.46 |
brlcad |
it was a fail
in that the simd version wasn't actually faster -- needed more
data, not just one vector/matrix at a time |
| 21:07.01 |
starseeker |
fix tkhtml3
on Win64? |
| 21:07.22 |
starseeker |
for large
numbers of students, I'd vote mailing list |
| 21:07.23 |
``Erik |
I think irc
will be quicker and more accepting of newbs |
| 21:07.31 |
starseeker |
hard to track
conversations though |
| 21:07.34 |
brlcad |
starseeker:
can you explain the problem? |
| 21:07.39 |
``Erik |
but irc would
lack good record |
| 21:07.45 |
starseeker |
probably not
well enough for a student |
| 21:07.46 |
brlcad |
remember that
these are *high school* students |
| 21:08.08 |
brlcad |
the questions
are going to be very much "hold my hand", what's next? |
| 21:09.23 |
brlcad |
bhinesley:
jordisayol: louipc: kanzure: anyone else: interested in being a GCI
mentor? |
| 21:10.20 |
starseeker |
brlcad: what
about bu_getopt_long or some such? |
| 21:10.57 |
starseeker |
just getting
it working + adding it to one command would be a good
start |
| 21:11.45 |
brlcad |
I don't think
bu_getopt_long is what we want really (at least there's
little-to-no value in having a bu version of
getopt_long()) |
| 21:12.09 |
starseeker |
uh... rt with
-- options seems worthwhile... |
| 21:12.10 |
brlcad |
we need long
options, but there's no reason it needs to be compatible with that
extension |
| 21:12.42 |
starseeker |
do they do it
the wrong way? |
| 21:12.43 |
brlcad |
getopt_long()
is an overlay with getopt() .. the two work suckily
together |
| 21:13.04 |
brlcad |
pretty
much |
| 21:13.28 |
starseeker |
we need
something - what do you suggest? |
| 21:14.09 |
brlcad |
writing an
option interface for bu |
| 21:14.20 |
brlcad |
already
sketched out the basics a month or two ago |
| 21:14.31 |
starseeker |
erm.
link? |
| 21:14.45 |
brlcad |
no
link |
| 21:14.46 |
brlcad |
code in a
checkout |
| 21:14.50 |
starseeker |
ah |
| 21:15.02 |
brlcad |
still, too
advanced for gci I think |
| 21:15.08 |
starseeker |
k.
pity |
| 21:15.24 |
brlcad |
if it's not
something that'd take you less than a half a day from start to
finish, it's probably too complex |
| 21:15.59 |
brlcad |
13 year olds
... |
| 21:16.02 |
starseeker |
well, there's
always fixing the bbox function for bots |
| 21:16.29 |
brlcad |
sure -- could
put that one up, but i'd mark it hard :) |
| 21:18.50 |
abhi2011 |
I think tcl
and gui will be easier for high school students :) |
| 21:19.04 |
abhi2011 |
maybe more of
tcl and some libged related code |
| 21:19.10 |
brlcad |
from other
project's reviews from prior years, the kids really do end up being
a nearly full-time effort so we need to manage the complexity up
front -- things we can explain and point trivially |
| 21:19.19 |
starseeker |
heh - I can't
seem to come up with small projects from the gui
side... |
| 21:19.25 |
brlcad |
abhi2011: you
have some project ideas? |
| 21:19.30 |
abhi2011 |
for example
the idea about integrating some of the visualization tools into the
gui |
| 21:19.45 |
abhi2011 |
most of them
have a fixed interface I guess |
| 21:19.48 |
brlcad |
remember that
it's basically a contest -- they're looking for tasks that take
hours or a day or two at most |
| 21:20.00 |
abhi2011 |
oh
ok |
| 21:20.22 |
brlcad |
which
includes the time to download the software, become familiar with
the problem, find their way around, run a tool, etc |
| 21:21.05 |
abhi2011 |
hmm, then tcl
and gui stuff would be tough |
| 21:21.23 |
brlcad |
came up with
what I think is a GREAT idea at the mentor summit... we can create
a preconfigured disk image for the students that already has a
source checkout and compiled install ready to go |
| 21:22.14 |
brlcad |
that with a
few simple instructions to download qemu, download disk image,
create new image, run .. source is here, binaries are there,
go! |
| 21:24.46 |
abhi2011 |
yes, that can
really get things going fast, did that for virtual box images
once |
| 21:25.21 |
abhi2011 |
so we are not
expecting code from them I guess, they design something using the
tools already present in brlcad ? |
| 21:25.59 |
brlcad |
you seen the
http://brlcad.org/wiki/Contributor_Quickies
list? |
| 21:26.03 |
brlcad |
it can be a
code project |
| 21:26.12 |
brlcad |
or docs, or
web or ... anything really |
| 21:26.21 |
brlcad |
something
that'd take hours of time |
| 21:28.19 |
abhi2011 |
ok |
| 21:33.14 |
abhi2011 |
well I was
thinking along the lines of making mged a bit easier to use : like
when an object is selected and the primitive editor is opened,
then the selected object's name should already be there and it
should be displaying the object name |
| 21:33.48 |
CIA-109 |
BRL-CAD:
03128.63.32.62 07http://brlcad.org
* r3193 10/wiki/Contributor_Quickies: /* Code */ add rt_bot_bbox
item |
| 21:34.03 |
abhi2011 |
or even
simpler, ensuring that closing the command window closes the
application |
| 21:34.47 |
abhi2011 |
including the
gfx window |
| 21:35.04 |
starseeker |
that... might
not be so simple, actually |
| 21:35.13 |
abhi2011 |
oh
:) |
| 21:35.23 |
starseeker |
seems to recall brlcad working with that
once... |
| 21:35.26 |
abhi2011 |
low level
opengl callbacks ? |
| 21:35.35 |
starseeker |
don't recall
now |
| 21:36.25 |
starseeker |
brlcad: is
excising Tcl functions from libraries too hard? (guessing
yes...) |
| 21:37.02 |
abhi2011 |
also is there
a script for moving the view along a specified path, it would be
awesome to write a script or a simple c function that revolves the
camera around the scene as objects are dropping |
| 21:37.08 |
abhi2011 |
*moving the
camera |
| 21:37.18 |
cvds_ |
abhi2011:
please dont, since I use that feature (closing thecommand window
but keeping the gfx window) |
| 21:37.29 |
abhi2011 |
hehe ok
:) |
| 21:37.53 |
abhi2011 |
so you run a
script then close the command window I guess |
| 21:38.27 |
cvds_ |
mged -c to
attach a single window and then set mged_default(multi_pane) 1;
gui; and close the mged command window ;) |
| 21:38.54 |
abhi2011 |
ah
ok |
| 21:40.13 |
cvds_ |
and using
yakuake as the input. Works like a charm |
| 21:40.32 |
starseeker |
brlcad:
http://directory.fsf.org/wiki/Popt |
| 21:40.40 |
starseeker |
http://rpm5.org/files/popt/popt-1.16.tar.gz |
| 21:40.46 |
starseeker |
would that be
of interest? |
| 21:41.38 |
starseeker |
looks like
MIT style license |
| 21:48.02 |
starseeker |
(not for GCI
per say, but as an alternative to rolling our own option
parsing?) |
| 21:59.21 |
brlcad |
abhi2011:
having the closure of all of mged's windows actually close mged
sounds like a great task -- can you add that to the
wiki? |
| 22:00.04 |
brlcad |
starseeker:
not sure what you meant with the excising |
| 22:00.34 |
starseeker |
doing
whatever is needed to get the Tcl/Tk C api usage up to libtclcad
(or steps in that direction) |
| 22:00.35 |
brlcad |
abhi2011:
camera 360 script sounds like another great one, wiki? |
| 22:01.20 |
starseeker |
blinks - must have been thinking something else - I thought
that "close all windows" issue was tied up with something else more
complex |
| 22:01.28 |
brlcad |
cvds_:
interested in being a mentor? :) |
| 22:02.01 |
abhi2011 |
brlcad: sure
and sure :) |
| 22:02.22 |
brlcad |
starseeker:
it's a bug, it used to close mged |
| 22:02.37 |
brlcad |
now you can
close those two windows and mged is still running |
| 22:02.41 |
brlcad |
abhi2011:
awesome :) |
| 22:08.42 |
CIA-109 |
BRL-CAD:
03starseeker * r47387 10/brlcad/trunk/src/ (3 files in 2 dirs):
Shouldn't have moved this, used only internally in libbu and it's
one file. |
| 22:11.06 |
brlcad |
starseeker:
Makefile.am |
| 22:11.20 |
starseeker |
coming
now |
| 22:11.39 |
CIA-109 |
BRL-CAD:
03starseeker * r47388 10/brlcad/trunk/src/ (5 files in 3 dirs):
Clean up the rest of the uce stuff |
| 22:11.41 |
starseeker |
prods CIA |
| 22:21.20 |
CIA-109 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3194 10/wiki/Contributor_Quickies: /* Code */ |
| 22:54.32 |
CIA-109 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3195 10/wiki/Contributor_Quickies: /* Code */ |
| 22:55.37 |
brlcad |
~abhi2011++ |
| 22:55.41 |
brlcad |
awesome |
| 22:55.44 |
CIA-109 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3196 10/wiki/Contributor_Quickies: /* EASY: Camera 360: A Tcl
script to capture images while rotating the view around a scene
*/ |
| 22:56.47 |
abhi2011 |
will try to
come up with some more tomorrow :) |
| 22:56.53 |
brlcad |
we need at
least 3 more outreach and translation tasks, and at least 1 more
research and UI task :) |
| 22:57.01 |
brlcad |
and
QA |
| 22:57.09 |
brlcad |
need at least
5 for each |
| 22:57.58 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 22:59.16 |
abhi2011 |
how about
starting the primitive editor with the currently selected object
instead of having the user type it in each time |
| 22:59.53 |
brlcad |
you mean
sed? |
| 22:59.58 |
brlcad |
sure |
| 23:00.16 |
brlcad |
oh, in the
gui |
| 23:00.20 |
abhi2011 |
yes |
| 23:00.30 |
brlcad |
yeah, that'd
be possible .. a bit complicated to explain, definitely a hard
task |
| 23:00.43 |
brlcad |
your camera
task is probably medium or hard for that matter :) |
| 23:00.47 |
abhi2011 |
yeah it
requires familairity with mged |
| 23:01.01 |
abhi2011 |
yeah
:P |
| 23:01.02 |
brlcad |
easy if you
know mged and know scripting.. but that's a big IF for a 13 year
old :) |
| 23:12.14 |
``Erik |
iff,
even |
| 23:12.38 |
``Erik |
*ponder* logo
on mged? |
| 23:12.59 |
brlcad |
perfect, add
it |
| 23:13.16 |
brlcad |
great
idea |
| 23:13.37 |
``Erik |
iirc, logo
was a variant of scheme, soooo... yeah, let's ditch tcl for
lisp! |
| 23:14.11 |
brlcad |
heh |
| 23:14.23 |
brlcad |
took that to mean .. model the BRL-CAD logo in MGED
:P |
| 23:14.52 |
``Erik |
if mged ate
lisp, it'd be automatable... |
| 23:15.00 |
``Erik |
"just a
couple lines" |
| 23:17.38 |
``Erik |
has an old sorbel filter in C *ponder* |
| 23:20.45 |
``Erik |
(whuddya
mean, making each pixel a colored arb8 ain't what ya
meant?) |
| 23:23.18 |
brlcad |
mmhmm |
| 23:23.33 |
brlcad |
pix-g will do
it now :) |
| 23:25.33 |
``Erik |
pix2g ya
mean? |
| 23:25.43 |
brlcad |
right |
| 23:25.55 |
brlcad |
didn't want
it to look like a proper tool :) |
| 23:26.07 |
``Erik |
does not recall that puppy |
| 23:26.30 |
brlcad |
proc-db |
| 23:26.35 |
``Erik |
and I keep
typing 'git log', starseeker has poisoned my brain |
| 23:26.57 |
``Erik |
it's old,
even |
| 23:27.12 |
brlcad |
yeah, did
that a long time ago |
| 23:27.21 |
brlcad |
fairly
useless, but fun hack |
| 23:27.39 |
``Erik |
is it
actually a planar arb8 set with colors? |
| 23:28.01 |
brlcad |
I started
with arbs, but I think that last rev uses spheres |
| 23:28.15 |
brlcad |
trivial to
put it back |
| 23:28.38 |
``Erik |
painter and
smoother might replicate something acceptable... push it to nurbs
and it's all good |
| 23:29.31 |
``Erik |
(curve fit on
a nurb is a whole lot easier than attempting to replicate geometry
in implicits, right?) |
| 23:29.57 |
``Erik |
srry, on a
nurbs |
| 23:32.00 |
brlcad |
you going to
add that logo task? that really is a great idea |
| 23:32.55 |
``Erik |
I'll let
you... I actually meant the language "logo" |
| 23:33.59 |
``Erik |
if you want
to give me credit for sparking the idea in you, that's cool, but
that definitely isn't what I meant :) |
| 23:36.26 |
brlcad |
even better
if you'd write it, cause writing this proposal is going to have me
right up against the submission deadline |
| 23:36.54 |
``Erik |
which
logo? |
| 23:37.18 |
brlcad |
the new
logo |
| 23:37.38 |
brlcad |
point them to
the news page on the main website |
| 23:38.25 |
``Erik |
I have a cat
on my lap, and I'm not sure if he's actually alive anymore
O.O |
| 23:40.29 |
``Erik |
abhi has no
user page |
| 23:42.32 |
``Erik |
I d'no, doco
or ux? |
| 23:43.06 |
``Erik |
I'll go ahead
and call it ux |
| 23:49.38 |
``Erik |
ffs, WoW is
stomping my machine here O.o 20-30 seconds before a keypress
registers in other apps :/ |
| 23:49.39 |
brlcad |
<PROTECTED> |
| 23:55.08 |
CIA-109 |
BRL-CAD:
03Erik 07http://brlcad.org * r3197
10/wiki/Contributor_Quickies: /* User Interface */ Add .g of logo
task |
| 23:55.53 |
``Erik |
wordsmith
your heart out, probably needs a time guess |
| 23:56.00 |
brlcad |
k |
| 23:56.41 |
brlcad |
ideas on
hold.. the deadline apparently isn't .. what I calculated it to be
.. (ffs.) |
| 23:56.52 |
brlcad |
just went to
submit (early) and .. it's not |
| 23:59.34 |
CIA-109 |
BRL-CAD:
03128.63.32.74 07http://brlcad.org
* r3198 10/wiki/Contributor_Quickies: move logo to outreach, needs
two more |
| 00:00.18 |
``Erik |
ooh, not
logged in, and still at the office |
| 00:00.42 |
brlcad |
wonder who
that is |
| 00:01.16 |
CIA-109 |
BRL-CAD:
03Erik 07http://brlcad.org * r3199
10/wiki/Contributor_Quickies: /* EASY: Model new BRL-CAD Logo using
BRL-CAD */ Add time guess |
| 00:03.43 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3200
10/wiki/Contributor_Quickies: clarify docs |
| 00:04.31 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3201
10/wiki/Contributor_Quickies: already had time estimate added,
update |
| 00:06.15 |
``Erik |
whups,
assumed fime would be between body and references |
| 00:09.06 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3202
10/wiki/Contributor_Quickies: /* Outreach */ idea on interviewing
jordi |
| 00:14.11 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3203
10/wiki/Contributor_Quickies: /* Outreach */ another on writing
geometry cpp articles |
| 00:26.48 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3204
10/wiki/Contributor_Quickies: /* Quality Assurance */ deep unit
test, and find bugs in archer |
| 00:32.44 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3205
10/wiki/Contributor_Quickies: /* Research */ update the
spreadsheet |
| 00:39.42 |
*** join/#brlcad juan_man
(~quassel@unaffiliated/juanman) |
| 00:41.04 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3206
10/wiki/Contributor_Quickies: /* User Interface */ reorganize
mged's menu |
| 00:47.38 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3207
10/wiki/Contributor_Quickies: /* Translation */ translate our intro
mged docs |
| 00:55.12 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3208
10/wiki/Contributor_Quickies: /* Translation */ be specific on the
desired languages |
| 00:56.57 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3209
10/wiki/Contributor_Quickies: /* Translation */ |
| 01:01.55 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3210
10/wiki/Contributor_Quickies: /* Translation */ HACKING |
| 01:04.40 |
CIA-109 |
BRL-CAD:
03Sean 07http://brlcad.org * r3211
10/wiki/Contributor_Quickies: /* Translation */ our portuguese
contingent deserve props for all the attention they've given over
the years |
| 01:07.25 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 02:09.50 |
starseeker |
hah cool,
didn't know about this project: http://www.helenos.org/ |
| 04:04.36 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.89.70) |
| 04:09.09 |
CIA-109 |
BRL-CAD:
03Abhi2011 07http://brlcad.org *
r3212 10/wiki/Contributor_Quickies: /* EASY: Translate a chapter
from the Introduction to MGED to Hindi */ |
| 04:09.21 |
abhi2011 |
:P |
| 06:16.49 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 06:25.15 |
abhi2011 |
hmm getting a
number of erros from a custom build rule in cmakelist.txt :
http://bin.cakephp.org/view/1879910803 |
| 07:00.39 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47389 10/brlcad/trunk/src/libged/simulate/simutils.c:
Corrected a bug in the primitive lookup code for a comb |
| 08:36.30 |
cvds_ |
tgc(thumbPlungerTop1.s): A not
perpendicular to B, f=-0.21693 <-- hmmm I did not know this was
a requirement -_- |
| 08:36.57 |
cvds_ |
in
thumbPlungerTop1.s rec 0 0 0 0 0 3 0 7.5 0 22.5 -5 0 <-- this is
what I more or less want |
| 08:38.29 |
cvds_ |
(its combined
with a in thumbPlungerTop2.s rpp 0 32.5 -7.5 7.5 0 3 thats why its
not perpendicular) |
| 08:53.55 |
cvds_ |
resolved it
by orot the rec inside the combination then pushing it |
| 10:03.53 |
cvds_ |
brlcad: I
ordered a lot of thing for the printer so hopefully I can give you
those pictures somewhere december (provided I can tune the printer
well enough) |
| 10:32.45 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 10:32.45 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 10:32.45 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
| 10:32.45 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
| 10:33.21 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
| 10:34.09 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 10:34.18 |
*** join/#brlcad cvds_
(~leila@h111030.upc-h.chello.nl) |
| 10:34.50 |
*** join/#brlcad packrat
(~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 10:51.43 |
*** join/#brlcad bhinesley
(~bhinesley@adsl-99-52-241-103.dsl.bkfd14.sbcglobal.net) |
| 10:51.43 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
| 10:51.43 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 10:51.43 |
*** mode/#brlcad [+o ChanServ] by
calvino.freenode.net |
| 11:21.43 |
CIA-109 |
BRL-CAD:
03starseeker * r47390 10/brlcad/trunk/src/libbu/CMakeLists.txt:
Whoops, ignoring wrong file |
| 11:53.06 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.84.234) |
| 12:02.05 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.88.30) |
| 12:05.36 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:45.27 |
*** join/#brlcad juanman
(~quassel@201.216.198.121) |
| 12:45.32 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
| 12:51.41 |
brlcad |
cvds_: if
you'd like to generalize the tgc even further, go for it
;) |
| 12:52.02 |
brlcad |
the
intersection calculations get even more hairy if they're not
perpendicular |
| 12:52.54 |
brlcad |
you can get
non-perpendicular caps with a subtraction, so it's still an
achievable shape -- just not with one tgc |
| 12:53.32 |
brlcad |
can't wait to
see the pics ;) |
| 13:34.12 |
CIA-109 |
BRL-CAD:
03brlcad * r47391 10/brlcad/trunk/HACKING: freshmeat change their
name to freecode |
| 13:47.28 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.86.135) |
| 14:53.45 |
cvds_ |
brlcad: I
see, I sorted it with a normal rec, looks good enough for
now |
| 14:55.44 |
cvds_ |
http://flic.kr/p/aBer23 you can see
the result here |
| 14:57.59 |
CIA-109 |
BRL-CAD:
03brlcad * r47392 10/brlcad/trunk/HACKING: |
| 14:57.59 |
CIA-109 |
BRL-CAD: add
a regex one-liner awesomeness for automatically extracting the
latest NEWS |
| 14:57.59 |
CIA-109 |
BRL-CAD:
section into a release notes README-#-#-#.txt file. also fix the
release steps |
| 14:57.59 |
CIA-109 |
BRL-CAD: so
that binary platform maintainers are notified before public
release |
| 14:57.59 |
CIA-109 |
BRL-CAD:
announcements are posted (so they can have a chance to get started
on binary |
| 14:57.59 |
CIA-109 |
BRL-CAD:
builds) |
| 15:07.14 |
cvds_ |
and for the
live of me I dont get solid rotation |
| 15:15.38 |
cvds_ |
rot takes
into account current view angle ? |
| 15:18.39 |
cvds_ |
hmm arot
actually seem to do what I expect |
| 15:30.33 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 15:36.47 |
brlcad |
cvds_:
primitives rotate around some primitive-specific keypoint, which
might not be where you'd expect an origin to be |
| 15:37.01 |
brlcad |
for a
cylinder, for example, it's the center of the base
ellipse |
| 15:37.11 |
brlcad |
for an arb8,
it's the first corner |
| 15:37.50 |
brlcad |
you'd
probably expect the object center for both, but to get that
behaviour you'll either need to use one of the other rotation
commands or set a keypoint explicitly |
| 15:38.50 |
cvds_ |
brlcad: nope,
with rot I was expecting a rotation over 1 primary vertex, but it
rotated over more. with arot I specify the vertex explicitly and
things are spiffy ;_ |
| 15:38.53 |
cvds_ |
:) |
| 15:47.38 |
CIA-109 |
BRL-CAD:
03brlcad * r47393 10/brlcad/trunk/src/util/ (bw-png.c pix-png.c
png-bw.c png-pix.c png_info.c): zlib.h needs to be included before
png.h in case compression flags are used. also, they're system
headers, so use brackets instead of quotes and pull them up into
the right section. |
| 15:50.07 |
CIA-109 |
BRL-CAD:
03brlcad * r47394 10/brlcad/trunk/src/libged/png.c: they're system
headers, so use brackets instead of quotes and pull them up into
the right section. |
| 15:52.35 |
CIA-109 |
BRL-CAD:
03brlcad * r47395 10/brlcad/trunk/src/fb/ (fb-png.c png-fb.c): more
header cleanup. png/zlib are system headers. use bin.h instead of
directly including winsock.h |
| 16:11.34 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.83.152) |
| 16:31.16 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47396 10/brlcad/trunk/src/libged/simulate/simrt.c:
Shooting rays in y direction now and analyzing the normals
generated. |
| 16:40.11 |
brlcad |
``Erik: you
see the new gcc farm server? |
| 16:40.25 |
brlcad |
64-proc
power7 .. frickin awesome :) |
| 16:40.52 |
brlcad |
rather,
64-core |
| 16:47.08 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 17:04.46 |
brlcad |
starseeker:
http://paste.debian.net/142105/ |
| 17:05.39 |
brlcad |
that was a
default "cmake .." build |
| 17:48.52 |
cvds_ |
http://flic.kr/p/aBfMH8 <-- fun
making these shapes |
| 17:56.59 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47397 10/brlcad/trunk/src/libged/simulate/ (simrt.c
simrt.h): Added code for shooting z rays and analyzing
normals. |
| 18:07.46 |
brlcad |
cvds_: nice
:) |
| 18:07.59 |
brlcad |
some sort of
switch? |
| 18:08.08 |
brlcad |
electric
contact switch ? |
| 18:12.14 |
*** join/#brlcad Forth
(~Forth@92.242.118.253) |
| 18:53.45 |
CIA-109 |
BRL-CAD:
03128.63.32.62 07http://brlcad.org
* r3213 10/wiki/Early_Raytracing_History: Stub out page for
organizing early raytracing historical reports |
| 18:55.31 |
starseeker |
brlcad: are
the opengl headers present? |
| 18:56.01 |
starseeker |
what
platform? |
| 18:58.29 |
brlcad |
I don't see
any opengl headers |
| 18:58.36 |
brlcad |
it's a
linux |
| 18:59.06 |
brlcad |
looks like
it's Fedora 16 |
| 19:01.26 |
starseeker |
hmm. Yeah,
that's not going to be a widely tested setup |
| 19:01.30 |
brlcad |
obviously I
could probably disable opengl and get past this, but implies the
cmake logic isn't right if the default case doesn't properly
autodetect and disable |
| 19:01.52 |
brlcad |
fedora is
basically a future RHEL |
| 19:01.52 |
starseeker |
it's supposed
to turn off opengl if it's not there, but I'm not surprised it's
not quite right |
| 19:02.10 |
starseeker |
sans-opengl
machines are a rarity these days |
| 19:02.40 |
brlcad |
this is a
brand new system, so not really -- just a different type of
configuration |
| 19:03.04 |
brlcad |
brand new ibm
power series |
| 19:03.08 |
starseeker |
correction -
they *should* be a rarity these days, even if they
aren't |
| 19:03.17 |
brlcad |
server
platform |
| 19:03.21 |
starseeker |
still |
| 19:03.25 |
brlcad |
servers
rarely have graphics cards :P |
| 19:03.32 |
starseeker |
people run
opengl apps on servers |
| 19:03.56 |
brlcad |
not
necessarily on compute servers |
| 19:05.36 |
brlcad |
regardless,
it's a bonefide build system bug so it should get
fixed... |
| 19:23.19 |
*** join/#brlcad Forth
(~Forth@92.242.118.253) |
| 19:47.18 |
CIA-109 |
BRL-CAD:
03starseeker * r47398 10/brlcad/trunk/ (3 files in 3 dirs): Tweak
the OpenGL find routines to care more if the headers are
found. |
| 20:00.17 |
cvds_ |
brlcad: thumb
controlled switch. Magnetic / optical |
| 20:01.45 |
brlcad |
~starseeker++ |
| 20:01.52 |
brlcad |
that seems to
have done the trick, trying the build now |
| 20:02.31 |
brlcad |
giggles at make -j100 |
| 20:02.57 |
cvds_ |
-j100 ...
thats many many cores |
| 20:03.07 |
cvds_ |
I run -j9
*3 |
| 20:09.22 |
brlcad |
it's a 64
core server |
| 20:09.37 |
brlcad |
so it
actually should be able to juggle that many efficiently
:) |
| 20:10.03 |
brlcad |
lesse how
long this build takes.. :) |
| 20:10.18 |
starseeker |
winces... that's some heavy duty
parallelism |
| 20:11.05 |
starseeker |
haven't
actually tried a non-opengl build for months |
| 20:22.25 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47399
10/brlcad/trunk/src/libged/simulate/simrt.c: |
| 20:22.25 |
CIA-109 |
BRL-CAD: Some
bug fixes to ray shots, now the normals for rigid body B are
summed |
| 20:22.25 |
CIA-109 |
BRL-CAD:
correctly when there are overlapping objects : rigid body A and
rigid body B. |
| 20:22.25 |
CIA-109 |
BRL-CAD: Next
is shooting a bunch of rays in the direction opposite to this
normal, to |
| 20:22.25 |
CIA-109 |
BRL-CAD:
measure the depth of penetration of B into A and finally calculate
the bunch of |
| 20:22.26 |
CIA-109 |
BRL-CAD:
contact points on the surface of B which lies inside A(due to the
penetration). |
| 20:22.27 |
CIA-109 |
BRL-CAD: Then
we have all the required info to inject into Bullet |
| 20:22.33 |
CIA-109 |
BRL-CAD:
03starseeker * r47400 10/brlcad/trunk/src/other/CMakeLists.txt: If
we turn off opengl, turn off togl too |
| 20:32.11 |
brlcad |
starseeker:
hehe, we have a new winner! |
| 20:32.12 |
brlcad |
Elapsed
compilation time: 41 seconds |
| 20:32.13 |
brlcad |
Elapsed time
since configuration: 1 minute 19 seconds |
| 20:32.21 |
starseeker |
O.O |
| 20:32.37 |
starseeker |
it
succeeded? |
| 20:32.38 |
brlcad |
attempts autotools for comparison |
| 20:32.39 |
brlcad |
yep |
| 20:32.53 |
starseeker |
if you're
doing autotools compare, make sure you turn off the static
libs |
| 20:33.01 |
starseeker |
(unless you
enabled them in CMake) |
| 20:33.40 |
brlcad |
they're
default enabled in cmake, so it's fair |
| 20:33.50 |
starseeker |
only for
release config |
| 20:34.01 |
starseeker |
unless
something changed, I have them off in Debug mode |
| 20:35.15 |
brlcad |
hm,
hm |
| 20:35.40 |
starseeker |
(cept for
opennurbs - need to fix that) |
| 20:36.34 |
brlcad |
is the
summary not written out anywhere? |
| 20:36.43 |
starseeker |
you mean to a
file? |
| 20:36.51 |
brlcad |
I see nothing
in the CMakeOutput.log where I'd expect it.. |
| 20:37.02 |
starseeker |
no - it's
just on the console |
| 20:37.22 |
brlcad |
mm, that's
nfg .. there's no way to see the summary ? |
| 20:37.48 |
brlcad |
seeing AUTO
in the cache tells me nothing :) |
| 20:37.59 |
starseeker |
ah |
| 20:38.26 |
starseeker |
can probably
write it to a file easy enough |
| 20:38.47 |
brlcad |
ideally the
entire cmake output |
| 20:39.34 |
brlcad |
but minimally
the summary is super helpeful for debugging, can tell people to
just send you the log file and see what they saw |
| 20:39.57 |
starseeker |
I don't know
of any way offhand to capture just the on-screen output of
CMake |
| 20:39.58 |
brlcad |
use
config.log that way all the time |
| 20:40.14 |
brlcad |
it doesn't
have to be just the output |
| 20:40.16 |
starseeker |
I can teach
my summary logic to make a CMakeSummary.log file |
| 20:40.22 |
brlcad |
config.log is
a superset, for example |
| 20:40.42 |
brlcad |
better to
write to the existing CMakeOutput.log |
| 20:41.11 |
brlcad |
if you need
someone to send you a log, you really only want to have to explain
how to find/send one file |
| 20:44.53 |
starseeker |
right - I
should be able to append to that file |
| 20:45.51 |
brlcad |
three times
I've been bitten by the bundled/system/auto trio |
| 20:46.29 |
starseeker |
bitten
how? |
| 20:46.35 |
brlcad |
most of the
vars are on/off/auto, but the dep build flags aren't |
| 20:46.53 |
CIA-109 |
BRL-CAD:
03bob1961 * r47401 10/brlcad/trunk/src/tclscripts/mged/openw.tcl:
Check the display manager type before setting the zbuffer state in
"proc gui" |
| 20:47.15 |
brlcad |
I configure
with BRLCAD_BUNDLED_LIBS as "ON" .. and don't get them all on,
defaults back to auto because I didn't enter "BUNDLED"
;) |
| 21:24.00 |
CIA-109 |
BRL-CAD:
03brlcad * r47402 10/brlcad/trunk/src/ (12 files in 6 dirs): gcc
continues to get smarter. apply fixes for issues detected by gcc
2.6.1, vars set but unused, unsigned 'char' that need to be int,
and other type corrections. |
| 21:24.24 |
starseeker |
2.6.1? |
| 21:24.28 |
starseeker |
yow |
| 21:26.34 |
*** join/#brlcad merzo
(~merzo@205-134-133-95.pool.ukrtel.net) |
| 21:27.41 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47403 10/brlcad/trunk/src/libged/simulate/ (simrt.c
simrt.h simutils.c): Need to keep track of normals encountered so
far, for a ray passing through rigid_body B, otherwise the same
normals added twice will skew the resultant normal
direction. |
| 21:28.37 |
brlcad |
with static:
Elapsed compilation time: 57 seconds |
| 21:29.01 |
brlcad |
though not as
controlled as the first build |
| 21:29.22 |
brlcad |
libpng is
provoking some ld bug that I had to work around |
| 21:30.37 |
CIA-109 |
BRL-CAD:
03abhi2011 * r47404 10/brlcad/trunk/src/libged/simulate/simrt.c:
Corrected the initialization of the number of normals. |
| 21:31.16 |
starseeker |
still -
pretty darn impressive |
| 21:31.43 |
starseeker |
(or possibly
impressive - perhaps autotools will do as well) |
| 21:33.36 |
starseeker |
brlcad: does
that include docbook? |
| 21:34.59 |
brlcad |
if I had the
summary in a log file, I could tell you ;) |
| 21:35.10 |
starseeker |
heh |
| 21:35.30 |
starseeker |
getting
close |
| 21:35.47 |
brlcad |
autotools
failed in the docbook section after 3min, so presuming it's
compiling the same stuff, cmake is considerably faster |
| 21:36.53 |
brlcad |
though that's
really a comparison of recursive make to non-recursive make, it's
still a huge gain |
| 21:39.47 |
CIA-109 |
BRL-CAD:
03starseeker * r47405 10/brlcad/trunk/ (3 files in 2
dirs): |
| 21:39.47 |
CIA-109 |
BRL-CAD: Try
a cute trick - override the message command to enhance
logging. |
| 21:39.47 |
CIA-109 |
BRL-CAD:
CMakeFiles/CMakeOutput.log should now have almost all messages from
the cmake |
| 21:39.47 |
CIA-109 |
BRL-CAD:
configure process - possible exceptions are those written out
without using the |
| 21:39.47 |
CIA-109 |
BRL-CAD:
MESSAGE command. Also make a stab at accepting ON and OFF for
the |
| 21:39.48 |
CIA-109 |
BRL-CAD:
AUTO/BUNDLED/SYSTEM vars |
| 21:39.48 |
brlcad |
there we go,
so yeah .. about 3min20sec for autotools, enable-all, debug, with
docs (no pdf) |
| 21:40.03 |
brlcad |
that's my
usual compilation benchmark |
| 21:40.12 |
starseeker |
nifty
:-) |
| 21:40.33 |
starseeker |
that's
configure + build? |
| 21:40.54 |
brlcad |
configure was
faster than cmake.. :) |
| 21:41.05 |
starseeker |
humph -
figures |
| 21:41.33 |
brlcad |
and that's
not even considering that I have to run cmake three times if run
via ccmake to get an enable-all build |
| 21:41.51 |
starseeker |
nods - command line cmake ftw |
| 21:41.57 |
brlcad |
the system is
using ccache, so I'll have to rerun to make sure there's not some
object file caching going on too |
| 21:43.25 |
brlcad |
if I could
get a list of our variables from cmake (e.g., cmake
--help-variables) like configure, it'd be more feasible to run via
command-line |
| 21:43.36 |
brlcad |
don't have
the vars memorized |
| 21:43.48 |
starseeker |
nods - I need to finish the configure.cmake
script |
| 21:44.20 |
starseeker |
I've got
enable-all in there, but not the static libs flag |
| 21:44.52 |
brlcad |
in
where? |
| 21:45.01 |
brlcad |
oooh,
wrapper |
| 21:45.05 |
starseeker |
yeah |
| 21:45.21 |
brlcad |
bleh, that's
cheating :) |
| 21:45.27 |
starseeker |
have expected you to take that and finish it so you wouldn't
have to worry about the CMake options anymore |
| 21:45.33 |
starseeker |
:-P |
| 21:46.07 |
brlcad |
only after
the core system is already near-optimal |
| 21:46.16 |
brlcad |
hacking on
top of hacks is bad practice |
| 21:46.57 |
brlcad |
that goes for
absolutely any code, it's only closed API that you have to put up
with that |
| 21:47.14 |
starseeker |
hopes to $deity that we don't have much further to go, but
suppose he knows better... |
| 21:47.28 |
brlcad |
I give it
about two years |
| 21:52.38 |
brlcad |
doesn't
persist an "off" setting, otherwise looks like it's
closer |
| 21:55.33 |
brlcad |
there, more
controlled rebuild was 1min38sec |
| 21:55.49 |
brlcad |
cmake, enable
all (cept png), debug, with docs |
| 21:55.55 |
brlcad |
not too
shabby |
| 21:56.08 |
brlcad |
double that
time for the three config passes |
| 21:57.23 |
starseeker |
the second
and third config passes should be considerably
shorter... |
| 21:59.27 |
cvds_ |
about 50%
according to the previous statement ? |
| 22:00.51 |
brlcad |
there, about
3min30sec for a repeat autotools build |
| 22:01.10 |
brlcad |
so roughly
cutting the time in half or a third |
| 22:01.46 |
cvds_ |
heh... using
combination and oed you can cut back on a lot of solids |
| 22:04.47 |
CIA-109 |
BRL-CAD:
03starseeker * r47406 10/brlcad/trunk/misc/CMake/
(BRLCAD_Util.cmake ThirdParty_TCL.cmake): Check for on and off in
the optname, not the default |
| 22:38.06 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 00:05.45 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 01:08.54 |
jarray52 |
louipc: What
would be the primary limitations of using brl-cad for designing
something like a car, motorcycle, diesel generator, or
satellite? |
| 01:10.56 |
jarray52 |
And the
primary advantages over AutoCad or solidworks? |
| 01:59.46 |
starseeker |
makes a note to read this in more detail: http://www.linuxjournal.com/article/3687 |
| 02:02.42 |
louipc |
jarray52:
brl-cad has no dimensioning feature, or 2d drafting ability, no
step export, and step import is still in development |
| 02:05.41 |
louipc |
jarray52: one
of brl-cad's main purposes was for ballistics analysis for the
military, so it doesn't have the regular CAD stuff you usually
expect |
| 02:08.42 |
louipc |
jarray52: not
even a shaded view for solids in editing.. you have to explicitly
render the view |
| 02:09.32 |
jarray52 |
What are its
primary advantages? |
| 02:10.34 |
louipc |
seems more
geared for making 'true' solids |
| 02:10.36 |
jarray52 |
over
something like solidworks |
| 02:10.40 |
jarray52 |
or
autocad |
| 02:10.43 |
jarray52 |
other than
cost |
| 02:11.04 |
louipc |
it's not
really in the same realm at the moment |
| 02:11.17 |
louipc |
or ever?
dunno |
| 02:12.29 |
louipc |
depends on
what you want to do I guess |
| 02:12.37 |
jarray52 |
in quality or
purpose? |
| 02:12.45 |
louipc |
purpose |
| 02:13.01 |
jarray52 |
it can export
.dxf |
| 02:13.25 |
louipc |
think
so |
| 02:54.54 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.80.13) |
| 03:23.19 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.86.180) |
| 03:38.20 |
brlcad |
jarray52: the
primary limitation is usability -- like any cad system, there's a
significant learning curve |
| 03:38.30 |
brlcad |
and ours is
particularly steep |
| 03:40.39 |
brlcad |
jarray52:
BRL-CAD's strength is for assisting with a variety of engineering
analysis work, generally niche fields that have
varied/unpredicatble requirements |
| 03:42.41 |
jarray52 |
brlcad: After
getting past the learning curve, is the system nicely
useable? |
| 03:42.53 |
brlcad |
for basic
design/modeling, BRL-CAD is good once you get up the learning curve
but it is a different command-line driven approach that usually
favors people with scripting skills |
| 03:43.21 |
brlcad |
it's usable,
been used for production analysis work in the DoD for several
decades |
| 03:43.29 |
jarray52 |
I'm a
python/c++ programmer with little CAD experience. So, I really like
the idea of scripting oriented CAD. |
| 03:43.54 |
brlcad |
but make no
mistake, that learning curve is steep -- brl-cad is huge with lots
of features and lots of ways to get tasks done ;) |
| 03:44.02 |
jarray52 |
Is the
engineering analysis work limited to
ballistics/electromagnetics. |
| 03:44.06 |
jarray52 |
? |
| 03:44.36 |
jarray52 |
brlcad: Is
the learning curve steeper than learning a programming language
like C++ for the first time? |
| 03:44.45 |
brlcad |
not really,
and we don't even include that analysis logic directly within
BRL-CAD -- hooks are provided to the analysis codes |
| 03:44.58 |
brlcad |
oh heavens
no |
| 03:45.15 |
jarray52 |
what about
learning python for the first time? |
| 03:46.03 |
brlcad |
the biggest
issue is probably that it's not a discoverable system, you'll only
learn by going through tutorials (for which there are EXTENSIVE
tutorials across a range of topics), reading man pages, and
modeling, modeling, modeling |
| 03:46.41 |
brlcad |
I don't think
so, but that's a bit of a skewed question to ask... |
| 03:46.59 |
jarray52 |
Once
mastered, does it have lots of features not found in programs like
autocad, catia, and pro engineer? |
| 03:47.11 |
brlcad |
is it harder
to learn being a professional woodworker or a professional
mechanic? |
| 03:47.24 |
jarray52 |
sorry... |
| 03:47.27 |
brlcad |
they both can
take decades to master ;) |
| 03:47.40 |
jarray52 |
the questions
were misguided... |
| 03:47.57 |
brlcad |
it's fine,
just don't want you to have unrealistic expectations |
| 03:48.27 |
brlcad |
there are
some features BRL-CAD provides that are arguably better or more
powerful than features in commercial CAD systems |
| 03:48.38 |
jarray52 |
such
as? |
| 03:49.15 |
brlcad |
we are one of
the very best at loading superbly complex models with minimal
memory and processing, and still being able to render/analyse those
models more quickly than anyone else |
| 03:49.51 |
brlcad |
notorious for
being able to open models that bring Pro/E, NX, and others to their
knees on a powerful workstation |
| 03:50.24 |
brlcad |
our other
flexibility is in the breadth of flexibility, lots and lots of
tools that you can chain together to get a job done |
| 03:51.47 |
jarray52 |
Just so I
understand... this type of thing could for example be used to model
an aircraft carrier with planes taking off and landing or a space
station with multiple space vehicles docking, leaving, and so
on. |
| 03:52.27 |
jarray52 |
Is that the
type of specialized thing that brlcad would do well? |
| 03:52.28 |
brlcad |
if we were an
operating system code, we'd be more like bsd userland tools and a
bsd microkernel -- not the pretty shiny layer on top ala osx or the
facades of gnome/gtk, windows, etc |
| 03:52.53 |
starseeker |
Our graphical
interactions are very primitive by modern standards |
| 03:52.54 |
jarray52 |
microkernel? |
| 03:53.47 |
starseeker |
jarray52:
more like using a (relatively) small amount of information to
represent complex geometry - that's a specialty |
| 03:53.48 |
jarray52 |
Would this be
a good tool to design and model a diesel or car engine? |
| 03:54.12 |
jarray52 |
with internal
moving parts and all... |
| 03:54.22 |
brlcad |
jarray52:
nevermind the microkernel analogy if it's unfamiliar, the linux
kernel works as an analogy too -- we're (presently) more of a
kernel, not an easy-to-use distribution like ubuntu or
fedora |
| 03:54.22 |
starseeker |
we don't
currently simlulate part interactions |
| 03:54.43 |
brlcad |
jarray52: you
can model just about anything -- it's what you do with the model
once you're done |
| 03:54.45 |
starseeker |
(some nifty
work going on to integrate bullet, but that's in the experimental
stages) |
| 03:55.12 |
brlcad |
so yeah, you
could model up an entire aircraft carrier down to every nut bolt
and wire, no problem |
| 03:55.15 |
starseeker |
jarray52: if
you're going to create a model in BRL-CAD, you'll need to use
constructive solid geometry |
| 03:55.20 |
brlcad |
generate
renderings and visualizations, no problem |
| 03:56.02 |
brlcad |
but then if
you want blueprints -- we can provide the hidden line
blueprint-style image, but not with dimensions or labels
annotated |
| 03:56.33 |
brlcad |
or if you
want an animation, no problem .. but we don't (yet) provide physics
simulations with contact constraints |
| 03:57.16 |
jarray52 |
starseeker: I
don't understand what you mean by "we don't currently simulate part
interactions". |
| 03:57.25 |
brlcad |
jarray52:
take a look at the introduction to mged tutorial and scripting
tutorial on the website, they'll give you a good idea of some
things possible (along with the image gallery) |
| 03:57.29 |
jarray52 |
in light of
the other comments made by yourself and brlcad. |
| 03:57.46 |
starseeker |
jarray52: if
you model two gears and try to have one turn the other, for
example |
| 03:58.00 |
starseeker |
we don't do
that right now |
| 03:58.18 |
brlcad |
jarray52:
http://brlcad.org/wiki/Documentation
<-- #2 |
| 03:58.34 |
brlcad |
and http://brlcad.org/wiki/SGI_Cube
for a very brief scripting example |
| 03:59.12 |
jarray52 |
starseeker:
Does any cad program allow one gear to turn another? |
| 03:59.30 |
brlcad |
yeah, the big
five all have that ability |
| 04:00.02 |
jarray52 |
brlcad: big
five=CATIA, Pro/Engineer, NX, AutoCAD, xxx? |
| 04:00.09 |
brlcad |
you have to
specify a lot of crap to make it happen automagically, but it's
"possible" |
| 04:00.13 |
brlcad |
solidworks |
| 04:00.18 |
jarray52 |
right |
| 04:00.56 |
brlcad |
technically,
it's sorta possible in brl-cad, but that's functionality that was
last used more than 10 years ago |
| 04:01.17 |
brlcad |
we have
someone working on a new system now, way way cooler and easier to
use .. but just getting started :) |
| 04:01.53 |
jarray52 |
brlcad: So,
the user has to specify the motion for animations along with
contact constraints, but it is possible, right? |
| 04:03.06 |
brlcad |
jarray52:
this may be more familiar with your python background .. it's a
perl modeling example, but could do almost exactly the same with
python: http://brlcad.org/wiki/Spiral |
| 04:03.49 |
brlcad |
jarray52:
well like I said -- it's a new system and I wouldn't recommend
trying to use the old system unless you're willing to help
debug |
| 04:04.31 |
brlcad |
until then,
you basically have to manually put geometry where you want it,
motion is just basic model transformations |
| 04:05.06 |
brlcad |
ala
claymation, just not quite as tedious |
| 04:05.21 |
brlcad |
(because you
can script it all) |
| 04:05.58 |
jarray52 |
brlcad:
That's actually very cool because an external program could be
doing calculations and transformations and moving the
parts. |
| 04:06.05 |
brlcad |
louipc: ah,
interesting, I'd tried .1 and it found some new issues .. .2 finds
more .. someone must be actively boosting up those detection
abilities |
| 04:06.41 |
brlcad |
jarray52:
that's actually the intent (and you can see how we start to "fit
in" with external analysis codes) |
| 04:07.59 |
jarray52 |
brlcad: And,
once the model and external analysis code work the way they are
intended to work(in theory at least), the parts can be exported to
.dxf and manufactured. |
| 04:08.55 |
*** join/#brlcad Technicus
(~Technicus@DSLPool-net208-2.wctc.net) |
| 04:09.28 |
jarray52 |
brlcad: I
think you have me sold on BRL-CAD now. |
| 04:10.09 |
starseeker |
jarray52: the
thing that will probably feel strangest about BRL-CAD in its
current form is the lack of 3D shaded displays - we visualize only
with wireframes or raytracing now, unless you happen to have a
triangle based model |
| 04:10.53 |
jarray52 |
Raytracing
with wireframes only? |
| 04:11.05 |
starseeker |
no,
interactive display with wireframe only |
| 04:11.13 |
starseeker |
raytrace is
when it gets pretty :-) |
| 04:11.23 |
brlcad |
interactive
as in grab the mouse and spin the model around -- wireframe
only |
| 04:11.34 |
brlcad |
hit the
render button, though, and you get your pretty shaded
picture |
| 04:12.04 |
jarray52 |
brlcad:
That's acceptable. |
| 04:12.33 |
jarray52 |
brlcad: At
the end of the day, one can sell the pretty picture to a boss or
investors. |
| 04:12.39 |
jarray52 |
:) |
| 04:12.41 |
brlcad |
nods :) |
| 04:12.52 |
brlcad |
you've seen
the gallery yes? |
| 04:12.58 |
jarray52 |
brlcad:
Yes. |
| 04:13.06 |
jarray52 |
brlcad: And
read through some of the manuals. |
| 04:13.19 |
brlcad |
so that's a
pretty wide range of different types of projects and different
ability levels |
| 04:13.21 |
jarray52 |
brlcad: I'm a
CAD/CAE/CAM newbie. |
| 04:13.27 |
jarray52 |
brlcad:
Yes. |
| 04:13.33 |
brlcad |
all the
better, less to unlearn :) |
| 04:14.20 |
starseeker |
folks
expecting a Blender-like GUI are in for a shock, but there's a lot
of power under the hood |
| 04:14.56 |
jarray52 |
starseeker: I
prefer scripted model development. |
| 04:15.07 |
starseeker |
longer term
we're planning to get there, but there's a *lot* of foundational
work that has to come before the pretty interactive 3d |
| 04:15.10 |
starseeker |
:-) |
| 04:15.18 |
starseeker |
jarray52:
then you're in the right place :-) |
| 04:15.38 |
jarray52 |
In theory,
scripted development should be faster, right? |
| 04:15.55 |
starseeker |
for some
classes of problems, absolutely |
| 04:15.59 |
jarray52 |
probably
depends on the designer. |
| 04:16.10 |
jarray52 |
starseeker:
Yes. Most definitely. |
| 04:16.13 |
brlcad |
very much
so |
| 04:16.18 |
starseeker |
if you have
data you can feed the script, that's where scripting
shines |
| 04:16.31 |
brlcad |
if the
designer doesn't know how to write a script, that's a pretty huge
hurdle ;) |
| 04:16.37 |
starseeker |
jarray52: if
you really want to go to town, there are C apis for model
generation |
| 04:17.05 |
brlcad |
jarray52: a
case study example that may be of interest: http://brlcad.org/wiki/Ronja |
| 04:17.06 |
starseeker |
that's what
the tire tools does, for example - tire dimensions in, tire
geometry out. |
| 04:17.10 |
starseeker |
procedural
modeling |
| 04:18.04 |
brlcad |
jarray52:
that's an individual that learned to model in less than a day,
spent maybe a week modeling his design, then another week writing
scripts to generate various images and animations: http://ronja.twibright.com/3d/ |
| 04:19.15 |
brlcad |
not the best
example of good modeling practices in his models, but a decent
showcase of what is possible within just a few days
time |
| 04:19.40 |
starseeker |
oh, this one
is kinda fun for "what's possible" http://more.brlcad.org/model/basic-impeller |
| 04:20.13 |
brlcad |
that'd be a
fun one to feed to an arylic printer |
| 04:20.27 |
starseeker |
reflects we really should get that default GPL license label
off the more.brlcad.org listings... |
| 04:21.45 |
jarray52 |
brlcad:
BRL-CAD would probably be a good tool for modelling a network of
telephone or power transmission lines including the powerplant,
right? |
| 04:21.59 |
brlcad |
sure |
| 04:22.17 |
brlcad |
starseeker:
you going to close out and document sf bug #3435642 ? |
| 04:22.22 |
brlcad |
the obj
export bug |
| 04:22.23 |
starseeker |
fun with the
pipe primitive :-) |
| 04:22.33 |
starseeker |
brlcad: oh,
right - he confirmed the fix, didn't he |
| 04:22.36 |
jarray52 |
brlcad: This
would be the type of design for which BRL-CAD shines,
right? |
| 04:23.50 |
brlcad |
yeah, there
are only a few types of models that BRL-CAD is ill-suited for
direct modeling (import is fine though) |
| 04:25.28 |
brlcad |
namely: soft
bodies (e.g., human skin) and highly curved surfaces (e.g., some
modern car bodies) |
| 04:26.47 |
brlcad |
objects that
can be broken down into constituent primitives shapes can be
directly modeled much easier |
| 04:27.17 |
louipc |
brlcad:
http://louipc.mine.nu/brlcad/brlcad-7.20.4-1-x86_64-build.log |
| 04:27.39 |
louipc |
that's a full
build log with my version of gcc if that interests you |
| 04:27.52 |
louipc |
strict=off |
| 04:31.45 |
CIA-109 |
BRL-CAD:
03brlcad * r47479
10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: |
| 04:31.46 |
CIA-109 |
BRL-CAD:
attempt a fix for a variety of gcc 4.6.2 strict compilation
failures reported by |
| 04:31.46 |
CIA-109 |
BRL-CAD:
louipc (irc). compiler was clever enough to figure out that
2d-arrays were |
| 04:31.46 |
CIA-109 |
BRL-CAD:
getting passed around as pointers and getting later treated as
3d-arrays. |
| 04:32.03 |
brlcad |
louipc:
thanks... but do you have an svn checkout? :) |
| 04:32.09 |
louipc |
yeah |
| 04:32.10 |
CIA-109 |
BRL-CAD:
03starseeker * r47480 10/brlcad/trunk/NEWS: |
| 04:32.10 |
CIA-109 |
BRL-CAD: obj
export was producing facets that all shared the same number instead
of |
| 04:32.10 |
CIA-109 |
BRL-CAD:
pointing to the correct points - problem was very precisely
identified by |
| 04:32.10 |
CIA-109 |
BRL-CAD:
Christopher Pitts (down to the incorrect variable in the source
file), so he |
| 04:32.10 |
CIA-109 |
BRL-CAD: gets
credit for the fix - thanks\! |
| 04:32.26 |
brlcad |
line numbers
will be askew and easier to verify if you can svn up while I
fix |
| 04:32.40 |
louipc |
ok |
| 04:34.11 |
brlcad |
starseeker:
cool, thx |
| 04:35.02 |
brlcad |
unrelared,
r47471 seems wrong .. removed bu.h and pulled in a bunch of header
foo it was using in the test client? |
| 04:35.19 |
brlcad |
presume you
encountered some problem? |
| 04:35.44 |
starseeker |
the point of
that client was to be totally self contained |
| 04:36.29 |
brlcad |
is ntohll
required for something in the test client?? |
| 04:36.35 |
brlcad |
that seems ..
wrong :) |
| 04:36.50 |
starseeker |
IIRC, Eric
was using it to ensure network order when packing some
stuff |
| 04:37.35 |
starseeker |
shrugs - I'm still doing remedial education at this point, I
did that to ensure the build worked |
| 04:37.40 |
brlcad |
no
problem |
| 04:37.45 |
brlcad |
it was more a
curiosity |
| 04:37.55 |
brlcad |
it could
frankly be a shell script making telnet calls |
| 04:38.33 |
starseeker |
in principle,
sure - in practice I'm trying to at least *pretend* the goal is to
be portable to Windows :-P |
| 04:38.42 |
brlcad |
but by "self
contained" the main requirement is actually just not calling any
gs/ge code |
| 04:38.47 |
starseeker |
right |
| 04:39.01 |
brlcad |
bu.h isn't in
that category, so it's an impl detail |
| 04:39.31 |
brlcad |
it's the
stuff in the geomcore checkout that should be avoided (for the
indep test only of course) |
| 04:39.54 |
starseeker |
nods - I could have fixed the build logic too, but the logic
ran "why's this failing - oh, that's supposed to be self-contained
- huh it's just using that one feature - commit" |
| 04:39.54 |
brlcad |
either way,
like I said -- more just a curiosity, carry on ;) |
| 04:40.18 |
starseeker |
resumes wallowing in ignorance :-P |
| 04:40.30 |
starseeker |
btw, welcome
back |
| 04:41.25 |
brlcad |
it raised my
"what?" radar simply because it fails DRY and that usually
trumps |
| 04:41.39 |
starseeker |
ponders whether SCL should do as BRL-CAD does with version
numbers... |
| 04:42.36 |
brlcad |
for a project
that small, the version number could live in the top-level
CMakeLists.txt file, maybe wrap in a macro if it's needed in
multiple places but the built-in versioning hooks are probably
sufficient |
| 04:43.08 |
brlcad |
we're more of
a platform where that number is used all over the place in various
ways |
| 04:43.11 |
brlcad |
scl not so
much |
| 04:43.38 |
starseeker |
nods - that was my thought |
| 04:43.56 |
starseeker |
just do some
.in files if they want it in headers |
| 04:44.51 |
starseeker |
s/Eric/Erik |
| 04:44.57 |
starseeker |
alright,
bedtime |
| 04:47.09 |
brlcad |
hasta la
pasta |
| 04:48.42 |
louipc |
oops?
http://louipc.mine.nu/brlcad/brlcad-svn47480-build.log |
| 04:48.48 |
jarray52 |
brlcad:
Thanks for answering my questions. |
| 04:49.11 |
jarray52 |
I want to
thank starseeker and others as well. |
| 04:50.23 |
louipc |
thanks for
being patient and sticking around ;) |
| 05:39.25 |
jordisayol |
brlcad: hasta
la pasta!? |
| 05:41.11 |
jarray52 |
8-) |
| 08:10.20 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 08:52.57 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.85.67) |
| 09:07.51 |
*** join/#brlcad hackrat
(~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 11:39.05 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.88.176) |
| 12:45.29 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.88.176) |
| 12:50.03 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.88.176) |
| 13:27.18 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.88.176) |
| 13:42.04 |
*** join/#brlcad Technicus
(~Technicus@DSLPool-net208-2.wctc.net) |
| 14:10.20 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.82.152) |
| 14:22.24 |
*** join/#brlcad piksi (piksi@pi-xi.net) |
| 14:34.32 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
| 15:03.38 |
CIA-109 |
BRL-CAD:
03d_rossberg * r47481 10/rt^3/trunk/ (2 files in 2
dirs): |
| 15:03.39 |
CIA-109 |
BRL-CAD:
method to get a simple facetized boundary-representation of a
subtree |
| 15:03.39 |
CIA-109 |
BRL-CAD: it's
a method of the database because not only one element is involved
but the tree below the requested element |
| 15:09.48 |
``Erik |
the GS
"ping/pong" uses a network order uint64, so ntohll() was needed...
personally, I think the protocol should evolve as a human readable
ascii thing over the line (yes, so telnet can be used, and it can
be easily debugged), then add a 'binary' command and mode down the
road |
| 15:14.28 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 15:41.40 |
brlcad |
d_rossberg:
not that it matters much, but "nmg" stands for n-manifold
geometry |
| 15:42.07 |
brlcad |
the original
paper was entitled non-manifold, but by the time it was implemented
and announced, it became n-manifold |
| 15:48.35 |
brlcad |
of course,
the generalized structure happens to support n-manifold surfaces as
well as non-manifold vertices and edges (not sure about
non-manifold faces) |
| 16:00.29 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.84.128) |
| 16:02.07 |
d_rossberg |
these
n-manifold vs. non-manifold sounds unfortunate, espaecially because
it is still the original Weiler non-manifild |
| 16:02.51 |
d_rossberg |
including all
its ballast |
| 16:03.23 |
brlcad |
it's mainly
due to the audience perspective, though |
| 16:03.46 |
brlcad |
weiler was
trying to solve the academic problem of how to model non-manifold
entities |
| 16:04.17 |
brlcad |
the structure
does that, even if the dominant use is for n-manifold surface
boundaries |
| 16:05.18 |
d_rossberg |
i wouldn't
mind to get rid of the burden |
| 16:05.23 |
brlcad |
from our
users perspective, it should really just be called a "mesh" or
"solid polygonal mesh" or similar :) |
| 16:05.50 |
brlcad |
burden? |
| 16:06.14 |
d_rossberg |
the model,
region and lower dimensional things |
| 16:07.02 |
brlcad |
you mean
implement a non-weiler polygonal mesh api or something else?
:) |
| 16:07.17 |
d_rossberg |
all we really
need is a single shell |
| 16:08.36 |
d_rossberg |
it looks like
most of the algorothms using nmg can't handle models with multiple
regions |
| 16:09.30 |
brlcad |
that's
because they're all just copies of each other and the first guy was
lazy |
| 16:09.34 |
d_rossberg |
these are
relics of the original nmg CAD project |
| 16:09.48 |
``Erik |
most assume
an NMG is a single NMG region with a single NMG shell,
iirc |
| 16:11.21 |
brlcad |
I don't
believe the boolean evaluator used for E/ev is that
limited |
| 16:11.58 |
d_rossberg |
and support
of Euler operations would be nice |
| 16:13.27 |
brlcad |
if I have an
rcc and subtract an arb8 from the middle, makes two shells -- you
really don't want to create two single-shell nmg objects, you want
just one named object with the two shells in it |
| 16:15.25 |
d_rossberg |
nmg_booltree_leaf_tess creates a new model
for every primitive |
| 16:16.13 |
brlcad |
nmg supports
most euler operations iirc |
| 16:16.37 |
brlcad |
perhaps not
all |
| 16:22.28 |
brlcad |
creates a new
model for each prim, but then pairwise extracts their (single)
shell and performs the boolean |
| 16:22.53 |
brlcad |
the
limitation is only on a single primitive that might have multiple
shells (BoT, pnts, dsp, ..) |
| 16:24.14 |
brlcad |
otherwise,
the boolean of two shells will result in n-shells |
| 16:28.14 |
d_rossberg |
a shell is a
simple collection of faces, loops, edges and a vertex, there is no
real restriction to a single connected volume |
| 16:28.24 |
d_rossberg |
however, i
plan to write down my impress |
| 16:28.44 |
d_rossberg |
-ions and
send them to the devel-list |
| 16:28.55 |
d_rossberg |
...
later |
| 16:29.54 |
brlcad |
well, no
restriction other than that is the (current) definition of a shell
:) |
| 16:32.31 |
brlcad |
that said, I
do agree that there's no practical benefit that comes to mind for
having models and regions (to a slightly lesser degree) |
| 16:33.49 |
brlcad |
there would
be a purpose for regions and models if you could associate
user-data (void*) to caller API |
| 16:34.58 |
*** join/#brlcad velociostrich
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 16:35.42 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.82.93) |
| 17:21.04 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.82.93) |
| 18:22.46 |
starseeker |
hah, cool:
http://code.google.com/p/libmv/ |
| 18:51.57 |
``Erik |
was looking
at that a while ago, have they actually been working on it? O.o
seemed like a dead end at the time |
| 18:52.48 |
CIA-109 |
BRL-CAD:
03erikgreenwald * r47482
10/geomcore/trunk/tests/func/GE/GeometryEngineTest.cxx: fix usage
typo |
| 19:00.53 |
*** join/#brlcad merzo
(~merzo@128-101-133-95.pool.ukrtel.net) |
| 19:02.24 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.80.170) |
| 19:06.11 |
brlcad |
"BRLCAD" is a
typo too |
| 19:06.32 |
brlcad |
dash merely
in the wrong place |
| 19:59.25 |
CIA-109 |
BRL-CAD:
03brlcad * r47483 10/brlcad/trunk/ (5 files in 5 dirs): |
| 19:59.25 |
CIA-109 |
BRL-CAD: make
the invoking wrapper batch scripts all set the PATH before
running |
| 19:59.25 |
CIA-109 |
BRL-CAD:
mged/archer/bwish/rtwizard so that tools invoked by commands can be
found. |
| 19:59.25 |
CIA-109 |
BRL-CAD:
untested, but should do the trick without requiring the user to
have |
| 19:59.25 |
CIA-109 |
BRL-CAD:
admin/profile rights to modify the PATH permanently. this is in
response to a |
| 19:59.25 |
CIA-109 |
BRL-CAD:
feature request from the dwayne kregel. |
| 20:13.25 |
CIA-109 |
BRL-CAD:
03brlcad * r47484 10/brlcad/trunk/ (4 files in 2 dirs): apply
another tclscript update from carl g moore jr that reports what the
input object names are that weren't combs and makes reid report the
highest value set. |
| 20:20.56 |
CIA-109 |
BRL-CAD:
03brlcad * r47485 10/brlcad/trunk/TODO: document dwayne's detailed
feature request for a geometry prep lintian command |
| 20:55.02 |
CIA-109 |
BRL-CAD:
03brlcad * r47486 10/brlcad/trunk/NEWS: |
| 20:55.02 |
CIA-109 |
BRL-CAD:
daniel applied a fix in r47473 for a bug that was preventing the
detection of V4 |
| 20:55.02 |
CIA-109 |
BRL-CAD:
regions during raytrace. it looks like this is the same bug
reported by chris |
| 20:55.02 |
CIA-109 |
BRL-CAD:
pitts a couple weeks ago, which he'd traced down to
db5_sync_attr_to_comb() |
| 20:55.02 |
CIA-109 |
BRL-CAD:
wiping out the comb structure. |
| 21:02.47 |
CIA-109 |
BRL-CAD:
03brlcad * r47487 10/brlcad/trunk/NEWS: bob added the 'l'ist
command to archer, which improves/fixes the 'g' grouping
command |
| 21:08.45 |
CIA-109 |
BRL-CAD:
03brlcad * r47488 10/brlcad/trunk/AUTHORS: special thanks to chris
pitts for his efforts to report, diagnose, and even help pinpoint
where in the source code a problem was occurring. helped with v4
raytracing and obj export issue. |
| 21:11.02 |
CIA-109 |
BRL-CAD:
03brlcad * r47489 10/brlcad/trunk/AUTHORS: browder now belongs up
in the code contributions section given all of the recent
documentation efforts. |
| 22:53.22 |
*** join/#brlcad Technicus
(~Technicus@DSLPool-net208-2.wctc.net) |
| 23:10.59 |
CIA-109 |
BRL-CAD:
03n_reed * r47490 10/brlcad/trunk/src/other/ (9 files in 2 dirs):
adding sources for an experimental scanner-generator |
| 23:11.24 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 23:20.54 |
*** join/#brlcad velociostrich
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 00:50.33 |
CIA-109 |
BRL-CAD:
03starseeker * r47540 10/brlcad/trunk/misc/CMake/
(BRLCAD_Util.cmake ThirdParty.cmake ThirdParty_TCL.cmake): Make the
third party options a bit more informative |
| 01:08.31 |
*** join/#brlcad velociostrich
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 01:12.30 |
CIA-109 |
BRL-CAD:
03starseeker * r47541 10/brlcad/trunk/ (TODO.cmake
misc/CMake/BRLCAD_Util.cmake): Get the on/off toggles with auto
option displaying their actual state, not just 'AUTO' |
| 01:17.50 |
CIA-109 |
BRL-CAD:
03starseeker * r47542 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake:
AUTO isn't always in the front with new labels |
| 01:23.34 |
CIA-109 |
BRL-CAD:
03starseeker * r47543 10/brlcad/trunk/CMakeLists.txt: Be more
informative about what's going on with the CPU type,
too |
| 01:24.18 |
starseeker |
brlcad:
hopefully that'll be more informative |
| 01:27.19 |
CIA-109 |
BRL-CAD:
03starseeker * r47544 10/brlcad/trunk/TODO.cmake: add a todo item
for the alias mechanism |
| 02:49.23 |
CIA-109 |
BRL-CAD:
03starseeker * r47545 10/brlcad/trunk/ (CMakeLists.txt
misc/CMake/BRLCAD_Util.cmake): Proof-of-concept implementation of a
BRLCAD_OPTION macro that supports aliases for an option and appends
documentation to a txt file. |
| 02:50.16 |
starseeker |
brlcad:
before I go too much farther with that I'd appreciate some feedback
(in particular, how to write out the documentation) |
| 02:54.04 |
CIA-109 |
BRL-CAD:
03starseeker * r47546 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake:
tweak |
| 02:57.48 |
CIA-109 |
BRL-CAD:
03starseeker * r47547 10/brlcad/trunk/CMakeLists.txt: correct
global example |
| 03:04.42 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.86.6) |
| 03:06.09 |
CIA-109 |
BRL-CAD:
03starseeker * r47548 10/brlcad/trunk/ (CMakeLists.txt
misc/CMake/BRLCAD_Util.cmake): Wait - not handling things quite
right with the macro. FORCE shouldn't be needed for that var in the
GLOBAL file. |
| 03:14.32 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 03:17.02 |
CIA-109 |
BRL-CAD:
03starseeker * r47549 10/brlcad/trunk/ (CMakeLists.txt
src/other/CMakeLists.txt): Fix some of the stray variables that
should be advanced |
| 03:18.56 |
CIA-109 |
BRL-CAD:
03starseeker * r47550 10/brlcad/trunk/CMakeLists.txt: Hmm, that one
is easier to change than I thought. Static libs, not the whole
thing static |
| 03:36.22 |
abhi2011 |
starseeker:
there are mismatched if/endif pairs in brlcad_config.h : http://bin.cakephp.org/view/430932163 |
| 03:37.07 |
abhi2011 |
there are 2
endifs at the end |
| 04:21.11 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.89.252) |
| 04:35.11 |
*** join/#brlcad packrat
(~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 04:52.56 |
abhi2011 |
probably its
the cmakecache again, will clear and check |
| 05:20.15 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.89.252) |
| 05:39.19 |
starseeker |
abhi2011:
yeah, that's usually the cache or a stale file, and after that
series of changes to the build logic this evening you'll probably
have to clear out and reconfigure |
| 09:21.00 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.89.252) |
| 09:48.34 |
*** join/#brlcad Technicus
(~Technicus@DSLPool-net208-2.wctc.net) |
| 14:25.25 |
*** join/#brlcad abhi2011
(~chatzilla@117.200.80.155) |
| 14:45.25 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 15:23.10 |
CIA-109 |
BRL-CAD:
03starseeker * r47551
10/brlcad/trunk/src/libpkg/example/CMakeLists.txt: Add libbu to the
link lines... |
| 15:37.18 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.83.178) |
| 16:03.08 |
*** join/#brlcad Elrohir
(~kvirc@p5B149B04.dip.t-dialin.net) |
| 16:03.08 |
abhi2011 |
starseeker:
the other errors are gone now, however 3 link errors are still
there for libpkg : http://bin.cakephp.org/view/1734456229 |
| 16:25.56 |
starseeker |
abhi2011:
does commit 47551 fix it? |
| 16:41.10 |
abhi2011 |
starseeker:
yes thanks :), that did the trick |
| 17:22.45 |
CIA-109 |
BRL-CAD:
03starseeker * r47552 10/brlcad/trunk/misc/CMake/
(BRLCAD_Util.cmake ThirdParty.cmake ThirdParty_TCL.cmake): Tweaks
and corrections to new CMake labeling. |
| 17:25.00 |
CIA-109 |
BRL-CAD:
03n_reed * r47553 10/brlcad/trunk/doc/bison_to_lemon.txt: update on
alias substitution |
| 17:37.12 |
*** join/#brlcad abhi2011_
(~chatzilla@117.200.83.178) |
| 18:01.22 |
abhi2011 |
nope spoke
too early :P |
| 18:01.26 |
abhi2011 |
same
error |
| 18:01.52 |
abhi2011 |
http://bin.cakephp.org/view/412812688 |
| 18:03.40 |
abhi2011 |
well libged
compiles , so I can proceed with testing the simulate command
:) |
| 18:11.48 |
abhi2011 |
so when a ray
is travelling through a air region , is there some flag set in the
struct partition for it (that is returned in the hit call
back) |
| 18:12.43 |
abhi2011 |
or is only
way to check that a ray segment is travelling through air, to check
the order of the out and in primitives |
| 18:32.31 |
CIA-109 |
BRL-CAD:
03bob1961 * r47554 10/brlcad/trunk/src/ (libtclcad/tclcad_obj.c
tclscripts/lib/Ged.tcl): These mods add the functionality to apply
snap-to-grid to data polygon editing. |
| 19:19.04 |
*** join/#brlcad yukonbob
(~bch@S01060024a5c9dad4.ok.shawcable.net) |
| 19:19.09 |
yukonbob |
hello,
#brlcad |
| 19:19.12 |
brlcad |
hello |
| 19:19.34 |
yukonbob |
hey brlcad :)
-- how're things? |
| 19:19.47 |
yukonbob |
seeing lots of interesting discussions in
newsletters. |
| 19:20.25 |
brlcad |
usual, busy,
fun, frustrating, interesting, difficult, routine, new,
etc |
| 19:20.59 |
yukonbob |
what's
"new"? |
| 20:22.27 |
*** join/#brlcad velociostrich
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 20:53.36 |
CIA-109 |
BRL-CAD:
03n_reed * r47555 10/brlcad/trunk/src/other/perplex/ (parser.y
perplex.c perplex.h scanner.re template.c): pass app data to lemon
parser; first try at embellishing input |
| 21:03.04 |
starseeker |
yukonbob: any
luck with making the tcltk 8.6 branch of BRL-CAD/ |
| 21:03.10 |
starseeker |
? |
| 21:03.31 |
yukonbob |
starseeker:
haven't even tried yet. |
| 21:04.31 |
yukonbob |
I have a
local copy and installation; has been a while since I've played w/
the build, so I'd retry that, confirm it works. The code base will
be out-of-date w/ current repo, *but* should be a working piece,
which is the important part. |
| 21:04.45 |
CIA-109 |
BRL-CAD:
03brlcad * r47556 10/brlcad/trunk/src/rt/view.c: retStatus is
unused |
| 21:05.09 |
yukonbob |
from there,
pull changes from trunk -> 8.6, test, fix, test, fix, commit,
lather, rinse, repeat. |
| 21:09.02 |
CIA-109 |
BRL-CAD:
03brlcad * r47557 10/brlcad/trunk/src/librtserver/rtserverTest.c:
remove/comment out unused code. removes -a option since use_air
isn't used. |
| 21:09.25 |
starseeker |
if the
changes for 8.6 are something we can integrate back into trunk, it
might make your life easier |
| 21:10.13 |
CIA-109 |
BRL-CAD:
03starseeker * r47558
10/brlcad/trunk/src/libpkg/example/CMakeLists.txt: Ah, right - need
special compile flags for MSVC... (ugh) |
| 21:11.48 |
yukonbob |
starseeker:
the work I've got so far is as it relates to my work w/ NetBSD,
modularization, and BRLCAD. I'll see how it works; I know that I'm
not at tip of repo, and that I've tried/failed w/ more recent code;
I'll take stock though, and get something (with a description of
that "something") committed. |
| 21:13.35 |
starseeker |
archivist:
does 47558 do the trick? |
| 21:13.40 |
starseeker |
yukonbob:
sounds good! |
| 21:14.02 |
starseeker |
when you say
"modularization", what are you referring to? |
| 21:15.04 |
brlcad |
yukonbob:
more nurbs, physics engine, geometry editing goodness, cmake
stabilizing, archer revitalizing, ... |
| 21:15.34 |
brlcad |
getting 8.6
tested and udpated would be pretty helpful |
| 21:15.56 |
yukonbob |
will need to come to know nurbs. and is also still pretty
interested in (and may have work for) dsp. |
| 21:16.18 |
yukonbob |
dsp still a
stable, maintained, first-class citizen in BRLCADville? |
| 21:16.25 |
brlcad |
dsp is
awesome |
| 21:16.37 |
brlcad |
underutilized
and underdocumented, but good stuff nonetheless |
| 21:16.50 |
starseeker |
for
head-scratching values of "maintained" :-P |
| 21:16.58 |
yukonbob |
dsp was one
of my first forrays into brlcad, and I think my first bug-report
;) |
| 21:17.26 |
yukonbob |
anyway --
I'll get my scratch-work massaged and committed. |
| 21:17.42 |
brlcad |
lots of ways
it can be improved further still, but hard-pressed to find better
in-memory solid geometry terrain representation on the scale it
supports |
| 21:17.50 |
yukonbob |
was not a fan of 8.5, but -is- a fan of 8.6, so happy to have
that a side-effect of his work. |
| 21:18.01 |
starseeker |
sweet |
| 21:18.06 |
CIA-109 |
BRL-CAD:
03n_reed * r47559 10/brlcad/trunk/src/other/perplex/ (scanner.re
template.c): use re2c syntax for setting conditions |
| 21:18.12 |
starseeker |
can build 8.6 with CMake - took some pains to be sure I
could, actually |
| 21:18.23 |
brlcad |
well, as you
noted.. you do still have commit ability :) |
| 21:18.39 |
starseeker |
needs to get a TIP written up - would REALLY love to have the
CMake build logic just "there" in 8.6 final |
| 21:21.28 |
starseeker |
yukonbob: I
need to set up a virtual machine with NetBSD so I can try a build -
any recommendations on pre-cooked VirtualBox images? |
| 21:23.21 |
yukonbob |
starseeker:
no... |
| 21:23.40 |
yukonbob |
1s. |
| 21:24.14 |
yukonbob |
starseeker:
virtualbox == that sun vm? |
| 21:24.34 |
yukonbob |
sees "yes". |
| 21:25.14 |
CIA-109 |
BRL-CAD:
03brlcad * r47560 10/brlcad/trunk/ (9 files in 9 dirs): |
| 21:25.15 |
CIA-109 |
BRL-CAD:
rename BRLCAD-CPU_TYPE and CMAKE_CPU_TYPE to BRLCAD-WORD_SIZE
and |
| 21:25.15 |
CIA-109 |
BRL-CAD:
CMAKE_WORD_SIZE respectively so as not to imply chip type or
architecture. CPU |
| 21:25.15 |
CIA-109 |
BRL-CAD: may
be multimode as could the compiler, so it's not a good moniker.
also |
| 21:25.15 |
CIA-109 |
BRL-CAD:
consistently use either ##BIT or ##-bit styles when referring to
the size in |
| 21:25.15 |
CIA-109 |
BRL-CAD:
text. |
| 21:26.02 |
starseeker |
brlcad:
awesome, thanks! |
| 21:26.08 |
brlcad |
starseeker:
so I'm leaning more towards renaming all the BRLCAD- cases to
BRLCAD_ grouping all vars together, for improved
usability |
| 21:26.35 |
starseeker |
nods - sounds good. I have no particularly strong feelings on
that, so whatever you feel is best |
| 21:26.51 |
brlcad |
it'd be nice
to have subgroupings, but not at that usability crux since we'd
still want to document what it really is |
| 21:27.02 |
brlcad |
then the
aliases can just be shorthand and typo preventions |
| 21:27.14 |
starseeker |
nods |
| 21:27.15 |
brlcad |
not every _-
permutation :) |
| 21:29.32 |
CIA-109 |
BRL-CAD:
03starseeker * r47561 10/brlcad/trunk/src/libpkg/example/ (client.c
server.c): Hmm... trying to send a message back to the client from
the server. Doing something wrong... |
| 21:31.43 |
starseeker |
I suppose I
should have known it wouldn't be that simple... |
| 21:36.58 |
yukonbob |
starseeker:
re: nbsd -- nothing I see off top of head. |
| 21:37.08 |
starseeker |
no
problem |
| 21:37.54 |
yukonbob |
brl-cad still
maintains own build server? |
| 21:38.19 |
starseeker |
um... you
mean brlcad's setup? |
| 21:38.42 |
yukonbob |
not sure -- I've had an account on what I thought was a
brl-cad machine in past. |
| 21:39.33 |
starseeker |
yeah, that's
probably it - yeah, he's still got it up |
| 21:39.47 |
yukonbob |
only
wondering for same reasons you're wondering about nbsd -- If there
was some other box that's linux or fbsd or $whatever, just another
opportunity to test build/run, shake out bugs, etc.,
etc. |
| 21:40.08 |
starseeker |
hmm... well,
here's a bunch of images... no netbsd though http://virtualboxes.org/images/ |
| 21:40.38 |
starseeker |
come to think
of it, that might be the opensolaris image I grabbed |
| 21:41.05 |
starseeker |
hopes he remember how to get into that - it was set up for
building, and it's a long shot whether that could be done
again |
| 21:41.06 |
yukonbob |
ah -- my
account is still good. |
| 21:41.27 |
yukonbob |
oh wow.
timewarp. |
| 21:41.29 |
yukonbob |
:) |
| 21:41.34 |
starseeker |
hehe |
| 21:41.44 |
yukonbob |
s'all good in
the 'hood. ;) |
| 21:58.40 |
brlcad |
starseeker:
fyi, I did a quick check and confirmed that the server should be
able to send back to the client bidirectionally |
| 21:58.48 |
brlcad |
your comment
yesterday didn't sound right.. |
| 21:59.34 |
brlcad |
fbserv sends
back error notifications to the client being one relatively obvious
example |
| 22:00.51 |
brlcad |
that's a
pretty nifty virtualization OS list .. would be great for automated
compilation testing for someone to set up |
| 22:01.21 |
brlcad |
run vm with
each OS image, add brl-cad sources, compile, report to
dashboard |
| 22:01.45 |
brlcad |
shudders at the awesome power of that |
| 22:05.16 |
starseeker |
was discussing that with some of the GSoC
guys |
| 22:05.49 |
brlcad |
interesting,
I was too |
| 22:05.58 |
starseeker |
Jenkins is
apparently one of the relevant tools for managing something like
that... |
| 22:06.16 |
brlcad |
more for gci
purposes, though -- provide an image completely preconfigured,
go! |
| 22:06.18 |
yukonbob |
a build
dashboard? |
| 22:06.27 |
starseeker |
nods |
| 22:06.39 |
yukonbob |
cbuild |
| 22:07.08 |
yukonbob |
err.
ctest. |
| 22:07.33 |
starseeker |
oh - we don't
have ctest integrated yet |
| 22:07.38 |
yukonbob |
http://www.vtk.org/Wiki/CMake_Testing_With_CTest
<--- w/ cdash, or dart... |
| 22:07.56 |
yukonbob |
has never actually used these, but is
aware. |
| 22:08.49 |
yukonbob |
out. |
| 22:08.54 |
yukonbob |
chat later,
cadheads. |
| 22:08.57 |
starseeker |
later! |
| 22:09.04 |
brlcad |
jenkins is
one of the top ones |
| 22:09.17 |
starseeker |
hmm https://wiki.jenkins-ci.org/display/JENKINS/VirtualBox+Plugin |
| 22:09.18 |
brlcad |
hudson is a
fork that seems more promising |
| 22:09.38 |
brlcad |
cruisecontrol
is the old steadfast best |
| 22:09.54 |
starseeker |
um... thought
jenkins was a fork of hudson? |
| 22:09.57 |
brlcad |
buildbot is
one of the newercomers with some neat features |
| 22:10.45 |
brlcad |
sorry, that's
right |
| 22:11.48 |
brlcad |
"Both the
Jenkins and Hudson projects appear to consider the other to be a
fork." |
| 22:12.04 |
brlcad |
more Oracle
stupidity |
| 22:13.09 |
CIA-109 |
BRL-CAD:
03bob1961 * r47562 10/brlcad/trunk/ (3 files in 3 dirs): Added the
mechanism for sketching out elliptical shaped polygons. |
| 22:13.11 |
brlcad |
I think any
one of those four choices would be perfect for our needs, it's
mostly just needing someone to champion setting it up
proper |
| 22:13.36 |
starseeker |
brlcad: OK,
I'll take a look at fbserv |
| 22:14.26 |
brlcad |
suggest just
trying to figure it out with your own example still :) |
| 22:14.59 |
brlcad |
master of
your own domain and whatnot |
| 22:15.14 |
brlcad |
plus it then
requires really understanding what state both client and server are
in |
| 22:15.43 |
starseeker |
doen't want to understand pkg... just wants it to work and go
away... |
| 22:15.44 |
brlcad |
put printing
statements before and after all of your send() and recv()
statements in both client and server, so you can see who is waiting
on what |
| 22:16.53 |
brlcad |
don't think
that's a productive mindset |
| 22:17.00 |
brlcad |
it's not a
means to an end, we use it already |
| 22:17.24 |
brlcad |
so you either
want to learn it so you can/could use it or debug it or extend it,
or you leave it to someone else... |
| 22:18.22 |
starseeker |
fair
enough |
| 22:18.32 |
brlcad |
that would
even be the case if we picked up some 3rd party package .. it's all
fine and dandy when it works, but then it's a brick wall black box
when anything goes wrong (which it eventually always
does) |
| 22:19.15 |
velociostrich |
Activity on
this channel? Unheard of! |
| 22:19.23 |
velociostrich |
goes back into hiding |
| 22:19.44 |
brlcad |
velociostrich: it's usually like this most
days... |
| 22:19.47 |
CIA-109 |
BRL-CAD:
03bob1961 * r47563 10/brlcad/trunk/src/libtclcad/tclcad_obj.c:
Removed junk that was mistakenly included with the previous
commit. |
| 22:19.49 |
brlcad |
save maybe
for last week |
| 22:20.08 |
velociostrich |
I wouldn't
know, I'm not in here often, but when I have been I rarely noticed
activity |
| 22:20.35 |
velociostrich |
Besides the
'e' command, is there any way to get a nicer preview of work in
mged ala other cad packages, e.g., opencascade based
alternatives? |
| 22:20.41 |
brlcad |
*shrug* |
| 22:20.41 |
velociostrich |
iirc it was
'e', anyway |
| 22:21.02 |
brlcad |
velociostrich: you can render via
raytracing (File menu) |
| 22:21.29 |
velociostrich |
Yes, I do
realize that |
| 22:21.32 |
brlcad |
for simple
models, you can use the E or ev commands to get a polygonal
wireframe |
| 22:21.42 |
velociostrich |
how do e and
ev differ? |
| 22:21.58 |
brlcad |
e just draws
the fundamental wireframe |
| 22:22.05 |
brlcad |
ev evaluates
a polygonal wireframe |
| 22:22.18 |
brlcad |
E also
evaluates, but with a slightly different algorithm |
| 22:22.43 |
brlcad |
you probably
are looking for shaded display support, which is available for
certain types of models but not all so it's disabled by
default |
| 22:23.01 |
brlcad |
future
release will enable shaded display support for all geometry
types |
| 22:23.19 |
velociostrich |
strange, it
seems that ev is having some depth buffer related issues (Does
brlcad use a depth buffer?) |
| 22:23.30 |
velociostrich |
things on top
of things that shouldn't be |
| 22:23.34 |
brlcad |
the depth
buffer can be turned on/off under Misc |
| 22:23.59 |
brlcad |
along with
depth lighting, and a few other modes |
| 22:25.31 |
velociostrich |
aha |
| 22:25.48 |
velociostrich |
although it
seems that the depth buffer doesn't work unless Z clipping and the
buffer are enabled |
| 22:25.57 |
brlcad |
starseeker:
maybe you can convince bob to make that nsegs=30 dynamically
adjust |
| 22:26.09 |
brlcad |
velociostrich: yep, iirc that sounds
right |
| 22:26.45 |
velociostrich |
strange |
| 22:28.16 |
velociostrich |
Might I ask
if there is any particular reason for the use of Tk and not a (as
far as I know, ignorant as I am) more modern toolkit like Qt/Gtk
for Archer (which afaik is much newer than mged)? |
| 22:30.13 |
CIA-109 |
BRL-CAD:
03brlcad * r47564 10/brlcad/trunk/ (25 files in 20 dirs): rename
all of the BRLCAD- cmake variables to BRLCAD_ so we can
consistently only use underscores everywhere. should help improve
simplicity of docs and use. |
| 22:30.18 |
brlcad |
velociostrich: archer is still mged, just
the project name -- it's a refactoring of mged's existing code from
pure tcl to itcl |
| 22:30.33 |
velociostrich |
oooh |
| 22:30.42 |
brlcad |
main reason
is that tcl/tk was adopted long before any of the modern toolkit's
existed |
| 22:30.53 |
velociostrich |
Yeah, I
assumed as much |
| 22:30.59 |
brlcad |
qt is on our
horizon for archer's eventual replacement, couple years out on our
planning schedule |
| 22:31.20 |
velociostrich |
Yeah, from
and end-users' standpoint, Tk makes Archer/mged look dated
unfortunately |
| 22:31.35 |
velociostrich |
I've noticed
that most people are quick to judge a book by its cover |
| 22:31.37 |
brlcad |
still need to
refactor more of mged's internal engine code down into lower
library layers so the new GUI doesn't have to reinvent the
wheel |
| 22:32.15 |
brlcad |
in all
fairness, Tk can be made to look like most modern GUIs... it just
takes a bit of effort to get off the defaults |
| 22:32.25 |
velociostrich |
perhaps |
| 22:32.32 |
brlcad |
we just use
the defaults because there are more pressing engine matters to
develop |
| 22:32.40 |
velociostrich |
I can
understand that |
| 22:33.02 |
velociostrich |
Especially
considering the KLOCs you guys have on your hands |
| 22:33.04 |
brlcad |
if you'd like
to help in that regard (or library refactoring or whatever really),
have at it |
| 22:33.14 |
brlcad |
lemme know
how I can help you get started ;) |
| 22:33.16 |
starseeker |
archer is
better that way than mged - we're mostly using the new tile/ttk
widgets there |
| 22:33.19 |
velociostrich |
If only I had
time, I would :/ |
| 22:33.45 |
brlcad |
you just need
a mutual itch to scratch ;) |
| 22:33.58 |
brlcad |
a project
that is interesting and tangible perhaps |
| 22:34.03 |
velociostrich |
And
time |
| 22:34.33 |
brlcad |
time is
merely a matter of priorities |
| 22:34.43 |
brlcad |
if you had
that itch, some need, you'd scratch it |
| 22:34.53 |
brlcad |
because itchy
things get scratched |
| 22:34.54 |
brlcad |
:) |
| 22:35.40 |
velociostrich |
You're damn
right, now stop enticing me before my priorities go out of wack for
a few weeks while I do that ;) |
| 22:35.54 |
CIA-109 |
BRL-CAD:
03tbrowder2 * r47565 10/brlcad/trunk/INSTALL.cmake: give a tad bit
of help for a novice cmake builder; indent the configuration args
to cmake; eliminate the old autotools stuff to eliminate confusion;
show as a work in progress |
| 22:37.12 |
velociostrich |
Also, out of
curiosity, do you know if the ARL still uses BRL-CAD, or have they
abandoned it in favor of Autocad and friends? |
| 22:38.15 |
brlcad |
velociostrich: yep, still heavily
used |
| 22:38.50 |
brlcad |
it's pretty
much core business to the DoD for the foreseeable
decade |
| 22:39.00 |
velociostrich |
interesting |
| 22:39.03 |
velociostrich |
likely with
certain extras that the public won't ever see, though |
| 22:39.12 |
velociostrich |
namely extra
ballistics bits |
| 22:39.38 |
velociostrich |
Which I
assume was the point of it being solid geometry based and having
the raytracing library and all that |
| 22:39.39 |
brlcad |
there are
other CAD packages that have to interoperate with more these days
than before, so strong focus on STEP import, for example, so we can
bring in external CAD models without changing the representation
format |
| 22:39.57 |
brlcad |
those extra
ballistic bits aren't part of brl-cad, never have been |
| 22:40.24 |
velociostrich |
Yes, but
would have used the raytracing library, correct? |
| 22:40.29 |
brlcad |
those bits
call into our core libraries, which are built for exactly that
purpose (and are still pretty much the best at it
barnone) |
| 22:40.39 |
velociostrich |
Yes, that's
what I meant |
| 22:41.56 |
velociostrich |
Y'know, that
makes me wonder if perhaps brlcad's raytracing library might be
well suited to the games industry; from what I understand AI makes
heavy use of raytracing for pathfinding and such, and they claim
it's quite expensive to compute |
| 22:42.16 |
velociostrich |
which I think
is typically done using whatever partitioning scheme they're
using |
| 22:42.29 |
velociostrich |
which is less
than ideal |
| 22:42.30 |
brlcad |
it is very
well suited for that purpose |
| 22:42.57 |
brlcad |
used within
DoD by a couple groups playing wargames in that way
(sorta) |
| 22:43.00 |
CIA-109 |
BRL-CAD:
03n_reed * r47566 10/brlcad/trunk/src/other/perplex/ (perplex.h
scanner.re template.c): changed token text allocation scheme to be
leak resistant |
| 22:48.17 |
brlcad |
starseeker:
/home/sean/brlcad/src/libpkg/example/server.c:117:10: error:
variable ?bytes? set but not used
[-Werror=unused-but-set-variable] |
| 22:48.18 |
CIA-109 |
BRL-CAD:
03bob1961 * r47567 10/brlcad/trunk/src/libtclcad/tclcad_obj.c:
Dynamically calculate the number of segments used to approximate
circles and ellipses using the window size. |
| 22:48.53 |
starseeker |
brlcad: hang
on - will be doing a commit in a sec anyhow |
| 22:54.03 |
CIA-109 |
BRL-CAD:
03starseeker * r47568 10/brlcad/trunk/src/libpkg/example/ (client.c
server.c): Back to basics - don't worry about the file, just dirt
simple back-and-forth. |
| 22:54.14 |
starseeker |
brlcad:
convinced ;-) |
| 22:56.00 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
| 23:12.10 |
starseeker |
ok, I see why
it was doing what it was doing, I think... |
| 23:12.41 |
starseeker |
brlcad:
thanks for the print statement suggestion, that helped |
| 23:12.59 |
starseeker |
didn't
realize it didn't break out of the while loop after completing the
file transfer |
| 23:30.43 |
*** join/#brlcad velociostrich
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 23:35.38 |
*** join/#brlcad Technicus
(~Technicus@DSLPool-net208-2.wctc.net) |
| 23:43.08 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 01:19.35 |
brlcad |
starseeker:
you still have to check if BU_EXPORTS is defined, else you can end
up with a double-definition error |
| 01:19.55 |
brlcad |
er,
BU_EXPORT |
| 01:22.37 |
brlcad |
the plural
naming convention you pulled from opennurbs doesn't really apply to
C code too (wasn't even necessary for opennurbs really, they're all
the same macro) |
| 01:23.23 |
brlcad |
that one's
not a big deal, of course, just not necessary |
| 01:24.20 |
brlcad |
maybe better
to keep it consistent with opennurbs, that's fine too |
| 01:44.19 |
CIA-61 |
BRL-CAD:
03brlcad * r47605 10/brlcad/trunk/include/bu.h: make sure BU_EXPORT
isn't already defined (so callers have some means to override), and
error out if caller tries to import and export
simultaneously. |
| 01:45.28 |
CIA-61 |
BRL-CAD:
03starseeker * r47606
10/brlcad/trunk/src/other/clipper/CMakeLists.txt: tweak clipper dll
CMake logic. |
| 01:46.12 |
starseeker |
brlcad: this
still feels funny to me somehow - explicitly calling out the import
with a library specific flag, rather than using the more "global"
BRLCAD_DLL seems to complicate the build logic quite a
bit... |
| 01:46.14 |
brlcad |
that template
should work well, how's it look? |
| 01:48.24 |
brlcad |
it does
complicate matters some given each library has to be listed now,
that was to be expected |
| 01:48.43 |
brlcad |
the problem
and benefit of BRLCAD_DLL is that it was global |
| 01:48.59 |
starseeker |
brlcad:
don't we still need that last else case with the empty BU_EXPORT
? |
| 01:49.03 |
brlcad |
it
effectively meant *_IMPORT_DLL |
| 01:49.23 |
starseeker |
nods - finding myself thinking that wasn't such a bad idea,
really... |
| 01:50.17 |
brlcad |
it's not a
terrible idea but there are some downsides |
| 01:50.39 |
brlcad |
can't make a
target that both exports and imports (plugins,
libraries) |
| 01:51.22 |
starseeker |
brlcad: the
"check for both definitions" case - will the logic ever get
there? |
| 01:51.26 |
brlcad |
also means
that there's cross-library pollution which prevents core library
components from standing on their own |
| 01:51.29 |
starseeker |
shouldn't we
be checking for that first? |
| 01:51.34 |
brlcad |
e.g., a libbu
distribution akin to apr |
| 01:52.27 |
brlcad |
yeah, you're
right |
| 01:52.31 |
brlcad |
on both
counts |
| 01:52.57 |
starseeker |
one
sec.. |
| 01:53.40 |
brlcad |
already
fixed |
| 01:53.43 |
CIA-61 |
BRL-CAD:
03brlcad * r47607 10/brlcad/trunk/include/bu.h: starseeker right on
both counts, need the empty BU_EXPORT so preprocessor makes the
symbol go away and the error case needs to be tested
first |
| 01:53.52 |
CIA-61 |
BRL-CAD:
03starseeker * r47608
10/brlcad/trunk/src/other/clipper/clipper.hpp: Upgrade the export
macro logic for clipper (hopefully)... |
| 01:54.46 |
starseeker |
do we need
BU_DLL_IMPORTS for a library that just links to librt? |
| 01:56.15 |
brlcad |
I don't
remember the dll import/export rules that closely but I believe it
depends how the library is defined |
| 01:56.38 |
starseeker |
mm. Well, I
guess there's always the "try it and see" approach... |
| 01:56.41 |
brlcad |
if librt
imports bu/bn and exports it's symbols, then I *think* it'll look
for their dll when librt is loaded |
| 01:56.55 |
starseeker |
guess I'll be
playing with the windows build again tomorrow (joy...) |
| 01:57.08 |
brlcad |
if it doesn't
import, they get linked static and have to be resolved at compile
time |
| 01:57.50 |
starseeker |
is trying to decide if librt should define an RT_DEFINES
variable that holds BU_DLL_IMPORTS, BN_DLL_IMPORTS,
etc... |
| 01:58.51 |
brlcad |
to do it
"proper", I believe so |
| 01:59.25 |
brlcad |
rather, it
needs to have them defined when librt is compiled .. but not
necessarily when rt is compiled |
| 01:59.45 |
brlcad |
(but
can) |
| 02:00.54 |
brlcad |
it needs them
when rt is compiled if librt doesn't import them or if it also uses
bu/bn too (which it does) |
| 02:02.08 |
starseeker |
needs to think tactically about how to set this up... would
*really* suck to have to specify defines for executables per-exec
instead of per directory |
| 02:03.53 |
starseeker |
probably need
to for exec targets in the same directory as a library (test apps,
etc.) since I can't go defining both, but (say) in util I would
prefer to "define 'em all and let the compiler sort it out", so to
speak |
| 02:12.14 |
brlcad |
starseeker:
how about in a/the exec wrapper macro, have it look for variables
matching the provided prefix -- then it's a naming convention all
our libs use to define their vars in one place |
| 02:12.43 |
starseeker |
you mean use
the library list to go after the variables? |
| 02:13.07 |
starseeker |
might work,
except when we send in libraries that aren't ours... |
| 02:13.14 |
brlcad |
something
like BUILD_MY_EXEC(rt, LIBRT LIBBN LIBBU) |
| 02:13.38 |
starseeker |
nods - BRLCAD_EXEC already has most of
that |
| 02:13.46 |
brlcad |
which would
then look for LIBRT_LIBS, LIBRT_CPPFLAGS, LIBRT_CFLAGS, LIBBN_LIBS,
LIBBN_CPPFLAGS, LIBBN_CFLAGS, etc |
| 02:14.01 |
starseeker |
come to think
of it... |
| 02:14.30 |
starseeker |
yeah, there
might be a way to handle it there |
| 02:14.39 |
starseeker |
will look into it tomorrow |
| 02:14.51 |
brlcad |
LIBRT_LDFLAGS
might be different from LIBRT_LIBS |
| 02:15.07 |
brlcad |
-lrt vs deps
-lbn -lbu -ltcl ... |
| 02:15.19 |
starseeker |
cmake uses
full paths for most things |
| 02:15.37 |
starseeker |
I can
recognize when I'm looking at a full path (do so for the distcheck
logic) |
| 02:15.49 |
brlcad |
path isn't
the issue |
| 02:16.09 |
brlcad |
it's what
libraries are added to the link line (and in what order if you want
to get pedantic) |
| 02:16.26 |
starseeker |
I was
thinking to use the list of libraries passed to
BRLCAD_EXEC |
| 02:17.09 |
starseeker |
couple ideas,
actually |
| 02:17.10 |
brlcad |
right, but
then if libraries are self-aware of their dependencies (and they
are) |
| 02:17.31 |
brlcad |
then you
wouldn't need to specify all the (potential) dependencies any time
a library is used |
| 02:17.58 |
brlcad |
like my
example above -- kind of silly to list libbn and libbu since librt
requires them |
| 02:18.11 |
starseeker |
oh, I
see... |
| 02:18.14 |
starseeker |
different
issue |
| 02:18.16 |
brlcad |
I couldv'e
queried a var set by librt that told me bn, bu, etc |
| 02:18.36 |
brlcad |
that could
greatly reduce redundancy throughout the build files |
| 02:19.06 |
starseeker |
nods... again less explicit though |
| 02:19.55 |
brlcad |
yet less
error-prone too |
| 02:20.20 |
brlcad |
most devs
don't think very long about what the actual libs are, they
copy-paste another similar and add libs until it
compiles |
| 02:20.40 |
starseeker |
true... the
way we're trending here though, I'm going to *have* to write up
some sort of detailed overview of what we're doing and
why |
| 02:21.42 |
starseeker |
granting
there are usually good reasons for what's being done, the further
we get from "vanilla" the greater the hurdles become for a newbie
to figure out what's happening and why |
| 02:22.08 |
brlcad |
already
warranted with any custom macro -- it's obvious to you now because
you wrote it and you still remember |
| 02:22.19 |
starseeker |
right |
| 02:22.38 |
starseeker |
in fact, for
a lot of reasons I'd *better* do it now |
| 02:22.51 |
starseeker |
's memory is... quirky |
| 02:23.13 |
brlcad |
might let you
clean out some unnecessary macros too if you attempt to document
them :) |
| 02:23.24 |
brlcad |
"oh yeah ..
no longer need this one" |
| 02:23.48 |
starseeker |
heh - one of
the fundamental arguments for literate programming, actually - "if
I have to explain to a human what I'm trying to do, it's hard to
hide the stupid parts :-P" |
| 02:24.00 |
brlcad |
it actually
looks like you already do some sort of lib dependency expansion in
BRLCAD_ADDEXEC |
| 02:24.32 |
starseeker |
uh... where
are you looking? |
| 02:24.45 |
brlcad |
just looking
at some binaries |
| 02:24.53 |
brlcad |
src/rt/CMakeLists.txt for
example |
| 02:25.04 |
brlcad |
no mention of
libbu, but guarantee they all use it |
| 02:25.29 |
starseeker |
actually
that's probably just dumb luck |
| 02:25.35 |
brlcad |
heh |
| 02:25.53 |
brlcad |
enfeeds |
| 02:26.43 |
starseeker |
that list is
passed pretty much as-is to target_link_libraries - did it mainly
because it cut a few hundred
add_executable/target_link_libraries/install triplets down to a
one-liner |
| 02:27.10 |
starseeker |
s/a
one-liner/one-liners/ |
| 02:27.20 |
starseeker |
yeah, gotta
get outta here |
| 02:34.59 |
*** join/#brlcad Technicus
(~Technicus@DSLPool-net208-2.wctc.net) |
| 03:14.39 |
*** join/#brlcad Technicus
(~Technicus@DSLPool-net208-2.wctc.net) |
| 04:13.23 |
CIA-61 |
BRL-CAD:
03brlcad * r47609 10/brlcad/trunk/NEWS: nick added a new -r
orientation option for the obj-g importer so you can specify 1/2/3
as values for unoriented, ccw, and cw orientation. |
| 05:26.30 |
brlcad |
starseeker:
then I'd wonder if cmake is doing some expansion for us since the
libs deps are listed with the libs and it expands
correctly |
| 05:26.48 |
brlcad |
either way,
somehow it's happening now, so that's a good sign |
| 05:27.12 |
brlcad |
installs cmake on gcc12 (openbsd sparc64) |
| 06:26.23 |
*** join/#brlcad milamber
(~devlin@d118-75-244-176.try.wideopenwest.com) |
| 07:42.45 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
| 11:50.28 |
CIA-61 |
BRL-CAD:
03erikgreenwald * r47610 10/brlcad/trunk/include/bu.h: add missing
#endif |
| 12:12.02 |
``Erik |
hm, anne
mccaffrey passed |
| 12:13.06 |
``Erik |
doom3 source
released, too |
| 13:36.21 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
| 16:37.07 |
*** join/#brlcad Technicus
(~Technicus@DSLPool-net208-2.wctc.net) |
| 16:37.07 |
*** join/#brlcad 77CAA2ALN
(~Technicus@DSLPool-net208-2.wctc.net) |
| 16:59.53 |
CIA-61 |
BRL-CAD:
03brlcad * r47611 10/brlcad/trunk/HACKING: gentoo folks moved
brl-cad from sci-misc to media-gfx |
| 17:32.32 |
brlcad |
starseeker:
any technical reason for the lack of blank lines in the cmake
files? |
| 17:33.17 |
starseeker |
uh... not
really |
| 17:33.31 |
brlcad |
k |
| 17:34.04 |
starseeker |
can't think
of any offhand, although there may be a few cases where it matters
(messages can't have stray end-of-line characters, for
example...) |
| 17:34.29 |
starseeker |
or rather,
they can but it messes with the formatting of the printed
result |
| 17:41.19 |
brlcad |
that's fine,
it's more whether there was some reason the logic or macros
prohibited it |
| 17:42.37 |
brlcad |
like a C file
without blank lines, a bit of a readability hindrance |
| 18:12.40 |
CIA-61 |
BRL-CAD:
03brlcad * r47612 10/brlcad/trunk/misc/CMake/
(BRLCAD_CompilerFlags.cmake CompilerFlags.cmake): relax the
comparisons to substring matches |
| 18:14.22 |
CIA-61 |
BRL-CAD:
03brlcad * r47613 10/brlcad/trunk/CMakeLists.txt: similar, relax
string comparisons. makes the unknown value test a little more
robust |
| 18:18.12 |
CIA-61 |
BRL-CAD:
03brlcad * r47614 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake:
trying to make some sense of the logic, add ws for
readability |
| 18:29.43 |
CIA-61 |
BRL-CAD:
03brlcad * r47615 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake:
simplify logic with relaxed substring searching |
| 18:41.02 |
CIA-61 |
BRL-CAD:
03brlcad * r47616 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake:
more logic simplification. reorder IF/ELSE to avoid needing NOT,
eliminate need for multiple comparisons by using substring
comparison. reword cache string to indicate what action is being
taken. |
| 18:42.44 |
CIA-61 |
BRL-CAD:
03starseeker * r47617
10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: |
| 18:42.44 |
CIA-61 |
BRL-CAD: Make
an initial stab at support for library-wide usage of
<LIB>_DLL_IMPORTS |
| 18:42.44 |
CIA-61 |
BRL-CAD:
approach to building with MSVC. This is just hte macro logic and
(for the |
| 18:42.44 |
CIA-61 |
BRL-CAD:
moment, until the rest of this is worked out) the Windows build is
almost |
| 18:42.44 |
CIA-61 |
BRL-CAD:
certainly well and truly busted. |
| 18:48.13 |
CIA-61 |
BRL-CAD:
03starseeker * r47618 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake:
remove debug prints for now. |
| 18:48.38 |
CIA-61 |
BRL-CAD:
03brlcad * r47619
10/brlcad/trunk/misc/CMake/ThirdParty.cmake: |
| 18:48.39 |
CIA-61 |
BRL-CAD: big
restructuring in support of better reporting for whether bundled or
sys libs |
| 18:48.39 |
CIA-61 |
BRL-CAD: are
being used (and why). few cases weren't being handled and the
string |
| 18:48.39 |
CIA-61 |
BRL-CAD:
STREQUAL testing was causing cmake to report warnings. simplify
string |
| 18:48.39 |
CIA-61 |
BRL-CAD:
comparisons to substrings where applicable, reduce/reorder logic
for clarity, |
| 18:48.39 |
CIA-61 |
BRL-CAD: and
reword messages for consistency. |
| 18:52.33 |
CIA-61 |
BRL-CAD:
03starseeker * r47620 10/brlcad/trunk/misc/CMake/ThirdParty.cmake:
stray duplicate comment line |
| 19:01.05 |
CIA-61 |
BRL-CAD:
03brlcad * r47621
10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: |
| 19:01.06 |
CIA-61 |
BRL-CAD: sync
up with the same that was done for ThirdParty_Tcl.cmake using
consistent |
| 19:01.06 |
CIA-61 |
BRL-CAD:
printing statements (e.g., they might not be libs), relax to
substring matching |
| 19:01.06 |
CIA-61 |
BRL-CAD: and
reduced logic where we can. inject blank lines, separators, and
comments |
| 19:01.06 |
CIA-61 |
BRL-CAD: for
improved readabaility. |
| 19:09.19 |
CIA-61 |
BRL-CAD:
03starseeker * r47622 10/brlcad/trunk/include/ (22 files): Convert
all the include headers to the <LIB>_DLL_IMPORTS
format |
| 19:15.34 |
CIA-61 |
BRL-CAD:
03brlcad * r47623 10/brlcad/trunk/misc/CMake/ (33
files): |
| 19:15.34 |
CIA-61 |
BRL-CAD: as
these are build system infrastructure and not actual build rules,
they should |
| 19:15.34 |
CIA-61 |
BRL-CAD:
include the requisite license headers and footers like any other
source file. |
| 19:15.34 |
CIA-61 |
BRL-CAD:
CMakeLists.txt don't need the wrapping, but macro files
should |
| 19:26.11 |
starseeker |
brlcad: uh...
- a lot of those Find* cmake macro files are based on other macro
files, might want to be careful |
| 19:26.43 |
starseeker |
I'd have to
dig back to make sure, but I think at least FindGL, FindX11 and
FindYACC are based off of other macros |
| 19:27.02 |
starseeker |
I was waiting
until things settled to do a thorough review of all of
that |
| 19:38.47 |
CIA-61 |
BRL-CAD:
03brlcad * r47624 10/brlcad/trunk/autogen.sh: given the magnitude
of impact, add a massive deprecation notice to begin our requisite
deprecation notification process. refer them to the INSTALL file
for now since there's not (yet?) an equivalent step |
| 19:39.23 |
``Erik |
is seeing tons of cmake breakage right now, http://paste.lisp.org/display/126045 |
| 19:39.48 |
brlcad |
legally, that
needs to happen asap and should have happened before a release was
made with them |
| 19:40.17 |
starseeker |
k - I'll do a
scan-through |
| 19:41.21 |
brlcad |
if they are
mererly bundled for convenience, our header should be pulled or
appended after theirs |
| 19:41.36 |
starseeker |
most of them
are tweaked |
| 19:41.52 |
starseeker |
maybe all of
them |
| 19:45.34 |
brlcad |
if it's not
significant (like no logic changes, just additions of paths,
removal of code, or just a couple lines) then our header is
arguably not necessary |
| 19:47.19 |
brlcad |
``Erik: your
build failure looks related to r47617, work in progress .. though
my build curiously worked, maybe I need to wipe cache to hit
it |
| 19:47.58 |
CIA-61 |
BRL-CAD:
03starseeker * r47625 10/brlcad/trunk/misc/CMake/
(BRLCAD_Util.cmake CheckCFileRuns.cmake): Add the full license text
for ChechCFileRuns.cmake - need to fix up the rest of the
Kitware-based files to have the full BSD license txt. |
| 19:51.05 |
brlcad |
starseeker:
do they use the same 3-clause license? |
| 19:53.03 |
brlcad |
if they do,
there can just be 2 copyright lines instead of two copies of the
text |
| 19:53.07 |
starseeker |
I believe so,
give or take some minor wording and formatting... |
| 19:53.19 |
starseeker |
take a look
at CheckCFileRuns.cmake, it's got both |
| 19:54.06 |
CIA-61 |
BRL-CAD:
03starseeker * r47626
10/brlcad/trunk/misc/CMake/CheckPrototypeExists.cmake:
CheckPrototypeExists.cmake is from KDE, flesh out their BSD license
and add a link to the file origin |
| 19:59.30 |
CIA-61 |
BRL-CAD:
03brlcad * r47627 10/brlcad/trunk/autogen.sh: move the deprecation
section down so we're more sure echo -n work. still before anything
is printed. |
| 20:00.51 |
CIA-61 |
BRL-CAD:
03starseeker * r47628 10/brlcad/trunk/misc/CMake/FindLEMON.cmake:
FindLEMON was originally based on FindBISON - note that fact.
Trying to stay close to the formatting of 'standard' CMake modules
for those that we might have a hope of getting accepted into CMake
proper at some point. |
| 20:03.11 |
CIA-61 |
BRL-CAD:
03starseeker * r47629 10/brlcad/trunk/misc/CMake/FindLEX.cmake:
FindLEX.cmake is basically FindFLEX.cmake slightly generalized, and
we already had ourselves listed in the 'standard' CMake BSD
license. We may not even need this at all once the
perplex/re2c/lemon work is complete... |
| 20:04.07 |
starseeker |
mutter...
looks like I got some of them "properly" containing the full
license, but missed a few |
| 20:04.44 |
starseeker |
I think in
the GL/X11 case I might have been hoping to get the changes
accepted back... ah well, no matter |
| 20:08.22 |
CIA-61 |
BRL-CAD:
03starseeker * r47630 10/brlcad/trunk/misc/CMake/ (FindGL.cmake
FindX11.cmake FindZLIB.cmake): Add the rest of the 'full' licenses
for the Kitware stuff - was hoping to commit these changes back to
Kitware, but either way we'll have to hang on to these until we can
require a modern enough CMake with the changes. |
| 20:15.29 |
CIA-61 |
BRL-CAD:
03brlcad * r47631 10/brlcad/trunk/configure.ac: add a similar
massive deprecation notice with an annoying pause to
configure. |
| 20:18.38 |
CIA-61 |
BRL-CAD:
03brlcad * r47632 10/brlcad/trunk/configure.ac: put a deprecation
notice in the summary too since most people actually read
it. |
| 20:23.06 |
CIA-61 |
BRL-CAD:
03brlcad * r47633 10/brlcad/trunk/Makefile.am: last one, repeat the
deprecation warning when they run autotools make too. |
| 20:58.01 |
CIA-61 |
BRL-CAD:
03brlcad * r47634 10/brlcad/trunk/src/rt/view.c: |
| 20:58.01 |
CIA-61 |
BRL-CAD:
can't compile due to cmake errors, but add an ambOffset parameter
so you can |
| 20:58.01 |
CIA-61 |
BRL-CAD:
control how far we pull away from a surface before shooting ambient
rays. this |
| 20:58.01 |
CIA-61 |
BRL-CAD: is
intended to help 'smooth out' shots against polygonal models where
you get |
| 20:58.01 |
CIA-61 |
BRL-CAD:
artifacts from hitting nearby/neighboring polygons. |
| 20:58.09 |
starseeker |
reflects that with the new open source SCL activity, he's
probably going to need to beef up the FindSCL
macro... |
| 21:02.04 |
CIA-61 |
BRL-CAD:
03brlcad * r47635 10/brlcad/trunk/src/rt/view.c: reduce the code
duplication in ambient occlusion. pulling the branch out of both
loops is inconsequential to performance in the long
term. |
| 21:02.45 |
CIA-61 |
BRL-CAD:
03starseeker * r47636 10/brlcad/trunk/ (9 files in 9 dirs): This
should get the build working again on non Windows platforms...
also, start the process of clearing out BRLCAD_DLL |
| 21:04.18 |
starseeker |
brlcad:
something else is busted - LEMON_EXECUTABLE is set to
NOTFOUND |
| 21:06.10 |
starseeker |
and the
global BRLCAD_BUNDLED_LIBS flag being set to bundled isn't turning
everything on anymore |
| 21:20.18 |
brlcad |
curious, I
didn't modify FindLEMON |
| 21:21.15 |
brlcad |
the
BRLCAD_BUNDLED_LIBS isn't too surprising, couldn't test it with the
breakage and the logic in BRLCAD_Util seems quite a
mess.. |
| 21:40.14 |
brlcad |
looks like
the problem is actually in ThirdParty, fix forthcoming |
| 21:42.22 |
CIA-61 |
BRL-CAD:
03bob1961 * r47637 10/brlcad/trunk/include/ged.h: Added gdps_scale
to ged_data_polygon_state. |
| 21:52.05 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 21:58.59 |
CIA-61 |
BRL-CAD:
03brlcad * r47638 10/brlcad/trunk/misc/CMake/ThirdParty.cmake:
getting a feel for how the aggregate BRLCAD_BUNDLED_LIBS was
implemented. this makes ccmake report proper propagation of the
parent BUNDLED (AUTO) setting (but still keying off AUTO at higher
precedence than BUNDLED). |
| 22:35.56 |
CIA-61 |
BRL-CAD:
03brlcad * r47639
10/brlcad/trunk/misc/CMake/ThirdParty.cmake: |
| 22:35.57 |
CIA-61 |
BRL-CAD: this
seems to get things back to working for the parent
BRLCAD_BUNDLED_LIBS |
| 22:35.57 |
CIA-61 |
BRL-CAD:
option. wasn't accounting for a stray STREQUAL in the parent logic
and wasn't |
| 22:35.57 |
CIA-61 |
BRL-CAD:
setting the ON/OFF variable consistently with the statements being
printed |
| 22:48.01 |
CIA-61 |
BRL-CAD:
03brlcad * r47640
10/brlcad/trunk/misc/CMake/ThirdParty.cmake: |
| 22:48.01 |
CIA-61 |
BRL-CAD: if
BRLCAD_BUNDLED_LIBS is set to SYSTEM and system-installed libs
aren't |
| 22:48.01 |
CIA-61 |
BRL-CAD:
available, it's not our problem -- let them proceed as if it was
installed and |
| 22:48.01 |
CIA-61 |
BRL-CAD:
found since that's what they asked for. perhaps useful for
distribution |
| 22:48.01 |
CIA-61 |
BRL-CAD:
debugging. |
| 22:52.34 |
CIA-61 |
BRL-CAD:
03brlcad * r47641 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake:
mark BRLCAD_LIBS as advanced |
| 23:16.09 |
CIA-61 |
BRL-CAD:
03brlcad * r47642 10/brlcad/trunk/src/other/
(re2c/CMake/FindLEMON.cmake step/CMake/FindLEMON.cmake): sync
top-level cmake file |
| 23:46.32 |
CIA-61 |
BRL-CAD:
03starseeker * r47643 10/brlcad/trunk/misc/CMake/ThirdParty.cmake:
LIBRARY->EXECUTABLE |
| 00:08.46 |
CIA-28 |
BRL-CAD:
03starseeker * r48006 10/brlcad/trunk/CMakeLists.txt: Need to do
the 32/64 bit check earlier in the game, before we try to find
anything at all. |
| 00:09.41 |
CIA-28 |
BRL-CAD:
03n_reed * r48007 10/brlcad/trunk/src/other/perplex/ (scanner.re
scanner_template.c): Comparing disparate pointers is undefined.
Don't do it. |
| 00:37.42 |
CIA-28 |
BRL-CAD:
03n_reed * r48008 10/brlcad/trunk/src/other/perplex/ (scanner.re
scanner_template.c): need to update input markers if input buffer
is reallocated |
| 01:55.12 |
CIA-28 |
BRL-CAD:
03starseeker * r48009 10/brlcad/trunk/ (10 files in 2 dirs): Slew
of documentation updates. Not claiming final form yet, but
closer. |
| 02:07.49 |
CIA-28 |
BRL-CAD:
03starseeker * r48010 10/brlcad/trunk/doc/README.Windows: Start
reworking the Windows docs for CMake. |
| 02:13.23 |
CIA-28 |
BRL-CAD:
03starseeker * r48011 10/brlcad/trunk/ (8 files): Move the CMake
versions of doc files into place. |
| 02:19.18 |
dli |
svn version
building error: http://pastebin.com/HUC6ibBc |
| 02:23.58 |
CIA-28 |
BRL-CAD:
03starseeker * r48012 10/brlcad/trunk/ (INSTALL
src/other/CMakeLists.txt): Copy/paste strikes again |
| 02:33.51 |
CIA-28 |
BRL-CAD:
03starseeker * r48013 10/brlcad/trunk/configure.cmake.sh: Add a
bunch more of the options to the configure script. Looking more
like it will be possible to simply autogenerate the verbose part of
this. Also points out there are a few toplevel options that still
need docs. |
| 02:34.39 |
starseeker |
dli: can you
paste it using the mozilla pastebin? |
| 02:34.52 |
dli |
starseeker,
ok |
| 02:35.40 |
dli |
starseeker,
http://pastebin.mozilla.org/1407174 |
| 02:39.59 |
starseeker |
um... not
sure what's going on - I just got a clean build from latest trunk
here... what were your configure options? |
| 02:41.58 |
dli |
starseeker,
one moment |
| 02:45.05 |
dli |
starseeker,
http://pastebin.mozilla.org/1407179 |
| 02:45.58 |
dli |
starseeker,
reported from cmake: http://pastebin.mozilla.org/1407180 |
| 02:46.34 |
starseeker |
holy
bleep |
| 02:46.43 |
starseeker |
are you
building it as part of a packaging system? |
| 02:46.56 |
dli |
starseeker,
yes, in gentoo |
| 02:46.59 |
starseeker |
oh, I see
gentoo |
| 02:47.21 |
starseeker |
well, for one
thing, a lot of the options are incorrect for trunk |
| 02:48.23 |
starseeker |
and they
shouldn't be trying to turn off scl or utahrle, unless they've got
ebuilds of our own src/other srcs |
| 02:48.39 |
starseeker |
dli: where
did you get that ebuild from? |
| 02:48.43 |
starseeker |
is that an
overlay? |
| 02:48.48 |
dli |
starseeker,
yes |
| 02:48.53 |
starseeker |
which
one? |
| 02:49.06 |
dli |
starseeker,
science-overlay |
| 02:49.50 |
starseeker |
hmm. I'd
have to take a look, but it looks like someone either isn't
maintaining that ebuild or isn't paying close enough
attention |
| 02:50.09 |
dli |
starseeker,
very old ebuilds |
| 02:54.30 |
starseeker |
yeah, this
needs a total overhaul |
| 02:54.36 |
starseeker |
who's
maintaining it? |
| 02:55.37 |
starseeker |
he DISABLED
opengl?? |
| 02:56.03 |
starseeker |
and did it
wrong to boot - it's -DBRLCAD_ENABLE_OPENGL=OFF, not
-BRLCAD_ENABLE_OPENGL=OFF |
| 02:56.06 |
dli |
starseeker, I
disabled opengl, because builds fails with opengl |
| 02:56.35 |
starseeker |
O.o -
why? |
| 02:57.17 |
starseeker |
dli: can you
do me a favor? Just grab a trunk checkout and build it
"stand-alone" without the ebuild? |
| 02:57.35 |
starseeker |
cmake ..
-DBRLCAD_BUNDLED_LIBS=ON and see what happens? |
| 02:57.50 |
dli |
starseeker,
sure |
| 03:00.17 |
starseeker |
all the
BRLCAD_BUILD_LOCAL variables are obsolete and not doing
anything |
| 03:00.49 |
dli |
starseeker,
reported from cmake: http://pastebin.mozilla.org/1407198 |
| 03:00.58 |
starseeker |
to achieve
what it looks like he's after, all he had to do was
-DBRLCAD_BUNDLED_LIBS=System , but that doesn't stand a good chance
of working... |
| 03:01.18 |
starseeker |
dli: try
building once |
| 03:01.40 |
dli |
starseeker,
it's building |
| 03:02.25 |
dli |
starseeker,
/var/tmp/portage/media-gfx/brlcad-9999/work/brlcad-9999/include/sysv.h:61:26:
error: conflicting types for ‘strchr’ |
| 03:02.58 |
dli |
starseeker,
that's from cmake -DBRLCAD_BUNDLED_LIBS=ON . |
| 03:04.58 |
starseeker |
what's the
full error? |
| 03:05.10 |
starseeker |
previous
definition? |
| 03:06.17 |
dli |
starseeker,
that's all I got: http://pastebin.mozilla.org/1407203 |
| 03:06.32 |
starseeker |
also, you're
still using the gentoo brlcad-9999 sources? |
| 03:07.41 |
dli |
starseeker,
should not be, I run cmake in the source folder, gentoo builds it
in a different folder |
| 03:07.56 |
dli |
starseeker, I
can try to copy the source and try again |
| 03:09.20 |
starseeker |
dli: I'd
suggest starting totally clean, if you can |
| 03:09.34 |
dli |
starseeker,
no problem |
| 03:10.09 |
starseeker |
in your home
directory: svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk
brlcad && mkdir brlcad-build && cd brlcad-build
&& cmake ../brlcad -DBRLCAD_BUNDLED_LIBS=ON &&
make |
| 03:10.38 |
starseeker |
clearly
turning off opengl in CMake is causing some... unexpected issues,
I'll have to look into it |
| 03:11.59 |
dli |
starseeker,
trying again |
| 03:17.49 |
dli |
starseeker,
better, that error doesn't show up |
| 03:19.07 |
CIA-28 |
BRL-CAD:
03starseeker * r48014 10/brlcad/trunk/misc/CMake/ThirdParty.cmake:
Correct a few gross errors in ThirdParty.cmake, but still not clear
how disabling opengl is messing with everything. |
| 03:19.41 |
starseeker |
I gotta go -
dli, post how that turns out. Clearly I've got a bug to fix, but
that ebuild is hopelessly out of date |
| 03:20.03 |
dli |
starseeker,
ok |
| 04:43.57 |
CIA-28 |
BRL-CAD:
03starseeker * r48015 10/brlcad/trunk/misc/CMake/ (ThirdParty.cmake
ThirdParty_TCL.cmake): Er, right, macros. Reset a conditional
variable before using it again... |
| 05:01.34 |
starseeker |
dli: did it
build? |
| 05:03.12 |
dli |
starseeker,
it builds in a fresh folder |
| 05:03.25 |
dli |
starseeker,
but still couldn't get it build in ebuild |
| 05:05.30 |
starseeker |
that ebuild's
settings are way too aggressive |
| 06:11.59 |
CIA-28 |
BRL-CAD:
03starseeker * r48016 10/brlcad/trunk/ (3 files in 3
dirs): |
| 06:12.01 |
CIA-28 |
BRL-CAD: Do
more work to make BRLCAD_BUNDLED_LIBS=System do what it claims to
do. Also |
| 06:12.01 |
CIA-28 |
BRL-CAD: make
Tcl packages respect it, unless BRLCAD_TCL is overridden locally -
then |
| 06:12.01 |
CIA-28 |
BRL-CAD:
respect the local Tcl setting rather than BUNDLED_LIBS. Still needs
some |
| 06:12.01 |
CIA-28 |
BRL-CAD:
testing - not a terribly useful setting for us, but the Linux
distributions will |
| 06:12.01 |
CIA-28 |
BRL-CAD:
probably want it so we should shake it out and make it
behave. |
| 06:12.40 |
CIA-28 |
BRL-CAD:
03starseeker * r48017 10/brlcad/trunk/INSTALL: Doing Tk as a Tcl
extension, so docs are generated for it - add 'em. |
| 06:48.24 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 10:33.02 |
*** join/#brlcad hackrat
(~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 11:54.46 |
*** join/#brlcad ``Erik (~erik@BRLCAD.ORG) |
| 14:12.25 |
*** join/#brlcad packrat
(~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 16:22.42 |
CIA-28 |
BRL-CAD:
03starseeker * r48018 10/brlcad/trunk/src/other/CMakeLists.txt:
Needing the C library from a Tcl/Tk package is compilcating
things... however, a bit of a pattern is emerging... |
| 16:27.11 |
dli |
starseeker, I
updated ebuilds in gentoo science overlay. Noticed building
failures due to: LDFLAGS "--as-needed", BRLCAD_ENABLE_RTSERVER=ON,
and CXXFLAGS="-std=c++0x" |
| 16:32.28 |
starseeker |
hmm. yeah,
rtserver's build can be a bit finicky |
| 16:32.44 |
starseeker |
that's the
java bit - I doubt most people would miss it |
| 16:33.11 |
starseeker |
hehe - this
is awesome: |
| 16:33.23 |
starseeker |
'"Computer
scientists" don't write code, they write books explaining why all
existing implementations are wrong.' |
| 16:34.58 |
dli |
starseeker,
still, gentoo wants features be specified by USE flags, not but
auto-detection, so, it's not encouraged to use
BRLCAD_BUNDLED_LIBS=AUTO |
| 16:42.23 |
starseeker |
dli: yeah, I
know - one of the longer active bugs in the history of the gentoo
bug database was the "here's a BRL-CAD ebuild" discussion arguing
about things like autodetection and default installation
location |
| 16:43.11 |
dli |
starseeker,
default location settled down to /usr/brlcad/, iirc |
| 16:43.16 |
starseeker |
The commits
last night were working to fix the "System" setting for
BRLCAD_BUNDLED_LIBS. That's what distributions *should* set in the
future if they don't want any of our bundled libs |
| 16:44.04 |
starseeker |
It will still
annoy them because System won't disable opennurbs, scl, and one or
two other src/other libraries |
| 16:44.32 |
starseeker |
the reason
for that, however, is those are *locally modified* copies - a
system version, at least at the moment, would not be expected to
work correctly |
| 16:45.39 |
starseeker |
we *could*
stick those local "forks" into our own source tree and avoid the
issue, but the point/hope is to eventually establish those as
separate projects - progress is already being made in that regard
with scl |
| 16:46.10 |
starseeker |
src/other
libraries and tools tend to have more uses than just BRL-CAD, so
there is a reasonable hope they will attract other
interest |
| 16:46.47 |
starseeker |
the odds of
that go up if it's easy to build the library "in
isolation" |
| 16:47.38 |
starseeker |
so we
maintain our build system in such a way that those libraries are
seaprate projects, even though we're the only users/source for
those particular versions |
| 16:47.51 |
starseeker |
s/seaprate/separate/g |
| 16:50.28 |
starseeker |
scl (the Step
Class Libraries) is showing activity on a github project, and once
we get things to the point where their build and auto-generated
output work for us and support our step-g convertor, we'll be able
to use a hypothetical system SCL install |
| 16:51.10 |
dli |
starseeker,
setting to System fails with svn: http://pastebin.mozilla.org/1408136 |
| 16:51.54 |
starseeker |
dli: do you
have itcl and itk installed? |
| 16:52.38 |
dli |
starseeker,
yes: Installed versions: 3.4_beta1, Installed versions:
3.4_pre20090417-r1 |
| 16:53.05 |
starseeker |
where is
libitcl located? |
| 16:53.11 |
starseeker |
and
libitk? |
| 16:53.39 |
dli |
starseeker,
/usr/lib64/itcl3.4/libitcl3.4.so |
| 16:53.53 |
dli |
/usr/lib64/itk3.4/libitk3.4.so |
| 16:54.23 |
starseeker |
alright...
let me see if I can tell why the find_library calls aren't seeing
those |
| 16:56.13 |
starseeker |
oh, by the
way - unless gentoo's lemon package puts lempar.c in /usr/bin/,
lemon isn't going to work |
| 16:59.45 |
CIA-28 |
BRL-CAD:
03starseeker * r48019 10/brlcad/trunk/src/other/CMakeLists.txt: We
need the ITCL version set for find_library... since we aren't
testing for it when we're going whole-hog system, set it to 3.4 if
it's not defined. |
| 17:00.44 |
starseeker |
need to think
about that one... ideally, even if we're forcing system we'd still
want the version installed if there is one... |
| 17:01.10 |
starseeker |
jeez, this
business of using Tcl/Tk package C libraries is a
nightmare |
| 17:07.58 |
starseeker |
actually,
gentoo doesn't even have its own lemon package - must be part of
sqlite |
| 17:09.33 |
starseeker |
aaand the
installed one doesn't like something |
| 17:09.39 |
starseeker |
even with
lempar.c present |
| 17:14.31 |
starseeker |
dli: you have
re2c installed? |
| 17:14.52 |
starseeker |
dev-util/re2c-0.13.5 is what I've got
here... |
| 17:15.03 |
dli |
starseeker,
yes, Installed versions: 0.13.5 |
| 17:15.07 |
starseeker |
ok |
| 17:15.24 |
starseeker |
that looks
like it should work, but the system lemon is a disaster |
| 17:15.35 |
starseeker |
it's not even
versioned on its own |
| 17:16.21 |
starseeker |
and I can't
stick lempar.c in /usr/bin even if this version HAD worked... talk
about your sandbox violations |
| 17:16.47 |
starseeker |
perplex is
written by one of our own developers to wrap re2c, so there won't
be a package for that one |
| 17:16.51 |
starseeker |
one
sec... |
| 17:19.25 |
CIA-28 |
BRL-CAD:
03starseeker * r48020 10/brlcad/trunk/ (misc/CMake/ThirdParty.cmake
src/other/CMakeLists.txt): (log message trimmed) |
| 17:19.25 |
CIA-28 |
BRL-CAD:
Extend the NOSYS mechanism to tools as well. Perplex is our own
tool, so even a |
| 17:19.25 |
CIA-28 |
BRL-CAD:
SYSTEM install isn't going to have it available (it's our own code,
just being |
| 17:19.25 |
CIA-28 |
BRL-CAD:
treated as a separate project) and trying to use a system version
of lemon is... |
| 17:19.25 |
CIA-28 |
BRL-CAD:
problematic, to say the very least. lempar.c isn't likely to be
present, and |
| 17:19.25 |
CIA-28 |
BRL-CAD: even
when our copy is placed in /usr/bin problems occurred. lemon
isn't |
| 17:19.25 |
CIA-28 |
BRL-CAD:
packaged by itself, so it's hard to know what to do about that...
suggest |
| 17:22.06 |
CIA-28 |
BRL-CAD:
03starseeker * r48021 10/brlcad/trunk/src/libged/simulate/simrt.c:
shadowed variable warning... |
| 17:29.48 |
*** join/#brlcad Elrohir
(~kvirc@p579F0159.dip.t-dialin.net) |
| 17:33.32 |
dli |
starseeker,
it works now, with System |
| 17:34.08 |
starseeker |
There's a
lemon ebuild in an overlay: http://gpo.zugaina.org/dev-util/lemon/euscan |
| 17:37.55 |
CIA-28 |
BRL-CAD:
03n_reed * r48022 10/brlcad/trunk/src/other/perplex/ (scanner.re
scanner_template.c): cleanup |
| 17:38.09 |
starseeker |
that DOES
work, if I re-work the FindLEMON logic a bit |
| 17:38.25 |
starseeker |
http://gentoo-overlays.zugaina.org/gentoo-zh/portage/dev-util/lemon/ |
| 17:38.49 |
starseeker |
that would be
a good one to advocate for in the main gentoo trunk, to help a
system BRL-CAD build work |
| 17:39.06 |
starseeker |
he's patched
lemon so the template file can live in /usr/share |
| 17:52.49 |
CIA-28 |
BRL-CAD:
03starseeker * r48023 10/brlcad/trunk/ (misc/CMake/FindLEMON.cmake
src/other/CMakeLists.txt): Redo the handling of lemon a bit, since
there does exist at least one working path for a viable system
lemon installation. |
| 17:54.18 |
starseeker |
hah - there's
a redhat package too, that apparently does the same
thing |
| 17:54.20 |
starseeker |
sweet |
| 17:54.28 |
starseeker |
http://rpm.pbone.net/index.php3/stat/4/idpl/15156214/dir/redhat_el_5/com/lemon-3.6.20-1.el5.i386.rpm.html |
| 18:00.11 |
starseeker |
and it looks
like FreeBSD does something sane |
| 18:00.18 |
starseeker |
looks like
Gentoo is behind the curve |
| 18:00.24 |
starseeker |
embarassing
on a dev tool |
| 18:03.18 |
CIA-28 |
BRL-CAD:
03starseeker * r48024 10/brlcad/trunk/src/other/CMakeLists.txt:
Rework explanatory text for lemon |
| 18:04.51 |
starseeker |
dli: it
should still work with Gentoo, but you'll probably need that
overlay ebuild install of lemon |
| 18:05.04 |
starseeker |
or specify
-DBRLCAD_LEMON=Bundled |
| 18:09.28 |
starseeker |
and there's
no tkhtml ebuild that I can see, so out of the box archer won't
work... |
| 18:18.25 |
CIA-28 |
BRL-CAD:
03starseeker * r48025
10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: Add a note about
another refactor needed to allow local enabling - right now can't
set SYSTEM and then turn on just Tkhtml |
| 19:39.56 |
CIA-28 |
BRL-CAD:
03bob1961 * r48026 10/brlcad/trunk/src/libtclcad/tclcad_obj.c:
Allow empty polygons. |
| 19:45.46 |
CIA-28 |
BRL-CAD:
03bob1961 * r48027 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Add
callbacks for polygon creation. |
| 21:50.30 |
CIA-28 |
BRL-CAD:
03n_reed * r48028 10/brlcad/trunk/misc/CMake/FindPERPLEX.cmake:
Corrected perplex and re2c options. Basing re2c intermediate name
on output name, not output path. |
| 22:46.09 |
CIA-28 |
BRL-CAD:
03n_reed * r48029 10/brlcad/trunk/src/libgcv/wfobj/tri_face.c:
s/BU_GET/bu_pool_get/ so that freeing with standard nmg routines
doesn't cause bomb. |
| 00:03.39 |
jordisayol |
brlcad: can
you please give me some info about rpm failure reports? |
| 00:38.26 |
jordisayol |
I have to
go |
| 00:38.42 |
jordisayol |
brlcad: bye
bye |
| 00:38.49 |
brlcad |
ok |
| 00:38.52 |
brlcad |
sorry, got
distracted |
| 00:38.56 |
brlcad |
the reports
were here |
| 00:39.05 |
brlcad |
12:16 <
xFirex_> Hello Everyone, I have a problem with BRLCad
brlcad-7.20.4-0.fedora.i386.rpm in Fedora 16 |
| 00:39.08 |
brlcad |
12:16 <
xFirex_> Getting this error when trying to start it
"/usr/brlcad/bin/mged: error while loading shared libraries:
libtclcad.so.19: cannot open shared object file: No such file or
directory " |
| 00:39.31 |
brlcad |
then another
individual a little while later12:35 < Konopen> Hello
Everyone, I have problem running brlcad 7.20.4-0 in fedora
16 |
| 00:42.23 |
jordisayol |
brlcad: do
you know if they re-login after install? |
| 00:42.32 |
brlcad |
onope |
| 00:42.40 |
brlcad |
ill ask if
they come back |
| 00:42.54 |
jordisayol |
brlcad: paths
need re-login to be loaded |
| 00:43.00 |
brlcad |
do you modify
ldconfig or something? |
| 00:43.41 |
jordisayol |
nop, i just
modify the path and manpath env variables |
| 00:44.08 |
brlcad |
hm,
interesting |
| 00:44.52 |
brlcad |
okay, well if
someone else reports same error we'll see if that does the trick
:) |
| 00:45.00 |
brlcad |
good to know,
thanks |
| 00:45.18 |
brlcad |
would be good
note for the release notes if it wasn't included |
| 00:45.19 |
jordisayol |
wait a
moment.... |
| 00:49.37 |
jordisayol |
brlcad: the
script executed during the installation is:
brlcad/misc/debian/brlcad.postinst and when removed
brlcad/misc/debian/brlcad.postrm , that's all |
| 00:49.46 |
brlcad |
k |
| 00:51.03 |
brlcad |
under
traditional gnu ld behavior, that shouldn't affect a runtime error
loading shared libraries |
| 00:51.24 |
brlcad |
but I know
there have apparently been some major changes to the behavior of ld
recently on linux |
| 00:52.44 |
jordisayol |
tomorrow I'll
create a virtual machine with fedora 16 . is important the bit, 32
or 64? |
| 00:52.56 |
brlcad |
no idea, they
weren't specific |
| 00:53.28 |
jordisayol |
well, I don't
think so |
| 00:54.17 |
jordisayol |
ok, tomorrow
i'll tell you something about |
| 00:55.12 |
jordisayol |
brlcad: goog
night for me :-) near 2 o'clock here |
| 00:55.19 |
brlcad |
cya
:) |
| 00:55.24 |
jordisayol |
bye |
| 07:07.43 |
*** join/#brlcad packrat
(~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 07:12.13 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 08:14.34 |
*** join/#brlcad packrat
(~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 12:57.12 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
| 13:15.22 |
jordisayol |
brlcad:
ping |
| 15:18.14 |
``Erik |
O.o |
| 15:19.16 |
``Erik |
jordisayol:
personal, or something that someone else can help with? |
| 15:19.46 |
jordisayol |
``Erik:
hello! |
| 15:20.31 |
``Erik |
this laptop
isn't letting me scroll up right, you're doing something with a
debain leenewx variant? |
| 15:20.43 |
``Erik |
debian, even
:) |
| 15:21.16 |
``Erik |
and something
about fedora, even... but still linux |
| 15:21.19 |
jordisayol |
No, is just
that yesterday brlcad toll me that some fedora 16 users experienced
problems with our rmp packages |
| 15:21.48 |
``Erik |
I vagually
recall something about some sigill stuff, is that it |
| 15:22.27 |
jordisayol |
well, he says
something about the shared libraries |
| 15:22.41 |
jordisayol |
missing for
mged command |
| 15:23.19 |
``Erik |
hm, you'll
have to help me help you... the typical issue is requiring dev libs
(.so) instead of user libs (.so.0.0) |
| 15:23.26 |
``Erik |
in the link
stage |
| 15:23.40 |
``Erik |
(linux uses
.so, right?) |
| 15:24.17 |
jordisayol |
yes, but this
problem do not happen on fedora 15 and previous
releases |
| 15:24.25 |
``Erik |
if you do,
um, the command to show link deps on the mged binary, that'll tell
you a lot |
| 15:25.07 |
jordisayol |
the case is
that today I've installed fedora 16 (64-bit) on a virtualbox, and
in this clean linux, the mged properly works without
problems |
| 15:25.48 |
``Erik |
and 64b is
the issue they complain about? or 32b? |
| 15:25.55 |
brlcad |
``Erik: you
read up on the penny arcade lashing? hilarious |
| 15:26.00 |
brlcad |
jordisayol:
pong :0 |
| 15:26.03 |
jordisayol |
brlcad don't
know |
| 15:26.08 |
``Erik |
brlcad: ocean
marketing? yeah... |
| 15:26.13 |
jordisayol |
hello
brlcad |
| 15:26.14 |
brlcad |
hehe |
| 15:26.22 |
``Erik |
talk about
putting a foot in ones mouth |
| 15:26.33 |
``Erik |
"bah, I can
get into pax, who is this gabe guy? |
| 15:26.50 |
jordisayol |
hmmm, I
already take lunch today.... |
| 15:27.22 |
``Erik |
brlcad:
bz->crit ? |
| 15:27.42 |
brlcad |
good idea
actually |
| 15:28.07 |
brlcad |
been catching
up on mails and commits, but this would be a good time |
| 15:28.22 |
``Erik |
over a year
coming |
| 15:28.52 |
``Erik |
I put up an
ssl httpd on crit, that might... complicate things. |
| 15:28.59 |
jordisayol |
brlcad: I've
installed rpm for fedora on a fresh installed fedora 16 in
virtualbox, and there is not any problem, even without re-login,
just typing the full path /usr/brlcad/bin/mged |
| 15:29.29 |
brlcad |
jordisayol:
okay, that's all that can be done for now then |
| 15:29.44 |
jordisayol |
brlcad:
yes |
| 15:29.49 |
``Erik |
jordisayol:
can you pastebin ldd path/to/mged to see if there's an dev vs user
lib issue? |
| 15:29.51 |
brlcad |
if it can't
be reproduced and the person isn't here, we'll just have to wait
for a follow-up report if any |
| 15:30.15 |
``Erik |
(it's ldd,
right? so used to otool -L) |
| 15:30.19 |
jordisayol |
ok, just a
moment |
| 15:30.49 |
jordisayol |
yes, it
is |
| 15:32.27 |
brlcad |
what I
suspect is happening is there's some incompatible library already
installed on their fedora system |
| 15:32.45 |
brlcad |
that or it
was a partial/failed rpm download |
| 15:33.10 |
brlcad |
from the
report, libtclcad.so.19 fails to load |
| 15:33.23 |
``Erik |
if this is
the sigill, it's a damaged binary, damaged cpu, or cpu spec'd for a
different arch (686 vs 586 using 686 only opcodes) |
| 15:33.29 |
brlcad |
that may
simply be the first library attempting to be loaded |
| 15:33.33 |
``Erik |
illegal
instruction and all |
| 15:34.11 |
brlcad |
it wasn't
getting that farb |
| 15:34.17 |
brlcad |
far
even |
| 15:34.22 |
brlcad |
12:16 <
xFirex_> Getting this error when trying to start it
"/usr/brlcad/bin/mged: error while loading shared libraries:
libtclcad.so.19: cannot open shared object file: No such file or
directory " |
| 15:34.54 |
``Erik |
ah, my bad,
thought I saw a sigill convo and this was pertinant... this laptop
won't let me page up to read backlog :) |
| 15:36.33 |
``Erik |
brlcad: I
took the day off, I want crit to get to 'stable' asap, I don't want
to be responsible for other biz's and such, but will aid how I
can... lets DO THI! YEAH!
</joeswansonfromfamilyguy> |
| 15:38.38 |
jordisayol |
brlcad: here
you have it: http://paste.debian.net/150390/ |
| 15:40.28 |
jordisayol |
brlcad:
partial/failed is very unprovable because as rpm are compresses gz
files, they cannot uncompress. |
| 15:41.22 |
brlcad |
yeah, so
libtclcad is the first lib listed there |
| 15:41.54 |
``Erik |
my guess
would be that the issue is because someone installed to somewhere
other than /usrbrlcad |
| 15:42.05 |
brlcad |
that could
be |
| 15:42.31 |
brlcad |
whew, that
mystery is solved |
| 15:43.11 |
jordisayol |
well, i can
test this, by installing one by one on the system and testing mged.
but this requires some time |
| 15:43.26 |
``Erik |
can it be
scripted? |
| 15:43.29 |
brlcad |
jordisayol:
if you like, but I wouldn't worry about it |
| 15:43.43 |
``Erik |
machine time
is cheap, human time is expensive :) |
| 15:44.00 |
brlcad |
it's all
speculation without that user -- more time effective to just wait
for someone else to report an issue since it can't be easily
reproduced |
| 15:44.07 |
jordisayol |
brlcad: can
you make a "short" list of the probably libraries from the
list? |
| 15:44.29 |
brlcad |
it seemed
like more than that given two people reported a failure within a
couple hours for fed16 but could have just been
coincidence |
| 15:44.47 |
brlcad |
still all
speculation though |
| 15:44.55 |
jordisayol |
or just the
same user loget with different nicks |
| 15:45.17 |
jordisayol |
loed* |
| 15:45.35 |
jordisayol |
arggg!
"logged" |
| 15:45.59 |
``Erik |
smells like
someone thought they were smarter than they were and screwed up
being "clever" |
| 15:46.12 |
brlcad |
jordisayol:
looks like they were the same person, same ip |
| 15:46.21 |
jordisayol |
hehe |
| 15:46.23 |
brlcad |
so yeah,
don't worrya bout it ;) |
| 15:48.56 |
jordisayol |
well, if this
"schizophrenic" user re-login, then we can continue the
research |
| 15:49.18 |
``Erik |
brlcad: bz
lacks modssl and modproxy, which is why i'm reliant on crit. I'm
using app servers behind modproxy, thus my interest in migration :)
think we can knock it out before the newyear? |
| 15:49.56 |
brlcad |
possibly |
| 15:50.05 |
brlcad |
quite likely
even |
| 15:51.03 |
``Erik |
jordisayol:
yeah, I'd call it pebcak, awesome that you're so aggressive in
making it right :) |
| 15:52.43 |
jordisayol |
well, I don't
know what "pebcak" is, but thank you :-) |
| 15:53.52 |
``Erik |
"problem
exists between computer and keyboard" |
| 15:54.46 |
jordisayol |
wow! i'll
keep this sentence, hehe |
| 15:55.26 |
brlcad |
~pebcak |
| 15:55.26 |
ibot |
methinks
pebcak is Problem Exists Between Chair And Keyboard |
| 15:55.28 |
``Erik |
<-- marks
jordisayol down as a hero of open source software maintenance O.o
:) |
| 15:55.35 |
``Erik |
er, chair and
keyboard, my bad |
| 15:55.55 |
jordisayol |
I think
``Erik is right :-/ |
| 15:55.58 |
brlcad |
usb isn't
likely the problem ;) |
| 15:56.08 |
``Erik |
din5,
beeyotch |
| 15:56.18 |
``Erik |
sometimes
ps2 |
| 15:57.58 |
``Erik |
brlcad:
ponder... ssh tunnel for 3306 to new machine, migrate mysqldb, test
on various hosted sites, then start moving sites? |
| 15:58.21 |
``Erik |
(or is there
an acceptable downtime window?) |
| 15:59.15 |
brlcad |
downtime is
acceptable if it's less than a few hours |
| 15:59.21 |
brlcad |
tunnel would
work too |
| 16:00.46 |
``Erik |
I don't know
the write rates of the variou sites, so I can't plot optimal
migration |
| 16:01.29 |
``Erik |
but I do want
you to stop paying for that old clunker ;) |
| 16:02.22 |
brlcad |
this biggest
one should be no longer active (bzflag's list service) |
| 16:03.41 |
``Erik |
personally,
I'd bias impact based on $$'s... a free service can take several
hours downtime... a day or two, even |
| 16:03.43 |
brlcad |
I'll get
working on moving our site today, that should at least get things
going again |
| 16:04.00 |
``Erik |
it's those
$'s that scare me |
| 16:04.01 |
brlcad |
when was the
last fs sync? |
| 16:04.10 |
``Erik |
iuhho |
| 16:04.25 |
``Erik |
I don't know
if this machine has ever been synced |
| 16:05.16 |
``Erik |
ya starting
one up? |
| 16:05.19 |
brlcad |
.bz is
technically a free service to those $$ users, so that's why a few
hours is still acceptable .. just within reason shouldn't be more
than a couple hours tops and that's with things going horribly
wrong |
| 16:05.47 |
brlcad |
i'll check on
it, don't want to migrate everything but user data is a good one to
start with |
| 16:06.04 |
``Erik |
I'm an rsync
newb, so if you know it, I'll step back |
| 16:06.15 |
``Erik |
otherwise,
I'll pull up tutorial sites and start, let me know |
| 16:06.51 |
``Erik |
I had some
c&p scripts on the old crit, but no understanding |
| 16:09.16 |
``Erik |
http://www.solitechgmbh.com/2010/03/06/using-rsync-for-quick-server-migartion/
seems useful |
| 16:09.20 |
brlcad |
you can sync
the passwd/group files |
| 16:12.55 |
``Erik |
done |
| 16:13.05 |
brlcad |
gettings an
fs manifest, I'll sync user data |
| 16:13.37 |
brlcad |
is the
sslified apache from ports or custom install? |
| 16:14.57 |
``Erik |
ports |
| 16:15.07 |
brlcad |
great |
| 16:15.12 |
``Erik |
lacks a
primary, is all for vhost |
| 16:15.43 |
``Erik |
well, it has
a self-signed for primary, rather |
| 16:16.10 |
``Erik |
"namecheap"
was offering a free year of ssl for one name, so I grabbed one for
elfga.com |
| 16:16.26 |
brlcad |
that's fine,
nothing else using ssl obviously :) |
| 16:16.40 |
``Erik |
they're also
offering discounts and donations to eff for people who move from
godaddy after the sopa mess |
| 16:16.55 |
``Erik |
$10/yr for a
basic cert |
| 16:17.01 |
``Erik |
or
so |
| 16:17.41 |
brlcad |
another task
you could take up, setting up intrusion detection/monitoring and
stats |
| 16:18.18 |
``Erik |
I'm not sure
what all you have set up, I've been manually setting the ipfw
rules |
| 16:18.26 |
brlcad |
my manual
scripts are rather old school now .. I'd imagine there has to be
some better tools in ports that could be set up |
| 16:18.34 |
brlcad |
or even just
migrating what's there, but that's not needed |
| 16:19.27 |
brlcad |
basically
"figure something out" so some measure is in place, ideally
something that firewalls based on some profile of bad
actvitivity |
| 16:19.43 |
``Erik |
we're not
running telnetd, so there's no remote issue... I really don't know
heh :( |
| 16:19.56 |
``Erik |
what's the,
uh, auto-ipfw deny script on bz? |
| 16:20.02 |
``Erik |
I'll migrate
it as a first stage |
| 16:20.19 |
``Erik |
and we can
todo a better solution |
| 16:21.22 |
``Erik |
(I mean, no
default accounts, no simple pw's, I don't think the risk profile is
that high righ tnow) |
| 16:21.47 |
``Erik |
ack, lappy
assploded |
| 16:22.44 |
``Erik |
defcon slides
say "don't be stupid with setup" |
| 16:22.58 |
brlcad |
/etc/sbin and
/etc/crontab have the juicy details |
| 16:23.23 |
brlcad |
but you'll
have to go through each crontab one at a time to make sure it still
is applicable for crit |
| 16:23.41 |
brlcad |
potential
path and tool changes, safeguard changes, etc |
| 16:23.51 |
brlcad |
nothing
terribly complicated, should be obvious |
| 16:24.03 |
``Erik |
oh, your
logging stuff, I've no idea what's up with that stuff |
| 16:24.07 |
``Erik |
go set that
up |
| 16:24.22 |
brlcad |
that can be
later |
| 16:24.33 |
``Erik |
ok, crit has
been unlogged so far, fwiw |
| 16:24.47 |
brlcad |
knows |
| 16:24.49 |
``Erik |
pheer my
botnets |
| 16:25.05 |
brlcad |
so that's why
you're logged in 15 times |
| 16:26.47 |
``Erik |
don't make me
slap your fro |
| 16:27.42 |
``Erik |
(I believe
this is the first time I've seen bz below 1.0 load) |
| 16:29.24 |
brlcad |
http://www.zazzle.com/dont_tease_my_fro_tshirt-235666363645812532 |
| 16:34.02 |
``Erik |
http:/crit.brlcad.org:3000 |
| 16:37.16 |
brlcad |
don't know
what to make of that |
| 16:38.55 |
``Erik |
did it not
work? |
| 16:40.07 |
brlcad |
I get a page,
but have no idea what "Advertising Testes" are .. sounds
sticky |
| 16:40.52 |
``Erik |
that's bottom
goop, it's basically a 'todo' list on steroids, or a project
management suite stripped down |
| 16:41.15 |
``Erik |
add
locations, add tasks to locations, ... |
| 16:41.37 |
brlcad |
what about
locationless tasks? :) |
| 16:41.51 |
``Erik |
location
called "anywhere" ;) I have one called "internet" |
| 16:42.47 |
``Erik |
(seriosuly,
tell me what sucks, obviously the landing page pitch sucks... but
learn and adjust, right?) |
| 16:44.01 |
brlcad |
having to add
a location sucks :) |
| 16:44.35 |
``Erik |
"better
default settings", roger |
| 16:45.06 |
``Erik |
home and
work, big honkin' delete buttons, yeh |
| 16:46.37 |
brlcad |
after I
created a location, I could add a task but then I can't get back to
that page if I merely start over .. back to creating a
location |
| 16:46.43 |
brlcad |
i.e, better
navigation |
| 16:47.34 |
``Erik |
hroger, I've
been unhappy with the default rails navigation myself |
| 16:47.37 |
brlcad |
when I
recreated the same location, now it lists twice on the tasks page
(along with a handful of other locations I didn't add) |
| 16:47.45 |
``Erik |
uniq opt,
ok |
| 16:48.04 |
``Erik |
bah, other
locs/ |
| 16:48.18 |
``Erik |
ok, hold
up... is the basic premise something you might use |
| 16:48.21 |
``Erik |
? |
| 16:49.32 |
brlcad |
dunno |
| 16:49.39 |
brlcad |
utility of
task tracking software is mostly dependant on usability (and some
on flexibility) |
| 16:50.03 |
``Erik |
the idea is a
todo list with deps, so things that are not readt are not
listed |
| 16:50.06 |
brlcad |
it's hard to
get that usability down to dead-simple obvious and still be
flexible enough for a given purpose |
| 16:50.41 |
``Erik |
(this is a
throw-away to help me learn rails, btw) |
| 16:52.29 |
``Erik |
yeah,
actually, I wrote this to help me, and I haven't used it... imma
call it :) |
| 16:52.49 |
brlcad |
heh |
| 17:58.34 |
brlcad |
woot,
transfer underway |
| 18:32.08 |
CIA-28 |
BRL-CAD:
03n_reed * r48175
10/brlcad/trunk/src/tclscripts/boteditor/botTools.tcl: rename some
labels to increase clarity |
| 22:03.45 |
*** join/#brlcad b0ef
(~b0ef@241.194.251.212.customer.cdi.no) |
| 22:07.51 |
CIA-28 |
BRL-CAD:
03n_reed * r48176 10/brlcad/trunk/src/tclscripts/boteditor/
(botEditor.tcl botPropertyBox.tcl): allow setting bot mode and
orientation from gui |
| 22:23.42 |
*** join/#brlcad ibot (~ibot@rikers.org) |
| 22:23.42 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in
Space! |
| 23:34.10 |
*** join/#brlcad kunigami
(~kunigami@201.53.198.241) |
| 23:35.32 |
*** join/#brlcad packrat
(~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
){kind=link}
