IRC log for #brlcad on 20130909

01:27.58*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
03:50.48brlcadmaths22: oh my gosh yes!
03:51.01brlcadi'll try to come up with a summary of where we're at on Monday
04:35.30*** join/#brlcad bch (~bch@dsl081-162-155.sea1.dsl.speakeasy.net)
04:35.34bchhello #brlcad
04:44.22brlcadhello bch, ltns!
04:47.46bchhey brlcad
04:48.01bchlong time no see. hows the 3d world ?
04:52.24Notify03BRL-CAD:phoenixyjll * 57496 brlcad/trunk/src/libbrep/boolean.cpp: Use the same surface if they are split from the same face.
04:56.37*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
05:52.17brlcadsteadily expanding ;)
05:55.16Notify03BRL-CAD:phoenixyjll * 57497 brlcad/trunk/src/libbrep/boolean.cpp: Not always the last vertex. We should compare all vertexes and find the right one.
06:39.07*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
07:22.17Notify03BRL-CAD:phoenixyjll * 57498 brlcad/trunk/src/libbrep/boolean.cpp: Detect whether the surfaces are the same - don't need SSI if they are the same.
08:18.53*** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16)
08:32.34*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
08:54.36*** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net)
08:55.49Notify03BRL-CAD Wiki:Phoenix * 6109 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 12 */
10:07.06*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
11:07.28*** join/#brlcad shadownet (~Shadownet@195.24.220.16)
11:24.53*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
11:51.04*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
12:34.25*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
12:37.21Notify03BRL-CAD:indianlarry * 57499 (brlcad/branches/nurbs/include/dm.h brlcad/branches/nurbs/include/icv.h and 13 others): Merging trunk into branch 'nurbs' r:57491:57498
12:54.20*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
13:22.31Notify03BRL-CAD:starseeker * 57500 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Ah - just as we have to do something different for rational curves, we'll need to do something for rational surfaces.
13:45.57Notify03BRL-CAD:starseeker * 57501 (brlcad/trunk/src/conv/step/g-step/CMakeLists.txt brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp brlcad/trunk/src/conv/step/g-step/ON_Brep.h): Start breaking out pieces of ON_Brep.cpp into individual files.
13:59.31Notify03BRL-CAD:starseeker * 57502 (brlcad/trunk/src/conv/step/g-step/CMakeLists.txt brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp brlcad/trunk/src/conv/step/g-step/ON_Brep.h): Break out NurbsCurve handling.
14:00.00Notify03BRL-CAD:starseeker * 57503 (brlcad/trunk/src/conv/step/g-step/ON_NurbsCurve.cpp =================================================================== and 218 others): Add ON_NurbsCurve.cpp
14:05.54*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
14:24.20Notify03BRL-CAD:starseeker * 57504 brlcad/trunk/src/conv/step/g-step/ON_NurbsCurve.cpp: Simplify code, re-use functions
15:31.50Notify03BRL-CAD:starseeker * 57505 (brlcad/trunk/src/conv/step/g-step/CMakeLists.txt brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp brlcad/trunk/src/conv/step/g-step/ON_Brep.h): Break out surfaces into their own file.
15:32.20Notify03BRL-CAD:starseeker * 57506 (brlcad/trunk/src/conv/step/g-step/ON_NurbsSurface.cpp =================================================================== and 288 others): Add ON_NurbsSurface.cpp
15:36.58Notify03BRL-CAD:starseeker * 57507 brlcad/trunk/src/conv/step/g-step/ON_NurbsSurface.cpp: Get a look at the attribute list for the rational surface aggregate
16:17.14Notify03BRL-CAD:mohitdaga * 57508 brlcad/trunk/src/util/dsp_add_t.cpp: Initialize the pointers to NULL. (An error in with [-Werror=uninitialized])
16:22.03``Erikheh http://www.youtube.com/watch?v=Oie1ZXWceqM
16:53.24*** join/#brlcad Izak (~Izak@195.24.220.16)
16:53.43Izakbrlcad: Found paametric equations for heart
16:54.05*** join/#brlcad Izak__ (~Izak@195.24.220.16)
16:54.21Izak__at http://paste.kde.org/p8f280097/
16:54.37Izak__How do i gon about plotting these ?
16:54.52Izak__s/gon/go ``Erik :
17:01.08Notify03BRL-CAD:starseeker * 57509 brlcad/trunk/src/conv/step/g-step/ON_NurbsSurface.cpp: print entity name too
17:03.00Izak__brlcad: Found parametric equations of the heart online pasted here http://paste.kde.org/p8f280097/
17:27.12brlcadIzak__: looks at some of the other primitives, like ell
17:27.37brlcadsuggest starting very very simple, like first drawing just a single line in plot()
17:28.28Izak__brlcad: a single line eh ?
17:28.47brlcaddrawing the bounding box, even better -- this would be throwaway code, but it'll teach you how to return the data before you worry about the parametric functions
17:33.04brlcadif your parametric equations are right, you can then create two for () loops, iterate over u and v and plot connected lines (contours) as a starting point
17:35.52*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)
17:36.31Izak__ok
17:38.04Notify03BRL-CAD:starseeker * 57510 (brlcad/trunk/src/conv/step/g-step/ON_Brep.h brlcad/trunk/src/conv/step/g-step/ON_NurbsSurface.cpp): Need to be able to get at the generic aggregate in the stepcomplex surface case - add a map to simplify getting at all aggregates.
17:59.24Notify03BRL-CAD:mohitdaga * 57511 (brlcad/trunk/src/libicv/bw.c brlcad/trunk/src/libicv/pix.c): Use fopen in instead of open.
18:00.25zero_levelhi brlcad
18:01.17zero_levelbrlcad : Can you help me to bring the regress back to its original.
18:01.31zero_levelIts currently down with dsp_add_t
18:01.44zero_levelwanted to test changes in bw_write and pix_write.
18:19.48kanzurehas anyone used brlcad with python + ctypes or libffi?
18:22.12kanzureoh cool user:phoenix is still doing nurbs things?
18:42.07Notify03BRL-CAD:starseeker * 57512 brlcad/trunk/src/conv/step/g-step/ON_NurbsSurface.cpp: Add knots to rational surfaces.
18:42.51Notify03BRL-CAD:mohitdaga * 57513 (brlcad/trunk/src/libicv/bw.c brlcad/trunk/src/libicv/pix.c): Convert open to fopen in bw_write, pix_write
18:42.54brlcadzero_level: what's "down" mean?
18:43.48zero_levelbrlcad : nice question. :)
18:43.50zero_levelbrlcad++
18:44.11zero_levelIts shows an error while regressing dsp_add_t.
18:44.30zero_levelI am copying the curent message to some paste.
18:44.51brlcadafaik, dsp_add_t is not part of the regression tests
18:45.24brlcadthough it may certainly be attempting to compile it if you just run "make regress" due to dependencies
18:46.05brlcadsuggest just fixing whatever it's complaining about
18:46.16brlcadshouldn't be anything major, it's a recent change
18:47.01zero_levelalright.
18:47.05zero_levelbrlcad : thanks
19:00.40brlcaddid you figure it out?
19:04.13brlcadzero_level: also, r57495 breaks DRY principle pretty hard...not to mention rule-of-three
19:10.28kanzureaww all of the symbol names are mangled
19:10.38kanzurelike when i check: nm /usr/brlcad/lib/libbrep.so.20
19:11.47brlcadkanzure: nm /usr/brlcad/lib/libbrep.so.20 | c++filt
19:12.17kanzurebrlcad: i was going to see if i could use python: import ctypes; libbrep = ctypes.cdll.LoadLibrary("/usr/brlcad/lib/libbrep.so.20"); libbrep.symbolname
19:12.24brlcadand yes, wu is still working quite hard on nurbs (specifically boolean evaluation)
19:12.26kanzurebut if the symbol names are mangled then they are probably different on each platform or each build or something
19:12.44*** join/#brlcad Izak__ (~Izak@195.24.220.16)
19:12.57brlcadwell yeah, it's a c++ library ... :)
19:13.12brlcadthat's kind of why swig exists
19:13.22brlcadwrapping C was never hard
19:13.50kanzurethe swig wrappers don't work at the moment
19:14.02kanzure(sorry, i don't have a more specific bug report to give you; i didn't try today)
19:14.17brlcad*shrug* would be a swig issue anyways
19:14.38brlcadnever really had trouble with it, but it's been a couple years since I last tried
19:14.56brlcaderik's used it more recently
19:15.13Izak__brlcad: How could you ask me to share that image? It was really aweful! :(
19:16.07brlcadthe name mangling is usually ABI-compatible, so you're good across versions of gnu, for example, but that obviously wn't match the mangling on windows or other runtimes
19:16.18brlcadIzak__: it's progress!
19:16.28brlcadit's cool progress
19:16.33brlcadplus I didn't know if you had anyting better
19:16.35Izak__:)
19:16.39brlcadheck even a different angle
19:16.45brlcaddid you at least figure that out?
19:16.57Izak__no
19:17.00zero_levelbrlcad : are you pointing towards the multiple files bein committed ?
19:17.00brlcadoof
19:17.10zero_levelbrlcad : I figured it out.
19:17.31zero_levelsee r57508
19:17.33brlcadzero_level: towards the same four lines of code you added in about 20-30 places :)
19:19.28brlcadzero_level: i don't understand -- you asked about regress and dsp_add_t 80 minutes ago, but r57508 was well before that
19:19.46brlcadIzak__: so you didn't read the rt man page?
19:19.50zero_levelbrlcad : I was running regress on bx.
19:19.54zero_level*bz
19:20.12zero_leveland didnt update it with my recent commits
19:20.50brlcadIzak__: see the -a -e options
19:20.55brlcadazimuth/elevation
19:21.07brlcaddefault is 35/25
19:21.10brlcadtry some other views
19:21.11Izak__looking at man rt page
19:21.23Izak__brlcad: Did you see my slide show
19:21.26brlcadzero_level: ah, okay so just out of date
19:21.32brlcadIzak__: nope
19:21.52Izak__I read the Animation wiki page and created a slide show using about 30 images
19:22.07brlcader, where did you mention that??
19:22.10Izak__Please take a look at the slides
19:22.15Izak__In the logs
19:22.20zero_levelbrlcad : I was trying to validate the images.
19:22.22brlcadoooh, heh
19:22.24Izak__I mentioned that in my logs
19:23.01brlcadIzak__: you know I don't just sit there hitting refresh on your log all day?? :D  got to give folks a hint or post a url :)
19:24.05brlcaddownloading movie.odp
19:24.07zero_levelOfcourse I should have made a function or must have added the log message in the macro itself.
19:24.08Izak__brlcad : I wasn under the impression that our logs are read each Sunday ;)
19:25.41Izak__s/wasn/was
19:26.13Notify03BRL-CAD Wiki:195.24.220.16 * 6110 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* Sept 02 - Sept 08 */
19:26.15zero_levelbrlcad : but each function had different return argument. and a log message also.
19:29.01brlcad5 had void return, 9 had -1 return, 13 had NULL return
19:29.13Notify03BRL-CAD Wiki:NyahCh3ck20 * 6111 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* Sept 09 - Sept 15 */
19:29.15brlcadall 27 had the same log message
19:29.30zero_levelso three different clusters.
19:29.31brlcadall had basically the same check
19:29.38Izak__brlcad: Any comments ?
19:29.39zero_levelright.
19:29.58brlcadso the returns aren't really the issue
19:30.24zero_levelalright. Can u suggest something ?
19:30.29brlcadit's really the 29 instances of the same bu_log line, and the general pattern of the same 4 lines of code repeated two dozen times
19:30.29zero_levelImprovement >
19:31.24brlcadsay we want to change that message, maybe not call bu_log() since this is a library and that's bad practice, maybe return it in a string passed int
19:31.27brlcads/int/in/
19:31.31brlcadit's now 29 times more expensive of an edit to make
19:32.00brlcadchange it just 3 times and it's nearly 100 times more costly to keep
19:32.21brlcadso how to reduce that cost?
19:32.51brlcadif you had to change that block of code once an hour, what would you change?
19:33.11brlcaddo that
19:33.15Notify03BRL-CAD:starseeker * 57514 (brlcad/trunk/src/conv/step/g-step/CMakeLists.txt brlcad/trunk/src/conv/step/g-step/G_STEP_internal.h and 2 others): Break out shape_definition_representation
19:33.18zero_levelbrlcad : I never made such calculations.
19:33.26zero_levelbrlcad : thanks.
19:33.50zero_levelthe only thing i can think is making a validation macro.
19:33.56zero_leveland a return pointer.
19:35.29zero_levelbut still not sure if I will need one macro or three.
19:35.54zero_levelbecause Dont know if i should return in the macro ?
19:36.15zero_levelalso have no idea how to return void functions ?
19:36.43zero_leveli mean what argument I will send to return void functions ?
19:41.09brlcadwell it begs the question why some are pointers, some are nothing, and some are ints
19:41.38zero_levelbrlcad : nice question.
19:41.43brlcadcan they be all made the same would be the first inspection I'd make since that would help reduce the duplication AND help make the API more consistent
19:41.45zero_levellet me explain.
19:42.07brlcadthere's no question why it's the way it is :)
19:43.29zero_levelso should I continue ? or We have mad up our minds to make them consistent (forcibly )
19:43.44Notify03BRL-CAD:starseeker * 57515 (brlcad/trunk/src/conv/step/g-step/CMakeLists.txt brlcad/trunk/src/conv/step/g-step/G_STEP_internal.h brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp): Break out the building of the geometric context stepcomplex object
19:43.45brlcadhm?
19:43.52zero_levelc/mad/made
19:43.59brlcadmade up our minds? this was the question
19:44.14brlcadwhether they 'can' be made consistent (in a useful way)
19:44.39brlcadwhat that would even look like
19:44.45brlcade.g., all void or all int or all pointer
19:45.00zero_levelbrlcad : I am a c-programmer. And I can make them return whatever we like.
19:45.08brlcadheh
19:45.17brlcadso take off your programmer hat for a second
19:45.25zero_levelhahahah :)
19:45.29brlcadput on an API *designer* hat ;)
19:45.47zero_levelyou will have to ship one :)
19:45.51brlcadyou're someone who downloads libicv for integration into your awesome application
19:46.17zero_levelok.
19:46.39brlcadi'm sure you can see the impact if the API always returned nothing, for example
19:46.58brlcadyou'd think "oh wow, I hope there's a way to check for error conditions or this really sucks"
19:47.33brlcadbut would also be comforted in never having to wrap each call in an if (succeeded) check
19:47.54brlcadthe other two options have their own tradeoffs
19:48.17brlcadof course any three can be made to work, but whether it makes sense depends on how they group
19:48.41zero_levelis wearing *designer's hat*
19:48.46brlcad;)
19:48.56brlcadfabulous
19:49.01zero_levelbrlcad : the whole point of having
19:49.15zero_levelthis was usability.
19:49.48brlcadactually maintainability, but continue :)
19:49.56zero_levelbrlcad : As I explain this. I will still leave the final call to you. If you say to change I will be doing.
19:50.14zero_levelNow. (usability)
19:50.17brlcadI get that, but I'm wanting feedback from you :)
19:50.27brlcadwhat do YOU think other than ...
19:50.38brlcad"yeah, I can change it" or "I like it how it is"
19:50.48brlcadthat's not useful.. :)
19:50.52zero_levellets primarily
19:50.59zero_levelgroup these functions into 3.
19:51.05Notify03BRL-CAD:starseeker * 57516 (brlcad/trunk/src/conv/step/g-step/CMakeLists.txt brlcad/trunk/src/conv/step/g-step/G_STEP_internal.h brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp): Break out Shape_Representation and Shape_Representation_Relationship
19:51.08brlcadwhy
19:51.32zero_levelone which creates a new ICV structure in the run time.
19:51.46zero_levelfor eg. icv_filter3
19:52.13zero_levelthis takes in the argument. three images. and creates the output image during function run time.
19:52.45zero_levelso has a icv_image_t* type return.
19:53.24zero_levelnow lets see the functions of the form icv_filter(...)
19:53.37zero_levelthis does filtering in place. (doenst create a new icv
19:53.45zero_level_struct)
19:53.54zero_levelon failure return -1
19:53.59zero_levelon succession 0.
19:54.18zero_levelbrlcad : this is type 2. (int return).
19:54.30zero_leveltype 3 : Mainly operations.
19:54.44zero_leveloops. mainly statistics.
19:56.20brlcadthat's basically the current state of the code
19:57.06zero_levelbrlcad : rightly figured.
19:57.17zero_levelSo do you see the poing ?
19:57.27zero_levelc/poing/point
19:57.45brlcadyes and no
19:57.56brlcadI see you've described what you did
19:58.21brlcadwhich you tried with 15:41 < zero_level> let me explain.
19:58.37brlcad"there's no question why it's the way it is :)"
19:58.45brlcadi understand what you wrote, why it is that way
19:58.58*** part/#brlcad Ch3ck_ (~Shadownet@195.24.220.16)
19:59.18brlcadyour creation funcs return a pointer, your filters return a code, your stats ... void
19:59.24brlcadsure, great
19:59.53zero_levelAnd All this was done in focuse with usability
20:00.10brlcadsure
20:00.23zero_leveland I see usability and maintainability in two sides of a balance here.
20:00.37brlcadis that to say there's no room for improvement on usability?
20:00.44brlcadit's perfect?
20:00.45brlcad:)
20:01.13zero_levelI will brlcad's suggestion here.
20:01.18zero_level^seek
20:01.22brlcadslaps forehead
20:02.00brlcadI'm trying to get you to envision and explore, not defend or just accept my envisioning/exploring
20:02.09brlcadyou don't need to defend
20:02.22brlcadit is what it is, it's already turning into a great API
20:02.50brlcadthe design question is what would it look like if you enforced some homogeneity
20:03.28zero_levelicv_Filter3 will become.
20:03.45brlcadwhat would it look like, how might it feel if, just for *example*, if you never returned a NULL pointer, for example
20:04.00zero_levelicv_filter3(icv_image_t* ......... , icv_filter_t **out_img);
20:04.27brlcadnow you're thinking
20:04.28zero_levelJust wanted to avoid this situation.
20:04.35brlcadwhy
20:04.48brlcadwhat's the downside?
20:05.24zero_leveldo you remember this page. ttp://brlcad.org/wiki/User:Level_zero/GSOC13/api
20:06.14brlcadyep
20:06.14zero_levelThe only downside i saw was complexity.
20:06.33brlcadI note that you already have that pattern in some places
20:06.57brlcadthe function that return int are mostly that pattern
20:06.58zero_levelwe also had a long discussion about that.
20:07.23zero_levelbut earlier revisions of this page will have void type.
20:07.35zero_levelc/will have/had
20:08.04zero_leveland then I wanted to handle error in a better way.
20:08.12zero_level0 for succession
20:08.18zero_level-1 for failure.
20:08.21brlcadslow down
20:08.24brlcadthat thought there
20:08.25zero_level-2 for some other..
20:08.29brlcadstop
20:08.37brlcadyou instantly jumped from WHAT to HOW
20:08.46brlcadthe WHAT is that you found a need to handle error better
20:08.50brlcadthat is good to recognize
20:09.07brlcadyou instantly jumped into HOW to handle an error (via a return code)
20:09.20brlcadwhen in reality there are many ways you could handle an error
20:09.25brlcadnot saying there's a better way
20:09.33brlcadbut don't mix the method (how) with the need (what)
20:09.45zero_levelI just picked it from the old version of libicv.
20:09.53zero_levelok.
20:10.18brlcadthe important point is that setting a NULL img_out was insufficient error reporting
20:10.25zero_levelI mean from the save_open and other functions.
20:10.35brlcadlog messages were presumably insufficient as well
20:11.07zero_levelthat was my major concern And I asked you in *1 of my doubts.
20:11.32brlcadwhat was your major concern?
20:11.45zero_levelAt this point of time I am open to your suggestion.
20:11.55zero_levelwait.
20:12.08zero_levelfinding the link.
20:12.52zero_levelfrom the paste link. * Regarding log messages,  After priting log messages. Is it better to exit or pass -1 ? Currently I pass NULL or -1 for failure and 0 (or Pointer to the structure) for succeding.
20:13.16brlcadyou mean your question in the commit message?
20:13.47zero_levelno. DO you remember we had a discussion over a paste link i gave on IRC.
20:13.57zero_levelit had around 8 links.
20:14.08zero_levels/links/ponts
20:14.29zero_levelis facing lots of lag here.
20:14.44zero_level(ssh lag)
20:15.24brlcadyeah, I don't know what you're referring to specifically but I'm not sure how it at all matters whether I remember or not, doesn't change where we are now or today's design brainstorming
20:15.56brlcadI vaguely recall that, actually, but again .. not sure it's relevant
20:16.31zero_levelhmm.
20:17.26zero_levelso. ? where we ?
20:17.27brlcadback to the design discussion... so the API you have on that wiki page is one good data point
20:18.55brlcadclearly, the pattern there (and the majority) is return some int code
20:19.33brlcadso at this point, the design question it asks is why there are functions that don't return a code
20:19.45zero_levelbrlcad : regarding the paste link. I was just able to dig. http://paste.kde.org/p38e0decb/
20:19.50brlcadand would it be worthwhile to make them return a code
20:20.26zero_levelbrlcaD : that is nice question to ask.
20:20.47brlcadah, *that* pastebin
20:21.20brlcadthink that is only peripherally related to today's design questions
20:21.54brlcadit assumes we should be printing log messages in the first place (we probably shouldn't)
20:23.43zero_levelI see thatvoid return could be made to return.
20:24.03brlcadexcellent
20:24.03zero_levellike icv_destroy(...)
20:24.11zero_levelicv_sanitize(..)
20:24.26brlcadso then you're just down to two categories
20:24.32brlcadthe creation functions and the processing functions
20:24.37zero_levelalso the vice versa could be done. like icv_Filter has void type.
20:24.48zero_levelok.
20:25.33zero_levelbut then we could have a global variable. ICV_ERROR. And set that.
20:25.39brlcadNO
20:25.46brlcadgood thinking
20:25.47zero_levelok.
20:25.50brlcadbut no globals :)
20:26.00brlcadno global state, no static state
20:26.12brlcadthey don't work for multiprocessing
20:26.36brlcadyou already have an issue of memory (what if in==out)
20:27.00zero_levelhm ? where ?
20:27.35brlcada discussion for later perhaps, but basically how many of the processing functions will not work if img_in == img_out
20:27.40brlcadi.e., process in place
20:28.05brlcadmany would need to create a copy to work right
20:28.15*** join/#brlcad vladbogo (~vlad@188.25.237.111)
20:28.30brlcador be designed to work on the copy passed in only
20:28.42brlcadnot your doing
20:28.52brlcadthat's how they were written to stream
20:29.58brlcaddon't worry about it
20:30.38zero_levelbrlcad : I think I didnt understand this point of yours.
20:31.15Notify03BRL-CAD:starseeker * 57517 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Flip loops when we flip the face (Keith's suggestion, seems to improve raytracing results for test rcc
20:31.27brlcadsome of the functions will not produce the right output if the output image image pointer is the exact same pointer as the input image pointer
20:31.27zero_levellet me try to see what point are you making.
20:31.43zero_levelbrlcad : wait.
20:31.49brlcaddoesn't wait
20:31.52brlcadmultitasks
20:32.03zero_levelwait means let me try to bring you a fact.
20:32.10brlcad~dict wait
20:32.40zero_levelactually i eamnt because i am facing ssh lag. It will take few secs.
20:32.42brlcadthat may be what you meant, but that's not what the word means ;)
20:33.24zero_levelbrlcad : lets say icv_crop(img) is called.
20:33.34zero_levelnow it will crop the image.
20:33.45zero_levelBut in place.
20:33.51zero_leveldoesnt pass the pointer.
20:34.05brlcadsure
20:34.09zero_leveloutput_pointer === input_pointer
20:34.10brlcaddoesn't have an out pointer
20:34.12brlcadno
20:34.14zero_level(they are same)
20:34.23zero_levelalright.
20:34.30zero_levelso what point were you making ?
20:35.05Notify03BRL-CAD:vladbogo * 57518 brlcad/trunk/src/libdm/dm-qt.cpp: Send mouse coordinates when generating Tk click events.
20:35.06brlcadlooking through your header, I don't think you've gotten to any of them yet
20:35.09brlcadso doesn't matter
20:35.22brlcadhad you implemented the wiki API, it would have been an issue perhaps
20:36.11brlcadnoticed that icv_rot() is still the first bit of API readers are introduced to...
20:36.17zero_levelexcellent :) That why it semt alien to me. Thanks.
20:36.18brlcadshould be further down
20:36.24zero_levelalright.
20:37.36brlcadso parting design thought
20:38.04brlcadthere is a cool aspect of always returning a (non-NULL) pointer that would be possible with this API
20:38.21brlcadyou could compose calls functionally
20:39.10brlcadicv_flip(icv_scale(icv_random(icv_create(),...), 2.0)...);
20:40.45brlcadone liner programs ;)  icv_destroy(icv_write(icv_flip(icv_scale(icv_random(icv_create(),...), 2.0)...), "myfile.png"));
20:44.36Notify03BRL-CAD Wiki:Vladbogolin * 6112 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 12 */
20:46.10zero_levelbrlcad : Returning non-null ?
20:50.36zero_leveldo you mean we should return a pointer to an empty icv_struct even if there is an error in input argumetns.
20:54.49Notify03BRL-CAD:mohitdaga * 57519 brlcad/trunk/include/icv.h: Structure the declarations of public apis in libicv.
20:56.40brlcadthe structure would be able to record any type of exception state, it would record what failed and could even hold log messages explaining why
20:57.39brlcadeach subsequent function would naturally skip processing just like your current check, and return the input (or even append another exception to the list)
20:58.00brlcadso the error propagates up, the memory is never potentially a null pointer dereference
20:58.46brlcadand you can still chose to invoke them one line at a time: img = icv_create(); img = icv_random(img, ...); img = icv_scale(img, 2.0); ...
21:04.20Notify03BRL-CAD Wiki:IIIzzzaaakkk * 6113 /wiki/User:Izak/GSOC_2013_logs: /* September 2nd to September 7th */
21:07.22zero_levelbrlcad : nice idea.
21:07.29zero_levelThis will require some planning.
21:26.37zero_levelbrlcad : what is take away from today's disucssion ?
21:27.02zero_levelhow should i plan. (Looking at the time as a constraint)
21:34.02Notify03BRL-CAD Wiki:IIIzzzaaakkk * 6114 /wiki/User:Izak/GSOC_2013_logs: /* September 2nd to September 7th */
21:34.15Notify03BRL-CAD:mohitdaga * 57520 brlcad/trunk/src/libicv/TODO: Remove TODO items.
21:37.53*** join/#brlcad greenride (~purplehaz@71.202.102.140)
21:41.01greenrideIf I have a system of parts (3D cad parts) and specify the momentum and angular momentum of each part, is there a library that will tell me the force on areas of contact between parts?
22:02.30Notify03BRL-CAD:starseeker * 57521 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Make a note to look into assigning b_spline_surface_form types when possible.
22:16.14Notify03BRL-CAD:starseeker * 57522 brlcad/trunk/src/conv/step/g-step/g-step.cpp: Free some memory - not properly freeing the STEPcomplex entities, but it's a start
22:30.28*** join/#brlcad cogitokat (~kat@ip70-171-0-190.ga.at.cox.net)
22:38.50*** join/#brlcad mpictor (~mark@c-67-177-102-131.hsd1.in.comcast.net)
22:44.38brlcadzero_level: do-to file for any ideas that you think are worth pursuing
22:45.29brlcadzero_level: I think at a minimum, converting the void functions to return an int code for success will be worthwhile
22:45.53brlcadthat will give you two return types that you can wrap into two macros
22:46.01brlcadthat will at least not break the rule of three
23:06.08*** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.