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