01:58.39 |
*** join/#brlcad cdk_
(~cdk@d173-238-127-19.home4.cgocable.net) |
02:03.55 |
*** join/#brlcad PrezKennedy
(~DarkCalf@173.231.40.99) |
02:06.24 |
*** join/#brlcad PrezKennedyX
(~DarkCalf@173.231.40.99) |
02:06.33 |
*** join/#brlcad n_reed_
(~molto_cre@BZ.BZFLAG.BZ) |
02:28.08 |
*** join/#brlcad cdk__
(~cdk@d173-238-127-19.home4.cgocable.net) |
02:38.15 |
starseeker |
sweet - ogre 1.8 was easier to build and run
(demo) than any previous release |
02:42.22 |
*** join/#brlcad cdk_
(~cdk@d173-238-127-19.home4.cgocable.net) |
02:46.16 |
starseeker |
cmake build of (enough of) freetype
too |
02:46.22 |
starseeker |
at least, enough for ogre |
02:49.17 |
starseeker |
yay ogredeps |
02:55.42 |
*** join/#brlcad crdueck
(~cdk@d173-238-127-19.home4.cgocable.net) |
03:47.42 |
CIA-23 |
BRL-CAD: 03brlcad * r51647
10/brlcad/trunk/misc/CMake/test_srcs/builddelta_end.c.in: ugh,
global variables suck. pita to find where the periods were coming
from. pass the 'lines' unadulterated so as not to get mixed up with
the install path |
03:51.25 |
CIA-23 |
BRL-CAD: 03brlcad * r51648
10/brlcad/trunk/misc/CMake/test_srcs/builddelta_end.c.in:
cleanup |
03:52.35 |
brlcad |
ccmake is not respecting my
CMAKE_INSTALL_PREFIX setting, keeps resetting it to a
/usr/brlcad/dev-... path |
03:56.59 |
brlcad |
maybe some conflict with BRLCAD_PREFIX (going
to advanced showed it also set to dev-) but setting both to still
didn't retain my path |
04:07.51 |
CIA-23 |
BRL-CAD: 03n_reed * r51649
10/brlcad/trunk/src/conv/step/ (MassUnit.cpp STEPWrapper.h): need a
more specific macro name to avoid a conflict |
04:14.38 |
CIA-23 |
BRL-CAD: 03n_reed * r51651
10/brlcad/trunk/src/other/step/src/base/scl_memmgr.h: remove
exception specifications |
04:31.17 |
CIA-23 |
BRL-CAD: 03brlcad * r51652
10/brlcad/trunk/CMakeLists.txt: |
04:31.17 |
CIA-23 |
BRL-CAD: given the preceeding logic, the only
way for there to be a mismatch is if the |
04:31.17 |
CIA-23 |
BRL-CAD: user specifically requested a
different path. moreover, the build type will |
04:31.17 |
CIA-23 |
BRL-CAD: default to Debug without any user
action making the claim doubly wrong. |
04:31.17 |
CIA-23 |
BRL-CAD: silently 'fixing' user-specified
input is also just bad practice... |
05:16.47 |
CIA-23 |
BRL-CAD: 03Phoenix 07http://brlcad.org * r4221
10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 9 */ |
05:18.46 |
CIA-23 |
BRL-CAD: 03Phoenix 07http://brlcad.org * r4222
10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 10 */ |
05:58.37 |
*** join/#brlcad andrei_
(~andrei@188.25.161.102) |
06:26.36 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
06:46.30 |
*** join/#brlcad elf11
(~elf11@p5.eregie.pub.ro) |
08:41.13 |
CIA-23 |
BRL-CAD: 03Phoenix 07http://brlcad.org * r4223
10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 10 */ |
08:43.18 |
*** join/#brlcad stas
(~stas@82.208.133.12) |
08:43.55 |
CIA-23 |
BRL-CAD: 03phoenixyjll * r51653
10/brlcad/trunk/src/librt/opennurbs_ext.cpp: Calculate the
coordinates of the intersection points in UV parameter
spaces. |
11:51.02 |
starseeker |
brlcad: what were you setting the path to?
The only deliberate override was to make sure a dev build didn't
end up in a rel directory or vice versa - that was quite
deliberate |
11:51.51 |
starseeker |
it's one of the things the build type was
intended to dictate |
11:55.00 |
starseeker |
at the very least, it should squawk very
loudly - setting a rev install directory on a dev build or vice
versa is a violation of convention and user expectation |
11:55.16 |
starseeker |
s/rev/rel |
13:23.14 |
CIA-23 |
BRL-CAD: 03starseeker * r51654
10/brlcad/trunk/CMakeLists.txt: Restore build type vs. installation
directory check, but just print a warning instead of
overriding. |
13:25.15 |
*** join/#brlcad xth1
(~thiago@187.80.143.8) |
13:32.41 |
CIA-23 |
BRL-CAD: 03starseeker * r51655
10/brlcad/trunk/src/other/step/src/base/scl_memmgr.h: revert 51651
- breaks build on Linux |
14:05.57 |
CIA-23 |
BRL-CAD: 03Ksuzee 07http://brlcad.org * r4224
10/wiki/User:Ksuzee/Reports: |
14:05.58 |
``Erik |
(and fbsd, and osX, and ...) |
14:10.38 |
*** join/#brlcad reuben
(~reuben@93-97-69-251.zone5.bethere.co.uk) |
15:12.14 |
*** join/#brlcad starseek1r
(~starseeke@BZ.BZFLAG.BZ) |
16:10.25 |
CIA-23 |
BRL-CAD: 03r_weiss * r51656
10/brlcad/trunk/src/conv/g-acad.c: Update to file "g-acad.c" which
is the brlcad to acad (not AutoCAD) converter. Fixed a bug where a
union tree was being freed and it should not have been. This
corrects a segmentation fault in the converter. |
16:26.52 |
*** join/#brlcad Al_Da_Best
(Al_Da_Best@5e0e10f8.bb.sky.com) |
16:38.39 |
CIA-23 |
BRL-CAD: 03n_reed * r51657
10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp:
s/MAX/FMAX |
17:02.34 |
*** join/#brlcad crdueck
(~cdk@d173-238-127-19.home4.cgocable.net) |
17:02.34 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
17:52.02 |
*** join/#brlcad Mahi
(~Mahi@ec2-107-21-190-192.compute-1.amazonaws.com) |
17:54.42 |
*** join/#brlcad Mahi
(~Mahi@ec2-107-21-190-192.compute-1.amazonaws.com) |
19:02.13 |
*** join/#brlcad Mahi
(~Mahi@ec2-107-21-190-192.compute-1.amazonaws.com) |
19:03.09 |
*** join/#brlcad andrei_
(~andrei@188.25.161.102) |
19:03.12 |
andrei_ |
hello |
19:04.40 |
andrei_ |
brlcad, did you have time to use / have a look
at the data? |
19:30.08 |
*** join/#brlcad Mahi
(~Mahi@ec2-23-22-106-230.compute-1.amazonaws.com) |
19:36.56 |
*** join/#brlcad elf11
(~elf11@p5.eregie.pub.ro) |
19:52.20 |
CIA-23 |
BRL-CAD: 03starseeker * r51658
10/brlcad/trunk/misc/CMake/FindSTL.cmake: If we find we don't need
the stdc++ link line per FindSTL, don't do the search at all (it
reports not-found, which is incorrect) |
19:58.01 |
CIA-23 |
BRL-CAD: 03starseeker * r51659
10/brlcad/trunk/ (4 files in 2 dirs): |
19:58.02 |
CIA-23 |
BRL-CAD: Try to get things working without an
explicit build type being set - i.e. don't |
19:58.02 |
CIA-23 |
BRL-CAD: force the user to use a build type so
manually specifying everything for release |
19:58.02 |
CIA-23 |
BRL-CAD: builds works without CMake barking
about conflicts due to the build type being |
19:58.02 |
CIA-23 |
BRL-CAD: automatically set to debug. |
20:09.24 |
*** join/#brlcad cristina
(~quassel@188.24.50.251) |
20:15.11 |
cristina |
brlcad: Hello. I wanted to pop up a new window
when running the command "graph" in MGED. |
20:15.19 |
cristina |
So, I created a new folder:
src/tclscripts/graph, added the CMakeLists.txt, Makefile.am,
graph.tcl, pkgIndex.tcl, tclIndex files. |
20:15.24 |
cristina |
<PROTECTED> |
20:15.53 |
cristina |
the command calls my ged_graph() routine and
runs it but the window doesn't show up |
20:16.17 |
starseeker |
cristina: does the command report
anything? |
20:16.51 |
cristina |
well, it runs my routine and prints out what I
set to be printed |
20:16.59 |
cristina |
besides this, no, starseeker |
20:19.21 |
cristina |
the source code for the window is the same as
the one for the "geometree" command, just that the package has some
other name (instead of geometree's GeometryBrowser) |
20:22.12 |
*** join/#brlcad xth1
(~thiago@177.120.220.121) |
20:28.47 |
starseeker |
hmm... cristina, if it doesn't break the build
you can go ahead and commit - it will be a lot easier to
tell |
20:31.27 |
cristina |
starseeker: I will, but the code in my package
is so far a duplication of the one in the geometree folder. I
wanted to use it to check if my configurations work were correctly
set |
20:35.12 |
starseeker |
hmm - setup.c doesn't have an entry for
geometree |
20:36.35 |
starseeker |
what's in your pkgIndex.tcl file? |
20:36.56 |
cristina |
oh, well in setup.c I used the "bot" command
as an example |
20:37.20 |
starseeker |
most of the ged commands (all?) don't involve
graphical Tcl/Tk elements |
20:37.40 |
cristina |
in my pkgIndex.tcl file the is the usual
comment at the beginning of the file and : package ifneeded
DisplayGraph 1.0 [list source [file join $dir
DisplayGraph.tcl]] |
20:38.06 |
cristina |
where DisplayGraph has geometree's
GeometryBrowser source code |
20:38.26 |
starseeker |
if you source DisplayGraph.tcl on the MGED
command line, what happens? |
20:38.43 |
starseeker |
or "package require DisplayGraph" might
work |
20:39.24 |
cristina |
it prints an error saying that the package
cannot be found |
20:39.34 |
starseeker |
ok - what about sourcing? |
20:40.27 |
cristina |
another error saying that it can't read the
DisplayGraph.tcl file because there's no such file or
directory |
20:40.55 |
starseeker |
cristina: try specifying the full path name,
e.g. source /home/me/file/path/DisplayGraph.tcl |
20:41.54 |
cristina |
ok, there is no error with full path |
20:42.18 |
starseeker |
ok. Now, how would you launch a window (tcl
logic) |
20:42.39 |
starseeker |
do you have a DisplayGraph command? |
20:44.25 |
cristina |
well, no, my command is called
"graph" |
20:45.37 |
*** part/#brlcad xth1
(~thiago@177.120.220.121) |
20:46.04 |
cristina |
but I have this statement in my graph.tcl
file: if [ catch {DisplayGraph $gt } gbName ] {//...} |
20:50.48 |
starseeker |
what is fed in in the gt variable? |
20:51.30 |
starseeker |
you should be able to try DisplayGraph on the
command line, if you can provide the right input |
20:52.45 |
starseeker |
is ged_graph something that you want to call
from within DisplayGraph.tcl? |
20:53.09 |
cristina |
gt is set within this line: set gt
.$_mgedFramebufferId.graph |
20:53.26 |
starseeker |
usually, the way C/Tcl integration works is
the C function is exposed via a tcl command, which is then
incorporated into the Tcl logic |
20:53.38 |
starseeker |
what's in the graph? |
20:53.53 |
starseeker |
or is that the window name? |
20:55.05 |
starseeker |
if it's a window name, try DisplayGraph
.$_mgedFramebufferId.graph |
20:57.29 |
cristina |
It can't read the variable
_mgedFramebufferId |
20:57.45 |
starseeker |
just try DisplayGraph .window1 |
20:58.13 |
cristina |
<PROTECTED> |
20:59.07 |
cristina |
of course, with the content of a Geometry
Browser window since it implements the same thing |
20:59.12 |
starseeker |
right |
21:00.45 |
starseeker |
remember, too, that having the source files
present in the source tree isn't enough to get things working -
minimally, you need to have the right links present in the build
tree (a cmake configure and make should take care of
that) |
21:02.27 |
cristina |
ok, I will rerun the cmake and make commands.
Still, I've done this before trying to pop out the
window. |
21:03.35 |
starseeker |
brlcad may more insight into this
process... |
21:04.13 |
starseeker |
s/may/may have |
21:05.15 |
cristina |
ok, thank you for your help starseeker, at
least I know now that the window can pop up |
21:12.03 |
cristina |
okay, I've made a stupid mistake, I didn't
save the change made to the CMakeLists.txt file when adding the
DisplayGraph.tcl to the graph_TCLSCRIPTS so it didn't take it in
account. This should solve the problem |
21:28.14 |
*** join/#brlcad Mahi
(~Mahi@ec2-23-22-106-230.compute-1.amazonaws.com) |
21:31.16 |
CIA-23 |
BRL-CAD: 03crdueck * r51660
10/brlcad/trunk/src/libged/analyze.c: code clean up |
22:59.56 |
*** join/#brlcad louipc
(~louipc@archlinux/fellow/louipc) |
23:05.18 |
CIA-23 |
BRL-CAD: 03Cprecup 07http://brlcad.org * r4225
10/wiki/User:Cprecup/GSoC2012_progress: 24/06/2012 - still having
issues with commands used for tcl |
23:45.23 |
CIA-23 |
BRL-CAD: 03starseeker * r51661
10/brlcad/trunk/src/librt/test_botpatches.cpp: Start setting up a
test for edge triangle overlaps in the projection of patches. Quite
a bit more to do here. |