| 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. |