| 00:13.34 | starseeker | bhinesley: one question - with the benefit of hindsight, would it be better going forward to switch to a linked list approach (not right now obviously, with gsoc winding up RSN, but in the future) |
| 00:14.43 | bhinesley | it probably depends on how often we're building commands programatically |
| 00:15.22 | starseeker | linked lists can also be built programatically though, can't they? |
| 00:16.13 | starseeker | figures for the editing commands programmatic calling will probably be fairly common... |
| 00:26.36 | dli | starseeker, brlcad with starseeker's patch, brlcad-7.20.2 builds with libpng-1.5, thanks |
| 00:27.52 | starseeker | dli: np - good to know it fixes it for external libpng as well as our local copy |
| 00:47.57 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 00:49.17 | bhinesley | starseeker: yes; but it *may* be easier, and/or less error prone for edit() callers to use the structs. (btw, callers can actually still use a linked list if need be, and just run it through edit_<subcmd-name>_add_cl_args() before calling edit()). I decided on the edit_cmd union because it seemed like building args would be more legible, and therefore easier to build: "cmd.translate.ref_vector.from = arg;" rather than "args |
| 00:52.12 | bhinesley | structs seems more "rigid", as you have a finite number of elements (arguments) that you can add |
| 00:54.21 | bhinesley | as far as creating new edit subcommands goes, I don't think it makes much of a difference; it requires a couple subcommand-specific functions that would not be required if linked lists were used, but they're ~20 lines and dead simple. |
| 00:58.06 | bhinesley | it feels like hacking in linked-list behavior, though |
| 01:24.14 | bhinesley | I can't think of a compelling reason switch to linked lists. I'm open to criticism, though. |
| 03:05.03 | *** join/#brlcad dli_ (~dli@dsl-173-248-211-69.acanac.net) | |
| 03:15.04 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 03:15.05 | yukonbob | oh hai |
| 03:27.51 | CIA-62 | BRL-CAD: 03brlcad * r45868 10/brlcad/trunk/src/librt/ (db_io.c dir.c): the rt_fwrite_internal/db_fwrite_internal functions are only intended to work with v4 geometry. |
| 03:31.23 | *** join/#brlcad dli_ (~dli@dsl-69-171-146-13.acanac.net) | |
| 03:39.11 | CIA-62 | BRL-CAD: 03brlcad * r45869 10/brlcad/trunk/src/proc-db/csgbrep.cpp: relearning how to write an object from nothing |
| 03:39.38 | CIA-62 | BRL-CAD: 03brlcad * r45870 10/brlcad/trunk/src/proc-db/csgbrep.cpp: ws |
| 03:40.06 | CIA-62 | BRL-CAD: 03brlcad * r45871 10/brlcad/trunk/src/proc-db/csgbrep.cpp: indent |
| 03:43.30 | CIA-62 | BRL-CAD: 03brlcad * r45872 10/brlcad/trunk/src/proc-db/ (19 files): ws and indent cleanup |
| 03:52.08 | yukonbob | before I dig in: I'm getting a build failure on 7.20.2 (NetBSD, providing some own utilities (ie: tcl/tk/itcl) |
| 03:53.08 | yukonbob | is a warning (treated as error): bitv.c: in function 'bu_hex_to_bitv': |
| 03:53.45 | yukonbob | bitv.c:250: warning: array subscript has type char |
| 03:53.48 | yukonbob | , same for line 255 |
| 03:54.05 | yukonbob | had same error w/ 7.20.0 |
| 03:54.20 | yukonbob | known issue? |
| 03:55.16 | yukonbob | hrmm... macro issue? |
| 03:55.35 | brlcad | yukonbob: not a known issue, just our strict compilation behavior treating a warning as an error |
| 03:55.53 | yukonbob | hey brlcad :) |
| 03:55.54 | brlcad | you can disable strict compilation and it'll succeed |
| 03:56.09 | yukonbob | nods. alright :) Onward! |
| 03:57.05 | brlcad | if you try to compile with trunk, a full build log would be useful |
| 03:57.11 | brlcad | so someone can fix the warnings |
| 03:57.43 | yukonbob | will work incrementally. |
| 03:58.19 | yukonbob | 7.20.2 for now... I've got some tcl/tk/itcl integration I'd like to work with somebody on; then bigger fish |
| 03:59.12 | yukonbob | just svn updated, but has to review tree, got merge conflicts, which is weird, considering I don't edit my local copy. |
| 03:59.51 | yukonbob | re-./configure'd, make'ing. |
| 04:00.36 | yukonbob | brlcad: autoconf et al still to be first class citizens for foreseeable future? |
| 04:01.51 | brlcad | yukonbob: not really |
| 04:02.01 | brlcad | the build system is being replaced with the new cmake build system |
| 04:02.05 | yukonbob | ok... so cmake transition went well? |
| 04:02.11 | brlcad | for the most part |
| 04:02.14 | yukonbob | nice. |
| 04:02.22 | brlcad | autotools is going through our deprecation process now |
| 04:02.27 | yukonbob | I like cmake, despite it's problems. |
| 04:02.47 | yukonbob | my biggest peave is that they didn't use Tcl as the control language, but half-baked their own, but... ;) |
| 04:02.54 | brlcad | http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/deprecation.txt?revision=HEAD |
| 04:03.09 | brlcad | basically a 3-month minimum to give people a head's up |
| 04:03.29 | yukonbob | nods. |
| 04:03.41 | yukonbob | well, congratulations on the shift; not a small feat! |
| 04:03.50 | brlcad | starseeker did all the hard work |
| 04:03.57 | yukonbob | was just going to ask... |
| 04:04.09 | yukonbob | I know cliff was heads-down in it for a while. |
| 04:04.34 | yukonbob | [incr starseeker] |
| 04:06.21 | yukonbob | dammit |
| 04:06.24 | CIA-62 | BRL-CAD: 03brlcad * r45873 10/brlcad/trunk/src/libged/ (dbip.c grid.c nmg_collapse.c): quell the non-%V warnings listed in dli's build log |
| 04:06.28 | yukonbob | now real macro issues. |
| 04:07.01 | yukonbob | iso C does not permit named variadic macros... |
| 04:07.43 | yukonbob | hrmm. Looks to be from own X11 headers. |
| 04:08.26 | yukonbob | oh. nm. /me reads on, sees, is itk. |
| 04:15.40 | CIA-62 | BRL-CAD: 03brlcad * r45874 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: looks like this file is not in sync with the sources.. build failure with missing symbol and sure enough the source file isn't being compiled. |
| 04:24.18 | brlcad | bhinesley: ../../../src/libged/edit.c:1226: warning: passing argument 2 of 'ged_path_validate' discards qualifiers from pointer target type |
| 04:25.33 | brlcad | if you can capture another "make -k 2>&1 | tee build.log" .. I can take another pass at squashing any warnings that remain so you can keep strict enabled |
| 04:26.40 | bhinesley | brlcad: will do |
| 04:27.32 | brlcad | also, |
| 04:27.33 | brlcad | ../../../src/libged/path.c:83: error: conflicting types for 'ged_path_validate' |
| 04:27.33 | brlcad | ../../../include/ged.h:1885: error: previous declaration of 'ged_path_validate' was here |
| 04:27.42 | brlcad | perhaps header not checked in |
| 04:27.56 | bhinesley | that's odd |
| 04:28.13 | brlcad | or... maybe I'm not up to date..... |
| 04:28.19 | brlcad | lemme check |
| 04:28.41 | bhinesley | I did change them in 2 seperate commits |
| 04:30.03 | brlcad | low and behold, that was the problem for both issues, it's all good |
| 04:30.09 | brlcad | sorry for the bother! |
| 04:30.18 | bhinesley | oh np |
| 04:39.27 | CIA-62 | BRL-CAD: 03brlcad * r45875 10/brlcad/trunk/src/proc-db/csgbrep.cpp: things are way simpler than I was attempting, just call wdb_put_internal() |
| 04:40.29 | CIA-62 | BRL-CAD: 03brlcad * r45876 10/brlcad/trunk/src/proc-db/csgbrep.cpp: unused var |
| 04:43.08 | bhinesley | brlcad: build log: http://paste.pocoo.org/show/455744/ |
| 04:48.11 | CIA-62 | BRL-CAD: 03brlcad * r45877 10/brlcad/trunk/src/proc-db/csgbrep.cpp: |
| 04:48.11 | CIA-62 | BRL-CAD: turns out, wdb_put_internal() has similar delusional notions to the mk_*() |
| 04:48.11 | CIA-62 | BRL-CAD: functions assuming memory is dynamic and ready to be released. since we have |
| 04:48.11 | CIA-62 | BRL-CAD: stack objects, that's bad. fortunately, it skips the free if idb_meth isn't |
| 04:48.11 | CIA-62 | BRL-CAD: set, so try to pull a fast one. |
| 05:00.24 | CIA-62 | BRL-CAD: 03brlcad * r45878 10/brlcad/trunk/src/librt/ (db5_io.c wdb.c): prevent crashing if idb_meth isn't set |
| 05:21.38 | CIA-62 | BRL-CAD: 03brlcad * r45879 10/brlcad/trunk/src/librt/primitives/ (5 files in 5 dirs): remove debugging print statements, noisy |
| 05:28.04 | CIA-62 | BRL-CAD: 03brlcad * r45880 10/brlcad/trunk/src/librt/primitives/pipe/pipe_brep.cpp: shush |
| 05:28.25 | CIA-62 | BRL-CAD: 03brlcad * r45881 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: print 5 in v5 routines, not 4 |
| 05:35.41 | CIA-62 | BRL-CAD: 03brlcad * r45882 10/brlcad/trunk/src/librt/primitives/ehy/ehy_brep.cpp: unused vars, perhaps wip |
| 05:36.27 | CIA-62 | BRL-CAD: 03brlcad * r45883 10/brlcad/trunk/ (include/raytrace.h src/librt/primitives/sketch/sketch.c): more uint32_t magic number fallout |
| 05:50.36 | CIA-62 | BRL-CAD: 03brlcad * r45884 10/brlcad/trunk/src/librt/primitives/ (extrude/extrude.c revolve/revolve.c sketch/sketch_brep.cpp): even more magic fallout. highlights the importance of consistently testing magic numbers, particularly where pointers to them are shoved into bu pointer tables and end up with signage issues. |
| 06:02.50 | CIA-62 | BRL-CAD: 03brlcad * r45885 10/brlcad/trunk/src/librt/primitives/revolve/revolve_brep.cpp: yep, more |
| 06:07.23 | yukonbob | yay me! successfully built, installing; issues that I recognize from previous installs; conflicts w/ libpng between in-tree and other-installations, need to #include <zlib.h> (will find file), tweak itcl/itk... |
| 06:11.29 | CIA-62 | BRL-CAD: 03brlcad * r45886 10/brlcad/trunk/src/librt/primitives/revolve/revolve_brep.cpp: more shushing |
| 06:12.36 | CIA-62 | BRL-CAD: 03brlcad * r45887 10/brlcad/trunk/src/proc-db/csgbrep.cpp: and with this, we should now have all primitives getting written out identically in brep and implicit form (export needed the idb_type to be set). dsp is hozered, so disable. |
| 06:13.09 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:29.32 | brlcad | bhinesley: THX! |
| 06:30.22 | bhinesley | np |
| 06:30.46 | *** part/#brlcad saltan (~lieven@d51530284.static.telenet.be) | |
| 06:46.06 | CIA-62 | BRL-CAD: 03bhinesley * r45888 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 06:46.06 | CIA-62 | BRL-CAD: Wrote a function to expand arguments with partial coordinates set, via -x/-y/-z |
| 06:46.06 | CIA-62 | BRL-CAD: options (support for this was missing in edit()). Required changes to functions |
| 06:46.06 | CIA-62 | BRL-CAD: for getting object coordinates; they now write to any vector they are passed, so |
| 06:46.06 | CIA-62 | BRL-CAD: that coordinates may be obtained without modifying the edit_cmd object. Resolved |
| 06:46.06 | CIA-62 | BRL-CAD: issue in an argument string parsing function, which was incorrectly pairing |
| 06:46.07 | CIA-62 | BRL-CAD: objects with the coordinates that they followed. Had to remove ability to |
| 07:06.27 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3066 10/wiki/User:Bhinesley: /* Log */ today |
| 07:23.16 | *** join/#brlcad dli (~dli@dsl-69-171-146-13.acanac.net) | |
| 09:45.54 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 09:46.33 | *** join/#brlcad d_rossbe1g (~rossberg@BZ.BZFLAG.BZ) | |
| 09:47.20 | abhi2011 | brlcad: I have been trying to insert a struct rt_db_internal into a directory |
| 09:48.10 | abhi2011 | it goes like this : http://bin.cakephp.org/view/73267920 |
| 09:48.30 | abhi2011 | so I create a in-mem dbip |
| 09:48.58 | abhi2011 | and then I create a struct directory by using dp = db_lookup(dbip, ip->idb_meth->ft_name, LOOKUP_NOISY) |
| 09:49.19 | abhi2011 | the struct directory is required when using rt_db_put_internal(dp, dbip, ip, &rt_uniresource) |
| 09:49.59 | abhi2011 | the db_lookup() is bound to fail however because the dbip it uses has just been created, so its empty |
| 09:50.39 | abhi2011 | so is there any other way to create a struct directory * that can be passed to rt_db_put_internal() |
| 09:54.47 | abhi2011 | probably db_diradd() may work |
| 10:34.47 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 11:17.49 | d_rossberg | abhi2011: you have just created the in-memory database, therefore it's empty |
| 11:18.35 | d_rossberg | you probably need a rt_i* as a parameter |
| 11:19.55 | abhi2011 | d_rossberg: Yes true, however I need top insert a struct rt_db_internal into the dbip before I can make a rt_i* out of it |
| 11:20.05 | abhi2011 | <PROTECTED> |
| 11:20.45 | abhi2011 | however before I can call rt_new_rti , i need to insert an object (represented by rt_db_internal) into the dbip |
| 11:22.12 | abhi2011 | to insert a rt_db_internal into the dbip, I call rt_db_put_internal(dp, dbip, ip, &rt_uniresource) |
| 11:22.29 | abhi2011 | which requires a struct directory * dp |
| 11:22.47 | abhi2011 | its while getting the dp that I run into an issue |
| 11:23.22 | abhi2011 | I obviously cannot use db_loopup() because dbip is empty |
| 11:23.32 | abhi2011 | yet I need dp :P |
| 11:23.56 | abhi2011 | *db_lookup() |
| 11:24.06 | d_rossberg | i'm afraid it's impossible to get the rtip back from a rt_db_internal structure |
| 11:24.49 | d_rossberg | rt_db_internal points to the internal representation of an object |
| 11:24.56 | abhi2011 | hmm, my final aim is to calculate the bounding box for the passed rt_db_internal |
| 11:25.07 | d_rossberg | it needs to be castet to the real object type |
| 11:25.13 | abhi2011 | oh ok |
| 11:25.31 | abhi2011 | so a switch case to detect the object type |
| 11:25.31 | abhi2011 | and convert |
| 11:25.31 | d_rossberg | look at rtgeom.h for these types |
| 12:53.39 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 12:53.39 | *** 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! | |
| 12:55.22 | CIA-62 | BRL-CAD: 03brlcad * r45889 10/brlcad/trunk/src/proc-db/csgbrep.cpp: this is v5 geometry, need to set the major_type as well as the minor. |
| 13:00.47 | abhi2011 | So I am calling wdb_put_external() using : |
| 13:00.49 | abhi2011 | if (wdb_put_internal(dbip->dbi_wdbp, ip->idb_meth->ft_name, &ip, 1.0) < 0) |
| 13:01.05 | abhi2011 | I want it to insert an object named sph2.s |
| 13:01.28 | abhi2011 | however ip->idb_meth->ft_name point to the ID of the sphere geometry ID_ELL |
| 13:01.46 | abhi2011 | I would need the object name here |
| 13:02.08 | abhi2011 | There should be some way to extract the object name from the struct rt_db_internal |
| 13:02.21 | abhi2011 | I am looking at the fields of idb_meth now |
| 13:03.39 | abhi2011 | so instead of wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0 "ID_ELL", ip=0x7fffffffd988, local2mm=1) |
| 13:03.52 | abhi2011 | I want to call the function as wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0 "sph2.s", ip=0x7fffffffd988, local2mm=1) |
| 13:06.23 | CIA-62 | BRL-CAD: 03brlcad * r45890 10/brlcad/trunk/src/proc-db/csgbrep.cpp: extrude and revolve don't actually need their own sketch objects, reduce |
| 13:09.02 | tofu | abhi2011: look at that file (csgbrep.cpp) .. in there is a little function that shows an rt_db_internal getting added to a database |
| 13:09.47 | tofu | at the rt_db_internal layer, you don't know the name any more, but you don't need to -- so you can just give it any dummy name |
| 13:10.25 | tofu | the whole point of adding it to a dbip in the first place is just so you can get a proper rtip so you can call dirbuild and/or prep to get the bounding box calculated automatically |
| 13:10.49 | tofu | see the write_out() function |
| 13:12.03 | abhi2011 | tofu: thanks! i suspected the name wouldnt be there anymore and yes i dont need it too |
| 13:12.04 | tofu | there's also wdb_put_internal() that is even simpler and might work for you (just write_out() couldn't use it) |
| 13:12.22 | abhi2011 | ok |
| 13:13.25 | abhi2011 | tofu: yes i am using wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0 "ID_ELL", ip=0x7fffffffd988, local2mm=1) now |
| 13:13.38 | abhi2011 | which needs a name to be pased as well |
| 13:13.53 | abhi2011 | i could try a dummy of course |
| 13:18.10 | tofu | bhinesley: you actually have no more compilation warnings listed in that log, just one bonefide build failure in cursor.c |
| 13:19.41 | tofu | bhinesley: something is awry with the termcap.h/term.h/curses.h header detection, so it's not getting a header included that it needs -- if you would, work with starseeker to see what cmake isn't detecting properly as it's not a source code issue but a build system issue |
| 13:30.03 | CIA-62 | BRL-CAD: 03brlcad * r45891 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: only attempt to override tk behavior if tk is loaded |
| 13:33.13 | starseeker | tofu: I'll take a look at that today - Bob's machine is having a similar issue |
| 13:33.57 | starseeker | mildly frustrating - I thought I finally had that sorted - but I'll squash it sooner or later |
| 13:34.35 | CIA-62 | BRL-CAD: 03brlcad * r45892 10/brlcad/trunk/src/tclscripts/mged/helpdevel.tcl: supposed to read helplib.tcl, but it doesn't, so simpilfy |
| 13:37.12 | CIA-62 | BRL-CAD: 03brlcad * r45893 10/brlcad/trunk/src/tclscripts/mged/help.tcl: try a different way to read in the helplib.tcl file, source it |
| 13:46.05 | CIA-62 | BRL-CAD: 03brlcad * r45894 10/brlcad/trunk/src/tclscripts/mged/mged.tcl: |
| 13:46.05 | CIA-62 | BRL-CAD: another case where a tk function is curiously being overridden for no apparent |
| 13:46.05 | CIA-62 | BRL-CAD: reason. TextInsert was added by gdurf back in 1995 with an empty log message, |
| 13:46.05 | CIA-62 | BRL-CAD: so yank it. the current tk version looks similar enough but better. |
| 13:48.44 | CIA-62 | BRL-CAD: 03brlcad * r45895 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl: don't shadow the dot proc with a value |
| 13:51.16 | CIA-62 | BRL-CAD: 03brlcad * r45896 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl: remove the Sketch_editor namespace lookalike prefix from a handful of funcs that aren't listed as itcl class methods but are pretending to be them. make them regular procs. |
| 13:53.34 | CIA-62 | BRL-CAD: 03brlcad * r45897 10/brlcad/trunk/src/tclscripts/rtwizard/RaytraceWizard.tcl: script isn't always being run as a main application, make sure argv exists |
| 13:55.31 | CIA-62 | BRL-CAD: 03brlcad * r45898 10/brlcad/trunk/src/tclscripts/ (cad_dialog.tcl hoc.tcl): make sure the tk namespace exists before trying to set variables in it |
| 14:04.00 | tofu | that should actually take care of most if not all of the tclscript blather |
| 14:04.12 | CIA-62 | BRL-CAD: 03brlcad * r45899 10/brlcad/trunk/src/tclscripts/mged/ (8 files): |
| 14:04.12 | CIA-62 | BRL-CAD: this could use some rethinking, but instead of testing to make sure the commands |
| 14:04.12 | CIA-62 | BRL-CAD: we need actually exist at 'source' time, see if they exist at run-time. this |
| 14:04.12 | CIA-62 | BRL-CAD: should avoid pkgindex blather and be more likely that the command is actually |
| 14:04.12 | CIA-62 | BRL-CAD: already loaded. |
| 14:07.37 | abhi2011 | csgbrep.cpp seems to be making a model by inserting arbs, ellipses etc using mk_brep() |
| 14:08.55 | tofu | it would seem that way because it is |
| 14:09.15 | tofu | it makes each primitive in implicit and brep/nurbs form |
| 14:09.23 | tofu | irrelevant for what you're doing |
| 14:09.45 | abhi2011 | ok but I can use mkprep() to insert rt_db_internal |
| 14:09.47 | tofu | the point is how it's writing out primitives using an existing rt_db_internal* is very similar to what you're trying to do |
| 14:09.51 | abhi2011 | to a wdb |
| 14:09.55 | tofu | no |
| 14:10.04 | tofu | ignore mk_* |
| 14:10.10 | abhi2011 | ok |
| 14:10.53 | tofu | you were trying to write an rt_db_internal to an inmem dbip, so you can get an rtip from it |
| 14:10.59 | abhi2011 | yes right |
| 14:11.06 | abhi2011 | mk_brep writes a boundary repr |
| 14:11.18 | tofu | IGNORE mk_* |
| 14:11.37 | abhi2011 | yes ignored :) |
| 14:11.40 | tofu | you care about the rt_db_internal |
| 14:11.46 | abhi2011 | yes |
| 14:11.53 | tofu | read write_out() |
| 14:12.16 | tofu | it's yet another example of writing an rt_db_internal, you might be able to use a similar method |
| 14:12.30 | tofu | you may also be able to just use wdb_put_internal() |
| 14:13.52 | abhi2011 | tofu: yes I have tried wdb_put_internal(), however it requires a valid name t be passed, a dummy name does not work |
| 14:14.05 | tofu | eh? |
| 14:14.29 | abhi2011 | well I have tried it like this : wdb_put_internal(dbip->dbi_wdbp, "dummy.s", &ip, 1.0) |
| 14:15.19 | tofu | it doesn't know what is valid/invalid, so if that failed, it's something else |
| 14:15.55 | tofu | in fact, the name you provided isn't dummy at that point -- you're saying "write this ip as dummy.s" |
| 14:16.18 | tofu | which is correct -- so if it fails, something is probably either wrong with the wdbp or ip |
| 14:16.21 | abhi2011 | yes right |
| 14:17.07 | abhi2011 | hmm, I do a valid lookup of the ip using if ( !rt_db_lookup_internal(dbip, argv[2], &dp, &intern, LOOKUP_NOISY, &rt_uniresource)){ |
| 14:18.09 | tofu | so then when you say it "does not work", what do you mean exactly |
| 14:19.18 | abhi2011 | well I get a bad pointer error : ERROR: bad pointer 0x7ffff73da148: s/b rt_db_internal(xdbbd867), was Unknown_Magic(x7ffff73da5e0), file /home/abhi/socis/brlcad/src/librt/wdb.c, line 289 |
| 14:19.42 | abhi2011 | so here is the main program I have got so far to test : http://bin.cakephp.org/view/73267920 |
| 14:19.56 | abhi2011 | the program tests the new function in librt |
| 14:20.36 | abhi2011 | this is the function : http://bin.cakephp.org/view/267477296 |
| 14:23.49 | abhi2011 | trying to find out if the ip i am passing is somehow in incorrect form : wdb_put_internal (wdbp=0x634420, name=0x7fffe964745f "dummy.s", ip=0x7fffffffd988, local2mm=1) |
| 14:25.16 | abhi2011 | hmm the magick number is wrong |
| 14:26.56 | abhi2011 | the struct rt_db_internal probably needs to be properly initialized, just passing a pointer wont do |
| 14:27.35 | abhi2011 | i ll try with RT_DB_INTERNAL_INIT(tmp_internal); |
| 14:30.20 | abhi2011 | hmm no , thats not the case, because i pass a valid ip using rt_db_lookup_internal() in the program |
| 14:32.46 | abhi2011 | wdb_put_internal() causes bu_badmagic (ptr=0x7fffffffd988, magic=230414439, str=0x7fffe96a4577 "rt_db_internal", file=0x7fffe96a4350 "/home/abhi/socis/brlcad/src/librt/wdb.c", line=289) to be called |
| 14:34.39 | tofu | abhi2011: are you up-to-date with your checkout? |
| 14:35.04 | abhi2011 | no I am not , will check out now |
| 14:35.16 | tofu | there were a lot of magic number changes just yesterday and last night affecting magic numbers, that error looks related |
| 14:35.23 | abhi2011 | oh ok |
| 14:35.42 | abhi2011 | are magick numbers in a definite range ? |
| 14:35.49 | tofu | should always stay as up-to-date as possible, svn updating throughout the day unless you're at a critical point yourself |
| 14:35.53 | tofu | yes |
| 14:35.58 | tofu | they're a specific value that is expected |
| 14:35.59 | abhi2011 | so I can just look at a number and say this looks wrong |
| 14:36.03 | abhi2011 | ok |
| 14:36.29 | tofu | s/b means "should be" |
| 14:36.45 | tofu | so it should have had a value of xdbbd867 ... but instead it encountered x7ffff73da5e0 |
| 14:37.15 | tofu | which just looks like the aforementioned type cast problem that has already been fixed |
| 14:37.34 | abhi2011 | oh ok, yah the 7fffff.. thing looks like a virtual memory pointer |
| 14:47.44 | tofu | make sure you're actually passing correct data too, of course, that it really is a valid rt_db_internal |
| 14:50.05 | abhi2011 | tofu: yes, I get the rt_db_internal using rt_db_lookup_internal(), which does not return an error |
| 14:50.51 | CIA-62 | BRL-CAD: 03n_reed * r45900 10/brlcad/trunk/src/libgcv/wfobj/ (7 files): Removing unused C versions of obj parser sources. They will be out-of-sync with the refactored C++ parser sources. |
| 14:51.44 | CIA-62 | BRL-CAD: 03Lighkatwheajec 07http://compilefarm.net * r3067 10/wiki/Main_Page: |
| 15:24.59 | abhi2011 | thats strange, I get a seg fault after the latest checkout , during make install |
| 15:25.04 | abhi2011 | while Generating ../share/brlcad/7.20.3/db/terra.g |
| 15:26.01 | abhi2011 | http://bin.cakephp.org/view/1252572721 |
| 15:26.48 | abhi2011 | ok I ll probably need to run cmake again as well |
| 15:30.30 | CIA-62 | BRL-CAD: 03n_reed * r45901 10/brlcad/trunk/src/libgcv/wfobj/ (obj_parser.h obj_parser.h): Reverted obj_parser.h to last working verion. |
| 15:52.08 | abhi2011 | thats wierd I got the same error again |
| 15:52.55 | abhi2011 | anyone else getting this error while building the latest version ? |
| 15:53.32 | abhi2011 | appears to be related to rt_uniresource : ../bin/asc2g: Symbol `rt_uniresource' has different size in shared object, consider re-linking |
| 16:11.52 | tofu | abhi2011: you need to fully rebuild |
| 16:15.10 | brlcad | whatever dependency checking that cmake is doing apparently isn't full proof, make clean and rebuild |
| 16:33.08 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 16:41.24 | bhinesley | starseeker: at your service; let me know if you need me to do anything for the termcap/term/curses detection issue |
| 17:01.47 | CIA-62 | BRL-CAD: 03n_reed * r45902 10/brlcad/trunk/src/libgcv/wfobj/ (7 files): Changing .cc to .cpp. Whitespace and style. |
| 17:04.37 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 17:48.10 | abhi2011 | thats strange a did a fresh checkout and a clean rebuild |
| 17:48.23 | abhi2011 | brlcad compiled successfully |
| 17:48.45 | abhi2011 | and I inserted my function into librt for finding the bounding box |
| 17:49.01 | abhi2011 | but I still get an error related to magick numbers |
| 17:49.13 | abhi2011 | ERROR: bad pointer 0x7fff838b3c18: s/b rt_db_internal(xdbbd867), was Unknown_Magic(x838b40b0), file /home/abhi/socis/brlcad/src/librt/wdb.c, line 289 |
| 17:49.50 | abhi2011 | i dont think this is a svn related problem, as I did a fresh build after clearing everything |
| 17:51.09 | brlcad | what does your function look like |
| 17:52.40 | abhi2011 | brlcad: here it is http://bin.cakephp.org/view/84589638 |
| 17:53.37 | abhi2011 | this is the test program : http://bin.cakephp.org/view/453281250 |
| 17:53.40 | brlcad | I have trouble believing that compiles without warning |
| 17:54.38 | brlcad | listen to your compiler :) |
| 17:55.17 | brlcad | the bad point failure is correct from what I see |
| 17:55.23 | brlcad | *pointer |
| 18:03.41 | abhi2011 | brlcad: I ll have a look at the warnings again :) |
| 18:09.21 | abhi2011 | ah shoot!!, missed that one among the thousand other warnings |
| 18:15.28 | brlcad | you shouldn't have any warnings in your code.... |
| 18:23.07 | abhi2011 | by the way, while building brlcad, do you generally enable strict off : cmake ../brlcad -DBRLCAD-ENABLE_STRICT=OFF -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 18:23.41 | ``Erik | leaves it at default strictness |
| 18:24.31 | abhi2011 | ok :) |
| 18:25.46 | bhinesley | abhi2011: We're supposed to leave it on. I'm running gcc 4.6, so it's been necessary for me to disable it while the compiler warnings were being dealt with; but all code should be strict compliant. |
| 18:25.57 | brlcad | strict would be very useful if we turned it off, the point is to fix the issues reported |
| 18:27.15 | abhi2011 | ok, yes I remember turning it off last month when I running on gcc 4.6.0 :P |
| 18:27.55 | bhinesley | abhi2011: should be close to working now, if not working already |
| 18:28.05 | abhi2011 | nice ! |
| 18:28.18 | bhinesley | brlcad has been working 25 hours a day on that |
| 18:28.30 | bhinesley | cracks whip |
| 18:28.36 | abhi2011 | yeah I have seen him committing all day ! |
| 18:28.42 | brlcad | jumps |
| 18:28.46 | abhi2011 | :P |
| 18:29.13 | abhi2011 | well lots of commits |
| 18:30.36 | brlcad | abhi2011: if you read the announcements from CIA-62 or join the brlcad-commits mailing list, it's easier to follow developments as they occur so you are aware what's going on and how changes might affect you |
| 18:31.17 | brlcad | the commits mailing list can be particularly educational if you read through the patches and comments, get more familiar reading code |
| 18:31.50 | brlcad | (and that's true for pretty much any dev and any project that has a commit tracker) |
| 18:31.58 | abhi2011 | yes I have been following the CIA-62 announcements, will join the brlcad-commits mailing list |
| 18:32.43 | brlcad | not just to see "oh, john has been very busy and codes day and night" .. but actually have a pretty good idea of what john is doing and why |
| 18:38.33 | ``Erik | one would hope the commit message does that, but the diff is what's really happening |
| 18:44.13 | CIA-62 | BRL-CAD: 03Sean 07http://compilefarm.net * r3068 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Lighkatwheajec|Lighkatwheajec]] ([[User talk:Lighkatwheajec|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 18:44.17 | CIA-62 | BRL-CAD: 03Sean 07http://compilefarm.net * r0 10/wiki/Special:Log/block: blocked [[User:Lighkatwheajec]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 18:47.27 | abhi2011 | yes, hoping to get commit access soon too :) |
| 19:05.14 | abhi2011 | ok I am finally past wdb_put_internal(), so rt_gettree() must always be called before rt_prep_parallel() , to load the geometry into rtip ? |
| 19:05.46 | brlcad | actually rt_gettree() should be sufficient, iirc |
| 19:05.55 | abhi2011 | ok |
| 19:06.07 | brlcad | you may have the bounding boxes computed by then |
| 19:06.49 | abhi2011 | ok, so rt_gettree() gets the tree structure for the passed object name, and attaches it to the rtip list of regions ? |
| 19:07.12 | abhi2011 | or probably marks them in rtip , that this and this will be raytraced in the future |
| 19:08.16 | ``Erik | hm, bounding volume info is generated during ft_prep() |
| 19:09.02 | abhi2011 | ok, and ft_prep() is probably called only by rt_prep() |
| 19:09.16 | ``Erik | yeh (or rt_prep_parallel() ) |
| 19:09.20 | brlcad | you'd think that |
| 19:09.23 | abhi2011 | yes |
| 19:09.26 | brlcad | but iirc, it's not |
| 19:09.43 | brlcad | don't guess, read the code |
| 19:10.03 | ``Erik | the 3 prims I looked at set st_center and friends in their _prep() funcs, rt_gettrees_muves() doesn't try to call prep on the primitives |
| 19:10.04 | brlcad | I believe you have everything you need after calling gettrees |
| 19:13.08 | brlcad | prior statement true, latter statement not so true |
| 19:16.12 | brlcad | basically, a slight nomenclature mismatch, always been the case afaicr |
| 19:16.22 | brlcad | rt_prep() and rt_prep_parallel() set up the spatial partitioning and other "preparation" activities |
| 19:16.42 | brlcad | the actual prep callbacks, however, are called before that during tree loading |
| 19:17.10 | brlcad | we consider all of that "prep time" when talking about rt, but code-wise, it's a separate step |
| 19:17.40 | ``Erik | huh, yeah, _rt_gettree_leaf() does the ft_prep |
| 19:18.19 | ``Erik | guess ya do have the primitive aabb's after rt_gettree(), just not the bvh |
| 19:18.24 | brlcad | thinks he brought a server to its knees |
| 19:18.38 | ``Erik | while(1)fork(); ? |
| 19:18.48 | brlcad | a little more insideous |
| 19:18.53 | brlcad | and unintentional |
| 19:18.55 | brlcad | actual work |
| 19:19.35 | ``Erik | g-nmg -a .00001 ? :D I oom'd a 64g box with something similar |
| 19:19.48 | brlcad | not even that far |
| 19:20.01 | brlcad | three or four big facetizations and a level 7 sphereflake output |
| 19:20.35 | ``Erik | ah, our sphflake example is level 3, right? |
| 19:20.41 | brlcad | a 0.1, two 0.01, and a default, along with sphflake |
| 19:20.50 | brlcad | something around there |
| 19:20.57 | brlcad | I've done a 7 and 8 before |
| 19:21.31 | brlcad | something like 100MB for 7, 1GB or so for 8 iirc |
| 19:22.44 | brlcad | course, could have been completely coincidental too |
| 19:22.59 | brlcad | but it's acting like a thrashed pig, a dead one at that |
| 19:25.51 | ``Erik | hm, c++ link issues with gcc 4.7, std::list stuff O.o |
| 19:32.10 | abhi2011 | ok I am trying to understand the code in tree.c, one thing I can immediately get : there is just one tree for the whole model right ? |
| 19:32.34 | abhi2011 | so rt_gettrees() can get nodes from this main tree |
| 19:32.51 | abhi2011 | which are the roots from smaller trees |
| 19:33.29 | abhi2011 | *for smaller trees I mean |
| 19:33.31 | brlcad | ``Erik: I linked with 4.7 just last week |
| 19:34.08 | brlcad | ooh, server sprung back to life! |
| 19:34.19 | ``Erik | I'm rebuilding with all local libs now, may've been a dep linked against 4.2 (this is on fbsd) |
| 19:34.32 | brlcad | hehe, load in the 50's |
| 19:35.10 | ``Erik | sphflake and the tesselations should all be single threaded... did someone do something silly and try to start a java program on it or something? O.o :D |
| 19:35.36 | CIA-62 | BRL-CAD: 03bhinesley * r45903 10/brlcad/trunk/src/libged/edit.c: flags for all 3 coordinates supplied in the "[x [y [z]]]" format were being set regardless of whether or not some of the optional coordinates were omitted |
| 19:36.32 | brlcad | probably memory, all four jobs I had running probably all wanted as much memory as they could get |
| 19:36.58 | brlcad | hm, though top seems to think there's plenty of memory, no swap in use |
| 19:37.09 | brlcad | *shrug* |
| 19:37.37 | ``Erik | http://paste.lisp.org/display/123942 |
| 19:37.49 | brlcad | aha... |
| 19:37.50 | brlcad | Program terminated with signal SIGKILL, Killed. |
| 19:38.13 | brlcad | someone intervened to bring it back to life |
| 19:38.50 | brlcad | apparently facetizing an ehy was sinking the ship |
| 19:39.51 | brlcad | ``Erik: at a glance, the GLIBCXX_3.4.15 is suspicious |
| 19:40.19 | ``Erik | yeh, considering librt links against /lib/libc.so |
| 19:40.23 | brlcad | gcc 4.7 should have come with a libc update |
| 19:41.13 | ``Erik | that librt links but things using librt don't is also surprising |
| 19:42.09 | ``Erik | hasn't really done c++ on gcc, or lately.. was almost all back on msvc1.0 and borland 4.5/5.02 |
| 19:44.21 | kunigami | does anyone know how to force cmake to find an include path? http://paste.ubuntu.com/662921/ |
| 19:47.03 | ``Erik | hm, interesting... it links against /usr/local/lib/gcc47/libstdc++.so, then runtime loads /usr/lib/libstdc++.so... might need explicit rpath info |
| 19:47.56 | brlcad | or ld_lib path set |
| 19:48.11 | brlcad | or /usr/local/lib config'd as a system lib dir before /usr/lib |
| 19:48.17 | ``Erik | yeah, my little test program worked when I gave it LD_LIBRARY_PATH |
| 19:48.31 | ``Erik | you mean /usr/local/lib/gcc47? I think /usr/local/lib is already there |
| 19:48.52 | brlcad | right |
| 19:49.52 | ``Erik | that's letting the build continue *shrug* interesting that the rpath info isn't being forced to the 'odd' library |
| 20:00.21 | CIA-62 | BRL-CAD: 03brlcad * r45904 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: revolve doesn't yet implement tessellation, but doesn't mean we should bomb. the NMG_CK checks aren't right since it's this function's job to fill them in. |
| 20:10.16 | CIA-62 | BRL-CAD: 03brlcad * r45905 10/brlcad/trunk/ (5 files in 3 dirs): revolve using sk instead of skt like extrude is just asking for trouble. make the two consistent, the same. |
| 20:13.19 | CIA-62 | BRL-CAD: 03starseeker * r45906 10/brlcad/trunk/src/other/CMakeLists.txt: |
| 20:13.20 | CIA-62 | BRL-CAD: Ah - when doing the local termlib, we have to specify that we are using the |
| 20:13.20 | CIA-62 | BRL-CAD: termcap.h header as well. Probably didn't spot this sooner because most systems |
| 20:13.20 | CIA-62 | BRL-CAD: had a system termcap.h and the BRLCAD_INCLUDE_FILE test just happened to work as |
| 20:13.20 | CIA-62 | BRL-CAD: well. |
| 20:19.47 | CIA-62 | BRL-CAD: 03brlcad * r45907 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: similarly wrong to check them for validity when we're supposed to fill them in |
| 20:20.35 | CIA-62 | BRL-CAD: 03brlcad * r45908 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: prevent tessellation from crashing on primitives that don't have a callback set (like sketch) |
| 20:27.29 | CIA-62 | BRL-CAD: 03erikgreenwald * r45909 10/brlcad/trunk/src/libged/typein.c: rt_revolve_internals sk is now skt. |
| 20:31.35 | CIA-62 | BRL-CAD: 03erikgreenwald * r45910 10/brlcad/trunk/src/libgcv/bottess.c: minor cleanup and reorg |
| 21:15.23 | abhi2011 | ok finally got the function working, testing it on regions/combinations and groups now before submitting a patch |
| 21:16.04 | kunigami | my problem was that cmake searches first on default paths. Adding NO_DEFAULT_PATH solved the problem |
| 21:21.54 | CIA-62 | BRL-CAD: 03kunigami * r45911 10/osl/trunk/osl/src/cmake/externalpackages.cmake: modified the way osl searches for external packages. we want it to seach for local libraries (that will be packed and compiled with osl) |
| 21:34.46 | starseeker | bhinesley: does that lastest commit to src/other/CMakelists.txt fix your compile issue? |
| 22:06.52 | bhinesley | applauds starseeker |
| 22:07.01 | bhinesley | works like a charm |
| 22:08.29 | bhinesley | This will be nice. No more grepping through build logs for my warnings. |
| 22:49.43 | brlcad | starseeker: vtk is the other project that came to mind that had implemented it a long while back |
| 22:50.49 | brlcad | looking at their docs, it looks like I was confusing their normal scene node sorting |
| 22:51.52 | brlcad | which, for what it's worth, is all we'd probably every want anytime soon anyways since depth peeling is relatively-speaking very expensive |
| 22:52.54 | brlcad | basically cuts performance by about an order .. which may be fine and dandy when your fps would have been 100+ .. but not when it's <1 fps |
| 22:53.08 | brlcad | http://www.vtk.org/Wiki/VTK/Depth_Peeling |
| 22:54.57 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:55.33 | brlcad | looks like there was/is a related ogre gsoc project this year |
| 22:56.49 | ``Erik | wishes ogre had a decent C interface for FFI O.o |
| 23:00.31 | abhi2011 | I am getting a strange error when I try to start Mged, after I shifted BRL-CAD from the default installation location at /usr/brlcad |
| 23:00.49 | abhi2011 | its now in /home/abhi/brlcad and is a debug build |
| 23:01.10 | abhi2011 | however when mged starts up its not able to find helplib.tcl and so cant start the gui |
| 23:02.44 | abhi2011 | I wonder how it knew previously to look in /usr/brlcad/share/brlcad/7.20.3/tclscripts |
| 23:03.25 | abhi2011 | there should be a configuration for mged which I am missing i think |
| 23:09.50 | bhinesley | abhi2011: with a debug build, you can run mged right from the build directory, without installing |
| 23:12.25 | bhinesley | much faster compile/dbug cycle that way anyways |
| 23:12.34 | bhinesley | *debug |
| 23:14.14 | abhi2011 | bhinesley: I tried that too just now, so I am in brlcad-build, I cd into bin and mged |
| 23:14.20 | abhi2011 | but the same error persists |
| 23:14.47 | bhinesley | what options are you building with |
| 23:15.18 | abhi2011 | cmake ../brlcad -DBRLCAD-ENABLE_STRICT=OFF -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 23:15.37 | bhinesley | actually, I'm getting the same error |
| 23:16.01 | abhi2011 | is it after a recent checkout ? |
| 23:16.38 | abhi2011 | the error is from mged.c |
| 23:16.43 | bhinesley | yes, recent checkout |
| 23:18.44 | bhinesley | yeah, it's looking in the wrong directory. changing to /home/bhinesley/brlcad-trunk/build/cmake/share/brlcad/7.20.3/tclscripts/geometree and then running ../../../../../bin/mged works |
| 23:19.44 | bhinesley | since ../helplib.tcl is correct if the CWD is geomtree |
| 23:20.10 | abhi2011 | the cmake changes wouldnt have a effect would it |
| 23:20.30 | bhinesley | I'm not sure, but it does sound like a job for starseeker |
| 23:20.43 | bhinesley | puts hand above brow and looks to the clouds |
| 23:20.53 | abhi2011 | :) |
| 23:22.41 | bhinesley | starseeker: archer isn't launching from build dir either: no files matched glob pattern "*.html" |
| 23:23.46 | abhi2011 | yes ../../../../../bin/mged works for me too |
| 23:58.13 | abhi2011 | brlcad: can we expect the librt bb function rt_bound_dbfullpath(struct rt_db_internal *ip, point_t *rpp_min, point_t *rpp_max) , to work only on primitives |
| 23:59.10 | abhi2011 | or should I expect the user to pass in regions or groups as well, in which I can iterate through the region's or group's constituent primitives |