IRC log for #brlcad on 20130712

02:13.51zero_level``Erik : that is what i am to. But then do we change the utilities to use the icv library.
02:59.42Notify03BRL-CAD:phoenixyjll * 56017 brlcad/trunk/src/libbrep/intersect.cpp: The original code cannot deal with elliptical arcs that cross the point where t=0, and fixed this problem.
03:48.40brlcadzero_level: yep, maintaining duplicate functionality, even briefly, is very undesirable
03:56.18zero_levelok brlcad
03:59.23*** join/#brlcad evgeny (~Miranda@109.194.34.184)
04:05.06brlcadwaves
05:31.08*** join/#brlcad caen23_ (~caen23@92.81.198.131)
05:46.00Notify03BRL-CAD:phoenixyjll * 56018 brlcad/trunk/src/libbrep/intersect.cpp: Use max_dis_u (v, s, t) seperately as the scale of their domains may differ a lot.
06:11.51Notify03BRL-CAD:phoenixyjll * 56019 brlcad/trunk/src/libbrep/intersect.cpp: Eliminate unnecessary collinear points on the polyline curves.
06:13.43Notify03BRL-CAD:phoenixyjll * 56020 brlcad/trunk/src/libbrep/intersect.cpp: -----------
06:34.21Notify03BRL-CAD Wiki:Phoenix * 5670 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 4 */
06:35.20Notify03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Epa_good.png:
06:35.34Notify03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Epa_bad.png:
06:35.43Notify03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Epa_2d_for_parabola.png:
06:35.56Notify03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Epa_2d_for_plane.png:
06:37.16Notify03BRL-CAD Wiki:Phoenix * 5675 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 4 */
06:43.09Notify03BRL-CAD Wiki:Phoenix * 5676 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */
06:44.43Notify03BRL-CAD Wiki:Phoenix * 5677 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */
06:46.06Notify03BRL-CAD Wiki:Phoenix * 5678 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */
07:44.00*** join/#brlcad evgeny (~Miranda@109.194.34.184)
08:03.36Notify03BRL-CAD Wiki:Izakkayems * 5679 /wiki/User:Izak/GSOC_2013_logs: /* From July 8th to July 13th */
08:06.34Notify03BRL-CAD Wiki:Izakkayems * 5680 /wiki/User:Izak/GSOC_2013_logs:
08:23.00Notify03BRL-CAD Wiki:Izakkayems * 5681 /wiki/User:Izak/GSOC_2013_logs: /* From July 8th to July 13th */
08:34.21Notify03BRL-CAD Wiki:Izakkayems * 5682 /wiki/User:Izak/GSOC_2013_logs: /* From July 8th to July 13th */
08:48.20*** join/#brlcad evgeny (~Miranda@109.194.34.184)
09:12.22*** join/#brlcad caen23 (~caen23@92.81.198.131)
10:18.51*** join/#brlcad yiyus (1242712427@je.je.je)
10:29.27*** join/#brlcad evgeny_t (~Miranda@109.194.34.184)
10:43.46*** join/#brlcad kesha (~kesha@223.237.136.225)
10:57.19*** join/#brlcad kesha (~kesha@223.237.136.225)
12:39.14*** join/#brlcad ejno (~ejno@unaffiliated/kazaik)
13:30.34*** join/#brlcad kesha_ (~kesha@49.249.9.87)
13:55.47brlcadthat's a lot of awesome status pics from wu
14:33.33zero_levelhi brlcad:
15:34.19*** join/#brlcad kesha__ (~kesha@49.249.1.27)
16:05.17Notify03BRL-CAD:brlcad * 56021 brlcad/trunk/pix/CMakeLists.txt: the lackluster lgt examples are pretty much useless at 91, 128, and 64 dimensions, serve no useful purpose. remove them.
16:11.04Notify03BRL-CAD:brlcad * 56022 brlcad/trunk/pix/CMakeLists.txt: remove the other three example images as they're no longer interesting or impressive. if we're to ship demo renderings, we should establish quality criteria and a fixed image size. for now, the website gallery suffices leaving only the benchmark images remaining.
16:14.42Notify03BRL-CAD:brlcad * 56023 (brlcad/trunk/db/CMakeLists.txt brlcad/trunk/pix/CMakeLists.txt): move the cube.rt script over with the model
16:31.00Notify03BRL-CAD:brlcad * 56024 brlcad/trunk/NEWS: carl's vengence on help option consistency continues to rage on.
16:32.12brlcadzero_level: (hi!) not sure how it happened, but patch 197 (already applied) apparently didn't compile... should that fd have been bif->fd?
16:33.26zero_levelcorrected by starseeker
16:34.59brlcadright, but was that the right fix?
16:35.16zero_levelyes
16:35.36brlcaddid you not test the compilation? :)
16:36.40zero_levelactually i had to remove a redundant variable (bif).
16:36.57brlcadi'm sure it was just an oversight, but that's the attention to detail that will be needed when you are committing directly (and even more so when making patch files)
16:37.06brlcadyou should always test your compile
16:37.52zero_levelalright :-)
16:38.12brlcadhacking talks about this, that mistakes will happen and are expected, but especially as a new contributor you should be testing every time
16:38.24brlcadnobody wants a broken build :)
16:43.02*** join/#brlcad ejno_ (~ejno@unaffiliated/kazaik)
16:54.03Notify03BRL-CAD:brlcad * 56025 (brlcad/trunk/CMakeLists.txt brlcad/trunk/TODO brlcad/trunk/doc/CMakeLists.txt): move shaded-display todo into doc/ subdir with the other existing todo.brep and reference where it's at in the main TODO file.
17:02.12*** join/#brlcad yiyus_ (1242712427@je.je.je)
17:10.41*** join/#brlcad caen23 (~caen23@92.81.198.131)
17:18.15Notify03BRL-CAD:brlcad * 56026 (brlcad/trunk/CMakeLists.txt brlcad/trunk/bench/CMakeLists.txt brlcad/trunk/bench/run.sh): change to a crazy long legacy. now that there are nothing but benchmark reference pix and log files in the top-level pix/ directory, move that directory to bench/ref/ and update accordingly. keep installation as pix/ though so we preserve the current installation hierarchy.
17:40.28*** join/#brlcad kesha (~kesha@223.228.81.168)
17:50.28*** join/#brlcad cstirk (~quassel@c-71-56-216-45.hsd1.co.comcast.net)
18:04.00*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
18:04.06*** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
18:04.48*** join/#brlcad crdueck (~cdk@24-212-219-10.cable.teksavvy.com)
18:12.17*** join/#brlcad caen23 (~caen23@92.81.198.131)
18:22.17*** join/#brlcad caen23 (~caen23@92.81.198.131)
18:25.07zero_levelbrlcad, will ensure this doesnt happen in future. Indeed this was the reason I have not submitted the patches of new ICV functions and structure definition.
18:25.32zero_levela) It will not compile cleanly because of existing use of ICV.
18:26.47zero_levelb) If I incorporate the changes in the exiting code in a patc, either this will make lots of patches or a single patch will be very large.
18:38.27*** join/#brlcad cstirk_ (~quassel@c-71-56-216-45.hsd1.co.comcast.net)
19:00.11*** join/#brlcad avneet (~avneet@202.164.53.122)
19:00.45*** join/#brlcad harmanpreet (~harman@202.164.53.122)
19:09.37Notify03BRL-CAD:brlcad * 56027 brlcad/trunk/src/libbrep/intersect.cpp: we might not care, but implementers of qsort() care, which is what opennurbs ultimately ends up passing this callback to. future We might care too, so cover our bases.
19:12.58brlcadzero_level: so a/b raises a good discussion point about how to structure changes
19:13.18brlcadbecause we want changes to compile cleanly AND to be as small as possible
19:13.23brlcadwhether they are patches or commits
19:13.53brlcadso the question is how you can structure the changes (incrementally) such that each incremental step is clean, applies cleanly, compiles, etc
19:18.42zero_levelI have changed them in a  private trunk on my machine this needed chaning rt/do.c rt/ext.h rt/view.c rt/viewedge.c  remrt/rtsrv.c libged/screengrab.c
19:19.13*** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99)
19:19.14zero_leveland ofcourse icv.h and fileformat.c
19:19.54zero_levelfor fileformat.c i have devided it into different files
19:20.18zero_levelimage.c (has functions to create image, zero_image, save/load image)
19:20.55zero_levelpixel.c has function for pixels (write line and write single pixel)
19:21.02brlcadI think you're missing my point
19:21.16brlcadyou've made lots of changes
19:21.22zero_levelyes
19:21.22brlcadthat's fine, that's development
19:21.45zero_leveli was coming to your point and the minimum we can do here
19:21.51brlcadthe topic is HOW those changes are contributed
19:22.19brlcadjust because you changed a lot doesn't mean a lot should be changed at once
19:22.26zero_levelthat said i mean, the smallest commit /patch size will require
19:22.31zero_levelthe following
19:23.56zero_levelall the files with the existing use of icv functions (will require changing 5-6 lines in each file )[7 files in total]
19:23.59zero_levelicv.h
19:24.04zero_leveland fileformat.c
19:24.16brlcadthat's fine
19:24.24brlcadif that really is the smallest possible chunk
19:25.09zero_levelAnd ofcourse chaning the current files were tricky.
19:25.14brlcadthe point is just to make sure that you're thinking about it at the smallest possible piece
19:25.37brlcadlike if you have a structure and you can get by changing just one field, then not grouping that field with others
19:25.46brlcadjust an example, it's not always possible
19:25.49brlcadoften is
19:26.14brlcadif you've done it that way, then your patches should review cleanly/quickly
19:27.13zero_levelbrlcad as per our discussion the two modifications we brought (removing the file info and changing data pointer)
19:27.51zero_levelit was required that we change the function definitions.
19:28.06zero_leveland thus it required chaning the exisitng use
19:28.27brlcadthis will make more sense with a concrete example if there's a problem
19:28.31zero_levelfor instance previously icv usage was
19:28.48zero_levelicv_save_open(...)
19:29.00zero_level.. do pixel write ...
19:29.06zero_levelicv_save close
19:29.12zero_levelbut now it is
19:29.17zero_levelicv_create_image
19:29.28zero_level..do pixel write..
19:29.35zero_levelicV_save_image
19:29.47brlcadsure
19:30.00brlcadgood example
19:30.28brlcadso if the two functions MUST be changed simulataneously, then they obviously go together in a patch
19:30.46brlcadif it's possible to just update icv_save_open() first, then it might make sense for two patches
19:31.00zero_levelyes. I think u got the point
19:31.03brlcadit might make sense to change the struct field as a patch, then two more patches for the function names
19:31.12brlcadit all depends
19:31.46zero_levelbut the moment i change the structure definition it will give errors because the file field is used
19:32.12brlcadwhen I say change the field, that means updating all of the places that field is used too
19:33.09zero_levelbut then the input parameters of icv_save_open will have to change thus changing the file where it is used
19:33.18brlcadi.e., I can change the field and update the callers as one patch, I could change the function names as another, and change function arguments as yet a third
19:33.21brlcadwhether it makes sense to do that depends on the code
19:34.20brlcadzero_level: it's okay really! :)
19:34.44brlcadi saids that IF they MUST be changed simulataneously, then sure .. it makes sense to put them together
19:35.06brlcadall I'm suggesting is to look at the changes from a minimalism perspective
19:35.13brlcadand perhaps you already have done this
19:35.19brlcadif you have GREAT! :)
19:35.28brlcadif you have not, it's something that most people have to learn
19:35.37zero_levelthanks for understanding this.
19:35.49brlcadI'm hoping YOU are understanding what I'm trying to tell you
19:36.01brlcadI get what you're saying, and you're being defensive
19:36.02zero_levelActually i wrote these sometimes around the starting of the last week
19:36.06brlcadyou don't need to be defensive :)
19:36.11zero_levelsure
19:36.25zero_leveland was thinking about the contributing changes.
19:36.46zero_levelBut I refrained from submitting it in a patch. Because of the size.
19:37.13zero_leveland then i made all the notes regarding minimum changes i have to make.
19:37.21zero_leveland this included the existing files
19:37.30zero_levelso. Here we are.
19:37.36brlcadthe question to ask yourself is "can I separate any part of it into a separate patch?"
19:37.58brlcadif you cannot, then it's approaching a perfect succinct commit
19:38.34brlcada "minimal" patch can be 10 lines ... and it can be 100000 lines
19:38.48zero_levelthats the beauty of the word ;)
19:38.57brlcadthe point is thinking about what REALLY is minimal
19:39.13zero_leveldepends in situations.
19:39.17brlcadsometimes you can change the way you change the code and get incremental changes
19:39.23brlcadyes, depending on the situation
19:39.34brlcadsometimes it'll even be slightly more work
19:39.51zero_levelEarlier I submitted a patch with all the load functionality (pix,bw,png)
19:40.02brlcadyep, I remember
19:40.05zero_levelbut ``Erik advised me to do minimum
19:40.11zero_leveland thus i splited
19:40.16brlcadclearly breaks into at least three different patches
19:40.21brlcadmaybe more
19:40.53zero_levelone of then is still at 210
19:41.04zero_levelwaiting to be reviewed
19:41.53brlcadnods
19:42.08brlcadlast two weeks have involved extensive release preparations
19:42.38brlcadwhy I was pressuring people to get those patches in and reviewed before GSoC, we knew it was going to get busy
19:42.57brlcadstill, I'll be reviewing lots more today and tomorrow so will be getting to whether are next in the queue
19:42.58zero_levelyeah. I saw on the IRC. and ``Erik also told me about his compilation for different OSs
19:43.01brlcadhopefully all clean :)
19:43.31zero_levelyeah still we have time.
19:44.03zero_levelActually I did nt account for changing exisitng function in the time line
19:44.25zero_levelbut i am done with them now.
19:44.38zero_levelfeels relieved
19:56.01*** join/#brlcad cstirk (~quassel@c-71-56-216-45.hsd1.co.comcast.net)
20:06.32*** join/#brlcad ChanServ (ChanServ@services.)
20:06.32*** mode/#brlcad [+o ChanServ] by orwell.freenode.net
20:15.05*** join/#brlcad kesha (~kesha@223.229.135.134)
20:42.52Notify03BRL-CAD:brlcad * 56028 brlcad/trunk/include/common.h: restructure the logic so that we clearly assert expectation that this header will always be included before system headers. this is particularly important on Windows, thus we should not need pragma warnings. conveniently, it's a few lines shorter and reduces a scope too.
20:44.31brlcadzero_level: thanks for updating them
20:47.07zero_levelAlthough those two patches apply cleanly and compile as well. But I have implemented them with the new icv_structures.
20:47.17Notify03BRL-CAD Wiki:NyahCh3ck20 * 5683 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 8 July - 14 July */
20:47.43zero_leveland functions properly ;)
20:50.37zero_levelAlso now 209, 210 are the only ones.
20:56.48Notify03BRL-CAD Wiki:195.24.210.66 * 5684 /wiki/User:Izak/GSOC_2013_logs: /* From July 8th to July 13th */
21:23.51Notify03BRL-CAD Wiki:KeshaSShah * 5685 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 4 */
21:24.24DarkCalfwaves to brlcad
22:39.42``Erikzero_level, brlcad: I am finishing up packing for vacation, I will be out of touch for about a week
23:19.53*** join/#brlcad cstirk (~quassel@c-71-56-216-45.hsd1.co.comcast.net)
23:25.30brlcad``Erik: safe travels

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