00:34.10 |
Notify |
03BRL-CAD:starseeker * 62996
brlcad/trunk/regress/repository.sh: Update repository regression
script. |
00:34.33 |
Notify |
03BRL-CAD:brlcad * 62997
brlcad/trunk/src/libfb/if_wgl.c: no WSA or other networking calls,
so should only need bselect.h |
01:48.47 |
Notify |
03BRL-CAD:brlcad * 62998
brlcad/trunk/include/bsocket.h: catch order inclusion issues even
when not compiling on windows |
01:49.06 |
Notify |
03BRL-CAD:brlcad * 62999
brlcad/trunk/include/bnetwork.h: reword, clarity |
02:23.15 |
Notify |
03BRL-CAD:starseeker * 63000
brlcad/trunk/src/libfb/if_wgl.c: rename |
02:33.16 |
Notify |
03BRL-CAD:starseeker * 63001
brlcad/trunk/src/bwish/cadAppInit.c: tweak cadAppInit.c
headers |
02:38.04 |
Notify |
03BRL-CAD:starseeker * 63002
(brlcad/trunk/src/mged/dm-generic.c
brlcad/trunk/src/mged/fbserv.c): Tweak some mged header includes -
not sure if these are right yet... |
02:42.52 |
Notify |
03BRL-CAD:starseeker * 63003
brlcad/trunk/src/mged/dm-generic.c: reorder includes for
Windows |
02:48.35 |
Notify |
03BRL-CAD:starseeker * 63004
brlcad/trunk/include/bu/version.h: Need defines or BU_EXPORT won't
function on Windows. |
02:50.19 |
starseeker |
grr |
02:50.33 |
starseeker |
tries to figure out what he's
still missing for version.h... |
02:52.44 |
Notify |
03BRL-CAD:starseeker * 63005
brlcad/trunk/src/libbu/vers.c: add the header to vers.c |
03:16.37 |
Notify |
03BRL-CAD:starseeker * 63006
(brlcad/trunk/src/adrt/isst_tcltk.c
brlcad/trunk/src/conv/asc/asc2g.c): Linux header tweaks |
03:22.28 |
starseeker |
urk. http://sourceforge.net/p/tcl/mailman/message/32865888/ |
03:24.40 |
starseeker |
think that's got it... Windows build
progressing now |
03:33.25 |
starseeker |
bingo |
03:58.51 |
brlcad |
starseeker: what was up with
src/adrt/isst_tcltk.c ? |
03:59.40 |
brlcad |
header rules should put dm.h after all system
headers, including gl.h and the bu headers etc |
04:24.42 |
Notify |
03BRL-CAD:brlcad * 63007
brlcad/trunk/src/adrt/isst_tcltk.c: ws |
05:36.32 |
brlcad |
starseeker: quick test on my laptop with just
libbu with and without header breakout, ~8% build time improvement
(wallclock) best case |
05:38.41 |
brlcad |
takes about 10sec to build libbu, so good bit
of noise in the numbers, but it is consistently faster
(whew!) |
05:38.53 |
brlcad |
so probably warrants checking the overall
build time |
05:39.29 |
brlcad |
here's a script that converts from breakout to
bu.h: |
05:42.54 |
brlcad |
cd include ; for file in ../src/[^o]*/*.c
../src/[^o]*/*/*.c ../src/[^o]*/*/*.c ../src/[^o]*/*/*/*.c ; do
second=0 ; for header in bu/*.h ; do if grep --quiet -E "include
\"$header\"" $file ; then if test $second -eq 0 ; then echo "$file:
SWAP $header for bu.h" ; perl -pi -e "s,include \"$header\",include
\"bu.h\"," $file ; second=1 ; else echo "$file: KILL $header" ;
perl -pi -e "s,.*include \"$header\",," $file ; fi ; fi ; done ;
done ; cd |
05:43.06 |
brlcad |
meant to be run from the top-level source
dir |
05:44.46 |
brlcad |
you'll want to comment out the header order
check in bsocket.h and bnetwork.h too |
06:00.04 |
brlcad |
does a full build test on old
mac |
06:00.39 |
brlcad |
(made sure to disable docs and prebuild
src/other before "time make") |
06:04.52 |
Notify |
03BRL-CAD:brlcad * 63008
brlcad/trunk/src/librt/primitives/pipe/pipe.c: pipe shadows pipe()
when unistd is included |
06:06.54 |
Notify |
03BRL-CAD:brlcad * 63009
brlcad/trunk/src/librt/primitives/pipe/pipe.c: didn't intend to
inject bu.h |
07:11.05 |
*** join/#brlcad mpictor
(~mark@c-68-58-38-45.hsd1.in.comcast.net) |
07:51.16 |
*** join/#brlcad ries
(~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
07:54.26 |
*** join/#brlcad teepee-
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
09:37.51 |
*** join/#brlcad clock
(~clock@77-58-143-135.dclient.hispeed.ch) |
09:41.05 |
*** join/#brlcad teepee-
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
10:01.34 |
*** join/#brlcad clock
(~clock@77-58-143-135.dclient.hispeed.ch) |
10:42.10 |
starseeker |
brlcad: on Windows, gl.h needs some other
stuff defined |
10:42.34 |
starseeker |
or rather, dm_xvars.h does |
10:43.50 |
starseeker |
no, sorry that one was GL/gl.h |
10:44.03 |
starseeker |
is looking at
diff |
10:48.19 |
starseeker |
huh |
10:48.30 |
starseeker |
moves the header and tries
again... |
10:52.01 |
Notify |
03BRL-CAD:starseeker * 63010
brlcad/trunk/src/adrt/isst_tcltk.c: try moving gl.h back with the
rest of the system headers - it should be there. |
10:58.18 |
starseeker |
I swear, sometimes these compiles feel like
quantum computing... |
11:00.05 |
``Erik |
iirc, gl.h on windows needed something weird
like windows.h included before |
11:03.32 |
starseeker |
that's my recollection as well - but now it
seems to be building with r63010 |
11:03.42 |
starseeker |
will have to try another
clean build tonight |
11:05.23 |
``Erik |
is common.h the first thing included? I'd
think that might cover the windows required header issue |
11:05.59 |
starseeker |
it is, but it doesn't include
windows.h |
11:23.24 |
starseeker |
reflects that if we *really*
want to increase our build speed we'll have to port a lot of C++ to
C... |
11:26.49 |
starseeker |
``Erik: feel like a project? C versions of
openNURBS and stepcode would be just the ticket :-P |
11:51.11 |
*** join/#brlcad teepee
(~teepee@gateway/tor-sasl/teepee) |
12:16.14 |
*** join/#brlcad yiyus
(1242712427@je.je.je) |
12:34.47 |
*** join/#brlcad teepee-
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
12:53.08 |
*** join/#brlcad teepee-
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
12:55.11 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
13:27.31 |
*** join/#brlcad teepee-
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
14:08.57 |
*** join/#brlcad teepee-
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
14:19.30 |
Notify |
03BRL-CAD:starseeker * 63011
(brlcad/trunk/CMakeLists.txt
brlcad/trunk/src/other/CMakeLists.txt): Merge gct into main branch
- doesn't look like working with this code will be disruptive
enough to warrant keeping in its own branch. |
14:20.38 |
Notify |
03BRL-CAD:starseeker * 63012 NIL: remove gct
branch |
14:21.35 |
Notify |
03BRL-CAD:starseeker * 63013
brlcad/trunk/misc/svn2git/archive_branches.sh: Add gct to git
archive list |
14:40.57 |
Notify |
03BRL-CAD:starseeker * 63014
brlcad/trunk/src/mged/fbserv.c: Fix bsd build of mged |
14:46.56 |
Notify |
03BRL-CAD:starseeker * 63015
brlcad/trunk/src/libdm/fontstash/fontstash.h: clear
warnings |
14:50.34 |
Notify |
03BRL-CAD:n_reed * 63016
brlcad/branches/brep-debug/src/libbrep/boolean.cpp: fix
leak |
14:56.18 |
Notify |
03BRL-CAD:starseeker * 63017
brlcad/trunk/CMakeLists.txt: whoops, OSG enablement slipped
in |
14:58.38 |
*** join/#brlcad clock
(~clock@77-58-143-135.dclient.hispeed.ch) |
15:13.51 |
brlcad |
oof, that's actually why the header was namged
bselect.h instead of bsocket.h |
15:16.01 |
brlcad |
sys/socket is both networking and
non-networking sockets whereas the select api is socket agnostic
(just works on descriptors) |
15:16.30 |
brlcad |
is a little
torn |
15:20.30 |
starseeker |
brlcad: can leave the explicit socket include
there - just wanted to check if it should be added or not |
15:20.38 |
Notify |
03BRL-CAD:brlcad * 63018
(brlcad/trunk/include/bnetwork.h brlcad/trunk/include/bsocket.h):
sys/socket is both networking and non-networking, which is part why
it wasn't originally included but now with 'network' being the
nomenclature, it does embiggen inclusion. it's consequently also
why bsocket was named bselect, to avoid having headers with
overlapping api (select.h is socket agnostic, sys/socket.h is far
more |
15:20.40 |
Notify |
general). go ahead an include in both for now
to see how things shake out but this probably either warrants
combining them or going back to the bselect distinction. |
15:27.22 |
brlcad |
starseeker: it's more about having headers
that fit expected intent implied by their name |
15:29.43 |
brlcad |
it's the difference between having a header
named myselect.h and mysocket.h ... I would certainly expect the
latter to provide sys/socket.h if I was told it's meant to be a
wrapper |
15:30.33 |
brlcad |
could argue that it already belonged in myin.h
vs mynetwork.h as socket.h is very much internet-centric (it just
does much more too) |
15:35.38 |
Notify |
03BRL-CAD:n_reed * 63019
brlcad/branches/brep-debug/src/libbrep/boolean.cpp: fix
leak |
15:36.40 |
Notify |
03BRL-CAD:starseeker * 63020
brlcad/trunk/regress/repository.sh: For in-src-dir build, don't do
bio.h test on obj_rules.cpp - it incorporates the perplex scanner
template, which we don't want to tie to BRL-CAD's specialized
headers. |
15:44.06 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
15:44.42 |
Notify |
03BRL-CAD:starseeker * 63021
(brlcad/trunk/CMakeLists.txt brlcad/trunk/misc/CMakeLists.txt and 2
others): Merge in the OpenCL work from opencl branch, using the
BRLCAD_ENABLE_OPENCL flag to turn it on/off. Need to actually try
this and make sure it still runs. |
15:47.00 |
Notify |
03BRL-CAD:starseeker * 63022 NIL: Delete
opencl branch - work merged into trunk, can be enabled with
BRLCAD_ENABLE_OPENCL |
15:47.57 |
*** join/#brlcad bhattigurjot
(~scott@117.214.202.39) |
15:48.19 |
Notify |
03BRL-CAD:starseeker * 63023
brlcad/trunk/misc/svn2git/archive_branches.sh: Add opencl to the
archived branches list |
16:00.41 |
bhattigurjot |
Hi, I compiled qtged branch on my system. I
have using Qt version 4.8.1 |
16:01.02 |
bhattigurjot |
should I compile against the latest
qt? |
16:01.05 |
bhattigurjot |
5+? |
16:01.20 |
brlcad |
bhattigurjot: did you run the tool
successfully? |
16:01.37 |
bhattigurjot |
brlcad: yes |
16:02.03 |
brlcad |
part of your goal should be to become familiar
with the current state of the tools, run mged and/or archer and use
the qt display manager (dm) and framebuffer (fb) |
16:02.51 |
brlcad |
are you yet familiar with mged? |
16:02.51 |
bhattigurjot |
okay |
16:03.30 |
bhattigurjot |
not extensively.. I guess I should go through
it thoroughly |
16:04.17 |
brlcad |
yeah, I suggest doing a couple of the
exercises (if not all of them) on the Intro to MGED here: http://brlcad.org/wiki/Documentation |
16:04.58 |
bhattigurjot |
alright |
16:05.09 |
brlcad |
there's about 16 lessons, you don't need to do
them all, but it's a good idea |
16:05.26 |
brlcad |
they take about 10-20 minutes each |
16:05.48 |
bhattigurjot |
yeah I did 1 or 2 few months back |
16:06.33 |
bhattigurjot |
I'll be doing them again |
16:06.35 |
brlcad |
okay, so maybe just a refresher |
16:06.46 |
bhattigurjot |
yeah |
16:06.48 |
brlcad |
a really quick way to test the Qt
interface: |
16:07.06 |
brlcad |
the "attach" command and the "rt"
command |
16:07.25 |
brlcad |
for example, start your qt mged: mged
test.g |
16:07.32 |
brlcad |
create a sphere: make sph sph |
16:08.12 |
brlcad |
if you run the rt command, it'll create a 2d
framebuffer window: rt |
16:08.55 |
brlcad |
if you run the attach command, it'll create
(another) 3d display manager window: attach qt |
16:09.02 |
Notify |
03BRL-CAD:starseeker * 63024
(brlcad/branches/qtged/CHANGES brlcad/branches/qtged/CMakeLists.txt
and 1088 others): Sync qtged with trunk up to r63023. |
16:09.46 |
brlcad |
you can create different types of framebuffer
and display manager windows by specifying other types, for
example: |
16:09.50 |
brlcad |
rt -F/dev/X |
16:09.53 |
brlcad |
rt -F/dev/ogl |
16:09.57 |
brlcad |
attach X |
16:09.59 |
brlcad |
attach ogl |
16:10.00 |
brlcad |
etc |
16:10.30 |
brlcad |
compare them, get comfortable with using
them |
16:11.02 |
brlcad |
then yes, the next useful step is probably to
upgrade to qt 5 and make sure everything is still working at least
as well as it is now |
16:11.03 |
bhattigurjot |
ok |
16:11.29 |
starseeker |
bhattigurjot: er, you might want to try
updating qtged branch again - I just did a big sync with trunk
:-/ |
16:11.35 |
brlcad |
if you see any differences between creating an
X, ogl, and qt display manager or framebuffer, that would also be a
perfect place to get working |
16:12.13 |
bhattigurjot |
starseeker: ok |
16:12.23 |
brlcad |
yeah, make sure the HEAD sources are still
working :) notice commit r63024 |
16:13.08 |
bhattigurjot |
okay |
16:13.17 |
starseeker |
sorry, didn't realize that sync was landing
right in the middle of someone working with the branch |
16:13.55 |
starseeker |
would have needed to be done at some point,
but I wasn't trying to make life harder on purpose ;-) |
16:13.55 |
brlcad |
i thought that's why you did it ;) |
16:14.04 |
starseeker |
heh |
16:14.33 |
starseeker |
is thoroughly in clean-up
mode... might as well ride the momentum while it
lasts |
16:15.29 |
starseeker |
brlcad: do you know if the work in
attr-extension-mods was merged? |
16:16.14 |
starseeker |
spose I should ask Tom... |
16:17.11 |
starseeker |
need to warn him he needs to sync his
d-bindings branch soon anyway if he wants to keep it
compatible |
16:19.39 |
*** join/#brlcad kamal__
(~kamal@14.98.39.73) |
16:21.38 |
brlcad |
it most definitely was not (and probably
should not, lots of changes that need careful reviewing) |
16:23.25 |
brlcad |
i've got a nice isolated compile-test going on
right now to check the header impact |
16:23.32 |
starseeker |
nods |
16:24.37 |
starseeker |
I'll leave attr-extension-mods alone
then |
16:25.14 |
brlcad |
in theory, should get the benefit per lib
additive, so it should be a good general measure of how it will
shake out ... just working on getting stable numbers now without
other influences (src/other, c++, etc) |
16:26.31 |
brlcad |
basically doing a full build, then running
this: for i in lib* fb gtools mged nirt rt sig util ; do echo $i ;
cd $i && make clean && make .. ; done &&
time make |
16:26.54 |
brlcad |
then running the script I pasted last night,
rebuilding full, and re-running the above |
16:27.11 |
brlcad |
should give a reasonable picture |
16:27.44 |
brlcad |
oops |
16:28.02 |
brlcad |
for i in lib* fb gtools mged nirt rt sig util
; do echo $i ; cd $i && make clean && cd .. ; done
&& time make |
16:29.07 |
starseeker |
nods - should tell the
story |
16:29.46 |
starseeker |
why the make .. after make clean? |
16:33.52 |
brlcad |
that was the oops... |
16:34.18 |
starseeker |
ah :-) |
16:34.20 |
starseeker |
sorry |
16:35.17 |
brlcad |
you try the script that converts all the bu's
back to a single bu.h? |
16:35.39 |
brlcad |
that was fun, took about 15 minutes |
16:39.55 |
starseeker |
brlcad: did try it on my home machine - was
pretty quick there for some reason (suspiciously so) |
16:40.48 |
starseeker |
build seemed slightly faster, but I didn't do
a proper isolated test so hard to say |
16:41.00 |
brlcad |
shouldn't be faster :) |
16:41.00 |
starseeker |
will give it the full
treatment tonight |
16:41.17 |
starseeker |
no, I mean the breakout of bu includes was
slightly faster |
16:41.27 |
brlcad |
ahh, right |
16:41.31 |
starseeker |
sorry, mean one thing and saying
another |
16:42.01 |
starseeker |
is trying to make sure
everything builds everywhere at the moment... |
16:42.16 |
brlcad |
I think i'm going to do one more run with just
the libs too as I suspect app linking is still going to
dominate |
16:42.32 |
brlcad |
yay for distcheck-full |
16:42.35 |
starseeker |
heh |
16:42.51 |
starseeker |
the handy "melt your computer in three easy
steps" tool |
16:43.37 |
starseeker |
probably is a decent stress test for operating
systems in a lot of ways |
16:43.42 |
Notify |
03BRL-CAD:n_reed * 63025
brlcad/branches/brep-debug/src/libbrep/boolean.cpp: fix
leak |
16:43.44 |
brlcad |
we seriously need to get buildbot going so
this all just happens |
16:43.51 |
starseeker |
agrees |
16:44.08 |
bhattigurjot |
Is it negligence on my part that I am not able
to run "attach qt"? It says there are only two types valid: X and
ogl |
16:44.21 |
starseeker |
what's needed? is the existing buildbot setup
working and someone needs to just write the proper
config? |
16:44.28 |
brlcad |
bhattigurjot: that means you probably did not
compile against qt |
16:44.34 |
brlcad |
check your cmake log |
16:44.34 |
starseeker |
bhattigurjot: um. Did your build detect
system Qt? |
16:44.53 |
starseeker |
cmake configure, not build |
16:47.48 |
starseeker |
brlcad: now that I think about it, does it
make sense to maintain distcheck-full vs. distcheck? I know I
wouldn't be happy with a release that didn't satisfy
distcheck-full... |
16:50.07 |
brlcad |
yeah, I think so .. I find myself using both
regularly |
16:50.16 |
brlcad |
quick check here, full check there,
etc |
16:50.41 |
starseeker |
ok, cool |
16:50.44 |
brlcad |
and distcheck is ever so slightly easier to
debug |
16:51.02 |
starseeker |
as long as someone is using the basic
distcheck :-) |
16:51.15 |
starseeker |
just blasts all of them
typically... |
16:51.16 |
Notify |
03BRL-CAD:starseeker * 63026
(brlcad/branches/gecode/src/other/CMakeLists.txt
brlcad/branches/gecode/src/other/gecode/CMakeLists.txt and 32
others): Update gecode to version 4.3.0 |
16:51.22 |
brlcad |
don't have to read down a convoluted make
-j100 log to find which one *actually* failed, find the dir, hunt
down the problem, ... |
16:52.23 |
starseeker |
raises eyebrow - if a
sub-component of distcheck-full fails, I just look at the .log file
for the build error. Can even cd into the distcheck-whatever subdir
and work directly on the problem there |
16:53.01 |
starseeker |
if any of the tests complete, the directory
associated with that test is gone and it's just the log
file |
16:54.14 |
brlcad |
yeah, but which log file? |
16:54.20 |
brlcad |
that's my point |
16:54.28 |
starseeker |
the one associated with the test that left a
directory behind |
16:54.42 |
starseeker |
if all of them left a directory behind, most
any will do - it's a common problem then |
16:54.56 |
brlcad |
eh? they're all still there usually |
16:55.09 |
brlcad |
but only one or two got to the point of
failure |
16:55.28 |
starseeker |
really? I often get situations where the
debugs will complete but the release don't, or tk or in-src-dir
fail while all the rest succeed |
16:55.49 |
starseeker |
in that situation (no-tk, for example) only
the no-tk directory should be left |
16:56.08 |
brlcad |
usually all the dirs are there for
me |
16:56.15 |
brlcad |
but not all fail |
16:56.23 |
starseeker |
O.o |
16:56.35 |
starseeker |
that's not good... |
16:57.00 |
brlcad |
anyways, the whole point is having to hunt and
peck (i.e., randomly pick one) is not my debugging style either ...
I want to see an error and trace it |
16:57.16 |
starseeker |
nods |
16:57.25 |
brlcad |
so I have to read the intermixed log output,
which is a pita |
16:57.39 |
brlcad |
so distcheck wins if all I want is quick
validation |
16:57.54 |
starseeker |
right |
16:57.56 |
brlcad |
which is probably 75% of the time unless it's
time to release |
16:58.00 |
brlcad |
then it flips |
16:58.37 |
starseeker |
you'll have to show me if you get that case
where only a few of the builds failed but extra directories got
left behind - that's not supposed to happen |
16:58.57 |
Stragus |
Erik, it's terrible, the Elfga comics page is
down! :) |
17:26.50 |
*** join/#brlcad Notify
(~notify@66-118-151-70.static.sagonet.net) |
17:26.52 |
Notify |
03BRL-CAD:n_reed * 63027
(brlcad/branches/brep-debug/CHANGES
brlcad/branches/brep-debug/CMakeLists.txt and 842 others): sync
from trunk through r63026 |
17:39.01 |
*** join/#brlcad Notify
(~notify@66-118-151-70.static.sagonet.net) |
17:39.02 |
Notify |
03BRL-CAD:n_reed * 63027
(brlcad/branches/brep-debug/CHANGES
brlcad/branches/brep-debug/CMakeLists.txt and 842 others): sync
from trunk through r63026 |
17:39.10 |
Notify |
03BRL-CAD:n_reed * 63028
(brlcad/trunk/src/libbrep/intersect.cpp Property Changed: and 3
others): merge changes from brep-debug r61544; fixes bugs in brep
intersection |
17:40.50 |
Notify |
03BRL-CAD:n_reed * 63029
(brlcad/trunk/src/libbrep/boolean.cpp Property Changed: and 3
others): merge changes from brep-debug r62107; we shouldn't discard
ssx curve intervals that lie on face boundaries |
17:40.55 |
``Erik |
heh, it's up now |
17:55.48 |
Notify |
03BRL-CAD:n_reed * 63030
(brlcad/trunk/src/libbrep/boolean.cpp
brlcad/trunk/src/libbrep/intersect.cpp and 4 others): merge changes
from brep-debug r62117, r62521; rename vars, quell
warning |
18:09.44 |
Notify |
03BRL-CAD:n_reed * 63031
(brlcad/trunk/src/libbrep/boolean.cpp Property Changed: and 3
others): merge changes from brep-debug r62416-r62519, r62522-62584;
initial reworking of split_trimmed_face to perform boolean
combinations of closed curves for trimmed face construction that's
more robust and easier to debug |
18:15.21 |
*** join/#brlcad clock
(~clock@77-58-143-135.dclient.hispeed.ch) |
18:15.33 |
bhattigurjot |
While compiling qtged branch against Qt, i'm
getting the error regarding header file inclusion for bio.h to come
after bsocket.h which is kinda surprising since bio.h is included
after bsocket.h in include/fb.h |
18:15.56 |
bhattigurjot |
<PROTECTED> |
18:17.42 |
Notify |
03BRL-CAD:carlmoore * 63032
brlcad/trunk/doc/docbook/system/man1/en/rt.xml: rewrite parts of
rt |
18:18.49 |
Notify |
03BRL-CAD:carlmoore * 63033
(brlcad/trunk/src/conv/asc/asc2g.c
brlcad/trunk/src/libdm/osg-test.cpp): remove trailing blanks/tabs;
fix spelling |
18:19.49 |
Notify |
03BRL-CAD:n_reed * 63034
(brlcad/trunk/src/libbrep/boolean.cpp
brlcad/trunk/src/libbrep/intersect.cpp): merge changes from
brep-debug r62593-r62614; fix unhandled cases in the sub_curve
routine and have it throw exceptions so callers can't ignore a NULL
result |
18:33.11 |
Notify |
03BRL-CAD:n_reed * 63035
(brlcad/trunk/src/libbrep/boolean.cpp Property Changed: and 3
others): merge changes from brep-debug r62623, r62660, r62674; more
work on split_trimmed_face implementation |
18:39.24 |
bhattigurjot |
This is the complete cmake command I'm
using: |
18:39.25 |
bhattigurjot |
"cmake ../brlcad-qtged
-DBRLCAD_ENABLE_STRICT=NO -DBRLCAD_BUNDLED_LIBS=ON
-DBRLCAD_ENABLE_QT=ON -DCMAKE_BUILD_TYPE=Debug" |
18:40.08 |
bhattigurjot |
I saw in the CMakeLists.txt file, that Qt5 is
required. |
18:40.17 |
Notify |
03BRL-CAD:n_reed * 63036
(brlcad/trunk/src/libbrep/intersect.cpp Property Changed: and 3
others): merge changes from brep-debug r62681-r62771; fixes bugs in
brep intersection |
18:41.30 |
bhattigurjot |
Although I'm using Qt 4.8.1(checked using
qmake -v) but my system does have qt5 files |
18:43.30 |
Notify |
03BRL-CAD:starseeker * 63037
brlcad/trunk/src/libdm/CMakeLists.txt: add osg-test.cpp to ignore
list |
18:44.59 |
starseeker |
bhattigurjot: the bio.h thing is most likely a
consequence of recent header work |
18:45.53 |
bhattigurjot |
starseeker: ok.. so how do I resolve
this? |
18:46.01 |
starseeker |
what file is throwing the error? |
18:46.24 |
bhattigurjot |
bsocket.h |
18:46.51 |
starseeker |
OK - what file is the build trying to compile
when that error is generated? |
18:46.56 |
Notify |
03BRL-CAD:n_reed * 63038
(brlcad/trunk/src/libbrep/boolean.cpp Property Changed: and 3
others): merge changes from brep-debug r62876; make linking of
intersection curves from separate faces more robust |
18:46.58 |
starseeker |
bsocket.h is included by something
else |
18:47.14 |
bhattigurjot |
dm-qt.cpp |
18:47.45 |
starseeker |
OK - try just removing the bio.h include from
that file |
18:47.58 |
starseeker |
the other headers should take care of it, so
you shouldn't need it explicitly |
18:48.12 |
starseeker |
(should be line 28) |
18:48.18 |
bhattigurjot |
yeah |
18:50.35 |
bhattigurjot |
starseeker: compiling now.. but is this
"bio.h" required in dm-qt? |
18:51.21 |
starseeker |
it's most likely already included by other
headers - that's why you were getting the conflict |
18:51.58 |
bhattigurjot |
okay,, btw this branch is it compatible with
qt5? |
18:52.39 |
starseeker |
not sure - vlad was just starting work on
this, so I'm not sure what version(s) he was assuming |
18:53.14 |
bhattigurjot |
I guess my cmake configuration picked qt5
files.. |
18:53.23 |
starseeker |
IIRC, Qt5 is needed primarily because of the
need to embed Qt in Tk - we're trying to get away from that by
using Qt instead of Tk, so either ought to work |
18:53.48 |
bhattigurjot |
yes |
18:53.59 |
starseeker |
Qt5 is the new version, so that's
fine |
18:54.32 |
starseeker |
if Qt4 can be supported without too much work
we will, but if Qt5 ends up a requirement we can live with
that |
18:55.07 |
bhattigurjot |
alright |
18:56.15 |
Notify |
03BRL-CAD:starseeker * 63039
brlcad/trunk/src/libdm/dm-qt.cpp: handled by other
headers... |
18:57.53 |
Notify |
03BRL-CAD:n_reed * 63040
(brlcad/trunk/src/libbrep/boolean.cpp Property Changed: and 3
others): merge changes from brep-debug r62901, r62907, r62910,
r62925, r62931-r63025; more work on split_trimmed_face
implementation |
19:02.45 |
bhattigurjot |
starseeker: on running "attach qt" I am
getting two windows.. one titled 'dm_qt0' it is blank.. and the
other one titled '(Unknown)' that shows the sphere I
created |
19:03.10 |
bhattigurjot |
I guess it is not being embedded |
19:03.27 |
starseeker |
bhattigurjot: that's were vlad left off, IIRC
- he had turned off the embedding of the Qt dm as a first step
towards replacing the Tk window with a Qt window |
19:04.02 |
*** join/#brlcad n_reed_
(~molto_cre@66-118-151-70.static.sagonet.net) |
19:04.12 |
bhattigurjot |
ok |
19:04.35 |
starseeker |
so the things to do are 1) understand how the
attach mechanism is working to create a Tk window and embed the dm,
and how to do that with a Qt window |
19:05.05 |
starseeker |
2) figure out how key bindings are set up for
the Tk dm window and translate those binding to the Qt mechanism
for key bindings |
19:05.19 |
starseeker |
3) same thing for mouse bindings |
19:06.23 |
starseeker |
you want to get to the point where "attach qt"
in the branch gives you the same functionality as "attach X" in
trunk |
19:06.49 |
bhattigurjot |
okay |
19:07.39 |
bhattigurjot |
correct me if I am wrong.. what I have
understood so far is that tcl script is being run to create a tk
widget when we run "mged" |
19:08.02 |
bhattigurjot |
which I can see in mged.c |
19:08.07 |
starseeker |
in "gui" mode I believe that's
correct |
19:08.21 |
starseeker |
"classic" mode - which is what this work is
looking at - may be doing something more basic |
19:09.22 |
starseeker |
but the 'attach' command is a tcl command that
will trigger other calls, since the MGED command prompt is a Tcl
prompt (currently, anyway) |
19:10.35 |
starseeker |
I would send an email to the dev list and see
if you can talk with vlad to find out what his design approach
is |
19:11.06 |
bhattigurjot |
ok |
19:11.22 |
bhattigurjot |
I'll post on devel list |
19:21.19 |
bhattigurjot |
starseeker: from the points you listed above,
for the 1st one, where should I begin looking into the
code? |
19:21.37 |
bhattigurjot |
for the "attach" one |
19:35.25 |
bhattigurjot |
ok.. attach.c it is! |
19:43.46 |
Notify |
03BRL-CAD:starseeker * 63041
brlcad/trunk/src/libbrep/CMakeLists.txt: Add brep_except.h to
ignore list |
19:43.53 |
brlcad |
there's no point in worrying about qt4 .. by
the time we're done with an alpha, qt6 will probably be
out |
19:43.57 |
brlcad |
they're already on 5.3 |
19:44.16 |
brlcad |
we should target the latest only
imho |
19:44.56 |
starseeker |
nods - works for me. I was
figuring that if we stick to the C api (as opposed to using qml)
then 4.8 might "just work" for a basic interface |
19:45.32 |
starseeker |
but the momentum is shifting to Qt5 now (KDE
is either on it or close to it, IIRC) |
19:53.00 |
Notify |
03BRL-CAD:n_reed * 63042
brlcad/trunk/src/libbrep/boolean.cpp: partial merge of changes from
brep-debug r61367; don't forget the surface-surface overlap
intersections; brep command now produces good output for all combs
in librt/tests/brep_boolean_test.g that have non-empty
results |
20:00.38 |
Notify |
03BRL-CAD:starseeker * 63043
brlcad/trunk/src/libbrep/CMakeLists.txt: Add the surfacetree test
code using queues as a patch for documentation purposes - needs to
be rethought in light of subsequent work. |
20:02.21 |
Notify |
03BRL-CAD:starseeker * 63044 NIL: saved work
added here as a patch in trunk - this branch is no longer
needed |
20:03.13 |
Notify |
03BRL-CAD:starseeker * 63045
brlcad/trunk/misc/svn2git/archive_branches.sh: Add surfacetree to
archived branches |
20:15.18 |
Notify |
03BRL-CAD:starseeker * 63046
(brlcad/branches/qtged/doc/docbook/system/man1/en/rt.xml
brlcad/branches/qtged/misc/svn2git/archive_branches.sh and 7
others): Update qtged to trunk r63045 |
20:35.02 |
*** join/#brlcad clock
(~clock@77-58-143-135.dclient.hispeed.ch) |
22:40.28 |
Notify |
03BRL-CAD:carlmoore * 63047
brlcad/trunk/doc/docbook/system/man1/en/rt.xml: Add 'This is'
remark involving -J |
22:59.01 |
Notify |
03BRL-CAD Wiki:Ernesto1955 * 0
/wiki/User:Ernesto1955: |