| 02:13.51 | zero_level | ``Erik : that is what i am to. But then do we change the utilities to use the icv library. |
| 02:59.42 | Notify | 03BRL-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.40 | brlcad | zero_level: yep, maintaining duplicate functionality, even briefly, is very undesirable |
| 03:56.18 | zero_level | ok brlcad |
| 03:59.23 | *** join/#brlcad evgeny (~Miranda@109.194.34.184) | |
| 04:05.06 | brlcad | waves |
| 05:31.08 | *** join/#brlcad caen23_ (~caen23@92.81.198.131) | |
| 05:46.00 | Notify | 03BRL-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.51 | Notify | 03BRL-CAD:phoenixyjll * 56019 brlcad/trunk/src/libbrep/intersect.cpp: Eliminate unnecessary collinear points on the polyline curves. |
| 06:13.43 | Notify | 03BRL-CAD:phoenixyjll * 56020 brlcad/trunk/src/libbrep/intersect.cpp: ----------- |
| 06:34.21 | Notify | 03BRL-CAD Wiki:Phoenix * 5670 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 4 */ |
| 06:35.20 | Notify | 03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Epa_good.png: |
| 06:35.34 | Notify | 03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Epa_bad.png: |
| 06:35.43 | Notify | 03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Epa_2d_for_parabola.png: |
| 06:35.56 | Notify | 03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Epa_2d_for_plane.png: |
| 06:37.16 | Notify | 03BRL-CAD Wiki:Phoenix * 5675 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 4 */ |
| 06:43.09 | Notify | 03BRL-CAD Wiki:Phoenix * 5676 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */ |
| 06:44.43 | Notify | 03BRL-CAD Wiki:Phoenix * 5677 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */ |
| 06:46.06 | Notify | 03BRL-CAD Wiki:Phoenix * 5678 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */ |
| 07:44.00 | *** join/#brlcad evgeny (~Miranda@109.194.34.184) | |
| 08:03.36 | Notify | 03BRL-CAD Wiki:Izakkayems * 5679 /wiki/User:Izak/GSOC_2013_logs: /* From July 8th to July 13th */ |
| 08:06.34 | Notify | 03BRL-CAD Wiki:Izakkayems * 5680 /wiki/User:Izak/GSOC_2013_logs: |
| 08:23.00 | Notify | 03BRL-CAD Wiki:Izakkayems * 5681 /wiki/User:Izak/GSOC_2013_logs: /* From July 8th to July 13th */ |
| 08:34.21 | Notify | 03BRL-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.47 | brlcad | that's a lot of awesome status pics from wu |
| 14:33.33 | zero_level | hi brlcad: |
| 15:34.19 | *** join/#brlcad kesha__ (~kesha@49.249.1.27) | |
| 16:05.17 | Notify | 03BRL-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.04 | Notify | 03BRL-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.42 | Notify | 03BRL-CAD:brlcad * 56023 (brlcad/trunk/db/CMakeLists.txt brlcad/trunk/pix/CMakeLists.txt): move the cube.rt script over with the model |
| 16:31.00 | Notify | 03BRL-CAD:brlcad * 56024 brlcad/trunk/NEWS: carl's vengence on help option consistency continues to rage on. |
| 16:32.12 | brlcad | zero_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.26 | zero_level | corrected by starseeker |
| 16:34.59 | brlcad | right, but was that the right fix? |
| 16:35.16 | zero_level | yes |
| 16:35.36 | brlcad | did you not test the compilation? :) |
| 16:36.40 | zero_level | actually i had to remove a redundant variable (bif). |
| 16:36.57 | brlcad | i'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.06 | brlcad | you should always test your compile |
| 16:37.52 | zero_level | alright :-) |
| 16:38.12 | brlcad | hacking talks about this, that mistakes will happen and are expected, but especially as a new contributor you should be testing every time |
| 16:38.24 | brlcad | nobody wants a broken build :) |
| 16:43.02 | *** join/#brlcad ejno_ (~ejno@unaffiliated/kazaik) | |
| 16:54.03 | Notify | 03BRL-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.15 | Notify | 03BRL-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.07 | zero_level | brlcad, 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.32 | zero_level | a) It will not compile cleanly because of existing use of ICV. |
| 18:26.47 | zero_level | b) 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.37 | Notify | 03BRL-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.58 | brlcad | zero_level: so a/b raises a good discussion point about how to structure changes |
| 19:13.18 | brlcad | because we want changes to compile cleanly AND to be as small as possible |
| 19:13.23 | brlcad | whether they are patches or commits |
| 19:13.53 | brlcad | so the question is how you can structure the changes (incrementally) such that each incremental step is clean, applies cleanly, compiles, etc |
| 19:18.42 | zero_level | I 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.14 | zero_level | and ofcourse icv.h and fileformat.c |
| 19:19.54 | zero_level | for fileformat.c i have devided it into different files |
| 19:20.18 | zero_level | image.c (has functions to create image, zero_image, save/load image) |
| 19:20.55 | zero_level | pixel.c has function for pixels (write line and write single pixel) |
| 19:21.02 | brlcad | I think you're missing my point |
| 19:21.16 | brlcad | you've made lots of changes |
| 19:21.22 | zero_level | yes |
| 19:21.22 | brlcad | that's fine, that's development |
| 19:21.45 | zero_level | i was coming to your point and the minimum we can do here |
| 19:21.51 | brlcad | the topic is HOW those changes are contributed |
| 19:22.19 | brlcad | just because you changed a lot doesn't mean a lot should be changed at once |
| 19:22.26 | zero_level | that said i mean, the smallest commit /patch size will require |
| 19:22.31 | zero_level | the following |
| 19:23.56 | zero_level | all the files with the existing use of icv functions (will require changing 5-6 lines in each file )[7 files in total] |
| 19:23.59 | zero_level | icv.h |
| 19:24.04 | zero_level | and fileformat.c |
| 19:24.16 | brlcad | that's fine |
| 19:24.24 | brlcad | if that really is the smallest possible chunk |
| 19:25.09 | zero_level | And ofcourse chaning the current files were tricky. |
| 19:25.14 | brlcad | the point is just to make sure that you're thinking about it at the smallest possible piece |
| 19:25.37 | brlcad | like if you have a structure and you can get by changing just one field, then not grouping that field with others |
| 19:25.46 | brlcad | just an example, it's not always possible |
| 19:25.49 | brlcad | often is |
| 19:26.14 | brlcad | if you've done it that way, then your patches should review cleanly/quickly |
| 19:27.13 | zero_level | brlcad as per our discussion the two modifications we brought (removing the file info and changing data pointer) |
| 19:27.51 | zero_level | it was required that we change the function definitions. |
| 19:28.06 | zero_level | and thus it required chaning the exisitng use |
| 19:28.27 | brlcad | this will make more sense with a concrete example if there's a problem |
| 19:28.31 | zero_level | for instance previously icv usage was |
| 19:28.48 | zero_level | icv_save_open(...) |
| 19:29.00 | zero_level | .. do pixel write ... |
| 19:29.06 | zero_level | icv_save close |
| 19:29.12 | zero_level | but now it is |
| 19:29.17 | zero_level | icv_create_image |
| 19:29.28 | zero_level | ..do pixel write.. |
| 19:29.35 | zero_level | icV_save_image |
| 19:29.47 | brlcad | sure |
| 19:30.00 | brlcad | good example |
| 19:30.28 | brlcad | so if the two functions MUST be changed simulataneously, then they obviously go together in a patch |
| 19:30.46 | brlcad | if it's possible to just update icv_save_open() first, then it might make sense for two patches |
| 19:31.00 | zero_level | yes. I think u got the point |
| 19:31.03 | brlcad | it might make sense to change the struct field as a patch, then two more patches for the function names |
| 19:31.12 | brlcad | it all depends |
| 19:31.46 | zero_level | but the moment i change the structure definition it will give errors because the file field is used |
| 19:32.12 | brlcad | when I say change the field, that means updating all of the places that field is used too |
| 19:33.09 | zero_level | but then the input parameters of icv_save_open will have to change thus changing the file where it is used |
| 19:33.18 | brlcad | i.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.21 | brlcad | whether it makes sense to do that depends on the code |
| 19:34.20 | brlcad | zero_level: it's okay really! :) |
| 19:34.44 | brlcad | i saids that IF they MUST be changed simulataneously, then sure .. it makes sense to put them together |
| 19:35.06 | brlcad | all I'm suggesting is to look at the changes from a minimalism perspective |
| 19:35.13 | brlcad | and perhaps you already have done this |
| 19:35.19 | brlcad | if you have GREAT! :) |
| 19:35.28 | brlcad | if you have not, it's something that most people have to learn |
| 19:35.37 | zero_level | thanks for understanding this. |
| 19:35.49 | brlcad | I'm hoping YOU are understanding what I'm trying to tell you |
| 19:36.01 | brlcad | I get what you're saying, and you're being defensive |
| 19:36.02 | zero_level | Actually i wrote these sometimes around the starting of the last week |
| 19:36.06 | brlcad | you don't need to be defensive :) |
| 19:36.11 | zero_level | sure |
| 19:36.25 | zero_level | and was thinking about the contributing changes. |
| 19:36.46 | zero_level | But I refrained from submitting it in a patch. Because of the size. |
| 19:37.13 | zero_level | and then i made all the notes regarding minimum changes i have to make. |
| 19:37.21 | zero_level | and this included the existing files |
| 19:37.30 | zero_level | so. Here we are. |
| 19:37.36 | brlcad | the question to ask yourself is "can I separate any part of it into a separate patch?" |
| 19:37.58 | brlcad | if you cannot, then it's approaching a perfect succinct commit |
| 19:38.34 | brlcad | a "minimal" patch can be 10 lines ... and it can be 100000 lines |
| 19:38.48 | zero_level | thats the beauty of the word ;) |
| 19:38.57 | brlcad | the point is thinking about what REALLY is minimal |
| 19:39.13 | zero_level | depends in situations. |
| 19:39.17 | brlcad | sometimes you can change the way you change the code and get incremental changes |
| 19:39.23 | brlcad | yes, depending on the situation |
| 19:39.34 | brlcad | sometimes it'll even be slightly more work |
| 19:39.51 | zero_level | Earlier I submitted a patch with all the load functionality (pix,bw,png) |
| 19:40.02 | brlcad | yep, I remember |
| 19:40.05 | zero_level | but ``Erik advised me to do minimum |
| 19:40.11 | zero_level | and thus i splited |
| 19:40.16 | brlcad | clearly breaks into at least three different patches |
| 19:40.21 | brlcad | maybe more |
| 19:40.53 | zero_level | one of then is still at 210 |
| 19:41.04 | zero_level | waiting to be reviewed |
| 19:41.53 | brlcad | nods |
| 19:42.08 | brlcad | last two weeks have involved extensive release preparations |
| 19:42.38 | brlcad | why I was pressuring people to get those patches in and reviewed before GSoC, we knew it was going to get busy |
| 19:42.57 | brlcad | still, I'll be reviewing lots more today and tomorrow so will be getting to whether are next in the queue |
| 19:42.58 | zero_level | yeah. I saw on the IRC. and ``Erik also told me about his compilation for different OSs |
| 19:43.01 | brlcad | hopefully all clean :) |
| 19:43.31 | zero_level | yeah still we have time. |
| 19:44.03 | zero_level | Actually I did nt account for changing exisitng function in the time line |
| 19:44.25 | zero_level | but i am done with them now. |
| 19:44.38 | zero_level | feels 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.52 | Notify | 03BRL-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.31 | brlcad | zero_level: thanks for updating them |
| 20:47.07 | zero_level | Although those two patches apply cleanly and compile as well. But I have implemented them with the new icv_structures. |
| 20:47.17 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5683 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 8 July - 14 July */ |
| 20:47.43 | zero_level | and functions properly ;) |
| 20:50.37 | zero_level | Also now 209, 210 are the only ones. |
| 20:56.48 | Notify | 03BRL-CAD Wiki:195.24.210.66 * 5684 /wiki/User:Izak/GSOC_2013_logs: /* From July 8th to July 13th */ |
| 21:23.51 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5685 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 4 */ |
| 21:24.24 | DarkCalf | waves to brlcad |
| 22:39.42 | ``Erik | zero_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.30 | brlcad | ``Erik: safe travels |