| 00:04.54 | brlcad | kunigami: it's because some files are listed in your ~/.subversion/config global-ignores directive, files that are "usually" auto-generated |
| 00:05.25 | brlcad | Makefile.in files being a byproduct of automake, though some projects choose to be autoconf-only and use Makefile.in |
| 00:05.53 | brlcad | remove the directive and should resolve itself |
| 00:06.34 | kunigami | that's strange, my global-ignores only includes .o, .lo and .la |
| 00:27.45 | starseeker | brlcad: we've got something odd going on with bu_ipwd |
| 00:27.58 | starseeker | I'm trying to run archer from build directory, and it's not finding the plugins |
| 00:28.31 | starseeker | the problem traces to how plugins are loaded - the current working directory is changed to being fairly deep in the share structure |
| 00:28.43 | starseeker | when there, bu_brlcad_data no longer gives useful results |
| 00:29.38 | starseeker | brlcad: try running bwish from share/brlcad/7.20.3/plugins/archer/Utility |
| 00:30.05 | starseeker | e.g ../../../../../../bin/bwish |
| 00:30.11 | starseeker | then try bu_brlcad_data "" |
| 00:32.30 | dli | starseeker, is there any known issue with building brlcad against libpng-1.5? |
| 00:36.19 | starseeker | dli: trunk can (we actually just upgraded to 1.5) |
| 00:36.44 | dli | starseeker, thanks a lot! just got a bug report from gentoo |
| 00:41.29 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 00:49.44 | CIA-62 | BRL-CAD: 03kunigami * r45835 10/osl/trunk/openexr/ (396 files in 67 dirs): adding latest version of openexr (v1.6.1) |
| 01:38.53 | kunigami | openexr requires zlib, which is packed with brlcad. but openexr uses autotools to build. should I modify it to automatically find the brlcad version or may I assume that the user will take care of this dependence? |
| 01:48.05 | brlcad | kunigami: that is pretty odd then .. it's in my config (but then I added it) |
| 01:49.18 | brlcad | as for zlib, is there already a configure option for --with-zlib=/path/to/zlib or somesuch? otherwise the top-level build file can take care of passing it in the build flags |
| 01:49.42 | kunigami | brlcad: hmm, let me check |
| 01:52.54 | kunigami | there's no such option. so the idea is that one top-level file builds all osl dependencies? |
| 01:58.16 | brlcad | yeah, something very simple to assist builds on linux/bsd/mac |
| 01:59.12 | kunigami | hm, ok |
| 01:59.16 | brlcad | either a makefile or a script, whatever is easiest |
| 02:00.54 | kunigami | I'd go for script. I'm not that fluent with makefiles |
| 02:01.49 | brlcad | starseeker: data path loading requires either a) that one of the libbu path functions is called prior to a directory change or b) that the resources are in their install location |
| 02:03.03 | brlcad | if both those are false, then there's no way for libbu to know what the initial working directory path was (other than a hard override) |
| 02:11.14 | CIA-62 | BRL-CAD: 03bhinesley * r45836 10/brlcad/trunk/src/libged/edit.c: |
| 02:11.15 | CIA-62 | BRL-CAD: Batch arguments were expanding, but only the first set was being executed. |
| 02:11.15 | CIA-62 | BRL-CAD: Fixing this meant writing a function to duplicate command argument groupings, |
| 02:11.15 | CIA-62 | BRL-CAD: which in turn required changing the subcommand functions for looping through |
| 02:11.15 | CIA-62 | BRL-CAD: args. The counters needed to be exposed as paramaters, and made non-static... |
| 02:11.15 | CIA-62 | BRL-CAD: which should have been done in the first place. Updated the half-dozen or so |
| 02:11.15 | CIA-62 | BRL-CAD: places that depended on the old logic. |
| 02:20.19 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 03:04.18 | CIA-62 | BRL-CAD: 03bhinesley * r45837 10/brlcad/trunk/src/libged/edit.c: off by one errors introduced r45836 |
| 03:09.53 | starseeker | brlcad: it can't key off the location of the bwish binary? |
| 04:00.49 | starseeker | hmm... may want to re-examine the mechanism being used for plugin loading |
| 04:02.14 | CIA-62 | BRL-CAD: 03bhinesley * r45838 10/brlcad/trunk/src/libged/edit.c: |
| 04:02.15 | CIA-62 | BRL-CAD: Simplified/removed some things in edit(), and resolved several unrelated issues, |
| 04:02.15 | CIA-62 | BRL-CAD: many of which were recently introduced. Translate isn't quite working yet. There |
| 04:02.15 | CIA-62 | BRL-CAD: seems to be a problem getting the apparent coordinates of objects, which I think |
| 04:02.15 | CIA-62 | BRL-CAD: might all be evaluating to (0,0,0). Also, there are several untested option/arg |
| 04:02.15 | CIA-62 | BRL-CAD: combinations. |
| 04:04.31 | starseeker | brlcad: if the "change to current working directory before doing things" approach is what's causing the break, I wonder if it might be workable to scrap that altogether |
| 04:07.30 | starseeker | or "change the current working directory" rather |
| 04:07.44 | starseeker | doesn't quite see why that's essential |
| 04:22.16 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3060 10/wiki/User:Bhinesley: /* Log */ today, plan |
| 04:22.46 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3061 10/wiki/User:Bhinesley: /* Log */ typo |
| 04:32.21 | brlcad | starseeker: why what is/isn't essential? |
| 04:32.42 | brlcad | archer needing to change the cwd sounds bad |
| 04:33.49 | brlcad | and even if it "needs to" for some odd reason, it should be getting the current dir (via libbu) first so the path can be restored |
| 04:41.28 | starseeker | Archer::pluginLoadCWDFiles |
| 04:42.09 | starseeker | will try to sort it out tomorrow |
| 05:06.05 | brlcad | yeah, without getting into the nitty gritty, there doesn't sound like there's any reason it needs to load files from "cwd" .. it needs to load files from a plugin dir, determined from bu_brlcad_data "path/to/plugin/dir" |
| 05:46.30 | *** join/#brlcad blindbox (~UPPnub@60.51.60.209) | |
| 06:32.52 | *** part/#brlcad blindbox (~UPPnub@60.51.60.209) | |
| 08:33.16 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:58.26 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 09:56.50 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:32.33 | abhi2011 | brlcad: I am working on a new function to be added to librt which will reside in librt/bbox.c |
| 13:32.57 | abhi2011 | the function looks like this : rt_bound_dbfullpath(const struct db_full_path *pp, struct rt_i *rtip, fastf_t *tree_min, fastf_t *tree_max) |
| 13:33.31 | abhi2011 | so it will take a db_full_path and return the bb for the combination or region in that path, otherwise return an error |
| 13:38.08 | abhi2011 | however for finding the bb a db_full_path is not needed, generall the databse would be opened using rt_dirbuild() which returns a struct rt_i and not struct db_i |
| 13:38.29 | abhi2011 | from that point onwards only rt_* functions would be involved |
| 13:39.59 | abhi2011 | so I am currently using db_path_to_string() to convert the struct db_full_path passed to rt_bound_dbfullpath(), to a string representation of the path |
| 13:42.04 | abhi2011 | I can use this string representation of a region/group to search the list of regions available in the struct rt_i * trip |
| 13:42.27 | abhi2011 | once the region is found then I can use rt_bound_tree() to get the bb |
| 13:43.11 | abhi2011 | so my point is that db_path_to_string() seems to be the only way to jump from using db_* functions to rt_* functions |
| 15:33.55 | brlcad | abhi2011: the function shouldn't take an rtip |
| 15:34.19 | brlcad | that's an implementation detail .. needs to be a simple form of "here's an object, get the bounding box" |
| 15:35.14 | brlcad | either using db_full_patths or rt_db_internal objects, not immediately clear to me which is better |
| 15:36.42 | brlcad | also, in general, the database won't necessarily be opened with rt_dirbuild() .. that's only for raytracing applications. they may simply call db_open() or db_open_inmem() or wdb_dbopen() or ... |
| 15:37.19 | brlcad | that's one of the points of creating this function, hiding the fact that we create a raytrace context so we can call prep so we can get the bounding boxes |
| 16:12.05 | CIA-62 | BRL-CAD: 03brlcad * r45839 10/brlcad/trunk/src/proc-db/csgbrep.cpp: eliminate the remainder of dynamic memory allocation now that it is no longer needed. greatly simplifies creating sketch objects procedurally. |
| 16:31.58 | CIA-62 | BRL-CAD: 03brlcad * r45840 10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: help prevent crashing if the data file cannot be found, validate before trying to use the mapped file. this should be using dsp_get_data() instead of replicating logic. |
| 16:53.07 | CIA-62 | BRL-CAD: 03brlcad * r45841 10/brlcad/trunk/TODO: sketch objects get copied deeply now |
| 16:55.38 | CIA-62 | BRL-CAD: 03brlcad * r45842 10/brlcad/trunk/TODO: most of the wdb routines now properly make a copy so wdb_export can free it. possibly a few stragglers remaining, but not nmg and sketch previously mentioned. |
| 16:57.12 | CIA-62 | BRL-CAD: 03brlcad * r45843 10/brlcad/trunk/src/proc-db/sketch.c: no more dynamic mem |
| 16:57.43 | abhi2011 | brlcad: ok I get it. |
| 16:57.52 | CIA-62 | BRL-CAD: 03brlcad * r45844 10/brlcad/trunk/src/proc-db/csgbrep.cpp: we already created a db_internal, don't call mk_sketch() directly. |
| 16:59.25 | abhi2011 | all the prep functions take an rtip as input however i.e. rt_prep(struct rt_i *rtip) & rt_prep_parallel() |
| 16:59.43 | brlcad | knows that :) |
| 16:59.51 | abhi2011 | I am guessing these are the only 2 ways to get the bb |
| 17:00.00 | brlcad | you need an rtip |
| 17:00.06 | brlcad | the function, however, does not |
| 17:00.06 | abhi2011 | hmm so I would need to convert the input to an rtip |
| 17:00.14 | brlcad | right |
| 17:01.19 | abhi2011 | rt_dirbuild() would open up the database and return a rtip, but we dont want the caller to pass the database name as well |
| 17:01.27 | abhi2011 | just an object |
| 17:01.30 | brlcad | right |
| 17:01.50 | brlcad | and they might not be a raytracing app, so all they have is a filename and/or a dbip |
| 17:02.20 | brlcad | you might get away with passing a (struct db_i *, struct rt_db_internal *, min, max) |
| 17:02.46 | brlcad | or db_i, name, min, max |
| 17:02.49 | abhi2011 | yes i am looking at rt_new_rti() which has db_i |
| 17:02.57 | abhi2011 | as input |
| 17:03.25 | abhi2011 | yah I am guessing the user will have at a minimum the db_i |
| 17:03.33 | abhi2011 | else they wont have a file open :P |
| 17:04.21 | brlcad | they won't necessarily have a file open |
| 17:04.33 | brlcad | you can create memory-only database instances |
| 17:04.39 | abhi2011 | ah yes right |
| 17:04.48 | brlcad | but that's still encapsulated in a dsip |
| 17:04.52 | brlcad | *dbip |
| 17:04.55 | abhi2011 | both ways, the db_i would exist |
| 17:06.02 | abhi2011 | ok I ll proceed assuming that a db_i can be passed by the caller , as of now |
| 17:06.29 | CIA-62 | BRL-CAD: 03brlcad * r45845 10/brlcad/trunk/src/external/Unigraphics/ug-g.c: call rt_curve_free() for consistent cleanup |
| 17:17.34 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 17:17.34 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 17:19.00 | abhi2011 | ok, what is an in-mem, you mean an in memory representation of the comb, which can be prepped ? |
| 17:19.30 | brlcad | db_open_inmem() |
| 17:19.39 | brlcad | it's a dbip that only lives in memory |
| 17:20.52 | brlcad | you can create an in-mem dbip, add the struct rt_db_internal * to it, call rt_new_rti() to get an rtip, and finally call rt_gettree() to evaluate the bounding boxes |
| 17:23.26 | abhi2011 | ok |
| 17:26.35 | CIA-62 | BRL-CAD: 03brlcad * r45846 10/brlcad/trunk/src/conv/dxf/dxf-g.c: free the sketch now that mk_sketch() doesn't |
| 17:27.48 | abhi2011 | I see a duplication in 1 thing though |
| 17:28.12 | abhi2011 | since db_* functions already provide database manipulation capabilities on disk and in-mem |
| 17:28.38 | abhi2011 | is there any need to duplicate it in functions like rt_dir_build() |
| 17:28.40 | CIA-62 | BRL-CAD: 03brlcad * r45847 10/brlcad/trunk/src/conv/dxf/dxf-g.c: struct is embedded, can't be null, and rt_curve_free() wants a pointer. |
| 17:29.02 | abhi2011 | eg. rt_dir_build() and db_open() both open a database |
| 17:30.07 | abhi2011 | but perhaps its because rt_dir_build() opens a on disk database and very conveniently returns a rt_i which can be used further down the raytracing system |
| 17:30.13 | brlcad | rt_dirbuild() calls db_open() |
| 17:30.26 | abhi2011 | oh ok |
| 17:31.09 | brlcad | the goal of dirbuild is to give a raytrace instance, the point of open is to get a database instance .. different (albeit related) purposes |
| 17:31.37 | abhi2011 | yes I get understand |
| 17:33.03 | CIA-62 | BRL-CAD: 03brlcad * r45848 10/brlcad/trunk/src/conv/shp/shp-g.c: no longer need to allocate dynamic memory for the sketch, keep it on the stack and just free the minimal set of dynamic memory that was needed for the sketch's curve segments. |
| 17:36.49 | CIA-62 | BRL-CAD: 03brlcad * r45849 10/brlcad/trunk/src/libged/tire.c: another rt_sketch_internal that no longer needs to be dynamic. release the dynamic data associated with it though, now that mk_sketch() won't |
| 17:42.15 | abhi2011 | i was looking at d b _ c r e a t e _ i n m e m() as well and I see that it add a default _GLOBAL object as well, but what would be the point of adding such an object |
| 17:42.54 | brlcad | doesn't matter |
| 17:43.18 | brlcad | _GLOBAL holds the working units for the geometry in question |
| 17:43.30 | abhi2011 | ok |
| 17:45.47 | CIA-62 | BRL-CAD: 03brlcad * r45850 10/brlcad/trunk/src/libged/make.c: enable creation of the old/original sketch object if a LIBGED_MAKE_SKETCH environment variable is set to 1. useful for debugging purposes and makes the code get compiled so it doesn't fall out of sync with the api. |
| 17:52.24 | abhi2011 | I was reading about sketches at http://brlcad.org/wiki/Sketch , since I see a lot of code changes going on related to them, I guess they are simply a line and curve based drawing of a model's shape ? |
| 18:02.10 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 18:04.07 | brlcad | abhi2011: they're autocad-style 2d "drawings" |
| 18:05.17 | abhi2011 | ok |
| 18:21.52 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: |
| 18:21.52 | CIA-62 | BRL-CAD: uploaded "[[Image:Example sketch.png]]": This is an example sketch that can be |
| 18:21.52 | CIA-62 | BRL-CAD: created with the ''make'' command if the LIBGED_MAKE_SKETCH environment variable |
| 18:21.52 | CIA-62 | BRL-CAD: is set to 1. This example sketch is primarily used for demonstration and |
| 18:21.52 | CIA-62 | BRL-CAD: debugging purposes. |
| 18:28.51 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3063 10/wiki/Sketch: link to the example sketch object image |
| 18:33.11 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3064 10/wiki/SGI_Cube: clean up alignment with |
| 18:35.04 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3065 10/wiki/SGI_Cube: swap images? |
| 18:47.55 | CIA-62 | BRL-CAD: 03brlcad * r45851 10/brlcad/trunk/ (include/raytrace.h src/librt/htbl.c): use size_t for hit table indexing |
| 19:03.43 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 19:03.43 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 19:05.21 | abhi2011 | Trying to convert the struct rt_db_internal to bu_external now as wdb_export_external() accepts only bu_external |
| 19:06.32 | abhi2011 | some of the primitives of librt do it |
| 19:06.57 | abhi2011 | like rt_ell_export5() in librt/primitives/ell/ell.c |
| 19:12.03 | abhi2011 | specifically the htond() and ntohd() seem to do conversions from an external db format bu_external to an internal rt_db_internal |
| 19:21.19 | brlcad | abhi2011: sounds too low-level |
| 19:22.46 | brlcad | wdb_put_internal() and rt_db_put_internal() both work at a higher level |
| 19:22.55 | abhi2011 | well I wish there was a wdb_export_external |
| 19:23.02 | abhi2011 | *wdb_export_internal |
| 19:23.04 | abhi2011 | ah ok |
| 19:23.36 | brlcad | get/put read/write to disk |
| 19:23.54 | abhi2011 | yes I need to look through the libwdb functions more carefully :P |
| 19:23.55 | brlcad | import/export convert from/to serialized (i.e., disk) format |
| 19:24.25 | brlcad | it's understandably complex to fresh eyes :) |
| 19:24.58 | abhi2011 | yah the thing is all the functions are there to make life easy, just need to run doxygen once |
| 19:25.39 | brlcad | even with doxygen, there are a LOT of functions .. so it takes a while |
| 19:25.52 | abhi2011 | ok |
| 19:56.59 | CIA-62 | BRL-CAD: 03kunigami * r45852 10/osl/trunk/compile.sh: Added a script to build ilmbase and openexr |
| 20:04.42 | brlcad | kunigami: ready for testing? |
| 20:07.06 | kunigami | no |
| 20:07.51 | kunigami | I'm currently trying to force openexr to use the local version of libz. It's getting from system] |
| 20:10.06 | brlcad | unless that causes a problem, wouldn't worry too much about it |
| 20:11.38 | kunigami | actually I don't know how to tell openexr where to look if it's not installed on the system :P |
| 20:12.04 | brlcad | main options are 1) install brlcad, then osl, then reinstall brlcad; or 2) link libz as svn external, then osl, then brlcad; or 3) copy libz, then osl, then brlcad |
| 20:12.44 | brlcad | autoconf supports setting CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS during configure, that'd be how |
| 20:13.20 | brlcad | ./configure CPPFLAGS=-I/path/to/libz/include LDFLAGS=-L/path/to/libz/libdir |
| 20:14.20 | kunigami | oh ok, great then. (by the way, I didn't understand what you meant in those three options) |
| 20:17.12 | brlcad | in terms of dealing with libz |
| 20:17.18 | brlcad | basically three options |
| 20:17.45 | brlcad | if you assume brlcad is already compiled/installed (so you can use the libz it compiled), then you'll have to build brl-cad twice |
| 20:18.31 | kunigami | true |
| 20:19.06 | brlcad | alternatives are to link in libz sources (svn:external) or svn cp (i.e., fork them in) |
| 20:34.12 | CIA-62 | BRL-CAD: 03starseeker * r45853 10/brlcad/trunk/src/ (6 files in 3 dirs): Simplify loading of Archer plugins - use bu_brlcad_data and avoid all the CWD logic. Good cleanup, and plugin loading now works in the build directory. |
| 20:34.40 | brlcad | awesome |
| 20:48.34 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 21:08.04 | CIA-62 | BRL-CAD: 03starseeker * r45854 10/brlcad/trunk/src/libbu/basename.c: Generalize bu_basename with the BU_DIR_SEPARATOR variable |
| 21:09.52 | CIA-62 | BRL-CAD: 03starseeker * r45855 10/brlcad/trunk/src/libbu/basename.c: Fix comments |
| 21:12.32 | brlcad | starseeker: i imagine the bu_basename() change is user-visible in some fashion |
| 21:12.41 | brlcad | possibly the plugins one too |
| 21:13.11 | starseeker | possibly... plugins is visible only when running from the build directory (probably why it never got addressed sooner...) |
| 21:13.21 | starseeker | adds NEWS item for basename |
| 21:13.33 | brlcad | yeah, plugins wouldn't be then |
| 21:16.35 | CIA-62 | BRL-CAD: 03starseeker * r45856 10/brlcad/trunk/NEWS: Generalized the bu_basename function to work with Windows paths - allows libraries and programs to capture their executable name without path information. |
| 21:18.40 | brlcad | which means what to the user? |
| 21:19.03 | starseeker | brlcad: not entirely sure. |
| 21:19.09 | brlcad | heh |
| 21:19.25 | brlcad | what wasn't working that now is working? |
| 21:19.28 | starseeker | brlcad: things *might* not work because of that, but we apparently hadn't run into anything |
| 21:23.35 | *** join/#brlcad saltan (~lieven@d51530284.static.telenet.be) | |
| 21:25.37 | CIA-62 | BRL-CAD: 03brlcad * r45857 10/brlcad/trunk/NEWS: |
| 21:25.37 | CIA-62 | BRL-CAD: how about this. cliff and bob improved mged/archer/bwish run-time behavior on |
| 21:25.37 | CIA-62 | BRL-CAD: windows by fixing bu_basename() to work with the windows path separator. this |
| 21:25.37 | CIA-62 | BRL-CAD: low-level interface is used for capturing the path to the running executable, |
| 21:25.37 | CIA-62 | BRL-CAD: data resources, and more; so fixing the routine should generally make things |
| 21:25.37 | CIA-62 | BRL-CAD: better, making apps more consistent for windows users. |
| 21:30.14 | brlcad | prepares a large whoosh commit |
| 21:30.16 | starseeker | that'll work :-) |
| 21:30.22 | starseeker | ducks and hides |
| 21:51.12 | CIA-62 | BRL-CAD: 03brlcad * r45858 10/brlcad/trunk/ (88 files in 23 dirs): (log message trimmed) |
| 21:51.12 | CIA-62 | BRL-CAD: Convert all BRL-CAD magic numbers to uint32_t. This change affects more than a |
| 21:51.12 | CIA-62 | BRL-CAD: dozen structs and more than 500 usages throughout the code including many |
| 21:51.12 | CIA-62 | BRL-CAD: function signatures, but is still considered minimally impacting. This |
| 21:51.12 | CIA-62 | BRL-CAD: consolidates the slew of int, long, unsigned int, unsigned long, etc definitions |
| 21:51.12 | CIA-62 | BRL-CAD: of magic numbers that were assuming to be 4 bytes for magic number validation. |
| 21:51.13 | CIA-62 | BRL-CAD: It also exposed a curious book-keeping practice in NMG where pointers to the |
| 21:51.42 | starseeker | tests the woosh |
| 21:57.56 | starseeker | yep, seems to work |
| 22:03.13 | brlcad | argh |
| 22:21.49 | CIA-62 | BRL-CAD: 03bob1961 * r45859 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: |
| 22:21.49 | CIA-62 | BRL-CAD: Need to copy result of call to bu_brlcad_root() into local storage before |
| 22:21.49 | CIA-62 | BRL-CAD: calling bu_brlcad_data() because bu_brlcad_root() uses static char array and |
| 22:21.49 | CIA-62 | BRL-CAD: bu_brlcad_data() calls bu_brlcad_root() overwriting what was previously in the |
| 22:21.49 | CIA-62 | BRL-CAD: static array. |
| 22:24.28 | abhi2011 | rt_uniresource is often(always) specified with rt_db_put_internal() |
| 22:24.43 | brlcad | it's a global |
| 22:24.47 | abhi2011 | I understand that it contains settings for uni processor machines |
| 22:24.56 | abhi2011 | yes |
| 22:24.57 | brlcad | sort of |
| 22:25.09 | abhi2011 | so what happens for multi cpu machines |
| 22:25.26 | CIA-62 | BRL-CAD: 03brlcad * r45860 10/brlcad/trunk/src/librt/ (4 files in 2 dirs): |
| 22:25.26 | CIA-62 | BRL-CAD: add a new private header for dsp-implementation use, moving the DSP() macro from |
| 22:25.26 | CIA-62 | BRL-CAD: dsp.c to this new dsp.h header so that the brep routine can use the same macro. |
| 22:25.26 | CIA-62 | BRL-CAD: remove the dsp_val() debugging wrapper function while we're at it. |
| 22:25.52 | brlcad | it's a "cpu resource" structure used for book-keeping |
| 22:26.11 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 22:26.15 | abhi2011 | ok |
| 22:26.29 | brlcad | the rt_uniresource can only be used by one cpu at a time, so it effectively makes that function single-threaded |
| 22:26.51 | abhi2011 | oh ok, some semaphore is present to enable that |
| 22:26.59 | brlcad | many functions pass resources around, but don't actually do anything with them |
| 22:27.13 | brlcad | others use the resource structure if they're SMP-aware |
| 22:27.17 | brlcad | like the ray tracer |
| 22:27.22 | abhi2011 | ok |
| 22:27.29 | brlcad | basically, don't worry about it |
| 22:27.35 | abhi2011 | ok :) |
| 22:27.43 | brlcad | if you were passed a resource, then pass it forward |
| 22:27.57 | brlcad | otherwise if you need to call something and don't have a resource, use the rt_uniresource |
| 22:28.17 | abhi2011 | ok |
| 22:31.35 | CIA-62 | BRL-CAD: 03brlcad * r45861 10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: |
| 22:31.35 | CIA-62 | BRL-CAD: make the dsp brep implementation use the new private dsp.h header for the DSP() |
| 22:31.35 | CIA-62 | BRL-CAD: macro instead of duplicating the code (bad, no donut for you). similarly, there |
| 22:31.35 | CIA-62 | BRL-CAD: shouldn't need to be any need to validate the dsp_ip or load it because that |
| 22:31.35 | CIA-62 | BRL-CAD: would have already happened during import. redoing that here will just leak |
| 22:31.36 | CIA-62 | BRL-CAD: memory and be not as good as what is done during import. |
| 22:36.08 | CIA-62 | BRL-CAD: 03starseeker * r45862 10/brlcad/trunk/src/other/tk/CMakeLists.txt: Make sure FREETYPE_LIBRARIES is empty if FREETYPE_FOUND is a no-go. |
| 22:38.40 | dli | /var/tmp/portage/media-gfx/brlcad-7.20.2-r1/work/brlcad-7.20.2/src/libged/png.c:363:38: error: 'Z_BEST_COMPRESSION' undeclared (first use in this function) |
| 22:39.10 | dli | starseeker, so, 7.20.2 is not compatible with libpng-1.5 |
| 22:40.14 | dli | starseeker, is there a patch to make 7.20.2 build with libpng-1.5? |
| 22:41.15 | ``Erik | that's actually a zlib symbol, one that's been there for a long time :/ |
| 22:43.15 | brlcad | dli: suspect that's not the actual first error |
| 22:43.38 | brlcad | probably preceeded with some failure to find/include zlib.h |
| 22:43.47 | dli | brlcad, seems to be, I do "make" again, that's the only error |
| 22:44.11 | brlcad | show the entire output from the compile line on |
| 22:44.33 | brlcad | make VERBOSE=1 if you're using cmake |
| 22:44.54 | dli | brlcad, http://pastebin.com/xH38anuF |
| 22:45.05 | brlcad | can't get to pastebin.com |
| 22:45.26 | brlcad | try http://paste.ubuntu.com/ |
| 22:46.20 | ``Erik | gnarly, that really is the first error |
| 22:46.44 | dli | brlcad, http://paste.ubuntu.com/662232/ |
| 22:48.06 | brlcad | so then it's finding some zlib.h that doesn't declare Z_BEST_COMPRESSION |
| 22:50.25 | dli | brlcad, let me try to build zlib |
| 22:50.27 | starseeker | dli: um. I suppose I could make a patch... |
| 22:50.36 | brlcad | dli: what does your system zlib.h look like? |
| 22:50.51 | dli | starseeker, if it's not too much work :( |
| 22:51.39 | brlcad | so far this has little if anything to do with libpng-1.5 |
| 22:52.03 | dli | brlcad, http://paste.pocoo.org/show/455636/ |
| 22:52.09 | ``Erik | you fools have 8 minutes until http://www.humblebundle.com is over, if'n ya wanna show your support for linux or osX :) |
| 22:54.53 | brlcad | dli: yeah, that zlib.h definitely defines Z_BEST_COMPRESSION |
| 22:55.08 | brlcad | edit that file and put a #error on the line before Z_BEST_COMPRESSION |
| 22:55.13 | brlcad | see if it's actually included |
| 22:55.19 | dli | brlcad, so, it's the building scripts or configure |
| 22:55.37 | brlcad | either neither? |
| 22:56.12 | starseeker | dli: this is most of it: http://bzflag.bz/~starseeker/png_patch.diff |
| 22:56.30 | starseeker | given it's gentoo, I'm assuming you're not using our src/other copies of zlib or libpng? |
| 22:56.42 | dli | starseeker, thanks |
| 22:57.09 | brlcad | the error says it's not declared, the source includes zlib.h, zlib.h lists it declared |
| 22:57.15 | brlcad | ergo, there is no problem |
| 22:57.23 | dli | starseeker, no other people, I'm the only one maintaining brlcad in gentoo |
| 22:57.32 | ``Erik | 2.5 minutes on humblebundle.com O.o |
| 22:58.08 | brlcad | nothing in libpng-1.5 changes Z_BEST_COMPRESSION |
| 22:58.30 | brlcad | so it's still an unknown problem, and libpng update is possibly a big red herring |
| 22:58.33 | starseeker | knows - was just giving him changes he will likely need later. |
| 22:58.58 | brlcad | OH |
| 22:59.13 | brlcad | I'm looking at head .. did 7.20.2 not include zlib.h ? |
| 22:59.19 | dli | starseeker, why do I still need this patch? http://paste.pocoo.org/show/455638/ |
| 22:59.21 | brlcad | (in src/libged/png.c |
| 22:59.47 | brlcad | that would explain it, lucy |
| 22:59.59 | dli | brlcad, the svn trunk builds without issue |
| 23:00.04 | starseeker | dli: um... may have something to do with spaces in paths... |
| 23:00.40 | starseeker | or just spaces in general |
| 23:00.42 | brlcad | dli: yeah, that explains it all -- the problem is a simple one-liner header #include missing |
| 23:01.14 | dli | brlcad, add the header to the c file itself? |
| 23:01.21 | brlcad | hm? |
| 23:01.29 | starseeker | dli: does the patch I posted fix it? |
| 23:01.31 | brlcad | #include "zlib.h" was missing from that file |
| 23:01.45 | dli | starseeker, let me try |
| 23:01.54 | brlcad | starseeker's patch, http://bzflag.bz/~starseeker/png_patch.diff fixes it for the previous release |
| 23:02.13 | brlcad | png.h must no longer auto-include zlib.h for you |
| 23:04.17 | CIA-62 | BRL-CAD: 03brlcad * r45863 10/brlcad/trunk/src/librt/primitives/dsp/dsp.h: prevent crashing if the dsp buffer isn't set yet |
| 23:04.46 | CIA-62 | BRL-CAD: 03brlcad * r45864 10/brlcad/trunk/src/proc-db/csgbrep.cpp: initialize all of the dsp fields so we don't crash on export |
| 23:08.01 | ``Erik | yup, 1.4 has #include <zlib.h>, 1.5 does not |
| 23:10.22 | ``Erik | png.h indicates that you should pass an actual number and that they may not correlate to the zlib values in the future |
| 23:11.08 | ``Erik | line 1646 |
| 23:11.45 | brlcad | funny, their manpage gives an example using Z_BEST_COMPRESSION :) |
| 23:13.06 | ``Erik | (does his best wallace shawn voice) docs that're out of date? inconceivable! |
| 23:14.49 | CIA-62 | BRL-CAD: 03kunigami * r45865 10/osl/trunk/compile.sh: added oiio compilation. there's an issue with cmake mixing TBB versions (like it does with opengl in brlcad), so by now I just set TBB_USE=0 |
| 23:16.43 | CIA-62 | BRL-CAD: 03bhinesley * r45866 10/brlcad/trunk/src/libged/edit.c: |
| 23:16.43 | CIA-62 | BRL-CAD: Enabled use of bounding box centers of objects as points. Basic object |
| 23:16.43 | CIA-62 | BRL-CAD: translations are working "translate -k obj1 -a obj2 obj3", "translate -a obj2 |
| 23:16.43 | CIA-62 | BRL-CAD: obj1", etc. (redrawing is broken, the objects have to be blasted). It turns out |
| 23:16.43 | CIA-62 | BRL-CAD: that getting the natural origin is what is causing the 0,0,0 coordinates; |
| 23:16.44 | CIA-62 | BRL-CAD: haven't been able to figure out why. Many things aren't working yet. At least |
| 23:16.44 | CIA-62 | BRL-CAD: some translations using reference vectors are working. |
| 23:18.21 | CIA-62 | BRL-CAD: 03brlcad * r45867 10/brlcad/trunk/src/librt/primitives/ (20 files in 20 dirs): |
| 23:18.21 | CIA-62 | BRL-CAD: make the caller allocate an ON_Brep object, maybe they want to avoid dynamic |
| 23:18.21 | CIA-62 | BRL-CAD: memory allocation altogether. this plugs a leak in the csgbrep proc-db and begs |
| 23:18.21 | CIA-62 | BRL-CAD: changing the *_brep() param to a simple ON_Brep * instead of a double pointer. |
| 23:19.42 | brlcad | cheers on bhinesley |
| 23:19.55 | brlcad | progress, :) |
| 23:20.04 | bhinesley | yes, finally :) |
| 23:21.49 | bhinesley | still a lot to fix/test |
| 23:22.18 | bhinesley | for instance "translate 5 obj1.c" is broken |
| 23:22.20 | bhinesley | rolls eyes |
| 23:22.31 | starseeker | heh - hang in there |
| 23:22.46 | starseeker | that "it's all coming together" feeling is a lot of fun |
| 23:25.59 | bhinesley | starseeker: agreed |
| 23:30.04 | bhinesley | if I could do one thing differently, I would have used simple linked lists of arguments with flags, instead of a union of subcommand structs of args. That made so much more work and caused so many problems, that it couldn't possibly have been worth it |
| 23:32.56 | bhinesley | the only 'pro' is that it should make it easier to build subcommand arguments programatically. Create a union, attach a command name, stuff the arguments in the correct elements and go. |
| 23:33.09 | bhinesley | s/Create/declare |
| 23:33.25 | starseeker | nods - hindsight is often like that |
| 23:49.32 | starseeker | makes a note to check this out later: http://dgnlib.maptools.org/ |