| 01:27.58 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 03:50.48 | brlcad | maths22: oh my gosh yes! |
| 03:51.01 | brlcad | i'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.34 | bch | hello #brlcad |
| 04:44.22 | brlcad | hello bch, ltns! |
| 04:47.46 | bch | hey brlcad |
| 04:48.01 | bch | long time no see. hows the 3d world ? |
| 04:52.24 | Notify | 03BRL-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.17 | brlcad | steadily expanding ;) |
| 05:55.16 | Notify | 03BRL-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.17 | Notify | 03BRL-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.49 | Notify | 03BRL-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.21 | Notify | 03BRL-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.31 | Notify | 03BRL-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.57 | Notify | 03BRL-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.31 | Notify | 03BRL-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.00 | Notify | 03BRL-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.20 | Notify | 03BRL-CAD:starseeker * 57504 brlcad/trunk/src/conv/step/g-step/ON_NurbsCurve.cpp: Simplify code, re-use functions |
| 15:31.50 | Notify | 03BRL-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.20 | Notify | 03BRL-CAD:starseeker * 57506 (brlcad/trunk/src/conv/step/g-step/ON_NurbsSurface.cpp =================================================================== and 288 others): Add ON_NurbsSurface.cpp |
| 15:36.58 | Notify | 03BRL-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.14 | Notify | 03BRL-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 | ``Erik | heh http://www.youtube.com/watch?v=Oie1ZXWceqM |
| 16:53.24 | *** join/#brlcad Izak (~Izak@195.24.220.16) | |
| 16:53.43 | Izak | brlcad: Found paametric equations for heart |
| 16:54.05 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) | |
| 16:54.21 | Izak__ | at http://paste.kde.org/p8f280097/ |
| 16:54.37 | Izak__ | How do i gon about plotting these ? |
| 16:54.52 | Izak__ | s/gon/go ``Erik : |
| 17:01.08 | Notify | 03BRL-CAD:starseeker * 57509 brlcad/trunk/src/conv/step/g-step/ON_NurbsSurface.cpp: print entity name too |
| 17:03.00 | Izak__ | brlcad: Found parametric equations of the heart online pasted here http://paste.kde.org/p8f280097/ |
| 17:27.12 | brlcad | Izak__: looks at some of the other primitives, like ell |
| 17:27.37 | brlcad | suggest starting very very simple, like first drawing just a single line in plot() |
| 17:28.28 | Izak__ | brlcad: a single line eh ? |
| 17:28.47 | brlcad | drawing 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.04 | brlcad | if 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.31 | Izak__ | ok |
| 17:38.04 | Notify | 03BRL-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.24 | Notify | 03BRL-CAD:mohitdaga * 57511 (brlcad/trunk/src/libicv/bw.c brlcad/trunk/src/libicv/pix.c): Use fopen in instead of open. |
| 18:00.25 | zero_level | hi brlcad |
| 18:01.17 | zero_level | brlcad : Can you help me to bring the regress back to its original. |
| 18:01.31 | zero_level | Its currently down with dsp_add_t |
| 18:01.44 | zero_level | wanted to test changes in bw_write and pix_write. |
| 18:19.48 | kanzure | has anyone used brlcad with python + ctypes or libffi? |
| 18:22.12 | kanzure | oh cool user:phoenix is still doing nurbs things? |
| 18:42.07 | Notify | 03BRL-CAD:starseeker * 57512 brlcad/trunk/src/conv/step/g-step/ON_NurbsSurface.cpp: Add knots to rational surfaces. |
| 18:42.51 | Notify | 03BRL-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.54 | brlcad | zero_level: what's "down" mean? |
| 18:43.48 | zero_level | brlcad : nice question. :) |
| 18:43.50 | zero_level | brlcad++ |
| 18:44.11 | zero_level | Its shows an error while regressing dsp_add_t. |
| 18:44.30 | zero_level | I am copying the curent message to some paste. |
| 18:44.51 | brlcad | afaik, dsp_add_t is not part of the regression tests |
| 18:45.24 | brlcad | though it may certainly be attempting to compile it if you just run "make regress" due to dependencies |
| 18:46.05 | brlcad | suggest just fixing whatever it's complaining about |
| 18:46.16 | brlcad | shouldn't be anything major, it's a recent change |
| 18:47.01 | zero_level | alright. |
| 18:47.05 | zero_level | brlcad : thanks |
| 19:00.40 | brlcad | did you figure it out? |
| 19:04.13 | brlcad | zero_level: also, r57495 breaks DRY principle pretty hard...not to mention rule-of-three |
| 19:10.28 | kanzure | aww all of the symbol names are mangled |
| 19:10.38 | kanzure | like when i check: nm /usr/brlcad/lib/libbrep.so.20 |
| 19:11.47 | brlcad | kanzure: nm /usr/brlcad/lib/libbrep.so.20 | c++filt |
| 19:12.17 | kanzure | brlcad: 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.24 | brlcad | and yes, wu is still working quite hard on nurbs (specifically boolean evaluation) |
| 19:12.26 | kanzure | but 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.57 | brlcad | well yeah, it's a c++ library ... :) |
| 19:13.12 | brlcad | that's kind of why swig exists |
| 19:13.22 | brlcad | wrapping C was never hard |
| 19:13.50 | kanzure | the swig wrappers don't work at the moment |
| 19:14.02 | kanzure | (sorry, i don't have a more specific bug report to give you; i didn't try today) |
| 19:14.17 | brlcad | *shrug* would be a swig issue anyways |
| 19:14.38 | brlcad | never really had trouble with it, but it's been a couple years since I last tried |
| 19:14.56 | brlcad | erik's used it more recently |
| 19:15.13 | Izak__ | brlcad: How could you ask me to share that image? It was really aweful! :( |
| 19:16.07 | brlcad | the 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.18 | brlcad | Izak__: it's progress! |
| 19:16.28 | brlcad | it's cool progress |
| 19:16.33 | brlcad | plus I didn't know if you had anyting better |
| 19:16.35 | Izak__ | :) |
| 19:16.39 | brlcad | heck even a different angle |
| 19:16.45 | brlcad | did you at least figure that out? |
| 19:16.57 | Izak__ | no |
| 19:17.00 | zero_level | brlcad : are you pointing towards the multiple files bein committed ? |
| 19:17.00 | brlcad | oof |
| 19:17.10 | zero_level | brlcad : I figured it out. |
| 19:17.31 | zero_level | see r57508 |
| 19:17.33 | brlcad | zero_level: towards the same four lines of code you added in about 20-30 places :) |
| 19:19.28 | brlcad | zero_level: i don't understand -- you asked about regress and dsp_add_t 80 minutes ago, but r57508 was well before that |
| 19:19.46 | brlcad | Izak__: so you didn't read the rt man page? |
| 19:19.50 | zero_level | brlcad : I was running regress on bx. |
| 19:19.54 | zero_level | *bz |
| 19:20.12 | zero_level | and didnt update it with my recent commits |
| 19:20.50 | brlcad | Izak__: see the -a -e options |
| 19:20.55 | brlcad | azimuth/elevation |
| 19:21.07 | brlcad | default is 35/25 |
| 19:21.10 | brlcad | try some other views |
| 19:21.11 | Izak__ | looking at man rt page |
| 19:21.23 | Izak__ | brlcad: Did you see my slide show |
| 19:21.26 | brlcad | zero_level: ah, okay so just out of date |
| 19:21.32 | brlcad | Izak__: nope |
| 19:21.52 | Izak__ | I read the Animation wiki page and created a slide show using about 30 images |
| 19:22.07 | brlcad | er, where did you mention that?? |
| 19:22.10 | Izak__ | Please take a look at the slides |
| 19:22.15 | Izak__ | In the logs |
| 19:22.20 | zero_level | brlcad : I was trying to validate the images. |
| 19:22.22 | brlcad | oooh, heh |
| 19:22.24 | Izak__ | I mentioned that in my logs |
| 19:23.01 | brlcad | Izak__: 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.05 | brlcad | downloading movie.odp |
| 19:24.07 | zero_level | Ofcourse I should have made a function or must have added the log message in the macro itself. |
| 19:24.08 | Izak__ | brlcad : I wasn under the impression that our logs are read each Sunday ;) |
| 19:25.41 | Izak__ | s/wasn/was |
| 19:26.13 | Notify | 03BRL-CAD Wiki:195.24.220.16 * 6110 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* Sept 02 - Sept 08 */ |
| 19:26.15 | zero_level | brlcad : but each function had different return argument. and a log message also. |
| 19:29.01 | brlcad | 5 had void return, 9 had -1 return, 13 had NULL return |
| 19:29.13 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 6111 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* Sept 09 - Sept 15 */ |
| 19:29.15 | brlcad | all 27 had the same log message |
| 19:29.30 | zero_level | so three different clusters. |
| 19:29.31 | brlcad | all had basically the same check |
| 19:29.38 | Izak__ | brlcad: Any comments ? |
| 19:29.39 | zero_level | right. |
| 19:29.58 | brlcad | so the returns aren't really the issue |
| 19:30.24 | zero_level | alright. Can u suggest something ? |
| 19:30.29 | brlcad | it'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.29 | zero_level | Improvement > |
| 19:31.24 | brlcad | say 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.27 | brlcad | s/int/in/ |
| 19:31.31 | brlcad | it's now 29 times more expensive of an edit to make |
| 19:32.00 | brlcad | change it just 3 times and it's nearly 100 times more costly to keep |
| 19:32.21 | brlcad | so how to reduce that cost? |
| 19:32.51 | brlcad | if you had to change that block of code once an hour, what would you change? |
| 19:33.11 | brlcad | do that |
| 19:33.15 | Notify | 03BRL-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.18 | zero_level | brlcad : I never made such calculations. |
| 19:33.26 | zero_level | brlcad : thanks. |
| 19:33.50 | zero_level | the only thing i can think is making a validation macro. |
| 19:33.56 | zero_level | and a return pointer. |
| 19:35.29 | zero_level | but still not sure if I will need one macro or three. |
| 19:35.54 | zero_level | because Dont know if i should return in the macro ? |
| 19:36.15 | zero_level | also have no idea how to return void functions ? |
| 19:36.43 | zero_level | i mean what argument I will send to return void functions ? |
| 19:41.09 | brlcad | well it begs the question why some are pointers, some are nothing, and some are ints |
| 19:41.38 | zero_level | brlcad : nice question. |
| 19:41.43 | brlcad | can 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.45 | zero_level | let me explain. |
| 19:42.07 | brlcad | there's no question why it's the way it is :) |
| 19:43.29 | zero_level | so should I continue ? or We have mad up our minds to make them consistent (forcibly ) |
| 19:43.44 | Notify | 03BRL-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.45 | brlcad | hm? |
| 19:43.52 | zero_level | c/mad/made |
| 19:43.59 | brlcad | made up our minds? this was the question |
| 19:44.14 | brlcad | whether they 'can' be made consistent (in a useful way) |
| 19:44.39 | brlcad | what that would even look like |
| 19:44.45 | brlcad | e.g., all void or all int or all pointer |
| 19:45.00 | zero_level | brlcad : I am a c-programmer. And I can make them return whatever we like. |
| 19:45.08 | brlcad | heh |
| 19:45.17 | brlcad | so take off your programmer hat for a second |
| 19:45.25 | zero_level | hahahah :) |
| 19:45.29 | brlcad | put on an API *designer* hat ;) |
| 19:45.47 | zero_level | you will have to ship one :) |
| 19:45.51 | brlcad | you're someone who downloads libicv for integration into your awesome application |
| 19:46.17 | zero_level | ok. |
| 19:46.39 | brlcad | i'm sure you can see the impact if the API always returned nothing, for example |
| 19:46.58 | brlcad | you'd think "oh wow, I hope there's a way to check for error conditions or this really sucks" |
| 19:47.33 | brlcad | but would also be comforted in never having to wrap each call in an if (succeeded) check |
| 19:47.54 | brlcad | the other two options have their own tradeoffs |
| 19:48.17 | brlcad | of course any three can be made to work, but whether it makes sense depends on how they group |
| 19:48.41 | zero_level | is wearing *designer's hat* |
| 19:48.46 | brlcad | ;) |
| 19:48.56 | brlcad | fabulous |
| 19:49.01 | zero_level | brlcad : the whole point of having |
| 19:49.15 | zero_level | this was usability. |
| 19:49.48 | brlcad | actually maintainability, but continue :) |
| 19:49.56 | zero_level | brlcad : As I explain this. I will still leave the final call to you. If you say to change I will be doing. |
| 19:50.14 | zero_level | Now. (usability) |
| 19:50.17 | brlcad | I get that, but I'm wanting feedback from you :) |
| 19:50.27 | brlcad | what do YOU think other than ... |
| 19:50.38 | brlcad | "yeah, I can change it" or "I like it how it is" |
| 19:50.48 | brlcad | that's not useful.. :) |
| 19:50.52 | zero_level | lets primarily |
| 19:50.59 | zero_level | group these functions into 3. |
| 19:51.05 | Notify | 03BRL-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.08 | brlcad | why |
| 19:51.32 | zero_level | one which creates a new ICV structure in the run time. |
| 19:51.46 | zero_level | for eg. icv_filter3 |
| 19:52.13 | zero_level | this takes in the argument. three images. and creates the output image during function run time. |
| 19:52.45 | zero_level | so has a icv_image_t* type return. |
| 19:53.24 | zero_level | now lets see the functions of the form icv_filter(...) |
| 19:53.37 | zero_level | this does filtering in place. (doenst create a new icv |
| 19:53.45 | zero_level | _struct) |
| 19:53.54 | zero_level | on failure return -1 |
| 19:53.59 | zero_level | on succession 0. |
| 19:54.18 | zero_level | brlcad : this is type 2. (int return). |
| 19:54.30 | zero_level | type 3 : Mainly operations. |
| 19:54.44 | zero_level | oops. mainly statistics. |
| 19:56.20 | brlcad | that's basically the current state of the code |
| 19:57.06 | zero_level | brlcad : rightly figured. |
| 19:57.17 | zero_level | So do you see the poing ? |
| 19:57.27 | zero_level | c/poing/point |
| 19:57.45 | brlcad | yes and no |
| 19:57.56 | brlcad | I see you've described what you did |
| 19:58.21 | brlcad | which you tried with 15:41 < zero_level> let me explain. |
| 19:58.37 | brlcad | "there's no question why it's the way it is :)" |
| 19:58.45 | brlcad | i understand what you wrote, why it is that way |
| 19:58.58 | *** part/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) | |
| 19:59.18 | brlcad | your creation funcs return a pointer, your filters return a code, your stats ... void |
| 19:59.24 | brlcad | sure, great |
| 19:59.53 | zero_level | And All this was done in focuse with usability |
| 20:00.10 | brlcad | sure |
| 20:00.23 | zero_level | and I see usability and maintainability in two sides of a balance here. |
| 20:00.37 | brlcad | is that to say there's no room for improvement on usability? |
| 20:00.44 | brlcad | it's perfect? |
| 20:00.45 | brlcad | :) |
| 20:01.13 | zero_level | I will brlcad's suggestion here. |
| 20:01.18 | zero_level | ^seek |
| 20:01.22 | brlcad | slaps forehead |
| 20:02.00 | brlcad | I'm trying to get you to envision and explore, not defend or just accept my envisioning/exploring |
| 20:02.09 | brlcad | you don't need to defend |
| 20:02.22 | brlcad | it is what it is, it's already turning into a great API |
| 20:02.50 | brlcad | the design question is what would it look like if you enforced some homogeneity |
| 20:03.28 | zero_level | icv_Filter3 will become. |
| 20:03.45 | brlcad | what would it look like, how might it feel if, just for *example*, if you never returned a NULL pointer, for example |
| 20:04.00 | zero_level | icv_filter3(icv_image_t* ......... , icv_filter_t **out_img); |
| 20:04.27 | brlcad | now you're thinking |
| 20:04.28 | zero_level | Just wanted to avoid this situation. |
| 20:04.35 | brlcad | why |
| 20:04.48 | brlcad | what's the downside? |
| 20:05.24 | zero_level | do you remember this page. ttp://brlcad.org/wiki/User:Level_zero/GSOC13/api |
| 20:06.14 | brlcad | yep |
| 20:06.14 | zero_level | The only downside i saw was complexity. |
| 20:06.33 | brlcad | I note that you already have that pattern in some places |
| 20:06.57 | brlcad | the function that return int are mostly that pattern |
| 20:06.58 | zero_level | we also had a long discussion about that. |
| 20:07.23 | zero_level | but earlier revisions of this page will have void type. |
| 20:07.35 | zero_level | c/will have/had |
| 20:08.04 | zero_level | and then I wanted to handle error in a better way. |
| 20:08.12 | zero_level | 0 for succession |
| 20:08.18 | zero_level | -1 for failure. |
| 20:08.21 | brlcad | slow down |
| 20:08.24 | brlcad | that thought there |
| 20:08.25 | zero_level | -2 for some other.. |
| 20:08.29 | brlcad | stop |
| 20:08.37 | brlcad | you instantly jumped from WHAT to HOW |
| 20:08.46 | brlcad | the WHAT is that you found a need to handle error better |
| 20:08.50 | brlcad | that is good to recognize |
| 20:09.07 | brlcad | you instantly jumped into HOW to handle an error (via a return code) |
| 20:09.20 | brlcad | when in reality there are many ways you could handle an error |
| 20:09.25 | brlcad | not saying there's a better way |
| 20:09.33 | brlcad | but don't mix the method (how) with the need (what) |
| 20:09.45 | zero_level | I just picked it from the old version of libicv. |
| 20:09.53 | zero_level | ok. |
| 20:10.18 | brlcad | the important point is that setting a NULL img_out was insufficient error reporting |
| 20:10.25 | zero_level | I mean from the save_open and other functions. |
| 20:10.35 | brlcad | log messages were presumably insufficient as well |
| 20:11.07 | zero_level | that was my major concern And I asked you in *1 of my doubts. |
| 20:11.32 | brlcad | what was your major concern? |
| 20:11.45 | zero_level | At this point of time I am open to your suggestion. |
| 20:11.55 | zero_level | wait. |
| 20:12.08 | zero_level | finding the link. |
| 20:12.52 | zero_level | from 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.16 | brlcad | you mean your question in the commit message? |
| 20:13.47 | zero_level | no. DO you remember we had a discussion over a paste link i gave on IRC. |
| 20:13.57 | zero_level | it had around 8 links. |
| 20:14.08 | zero_level | s/links/ponts |
| 20:14.29 | zero_level | is facing lots of lag here. |
| 20:14.44 | zero_level | (ssh lag) |
| 20:15.24 | brlcad | yeah, 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.56 | brlcad | I vaguely recall that, actually, but again .. not sure it's relevant |
| 20:16.31 | zero_level | hmm. |
| 20:17.26 | zero_level | so. ? where we ? |
| 20:17.27 | brlcad | back to the design discussion... so the API you have on that wiki page is one good data point |
| 20:18.55 | brlcad | clearly, the pattern there (and the majority) is return some int code |
| 20:19.33 | brlcad | so at this point, the design question it asks is why there are functions that don't return a code |
| 20:19.45 | zero_level | brlcad : regarding the paste link. I was just able to dig. http://paste.kde.org/p38e0decb/ |
| 20:19.50 | brlcad | and would it be worthwhile to make them return a code |
| 20:20.26 | zero_level | brlcaD : that is nice question to ask. |
| 20:20.47 | brlcad | ah, *that* pastebin |
| 20:21.20 | brlcad | think that is only peripherally related to today's design questions |
| 20:21.54 | brlcad | it assumes we should be printing log messages in the first place (we probably shouldn't) |
| 20:23.43 | zero_level | I see thatvoid return could be made to return. |
| 20:24.03 | brlcad | excellent |
| 20:24.03 | zero_level | like icv_destroy(...) |
| 20:24.11 | zero_level | icv_sanitize(..) |
| 20:24.26 | brlcad | so then you're just down to two categories |
| 20:24.32 | brlcad | the creation functions and the processing functions |
| 20:24.37 | zero_level | also the vice versa could be done. like icv_Filter has void type. |
| 20:24.48 | zero_level | ok. |
| 20:25.33 | zero_level | but then we could have a global variable. ICV_ERROR. And set that. |
| 20:25.39 | brlcad | NO |
| 20:25.46 | brlcad | good thinking |
| 20:25.47 | zero_level | ok. |
| 20:25.50 | brlcad | but no globals :) |
| 20:26.00 | brlcad | no global state, no static state |
| 20:26.12 | brlcad | they don't work for multiprocessing |
| 20:26.36 | brlcad | you already have an issue of memory (what if in==out) |
| 20:27.00 | zero_level | hm ? where ? |
| 20:27.35 | brlcad | a discussion for later perhaps, but basically how many of the processing functions will not work if img_in == img_out |
| 20:27.40 | brlcad | i.e., process in place |
| 20:28.05 | brlcad | many would need to create a copy to work right |
| 20:28.15 | *** join/#brlcad vladbogo (~vlad@188.25.237.111) | |
| 20:28.30 | brlcad | or be designed to work on the copy passed in only |
| 20:28.42 | brlcad | not your doing |
| 20:28.52 | brlcad | that's how they were written to stream |
| 20:29.58 | brlcad | don't worry about it |
| 20:30.38 | zero_level | brlcad : I think I didnt understand this point of yours. |
| 20:31.15 | Notify | 03BRL-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.27 | brlcad | some 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.27 | zero_level | let me try to see what point are you making. |
| 20:31.43 | zero_level | brlcad : wait. |
| 20:31.49 | brlcad | doesn't wait |
| 20:31.52 | brlcad | multitasks |
| 20:32.03 | zero_level | wait means let me try to bring you a fact. |
| 20:32.10 | brlcad | ~dict wait |
| 20:32.40 | zero_level | actually i eamnt because i am facing ssh lag. It will take few secs. |
| 20:32.42 | brlcad | that may be what you meant, but that's not what the word means ;) |
| 20:33.24 | zero_level | brlcad : lets say icv_crop(img) is called. |
| 20:33.34 | zero_level | now it will crop the image. |
| 20:33.45 | zero_level | But in place. |
| 20:33.51 | zero_level | doesnt pass the pointer. |
| 20:34.05 | brlcad | sure |
| 20:34.09 | zero_level | output_pointer === input_pointer |
| 20:34.10 | brlcad | doesn't have an out pointer |
| 20:34.12 | brlcad | no |
| 20:34.14 | zero_level | (they are same) |
| 20:34.23 | zero_level | alright. |
| 20:34.30 | zero_level | so what point were you making ? |
| 20:35.05 | Notify | 03BRL-CAD:vladbogo * 57518 brlcad/trunk/src/libdm/dm-qt.cpp: Send mouse coordinates when generating Tk click events. |
| 20:35.06 | brlcad | looking through your header, I don't think you've gotten to any of them yet |
| 20:35.09 | brlcad | so doesn't matter |
| 20:35.22 | brlcad | had you implemented the wiki API, it would have been an issue perhaps |
| 20:36.11 | brlcad | noticed that icv_rot() is still the first bit of API readers are introduced to... |
| 20:36.17 | zero_level | excellent :) That why it semt alien to me. Thanks. |
| 20:36.18 | brlcad | should be further down |
| 20:36.24 | zero_level | alright. |
| 20:37.36 | brlcad | so parting design thought |
| 20:38.04 | brlcad | there is a cool aspect of always returning a (non-NULL) pointer that would be possible with this API |
| 20:38.21 | brlcad | you could compose calls functionally |
| 20:39.10 | brlcad | icv_flip(icv_scale(icv_random(icv_create(),...), 2.0)...); |
| 20:40.45 | brlcad | one liner programs ;) icv_destroy(icv_write(icv_flip(icv_scale(icv_random(icv_create(),...), 2.0)...), "myfile.png")); |
| 20:44.36 | Notify | 03BRL-CAD Wiki:Vladbogolin * 6112 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 12 */ |
| 20:46.10 | zero_level | brlcad : Returning non-null ? |
| 20:50.36 | zero_level | do you mean we should return a pointer to an empty icv_struct even if there is an error in input argumetns. |
| 20:54.49 | Notify | 03BRL-CAD:mohitdaga * 57519 brlcad/trunk/include/icv.h: Structure the declarations of public apis in libicv. |
| 20:56.40 | brlcad | the 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.39 | brlcad | each 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.00 | brlcad | so the error propagates up, the memory is never potentially a null pointer dereference |
| 20:58.46 | brlcad | and 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.20 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6113 /wiki/User:Izak/GSOC_2013_logs: /* September 2nd to September 7th */ |
| 21:07.22 | zero_level | brlcad : nice idea. |
| 21:07.29 | zero_level | This will require some planning. |
| 21:26.37 | zero_level | brlcad : what is take away from today's disucssion ? |
| 21:27.02 | zero_level | how should i plan. (Looking at the time as a constraint) |
| 21:34.02 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6114 /wiki/User:Izak/GSOC_2013_logs: /* September 2nd to September 7th */ |
| 21:34.15 | Notify | 03BRL-CAD:mohitdaga * 57520 brlcad/trunk/src/libicv/TODO: Remove TODO items. |
| 21:37.53 | *** join/#brlcad greenride (~purplehaz@71.202.102.140) | |
| 21:41.01 | greenride | If 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.30 | Notify | 03BRL-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.14 | Notify | 03BRL-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.38 | brlcad | zero_level: do-to file for any ideas that you think are worth pursuing |
| 22:45.29 | brlcad | zero_level: I think at a minimum, converting the void functions to return an int code for success will be worthwhile |
| 22:45.53 | brlcad | that will give you two return types that you can wrap into two macros |
| 22:46.01 | brlcad | that will at least not break the rule of three |
| 23:06.08 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |