| 00:46.48 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 01:13.14 | raj12lnm | kanzure: yes. |
| 01:13.50 | raj12lnm | But this error is generated in a different fashion. But looks like a similar error. |
| 01:14.50 | raj12lnm | Just checkout my branch master/dsp_primitive and run test_wdb.py |
| 01:15.03 | raj12lnm | Also I have pastes the back trace. |
| 01:19.47 | kanzure | am not sure at the moment, sorry |
| 01:20.31 | raj12lnm | kanzure: just to confirm do you find the same error? I mean are you able to reproduce ? |
| 01:25.04 | kanzure | haven't tried |
| 01:25.26 | raj12lnm | kanzure: will you please look at it later. |
| 01:25.43 | raj12lnm | I am not able to find a way out. |
| 01:26.37 | raj12lnm | And there are very few people in this universe with the understanding of brlcad-c repository and pytho-brlcad as you do ;-) |
| 01:27.25 | raj12lnm | The issue is as follows:- |
| 01:28.02 | raj12lnm | 1. Since mk_dsp doesn't have enough parameters. |
| 01:28.04 | ``Erik | texture mapped raycaster in 128 bytes http://www.pouet.net/prod.php?which=63518 |
| 01:29.11 | raj12lnm | 2. Therefore to wrapp a DSP primitive I use the similar approach as in dsp_in_v5 func in libged/type in.x |
| 01:29.35 | raj12lnm | (typein.c) |
| 01:29.56 | kanzure | raj12lnm: today i have been working with this library, https://github.com/dcowden/cadquery |
| 01:30.10 | kanzure | raj12lnm: http://parametricparts.com/docs/examples.html#polylines |
| 01:30.16 | kanzure | (i like this API a lot) |
| 01:30.26 | raj12lnm | 3. But on testing I find that there is a null pointer while freeing. |
| 01:33.55 | raj12lnm | Ok. |
| 01:35.27 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 01:36.32 | raj12lnm | just had a look at the api |
| 01:38.16 | raj12lnm | kanzure: looks good. |
| 01:38.51 | kanzure | i was thinking of implementing python-brlcad as a backend for cadquery, but not many of the api concepts hook up |
| 01:38.56 | kanzure | so it will require lots of glue |
| 01:41.31 | raj12lnm | kanzure: my understanding to CAD tools is very limited. |
| 01:42.02 | raj12lnm | In fact it is limited to my GSoC work. |
| 01:42.29 | kanzure | well, to be fair, i don't know what a "dsp" primitive is or why i would want it :) |
| 01:43.21 | raj12lnm | It is displacement map. |
| 01:43.29 | kanzure | hmm |
| 01:43.46 | raj12lnm | You could find information on brlcad.org/wiki/DSP |
| 01:44.07 | kanzure | is it raster or vector? the page doesn't make this clear. |
| 01:44.13 | raj12lnm | Even I didn't have a clue before 4 days. |
| 01:44.19 | kanzure | it looks like it must be raster because the input is raster data |
| 01:45.11 | raj12lnm | Hmm |
| 01:45.35 | raj12lnm | But the input is converted to a DSP file. |
| 01:45.44 | kanzure | ok |
| 01:45.53 | raj12lnm | Looked vector to me when created using mged. |
| 01:46.16 | raj12lnm | is not sure, though |
| 01:46.56 | kanzure | the resolution of the object has to be limited by the resolution of the input data |
| 01:47.17 | raj12lnm | kanzure: so if you just checkout my branch and run the test you will find the error. |
| 01:47.33 | raj12lnm | Its a strange error. |
| 01:50.10 | kanzure | AttributeError: 'module' object has no attribute 'RT_HRT_INTERNAL_MAGIC' |
| 01:50.13 | kanzure | i think it's just a version error |
| 01:50.41 | raj12lnm | kanzure: I think its a different error. |
| 01:50.57 | raj12lnm | I get a different error. |
| 01:55.45 | *** join/#brlcad raj12lnm_ (70c4054a@gateway/web/freenode/ip.112.196.5.74) |
| 02:00.44 | raj12lnm_ | kanzure : I get the following error |
| 02:00.45 | raj12lnm_ | ERROR: bad pointer 0xb74b0060: s/b bu_mapped_file(x4d617066), was Unknown_Magic(x308), file /home/mohit/brlcad/src/librt/primitives/dsp/dsp.c, line 4586 |
| 02:04.06 | kanzure | hmm |
| 02:17.43 | raj12lnm | hope that you are able to produce the same. |
| 02:40.25 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 03:02.31 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 03:43.53 | *** join/#brlcad teepee_ (~teepee@gateway/tor-sasl/teepee) |
| 03:50.21 | starseeker | raj12lnm: do you have a backtrace? |
| 03:50.33 | starseeker | it would help to know how we got to that crash |
| 03:51.16 | raj12lnm | <PROTECTED> |
| 03:52.17 | starseeker | what are you using for displacement map data? |
| 03:53.09 | raj12lnm | Ex1.dsp used the same way as illustrated on brlcad.org/wiki/DSP |
| 03:53.44 | starseeker | and it works as expected in MGED? |
| 03:54.31 | raj12lnm | Yes. |
| 03:54.41 | starseeker | erm |
| 03:55.28 | raj12lnm | starseeker: you must have noted the issue is caused while freeing the dsp-data from dB. |
| 03:55.29 | starseeker | does the MGED keep command have any problems? |
| 03:55.42 | starseeker | yes - the question is how the bad pointer got there in the first place |
| 03:56.40 | starseeker | would suggest triggering a wdb_export purely in C - by writing a small test program, if necessary - to try and isolate the issue |
| 03:56.57 | starseeker | keep might do it, but if not you can construct a test |
| 03:57.58 | starseeker | another thing to do might be to step through the logic that creates the dsp in a C debugger and see what is changed when with regards to that pointer |
| 03:58.42 | raj12lnm | starseeker: did you glance through the python code? |
| 03:58.56 | raj12lnm | That is doing exactly the sane thing. |
| 04:03.16 | Notify | 03BRL-CAD:starseeker * 61381 (brlcad/branches/gecode/src/other/gecode/Makefile.in =================================================================== and 1949 others): Need the Makefile.in file |
| 04:06.33 | *** join/#brlcad mihaineacsu (~mihaineac@92.85.193.175) |
| 04:11.14 | raj12lnm | starseeker: is there a command in mged to free an object. |
| 04:14.30 | *** join/#brlcad Zhao_Anqing (~clouddrif@183.157.160.28) |
| 04:15.58 | raj12lnm | Or remove it :-) |
| 04:21.09 | brlcad | raj12lnm: "kill [object]" |
| 04:28.19 | raj12lnm | brlcad: I get this strange error with DSP. |
| 04:40.27 | raj12lnm | starseeker: and brlcad can you explain me which part of code is executed when wdb_export is triggered ? |
| 04:47.12 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 05:14.50 | *** join/#brlcad alisha (~alisha@202.164.53.117) |
| 05:32.54 | *** join/#brlcad amitt (~amitt@202.164.53.117) |
| 05:40.57 | *** join/#brlcad alisha (~alisha@202.164.53.117) |
| 05:46.54 | *** join/#brlcad amitt (~amitt@202.164.53.117) |
| 06:35.10 | *** join/#brlcad amitt (~amitt@49.138.214.80) |
| 06:37.46 | *** join/#brlcad amittbhardwj (~amitt@49.138.214.80) |
| 06:46.19 | *** join/#brlcad hsrai_ (~hsrai@49.138.214.80) |
| 06:51.38 | *** join/#brlcad hsrai__ (~hsrai@49.138.214.80) |
| 06:54.19 | *** join/#brlcad hsrai_ (~hsrai@49.138.214.80) |
| 07:06.51 | *** join/#brlcad andrei_ (~IceChat77@188.25.27.146) |
| 07:07.23 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 07:12.54 | Notify | 03BRL-CAD Wiki:14.98.254.161 * 7363 /wiki/User:Shainasabarwal/GSoC14/logs: /* Week 5 */ |
| 07:35.12 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 07:56.43 | *** join/#brlcad luca79 (~luca@net-2-34-208-72.cust.vodafonedsl.it) |
| 08:10.59 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 08:50.21 | *** join/#brlcad oana_ (~oana@188.209.97.130) |
| 09:03.25 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 09:56.15 | *** join/#brlcad vladbogo (~vlad@195.216.218.10) |
| 09:59.39 | *** join/#brlcad vladbogo_ (~vlad@195.216.218.10) |
| 10:06.37 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 10:14.20 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7364 /wiki/User:Popescu.andrei1991/devlogs2014: /* Week 6 */ |
| 11:13.35 | *** join/#brlcad Inderjeet_Singh (~Inderjeet@117.234.199.138) |
| 11:17.39 | *** part/#brlcad Inderjeet_Singh (~Inderjeet@117.234.199.138) |
| 11:51.56 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 12:24.45 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 13:01.00 | Notify | 03BRL-CAD:ejno * 61382 brlcad/trunk/src/conv/3dm/3dm-g.cpp: cleanups |
| 13:01.57 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 13:32.40 | *** join/#brlcad Zhao_Anqing (~clouddrif@183.157.160.17) |
| 13:40.03 | Notify | 03BRL-CAD:starseeker * 61383 brlcad/trunk/AUTHORS: Add Gustav Granroth to the code contributors in AUTHORS for his work on Windows parallel support. |
| 13:44.31 | Notify | 03BRL-CAD:starseeker * 61384 brlcad/branches/gecode/src/libpc/CMakeLists.txt: Add a basic gecode example, with an eye towards morphing it into something that can do the libpc solver test examples. |
| 13:57.25 | brlcad | kanzure: very interesting api link you shared (parametricparts) ... I like it! |
| 13:57.46 | brlcad | would be really interesting to see 1) an mged version of that and 2) a python-brlcad version of that ;) |
| 13:58.39 | kanzure | so, one of the concepts in cadquery is iterating over vertices, edges, wires (lists of edges, ick), faces/surfaces |
| 13:58.45 | kanzure | i am not sure if that is compatible with brlcad |
| 13:59.22 | kanzure | or if i could coerce that into compatibility somehow |
| 14:02.56 | Notify | 03BRL-CAD:carlmoore * 61385 (brlcad/trunk/doc/parsers/templates/main.c brlcad/trunk/doc/parsers/templates/parser.lemon brlcad/trunk/doc/parsers/writing_perplex_lemon_parsers.txt): remove a trailing blank, and fix spellings |
| 14:08.40 | Notify | 03BRL-CAD:starseeker * 61386 (brlcad/trunk/src/libbrep/CMakeLists.txt brlcad/trunk/src/librt/CMakeLists.txt): Disable the fit testing code again - it served its immediate purpose, and it's now clear we'll need to implement the full Eck/Hoppe approach to make this work. Keeping this code because pieces of it will likely be quite helpful when we get there |
| 14:10.04 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 14:21.34 | brlcad | vladbogo_: you get an answer about open_existing? |
| 14:21.35 | vladbogo_ | brlcad: no |
| 14:22.11 | vladbogo_ | can you tell me your opinion |
| 14:25.50 | brlcad | kanzure: which API concepts don't hook up? we should/can make them hook up |
| 14:26.42 | kanzure | brlcad: iterating over edges of a shape? |
| 14:27.03 | brlcad | oops |
| 14:27.04 | brlcad | nd yes, dsp is raster .. it's basically a height field entity (but we already had an old primitive named that, so the author picked a different name) |
| 14:27.58 | vladbogo_ | brlcad: I was thinking about creating a new header for the framebuffer and to declare the open_existing function there. |
| 14:28.06 | kanzure | for example, here's a limmrick in cadquery, |
| 14:28.07 | kanzure | result = result.faces(">Z").vertices("<XY").workplane() #select the lower left vertex and make a workplane |
| 14:28.10 | kanzure | result = result.circle(1.0).cutThruAll() #cut the corner out |
| 14:28.26 | vladbogo_ | what do you think? |
| 14:28.59 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:30.28 | kanzure | or this example: outer_shell.edges("#Z").fillet(p_topAndBottomRadius) |
| 14:30.58 | kanzure | i haven't done work in brlcad based on selecting edges like that |
| 14:31.03 | kanzure | is that doable? |
| 14:49.26 | *** join/#brlcad user_name (~hsrai@202.164.53.122) |
| 14:55.53 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 15:02.17 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:09.26 | *** join/#brlcad user_name (~hsrai@202.164.53.122) |
| 15:09.40 | *** join/#brlcad alisha (~alisha@115.184.74.197) |
| 15:10.34 | *** join/#brlcad amittbhardwj (~amittbhar@117.214.207.125) |
| 15:25.01 | d_rossberg | vladbogo_: as far as i understood ~_open existing are defined in libfb and used in libdm and mged, therefore the prototype has to be in a public header |
| 15:27.41 | vladbogo_ | d_rossberg: you are right, _open_existing are declared in fb.h and defined in libfb |
| 15:28.53 | vladbogo_ | the problem is that all framebuffers use the same fb.h and that there isn't a generic _open_existing prototype (I don't think it's possible quite easy to do one) |
| 15:30.40 | d_rossberg | that's right, but to change this the frame buffer logic in general had to be changed, this is probable the todo |
| 15:31.06 | vladbogo_ | so when adding the _qt_open_existing which has to have some Qt specific arguments some conflicts appear since the fb.h is used in all other fb's |
| 15:31.35 | d_rossberg | so, if you implement only a new frame buffer type you should do it analogous to the existing ones |
| 15:32.33 | *** join/#brlcad alisha (~alisha@115.244.15.40) |
| 15:32.51 | d_rossberg | what kind of conflict? (which symbol?) |
| 15:33.11 | vladbogo_ | <PROTECTED> |
| 15:34.17 | d_rossberg | unfortunately i've to go in a minute :( |
| 15:35.59 | vladbogo_ | I'm not currently at the computer where I have modified the code and it's not accessible so I have to do the changes now and wait to compile |
| 15:36.59 | d_rossberg | ok, i'll be back tomorrow (now i've to hurry to get my bus) |
| 15:37.08 | vladbogo_ | ok |
| 15:37.52 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:40.56 | *** join/#brlcad cwstirk (~charlie@c-24-9-78-79.hsd1.co.comcast.net) |
| 15:51.17 | *** join/#brlcad piyushparkash (~piyushpar@59.91.251.131) |
| 16:03.18 | Notify | 03BRL-CAD:brlcad * 61387 brlcad/trunk/src/libbu/mappedfile.c: make sure the mapped file pointer is not null before checking it, otherwise we don't need to do anything. doesn't need to be a halting condition. |
| 16:03.50 | Notify | 03BRL-CAD:starseeker * 61388 (brlcad/trunk/include/raytrace.h brlcad/trunk/src/librt/db_fullpath.c brlcad/trunk/src/librt/search.c): Rework the matrix handling a bit - I believe this addresses the memory loss reported by valgrind. Key was to not have the assignment macro for the matrix blindly malloc - needed to see if matrix memory had already been set first. |
| 16:04.07 | Notify | 03BRL-CAD:brlcad * 61389 brlcad/trunk/src/librt/primitives/dsp/dsp.c: bu_close_mapped_file() already checks the pointer |
| 16:06.20 | Notify | 03BRL-CAD:brlcad * 61390 brlcad/trunk/src/librt/primitives/dsp/dsp.c: couple more unnecessary mapped file checks |
| 16:07.16 | brlcad | raj12lnm: sorry belated reply .. wdb_export is called whenever an object is modified |
| 16:08.00 | raj12lnm | brlcad: that I understand. |
| 16:08.03 | brlcad | kanzure: that is compatible with our sketch and brep objects .. especially the latter, constructed the same way |
| 16:08.32 | brlcad | vladbogo_: open_existing should be added as a new callback into the fb callback table |
| 16:09.08 | raj12lnm | brlcad: but the issue are too many primitives and one function takes care of all. |
| 16:09.11 | brlcad | right now, those are implementation-specific functions that are declared, which makes the calling code (e.g., mged's front-end code) need to include all the right headers and such to use it |
| 16:09.19 | brlcad | instead of being encapsulated entirely by libfb |
| 16:09.34 | kanzure | brlcad: so, only the sketch and brep objects? in particular i am wondering about the other primitives. |
| 16:09.48 | kanzure | brlcad: for example, a circle |
| 16:10.08 | brlcad | kanzure: we're also working on exposing similar entities for all of our implicit primitives, so if you have an arb8 (box) for example, you can actually get at each edge and vertex in an automatic programmable fashion |
| 16:10.34 | kanzure | where is that function/tool to do that? |
| 16:10.45 | raj12lnm | brlcad: the issue is each export frees the internal dB. |
| 16:10.53 | kanzure | the exposing part doesn't matter much to me; i can just hook into the underlying library rather than libged |
| 16:10.57 | raj12lnm | And I don't understand why it fails. |
| 16:11.33 | brlcad | kanzure: all of freecad is basically our single "brep" object |
| 16:11.52 | brlcad | they only have one entity, a boundary representation |
| 16:11.56 | kanzure | freecad is opencascade... has way more than breps :) |
| 16:12.07 | brlcad | not really |
| 16:12.21 | brlcad | I mean, it is opencascade, that goes hand in hand |
| 16:12.25 | kanzure | see "gce - " on http://diyhpl.us/wiki/cad/opencascade/ |
| 16:12.46 | *** join/#brlcad raj12lnm_ (70c4054a@gateway/web/freenode/ip.112.196.5.74) |
| 16:13.07 | raj12lnm_ | brlcad : it gives this error |
| 16:13.08 | raj12lnm_ | ERROR: 0x507 mis-aligned bu_mapped_file pointer, file /home/raj/brlcad/src/librt/primitives/dsp/dsp.c, line 4586 |
| 16:13.36 | raj12lnm | This is while freeing the internal dB. |
| 16:13.49 | starseeker | brlcad: I think vladbogo_ left before he saw your reply |
| 16:14.02 | brlcad | opencascade is a brep modeling kernel, even their basic entities (boxes, cones, cylinders, etc) are represented in brep form |
| 16:14.09 | kanzure | brlcad, is that edge/vertex data that is "going to be exposed" already availble in librt somewhere? |
| 16:14.37 | starseeker | kanzure: that's a work in progress... |
| 16:14.42 | *** join/#brlcad alisha (~alisha@101.58.204.117) |
| 16:14.51 | kanzure | he said the exposing is a work in progress; what about the stuff-to-be-exposed? |
| 16:14.56 | brlcad | kanzure: it's exposed for our brep and sketch entities :) |
| 16:15.06 | brlcad | the other primitives are a work in progress |
| 16:15.33 | brlcad | brep exposure is the opennurbs API (really the ON_Brep portion of the API) |
| 16:16.07 | brlcad | sketch is the same entities that andrei is currently wrapping for our OO kernel |
| 16:16.41 | Notify | 03BRL-CAD:ejno * 61391 brlcad/trunk/src/conv/3dm/3dm-g.cpp: always make imported geometry names BRL-CAD compliant |
| 16:16.51 | brlcad | raj12lnm: that's not nearly enough information to help .. it looks like you probably have uninitialized data |
| 16:17.19 | brlcad | and/or a mapped file that didn't get set up correctly (so random data) and is causing havoc when it gets deleted |
| 16:17.40 | brlcad | raj12lnm: I just changed some of those checks -- svn up, compile, and see if it makes any difference |
| 16:17.45 | brlcad | probably won't but easy to try |
| 16:18.03 | brlcad | raj12lnm: where is the rt_dsp_internal coming from? who made it? |
| 16:18.37 | raj12lnm_ | i mean rt_db_internal |
| 16:18.56 | raj12lnm_ | I can give you the backtrace. |
| 16:19.25 | brlcad | kanzure: oh, also our NMG primitive is exposed that same way with vertices, edges, faces, "wires" (loops), shells, and solids |
| 16:19.40 | kanzure | can't i just bypass the primitives? |
| 16:19.47 | kanzure | do i have to use primitives? |
| 16:19.51 | brlcad | raj12lnm_: I already saw your backtrace, but that doesn't say where the object came from |
| 16:20.39 | brlcad | kanzure: you can if you stick strictly to brep |
| 16:20.49 | brlcad | or strictly to sketches or nmg .. but all three are completely different constructions conceptually |
| 16:21.18 | brlcad | sketchs are purely 2D and in theory will translated 100% to brep but that mapping hasn't been made |
| 16:21.28 | raj12lnm_ | this is how the object is created http://tny.cz/71ee65e79 |
| 16:21.57 | brlcad | nmg vs brep however is a different beast .. you could similarly map any nmg to brep, but not any brep to nmg (nmg are polygonal brep) |
| 16:22.41 | brlcad | raj12lnm_: well there ya go! |
| 16:23.07 | brlcad | raj12lnm_: what does /home/raj/brlcad/src/librt/primitives/dsp/dsp.c, line 4586 say? :) |
| 16:23.20 | *** join/#brlcad piyushparkash (~piyushpar@59.91.251.131) |
| 16:24.28 | raj12lnm_ | ?? |
| 16:24.33 | raj12lnm_ | what does it sat > |
| 16:24.40 | brlcad | you tell me |
| 16:24.49 | brlcad | what is that line of code? |
| 16:25.59 | raj12lnm_ | yeah you must be wondering that mapped file dsp_mp is not initialized. |
| 16:26.05 | brlcad | starseeker: 61388 doesn't look at all right |
| 16:26.12 | raj12lnm_ | it says this "BU_CK_MAPPED_FILE(dsp_ip->dsp_mp);" |
| 16:26.28 | brlcad | raj12lnm_: I'm not wondering, I see it's not initialized in the initialization code you posted |
| 16:26.52 | brlcad | it's accessing dsp_ip->dsp_mp .. which you never initialize/set |
| 16:26.53 | raj12lnm_ | brlcad : so it is not initiatialized in the typein.c file. |
| 16:27.28 | raj12lnm_ | also it is not not initialized in mk_dsp |
| 16:27.53 | raj12lnm_ | so i (presume) that the mapped file has to do something with the internal structure. |
| 16:28.10 | raj12lnm_ | and some other part of code does it (not sure which, couldnot find) |
| 16:28.29 | brlcad | raj12lnm_: au contraire .. BU_ALLOC() zero-initializes a structure |
| 16:29.06 | raj12lnm_ | brlcad : I know english only ;) |
| 16:29.11 | brlcad | it could/shoult have manually initialized the dsp_mp field and any others, but it's technically not needed |
| 16:29.15 | raj12lnm_ | cta.brlcad_new(libwdb.struct_rt_dsp_internal) but this i am sure also does |
| 16:29.30 | Notify | 03BRL-CAD:starseeker * 61392 (brlcad/branches/gecode/AUTHORS brlcad/branches/gecode/doc/CMakeLists.txt and 14 others): Sync through trunk r61391 |
| 16:29.31 | brlcad | raj12lnm_: that means "on the contrary" |
| 16:29.52 | Notify | 03BRL-CAD:starseeker * 61393 (brlcad/branches/openscenegraph/AUTHORS brlcad/branches/openscenegraph/doc/CMakeLists.txt and 14 others): Sync through trunk r61391 |
| 16:30.03 | brlcad | I wouldn't be so sure because uninitialized data is exactly what you're looking at in that stack trace |
| 16:30.04 | Notify | 03BRL-CAD:starseeker * 61394 (brlcad/branches/bullet/AUTHORS brlcad/branches/bullet/doc/CMakeLists.txt and 34 others): Sync through trunk r61391 |
| 16:30.07 | brlcad | malloc vs calloc |
| 16:30.22 | brlcad | what does brlcad_new do? |
| 16:30.47 | kanzure | i do not like that name |
| 16:30.53 | raj12lnm_ | ok :) |
| 16:30.53 | raj12lnm_ | malloc. |
| 16:30.56 | raj12lnm_ | so you i will zero initialize it. |
| 16:31.15 | brlcad | starseeker: what doesn't look right about it is the "char **" .. there's not character arrays involved anywhere so that's not the right type |
| 16:31.38 | brlcad | kanzure: you get really used to it after about 10 years ;) |
| 16:32.05 | brlcad | I found it quite annoying too, digital signal processing, damnits |
| 16:32.11 | kanzure | i mean brlcad_new |
| 16:32.14 | brlcad | ahh |
| 16:32.15 | kanzure | but yes dsp is also a bad name |
| 16:32.15 | brlcad | heh |
| 16:33.02 | brlcad | yeah, brlcad_new seems unnecessary .. it's just allocating - what's specific to brlcad about that? |
| 16:33.21 | kanzure | i don't like all the weird memory management stuff going on here |
| 16:33.30 | kanzure | isn't brlcad supposed to do that under the hood |
| 16:33.39 | kanzure | there shouldn't have to be malloc/calloc calls in python |
| 16:33.53 | kanzure | that's very much a code smell |
| 16:36.11 | raj12lnm | kanzure: yeah it is. |
| 16:36.44 | raj12lnm | And trust me without brlcad's help I could not have found the issue. |
| 16:37.25 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 16:39.18 | *** join/#brlcad alisha (~alisha@101.62.209.145) |
| 16:43.16 | brlcad | kanzure: I know nothing about how or why that is set up the way it is other than I believe he's wrapping libwdb API and some of the API does expose additional structures |
| 16:44.09 | brlcad | but that wouldn't explain the dsp case |
| 16:44.24 | brlcad | mk_dsp() does take care of it all for you |
| 16:49.24 | Notify | 03BRL-CAD:brlcad * 61395 brlcad/trunk/src/conv/3dm/3dm-g.cpp: 3dm-g is not documented (gah, it should be), so we don't need to take the flag through deprecation (it's probably minimally impacting too). just remove it. |
| 16:53.11 | *** join/#brlcad ishwerdas (~ishwerdas@117.212.54.152) |
| 16:54.50 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 16:56.03 | Notify | 03BRL-CAD:starseeker * 61396 brlcad/trunk/src/tclscripts/lib/gui_conversion.tcl: Take the BRL-CAD compliant names option out of the Archer dialog for 3dm-g |
| 16:56.28 | *** join/#brlcad alisha (~alisha@101.62.209.145) |
| 16:57.44 | *** join/#brlcad vladbogo (~chatzilla@5-12-239-156.residential.rdsnet.ro) |
| 17:01.19 | Notify | 03BRL-CAD:brlcad * 61397 brlcad/trunk/src/libged/typein.c: rework dsp initialization to clearly initialize all struct fields (for v5 and v4) instead of relying on zero-init from BU_ALLOC. |
| 17:08.27 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 17:21.30 | *** join/#brlcad alisha (~alisha@115.245.190.79) |
| 17:36.34 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 17:39.25 | Notify | 03BRL-CAD:indianlarry * 61398 brlcad/trunk/src/librt/primitives/brep/brep.cpp: In poly2tri_CDT() for trims that are at surface singularity assume trim definitions are correct and generate UV sample points using delta calculated from fraction of trim length. Needed to use trim parameter space not UV. |
| 17:44.23 | Notify | 03BRL-CAD:n_reed * 61399 brlcad/trunk/src/tclscripts/rtwizard/rtwizard: Something about r61095 broke raytracing via the render button in Archer by causing fblabel's call to vfont_get fail. Rtwizard assumed the error was from the port being in use, and its subsequent behavior left things in a bad state. Work around the problem by having rtwizard check the fblabel error code to ensure failure is from fb_open, not |
| 17:44.25 | Notify | vfont_get. |
| 18:01.37 | *** join/#brlcad piyushparkash (~piyushpar@117.205.66.59) |
| 18:02.32 | *** join/#brlcad pandrei (~pandrei@188.26.186.183) |
| 18:10.13 | kanzure | is there a difference between breps denoted by BRep and those breps denoted by Brep in brlcad? |
| 18:10.32 | kanzure | like ON_Brep vs STEP_Empty_BRep |
| 18:11.15 | kanzure | i suspect that the interesting parts of librt.ON_Brep are not available in python-brlcad because those portions are C++ :( |
| 18:14.39 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 18:43.53 | raj12lnm | kanzure: brlcad I have added a calloc option to brlcad new |
| 18:44.03 | raj12lnm | Now its not fishy anymore. |
| 18:44.21 | raj12lnm | Brlcad mk_dsp needs restructuring |
| 18:44.30 | raj12lnm | thinks so. |
| 18:45.28 | raj12lnm | Because with the current set-up one cannot specify certain parameters used in mged. |
| 18:55.13 | Notify | 03BRL-CAD Wiki:Krajkreddy * 7365 /wiki/User:Krajkreddy/GSOC14/summary: /* Week6 */ |
| 18:55.23 | Notify | 03BRL-CAD Wiki:Albertcoder * 7366 /wiki/User:Albertcoder/GSoC2014/logs: /* Week 6 */ |
| 18:56.44 | raj12lnm | brlcad: also as notified earlier metaball has a bug. And it could be resolved by patch 278 on sf. |
| 18:56.58 | raj12lnm | Please see this when you get time. |
| 18:57.15 | Notify | 03BRL-CAD:ejno * 61400 brlcad/trunk/src/conv/3dm/3dm-g.cpp: fix duplicate creation of instance references; remove redundant casts |
| 18:59.36 | kanzure | hmm python-brlcad doesn't wrap opennurbs because it's c++ :( |
| 19:00.29 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 19:14.41 | *** join/#brlcad luca79 (~luca@net-2-34-208-72.cust.vodafonedsl.it) |
| 19:32.39 | Notify | 03BRL-CAD:carlmoore * 61401 brlcad/trunk/src/util/mac-pix.c: no change in software; just rearrange the order of the 'case' statement regarding program options |
| 19:35.50 | Notify | 03BRL-CAD:bob1961 * 61402 brlcad/trunk/src/tclscripts/lib/RtImage.tcl: This fixes pid_wait which was breaking the rtwizard/rtimage functionality on windows (i.e., the edge drawing and ghosting were not working). |
| 19:42.39 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 19:47.54 | Notify | 03BRL-CAD:carlmoore * 61403 brlcad/trunk/doc/docbook/system/man1/en/mac-pix.xml: supply description for -x,-y,-X,-Y |
| 20:00.49 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 20:13.50 | Notify | 03BRL-CAD:n_reed * 61404 (brlcad/branches/brep-debug/AUTHORS brlcad/branches/brep-debug/doc/CMakeLists.txt and 16 others): sync from trunk through r61403 |
| 20:18.20 | Notify | 03BRL-CAD Wiki:Vladbogolin * 7367 /wiki/User:Vladbogolin/GSoC2014/Midterm: Created page with "=Embedding a framebuffer window= In the past month I started working at the Embedding a framebuffer window project. Like last year, I was really excited about participating i..." |
| 20:20.03 | Notify | 03BRL-CAD Wiki:Vladbogolin * 7368 /wiki/User:Vladbogolin/GSoC2014/Logs: /* Week 6 */ |
| 20:32.49 | ankesh11 | Is it okay to put the blog post on my own blog or should I use the wiki? |
| 20:33.04 | ankesh11 | (For GsoC Midterm Evaluations) |
| 20:35.14 | ``Erik | ankesh11: that's probably up to your mentor... we've had people use their own blogs in the past (with the necessary link in the wiki so it could be found) |
| 20:36.25 | ankesh11 | Alright. |
| 20:38.31 | ``Erik | you could always just use your blog, make the link in the wiki, then if someone asks you to put it in the wiki instead, it's just cut&paste, right? :) |
| 20:48.19 | ankesh11 | Yeah. That should be okay, will get onto it. |
| 20:50.38 | brlcad | your own blog with a link in your dev log is even preferred |
| 20:51.31 | brlcad | raj12lnm: what certain parameters? mk_dsp() can be changed |
| 20:53.08 | Notify | 03BRL-CAD:carlmoore * 61406 (brlcad/trunk/doc/docbook/system/man1/en/nastran-g.xml brlcad/trunk/src/conv/nastran-g.c): remove duplication in man page; add -xX to man page; add run-with-no-arguments for getting help |
| 20:53.08 | brlcad | kanzure: tthey both stand for "boundary representation" so you'll find the term "brep" in a number of contexts |
| 20:53.16 | Notify | 03BRL-CAD:n_reed * 61405 brlcad/branches/brep-debug/src/libged/brep.c: need to initialize counts prior to parsing and copy them to main info struct afterwards |
| 20:53.53 | kanzure | but why is it capitalied in one but not hte other |
| 20:53.54 | kanzure | *the |
| 20:53.55 | brlcad | it's the intrinsic format of most commercial CAD systems |
| 20:53.59 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 20:54.05 | kanzure | that wasn't what i was asking.. |
| 20:54.17 | kanzure | BRep and Brep have different capitalization |
| 20:54.45 | brlcad | yes, because it's different people mashing those two words in different ways |
| 20:55.00 | brlcad | you might even encounter B-Rep or BREP or ... |
| 20:55.41 | kanzure | i suggest picking a project standard and sticking to it |
| 20:55.42 | brlcad | in terms of code ON_Brep has no relation to STEP_Empty_BRep other than they both represent or do something with boundary representation geometry |
| 20:56.00 | brlcad | ON_Brep is openNURBS API |
| 20:56.13 | brlcad | STEP_Empty_BRep is almost certainly generated via the STEP standard |
| 20:57.51 | brlcad | i.e., two completely different, massive entities with their own interests and conventions |
| 20:58.56 | brlcad | we might be able to change STEP_Empty_BRep but I suspect that is auto-generated directly from the ISO schema, and merely presented through the SDAI binding interface |
| 20:59.09 | brlcad | i.e., it must be spelled that way per the STEP standard |
| 20:59.29 | kanzure | i believe there are other cases that aren't from the SDAI bindings unrelated to STEP that are using the inconsistent capitalization |
| 21:02.00 | brlcad | well there's nominally at least our C API which should be using "brep" in function names and struct elements because our naming style is lowercase for all those elements |
| 21:02.16 | Notify | 03BRL-CAD:n_reed * 61407 brlcad/branches/brep-debug/src/libged/brep.c: private functions don't need lib prefix |
| 21:02.19 | brlcad | and there's the C++ portions, which are heavily influenced by ON_Brep from openNURBS API |
| 21:02.45 | brlcad | and there's dev comments which probably span the gamut but are irrelevant because they're comments |
| 21:03.03 | brlcad | if you see a case worth fixing, point it out |
| 21:04.13 | Notify | 03BRL-CAD:ejno * 61408 brlcad/trunk/src/conv/3dm/3dm-g.cpp: simplify operations on the layer maps |
| 21:04.36 | Notify | 03BRL-CAD:starseeker * 61409 (brlcad/trunk/include/raytrace.h brlcad/trunk/include/rt/CMakeLists.txt): Not (yet) a properly fleshed out sub-include, but for readability break db_fullpath components out of raytrace.h |
| 21:05.04 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 21:05.44 | Notify | 03BRL-CAD:starseeker * 61410 brlcad/trunk/include/rt/db_diff.h: Add db_diff wrapper |
| 21:07.46 | Notify | 03BRL-CAD:brlcad * 61411 (brlcad/trunk/include/bu/vfont.h brlcad/trunk/src/libbu/vfont.h): use the right header guard prefix |
| 21:12.34 | Notify | 03BRL-CAD:n_reed * 61412 brlcad/branches/brep-debug/src/libged/brep.c: add dplot routine to step through isocsx events; set event count to 0 until we can parse it |
| 21:21.53 | ``Erik | looks like google's ditching imap in gmail for a custom api to make it a "platform" http://online.wsj.com/news/article_email/google-opens-gmail-making-it-more-of-a-platform-for-developers-1403719202-lMyQjAxMTA0MDIwNTEyNDUyWj |
| 21:23.28 | n_reed | brlcad: I'd appreciate it if you'd upgrade the repo so we can use mergeinfo |
| 21:40.48 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 21:44.30 | brlcad | n_reed: you and me both |
| 21:44.58 | brlcad | starseeker: RT_DB_DIFF_H |
| 21:50.28 | Notify | 03BRL-CAD:starseeker * 61413 (brlcad/trunk/include/raytrace.h brlcad/trunk/include/rt/db_fullpath.h and 2 others): Break pathHmat out of mged into a librt function - this appears to be the function that gets us the 'final placement' matrix for wireframes in the view. |
| 21:51.00 | Notify | 03BRL-CAD Wiki:Vladbogolin * 7369 /wiki/User:Vladbogolin/GSoC2014/Logs: |
| 21:56.34 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 21:59.19 | Notify | 03BRL-CAD:starseeker * 61414 (brlcad/branches/openscenegraph/doc/docbook/system/man1/en/mac-pix.xml brlcad/branches/openscenegraph/doc/docbook/system/man1/en/nastran-g.xml and 15 others): Sync through trunk r61413 |
| 22:05.28 | Notify | 03BRL-CAD:n_reed * 61415 (brlcad/branches/brep-debug/src/libbrep/debug_plot.cpp brlcad/branches/brep-debug/src/libged/brep.c and 3 others): write out isocurve-surface event counts and update parser to read them |
| 22:09.22 | *** join/#brlcad mihaineacsu (~mihaineac@92.85.193.175) |
| 22:10.20 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7370 /wiki/User:Popescu.andrei1991/devlogs2014: /* Week 6 */ |
| 22:10.21 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 22:12.51 | brlcad | mihaineacsu: how's coding coming along?? haven't seen much of any updates ... getting to be very concerning |
| 22:12.53 | Notify | 03BRL-CAD:starseeker * 61416 brlcad/branches/openscenegraph/src/libdm/osg-test.cpp: Start figuring out how to handle regions as atomic objects in the scenegraph for performance. |
| 22:14.36 | mihaineacsu | brlcad: I'm reading the gqa source file, I'm not sure how materials are to be saved and used after getting them from the web platform |
| 22:15.04 | mihaineacsu | <PROTECTED> |
| 22:15.30 | brlcad | mihaineacsu: these are questions you should have been asking a long time ago |
| 22:16.00 | mihaineacsu | I only got working on this matter this week, I've left an email concerning last week |
| 22:16.02 | brlcad | mihaineacsu: so did you figure out how to run rtweight? |
| 22:16.07 | mihaineacsu | yes |
| 22:16.16 | brlcad | I saw your e-mail |
| 22:18.03 | brlcad | mihaineacsu: my concern is with respect to the timeline, we're nearly 1/3rd done with SOCIS and you've written no code nor kept up your log nor been interactive in pretty much any capacity |
| 22:18.55 | brlcad | one week does not account for the three and a half weeks that have elapsed, please take active efforts to adjust your level of participation and activity |
| 22:19.06 | brlcad | you basically have no slack time remaining now |
| 22:19.33 | mihaineacsu | yes, I understand |
| 22:19.54 | brlcad | did you figure out how to run gqa successfully? |
| 22:20.07 | mihaineacsu | yes, I have |
| 22:20.14 | brlcad | you build a density file? |
| 22:20.20 | brlcad | s/build/used or built/ |
| 22:20.30 | mihaineacsu | I've reading and followed the manual |
| 22:20.37 | mihaineacsu | for gqa, so yes |
| 22:21.42 | brlcad | can you explain the process, the steps you took, what sample you used, what volume or mass result you got? |
| 22:22.31 | brlcad | want to make sure you have a firm understanding of how the tool presently works and the terminology before we can talk about how to go about changing things |
| 22:22.50 | mihaineacsu | well actually I used the test values from weight.sh |
| 22:23.43 | brlcad | okay, and how did you use them? |
| 22:23.56 | brlcad | walk me through it |
| 22:24.50 | mihaineacsu | built the same regions and saved the values in a .density file |
| 22:25.18 | brlcad | cool, that's good, what next? |
| 22:26.11 | mihaineacsu | saved the .density file in the working directory, and ran rtweight |
| 22:26.48 | mihaineacsu | from what I understood rtweight looks up the .density file |
| 22:30.12 | brlcad | ... and? :) |
| 22:31.22 | mihaineacsu | and it generated the output, used the density table and obtained the volume |
| 22:32.47 | brlcad | it doesn't use the .density file for volume |
| 22:33.15 | brlcad | it uses ray tracing (hence the rt* in the name) |
| 22:44.36 | *** join/#brlcad Izakee (~Isaac@41.205.22.2) |
| 22:46.59 | mihaineacsu | ok, I followed the same process when I tested out the first patch |
| 22:49.12 | *** join/#brlcad ankesh11 (uid8015@gateway/web/irccloud.com/x-csbpxbwmnpubgrjw) |
| 22:51.16 | brlcad | mihaineacsu: not understanding whether you misunderstood what I was saying or whether you're telling me something else... |
| 22:51.54 | brlcad | my point was that the .density file doesn't help compute volume .. it's material names and density values, it's used to compute mass |
| 22:52.22 | mihaineacsu | brlcad: I was saying something else. I understand, raytracing for volume, density table for weight |
| 22:52.52 | brlcad | okay |
| 22:53.01 | brlcad | so that's all good, but what about gqa? |
| 22:54.51 | mihaineacsu | with the gqa, we need to specify the file |
| 22:56.19 | mihaineacsu | I haven't tested it out properly |
| 22:57.39 | Notify | 03BRL-CAD Wiki:Erik * 7371 /wiki/Summer_of_Code/Checklis: mention posting midterm report to blog or wiki page |
| 22:58.23 | mihaineacsu | I know the file has to be imported beforehand as a binary object |
| 22:59.00 | brlcad | yes it does |
| 22:59.16 | brlcad | I think you need to build a simple example from the ground up |
| 22:59.19 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 22:59.25 | brlcad | something that anyone here can walk you through |
| 22:59.51 | mihaineacsu | ok |
| 22:59.58 | brlcad | create a simple sphere with mged, create a density file with just one or two entries |
| 23:01.27 | brlcad | create the sphere with radius 5mm) |
| 23:01.48 | brlcad | "in sph sph" ... the follow the prompts |
| 23:02.08 | brlcad | create a region with that sphere: "r sph.r u sph" |
| 23:02.37 | brlcad | assign material code to that region with the mater command |
| 23:03.50 | brlcad | run rtweight and confirm the volume, and mass for two materials, say water and gold |
| 23:04.37 | brlcad | then figure out how to import the density table (man gqa), and run gqa to also calculate volume and mass ... report back your results (all four values) |
| 23:04.48 | mihaineacsu | ok, thank you |
| 23:04.56 | brlcad | ask questions, discuss as you make progress, be interactive .. don't work quietly |
| 23:05.25 | brlcad | and for godsake, update your log with any and all days that you worked on anything with a sentence or two describing what you did (even if you did nothing, say that) |
| 23:06.00 | mihaineacsu | I will |
| 23:06.01 | brlcad | from here on out, you need to update that log every day |
| 23:06.14 | Izakee | :) |
| 23:07.44 | Notify | 03BRL-CAD Wiki:Ankeshanand * 7372 /wiki/User:Ankeshanand/GSoC14/logs: /* Week 6 */ |
| 23:16.21 | brlcad | mihaineacsu: have you gone through http://brlcad.org/wiki/Summer_of_Code/Checklist ? |
| 23:17.01 | mihaineacsu | aside the last points, yes |
| 23:17.25 | brlcad | okay, great (that should be in your dev log somewhere ;) |
| 23:17.32 | brlcad | thanks |
| 23:23.30 | *** join/#brlcad ParahSailin (~parahsail@unaffiliated/parahsailin) |
| 23:25.39 | mihaineacsu | brlcad: I'm getting this error on rtweight: "Material type 0 used, but has no density file entry." |
| 23:29.09 | brlcad | mihaineacsu: what does that mean? |
| 23:29.38 | brlcad | run "l sph.r" .. it will tell you what materialID is set |
| 23:29.39 | mihaineacsu | I understand what it means, but I did make .density file :) |
| 23:29.49 | brlcad | and what does your .density file look like? |
| 23:31.11 | mihaineacsu | http://cl.ly/image/432t1s370m1R/Screen%20Shot%202014-06-26%20at%2002.30.13.png it looks like this |
| 23:32.50 | brlcad | huh, that is odd |
| 23:32.59 | brlcad | so one thing I didn't explain, the "mater" command |
| 23:34.05 | brlcad | that sets a shader, not the material ID .. it's got a bad name |
| 23:34.18 | brlcad | the GIFTmater=1 is the value you're looking for |
| 23:34.24 | mihaineacsu | oh I see |
| 23:34.35 | brlcad | that means it's material "1" |
| 23:34.47 | brlcad | now if your .density file |
| 23:35.20 | brlcad | <PROTECTED> |
| 23:35.23 | brlcad | i.e., sph.r |
| 23:36.02 | brlcad | I'm not at all sure what you'd get Material type 0 used, but has no density file entry though ... that sounds like something work fixing |
| 23:36.06 | brlcad | worth fixing |
| 23:38.34 | raj12lnm | brlcad: like no interpolation, cut for direction given at http://brlcad.org/wiki/DSP |
| 23:39.29 | raj12lnm | Correction: (cut for direction)=(cut direction) |
| 23:43.12 | mihaineacsu | so just changing Gold to the region's name ought to fix it? http://f.cl.ly/items/1F250P1J3w0q253P3M0P/Screen%20Shot%202014-06-26%20at%2002.41.28.png |
| 23:49.36 | mihaineacsu | I'll try running the virtual machine, check if it's because of my built |
| 23:54.03 | brlcad | mihaineacsu: unless you modified your build, that would be a waste of time to check |
| 23:55.02 | brlcad | don't become victim of cargo cult programming techniques, just trying different environments until it magically works ... understand why it's not working ;) |
| 23:55.11 | brlcad | what is the format of a .density file? |
| 23:56.27 | brlcad | "you listed "Gold" (which you set as the shader name), but it's expecting an object name" <-- this is wrong |
| 23:56.48 | brlcad | Gold was fine, but you should check the format and understand what each column means |
| 23:56.58 | mihaineacsu | I know it's index density object_name |
| 23:57.18 | mihaineacsu | if you check the last screenshot, I made the changes and I get the same output...more or less |
| 23:57.42 | brlcad | it's not object_name |
