| 00:07.59 | *** join/#brlcad infobot (~infobot@rikers.org) |
| 00:07.59 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GSoC 2013! http://brlcad.org/wiki/Google_Summer_of_Code |
| 02:42.10 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) |
| 04:11.06 | brlcad | zero_level: where is the output file closed? |
| 04:11.33 | brlcad | (during rt/rtedge/rtwhatever ... used to be during view_end() |
| 04:23.11 | brlcad | zero_level: and your icv_image_save() changes seem to be at the heart of the benchmark failures |
| 04:23.36 | brlcad | you made it so that an unrecognized format results in no file being written out |
| 04:24.19 | brlcad | there are compound problems |
| 04:26.29 | brlcad | the guess routine should have recognized this format (base.pix.*) for starters |
| 04:27.12 | brlcad | arguably all unrecognized formats should simply default to pix |
| 04:27.36 | brlcad | as an output file is clearly expected |
| 04:29.07 | brlcad | also, the logic in icv_image_save is flawed -- the initial else is always true |
| 04:31.49 | brlcad | and the style has errors |
| 04:40.06 | brlcad | er, what the heck is ICV_IMAGE_AUTO_NO_PIX supposed to mean... |
| 04:55.15 | Notify | 03BRL-CAD:brlcad * 56312 brlcad/trunk/bench/run.sh: issue a warning if a frame image is not produced. something probably went wrong up in rt land. |
| 04:55.52 | Notify | 03BRL-CAD:brlcad * 56313 brlcad/trunk/include/icv.h: ws |
| 04:59.58 | Notify | 03BRL-CAD:brlcad * 56314 brlcad/trunk/src/libicv/fileformat.c: icv_image_save() cannot fail to do what it's told or we'll have to update all possible caller code to have pix fallback recovery code. no reason that cannot happen here. guess the format, but use PIX for anything unrecognized. note some bad fixed-size buffer assumptions already getting introduced. |
| 05:02.46 | Notify | 03BRL-CAD:brlcad * 56315 brlcad/trunk/src/libicv/fileformat.c: ws consistency cleanup |
| 05:04.03 | Notify | 03BRL-CAD:brlcad * 56316 brlcad/trunk/src/libicv/fileformat.c: cleanup, make pix_save a more clear default |
| 05:05.04 | Notify | 03BRL-CAD:brlcad * 56317 brlcad/trunk/src/rt/view.c: if icv_write_pixel does not require locking elsewhere, why does it require it here? |
| 05:10.04 | brlcad | zero_level: please review all of those commits so you can avoid similar problems in the future |
| 05:10.07 | brlcad | (and so you can clean up any other issues that I may have missed) |
| 05:11.18 | Notify | 03BRL-CAD Wiki:Fengn cshou * 0 /wiki/User:Fengn_cshou: |
| 05:12.58 | brlcad | having just spent several hours debugging an issue you introduced, I think it's fair to say that you need to be more careful in your coding, more thorough in testing, and more aware of style .. please work on this |
| 05:14.55 | zero_level | brlcad : All the output files are closed in do.c at line 923 |
| 05:15.02 | zero_level | *rt/do.c |
| 05:18.24 | zero_level | brlcad : I noticed the writepixel semaphore. Didnt remove that because writepixel doesn't need to acquire BU_SEM_SYSCALL |
| 05:20.26 | Notify | 03BRL-CAD:brlcad * 56318 (brlcad/trunk/include/icv.h brlcad/trunk/src/libicv/fileformat.c brlcad/trunk/src/rt/do.c): while these types should not be undocumented to begin with (code complete failure), I do not see the point of ICV_IMAGE_AUTO_NO_PIX or passing a type. we can enforce a type using a string convention (e.g. png:mypngfile.out) and basically always be 'inferred'. nix the ICV_IMAGE_AUTO_NO_PIX type for |
| 05:20.28 | Notify | now until a utility can be demonstrated. icv_image_save() should never do nothing. |
| 05:21.23 | brlcad | zero_level: so it becomes an unsuspecting bug for a future developer to spend time debugging? |
| 05:21.44 | brlcad | if the icv routine doesn't make a system call, it shouldn't acquire that lock |
| 05:22.02 | brlcad | moreover if it DID, that lock should be happening down inside ICV, not in rt application code |
| 05:22.34 | brlcad | the fb_*() routines were being considered system calls, hence the need for protections, but that's not the case with icv |
| 05:23.01 | zero_level | brlcad : Atleast we have started agreeing on this :-) |
| 05:23.47 | zero_level | regarding ICV_AUTO_NO_PIX it was a format which suggested to do automatically. But not pix. |
| 05:24.15 | zero_level | I just thought it was a convention looking at the previous code. And found it odd. |
| 05:24.28 | brlcad | i'm not even sure what that means |
| 05:24.29 | zero_level | Its nice that you have clariefied it with commites. |
| 05:25.08 | brlcad | the more critical issue is that icv_image_write() had a couple paths that would return 0 without doing anything |
| 05:25.12 | zero_level | I mean find image format automatically by seeing the name. |
| 05:25.12 | brlcad | that was critically bad |
| 05:25.46 | brlcad | oh i completely got that part, that's obvious |
| 05:25.55 | brlcad | what's not obvious is the value/reason/purpose |
| 05:26.12 | brlcad | ICV_IMAGE_AUTO infers from the name automatically as well |
| 05:26.36 | brlcad | what's the point of inferring anything except pix |
| 05:26.58 | brlcad | from an API design, it stinks to me |
| 05:27.30 | brlcad | even the notion of auto or API-types seems not ideal |
| 05:27.45 | brlcad | it should infer it, always |
| 05:28.19 | brlcad | no option needed, override would be part of the convention |
| 05:28.51 | brlcad | zero_level: I'm more concerned about the overall trend in that code |
| 05:29.31 | brlcad | it's brand new code and it's already got several code stinks in there, not a good foundation |
| 05:30.54 | brlcad | I'd suggest focusing at some point soon on eliminating the two fixed buffer sizes as well as the separation of fileformat.c ... |
| 05:30.57 | brlcad | there are clearly two categories of functions in that file that would be better encapsulated in separate files |
| 05:31.20 | zero_level | I have done that in my repo. |
| 05:31.31 | zero_level | image.c for icv_image_create |
| 05:31.43 | zero_level | icv_load |
| 05:31.46 | zero_level | icv_save |
| 05:31.55 | zero_level | free, zero |
| 05:32.05 | zero_level | pixel.c for writepixel writeline |
| 05:32.10 | zero_level | icv_bw.c |
| 05:32.14 | zero_level | icv_ppm.c |
| 05:32.19 | zero_level | icv_pix.c |
| 05:32.21 | zero_level | icv_png.c |
| 05:32.52 | Notify | 03BRL-CAD:brlcad * 56319 brlcad/trunk/src/libicv/fileformat.c: this is a brand new library. we can't get off the ground with fixed limits already getting introduced unnecssarily. |
| 05:33.38 | brlcad | it doesn't exist to me until it's committed properly |
| 05:34.15 | brlcad | don't let local commit be a crutch for coding complete, testing, and integrating properly |
| 05:35.41 | brlcad | if you're going to prefix some, there better be a darn good reason why the others aren't as well |
| 05:35.53 | brlcad | and vice versa |
| 05:42.46 | zero_level | the reason it was ICV_AUTO_NO_PIX was because rtxray required bw images. |
| 05:43.38 | zero_level | I guess, there was a need such that they cannot let all the images to be of pix format. A hirarchy I recieved in previous icv code. |
| 05:44.22 | zero_level | Although I am not sure about the reason but a guess. |
| 05:47.19 | brlcad | but would that not be inferred from the file.bw suffix |
| 05:48.00 | brlcad | the guess code is still there, and indeed it was guessing for ICV_AUTO_NO_PIX as well, just doing nothing if it didn't recognize |
| 05:48.47 | brlcad | that just doesn't make any logical sense to me |
| 05:49.29 | brlcad | it's not "letting all images be pix format" ... |
| 05:50.06 | brlcad | it's letting unrecognized files always be something, which was the critical problem |
| 05:51.34 | brlcad | moreover, I'd still expect rtxray -o file.png ... to do the right thing, to write out the bw data in png format (as 3-channel or 1-channel) |
| 06:16.01 | zero_level | ya understood it. But was counting on the experience of the person who introduced it. |
| 06:28.13 | *** join/#brlcad caen23_ (~caen23@92.83.187.206) |
| 06:57.54 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 07:49.17 | *** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16) |
| 07:55.49 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 08:41.30 | Notify | 03BRL-CAD:mohitdaga * 56320 brlcad/trunk/src/libicv/fileformat.c: Remove comments of old declaration of icv_image_save_close(..). New implementation of icv_image_save doesnot require return values related to file discriptor since icv_image struct doesnt contain fd information anymore. And icv_image_save() always opens and closes the image on success. |
| 08:53.10 | *** join/#brlcad caen23 (~caen23@92.83.187.206) |
| 08:59.14 | Ch3ck_ | working on a unit tests for /src/libbn/poly.c Well since my unit tests have to test the current functions against known values. I'm i suppose to write a new function I know that works which evaluates correctly and test against the bn_poly_multiply() or I should use known correct values for input and output? |
| 08:59.45 | Ch3ck_ | like +case, -case and 0 cases? |
| 09:14.03 | *** join/#brlcad caen23 (~caen23@92.83.187.206) |
| 09:29.43 | Notify | 03BRL-CAD Wiki:Who Thommy * 0 /wiki/User:Who_Thommy: |
| 10:13.08 | *** join/#brlcad Izak_ (~Izak@195.24.220.16) |
| 10:50.31 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5871 /wiki/User:Izak/GSOC_2013_logs: /* Mid-term Evaluation week */ |
| 11:08.27 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 11:15.28 | Notify | 03BRL-CAD:d_rossberg * 56321 (brlcad/trunk/doc/docbook/system/man1/en/g-stl.xml brlcad/trunk/src/conv/stl/g-stl.c): apply Jonathan's patch from https://sourceforge.net/p/brlcad/patches/195/ - updated the usage strings and man pages, and made them a little more readable |
| 11:30.31 | Notify | 03BRL-CAD:d_rossberg * 56322 brlcad/trunk/AUTHORS: credit Jonathan for his g-raw converter (sf patch 195) |
| 11:32.24 | Notify | 03BRL-CAD:phoenixyjll * 56323 brlcad/trunk/src/libbrep/intersect.cpp: Fix the wrong logic of determining whether a bounding box (or a point) is inside an overlap region or not. |
| 12:06.45 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5872 /wiki/User:Izak/GSOC_2013_logs: /* Mid-term Evaluation week */ |
| 12:10.41 | brlcad | Ch3ck_: known correct input/output values for a variety of cases including some extreme ones |
| 12:11.10 | brlcad | e.g. are the values correct for large magnitude coefficients with small magnitude |
| 12:11.20 | brlcad | or large+large or small+small, etc |
| 12:11.24 | Ch3ck_ | thats what i thought . Can you please explain the 'EXTREME' cases |
| 12:12.09 | Ch3ck_ | ok i get it for very large coeff. |
| 12:15.15 | ``Erik | ICV_IMAGE_AUTO_NO_PIX was to return an 'unknown' instead of pix for apps that default to something other than pix, so the app can figure out what to do |
| 12:17.05 | ``Erik | per-app overrides without eliminating pix as an output format |
| 12:19.37 | ``Erik | ("rtxray -o blah" will generate a bw file, if icv is just blindly slapped in, it'll change behavior and generator pix... auto_no_pix and then set to bw if a type can't be determined, now -o blah.png does the right thing, but -o blah doesn't change) |
| 12:28.47 | Notify | 03BRL-CAD Wiki:Phoenix * 5873 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 7 */ |
| 12:29.29 | Notify | 03BRL-CAD Wiki:Phoenix * 5874 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 7 */ |
| 12:33.51 | zero_level | ``Erik : thanks. |
| 12:34.00 | brlcad | I'd think that can still be done with a naming convention and one arg then |
| 12:34.57 | brlcad | where the name specifies any intent, the format specifies a 'default' hint (which can be overridden with convention and the type can still be inferred |
| 12:35.47 | brlcad | icvwrite("file", ICV_IMAGE_BW) would say write a bw file by default if you cannot infer what "file" is |
| 12:36.13 | brlcad | icvwrite("file.png", ICV_IMAGE_BW) would make it write a png file |
| 12:36.34 | brlcad | icvwrite("bw:file.png", ICV_IMAGE_BW) would make it write a bw file named file.png |
| 12:37.13 | brlcad | my assertion is that there shouldn't be a case where icvwrite ... doesn't write |
| 12:37.24 | brlcad | at least I think it would be good to devise a usage where that never needs to happen |
| 12:37.33 | brlcad | and have that usage documented in the header |
| 12:37.41 | brlcad | thoughts? |
| 12:37.58 | brlcad | will pick this thread up in a few |
| 13:31.27 | DarkCalf | waves to brlcad |
| 13:53.11 | Notify | 03BRL-CAD:mohitdaga * 56324 (brlcad/trunk/include/icv.h brlcad/trunk/src/libicv/CMakeLists.txt): Adding new file libicv/crop.c. This will cropping functions. Adding icv_rect api. This extracts any rectangular part of the image. |
| 13:54.55 | brlcad | howdy DarkCalf |
| 13:57.13 | Notify | 03BRL-CAD:mohitdaga * 56325 (brlcad/trunk/include/icv.h brlcad/trunk/src/libicv/crop.c): Adding icv_crop function. This can extract image from any quadrilateral part and maps it to a rectangulare image. |
| 13:57.52 | Izak_ | Ch3ck: Are u thee? |
| 13:58.25 | zero_level | Email shows a bad graphic. All though vim and gedit shows it right. ;) |
| 13:59.50 | zero_level | brlcad : I am waiting for ``Erik's suggestion. But your suggestion seems fine. |
| 14:00.01 | zero_level | It is similar to how matlab does it. |
| 14:00.50 | zero_level | Also once all the formats are written. (I will work on formats after utilities 3 weeks are given for that.) I think we can revert to this. |
| 14:01.59 | brlcad | icv should become a plugin library where each of these formats merely plug in via a folder or single file with everything needed for that format |
| 14:02.37 | brlcad | just register the format by adding one line in a file, have the rest queried |
| 14:02.52 | brlcad | so we don't end up with a plethora of switch statements and spagetti format handling |
| 14:05.04 | zero_level | Also brlcad, ``Erik :I think I will have to spend this week commiting all the current utilities i have written. And working on scale and shrink's (Week 6 work uncompleted). |
| 14:05.36 | zero_level | this will be taken care since I have a reserved week in utilities implementation. |
| 14:06.34 | zero_level | also brlcad : icvwrite is know as icv_image_save(..) ;) |
| 14:06.59 | brlcad | i know, i just didn't want to write that over and over |
| 14:07.15 | zero_level | ;) |
| 14:07.22 | brlcad | but it does beg a question |
| 14:07.41 | brlcad | icv_image_save() implies there's an icv_*_save() that is not image... |
| 14:07.54 | zero_level | yes there might be. |
| 14:07.58 | zero_level | at some stage. |
| 14:07.59 | brlcad | or at least some other icv_*() convention |
| 14:08.08 | zero_level | like saving plots |
| 14:08.27 | zero_level | like saving histograms in some txt formats. |
| 14:09.46 | brlcad | fair enough |
| 14:10.23 | brlcad | but then it still might make more sense to use icv_VERB_NOUN() as a convention since that will logically group calls |
| 14:10.35 | brlcad | icv_save_image() .. icv_save_plot() .. |
| 14:10.54 | zero_level | i researched regarding that |
| 14:11.08 | zero_level | see we BU_SEM_SYSCALL |
| 14:11.13 | brlcad | or with the current design, it's become a data-driven type |
| 14:11.17 | zero_level | not ! BU_SYSCALL_SEM |
| 14:11.28 | zero_level | ;) |
| 14:11.39 | brlcad | icv_save(..., ICV_IMAGE_BW) |
| 14:14.18 | brlcad | in LIBBU's case, the convention is slightly different but predominantly bu_GROUP_VERB |
| 14:14.33 | brlcad | where GROUP can be a noun or verb, but it logically groups the actions together |
| 14:15.28 | brlcad | having icv_image_* as a group would work, but that seems redundant on the surface |
| 14:15.41 | brlcad | it'd be like having bu_utility_* |
| 14:16.22 | zero_level | brlcad : what will be the scope of bu_utilit_* |
| 14:16.55 | zero_level | And you told yesterday : about working on rtedge ? |
| 14:17.22 | zero_level | I think i shld wait to complete utilities first. |
| 14:17.56 | zero_level | And I believe there will be some days left in he reserved week I have. |
| 14:18.43 | zero_level | In the meanwhile If you can tell me about the part of the code that require action. I might read a nd understand |
| 14:22.46 | brlcad | zero_level: my point was that bu_utility_ would make no sense (because it's a utility library, it's non-descript) |
| 14:24.18 | zero_level | alright. |
| 14:24.54 | zero_level | So do u think we shld change all icv_image_* apis to icv_* apis |
| 14:25.02 | brlcad | that was part of the concern about fully writing out a header file so issues like this could be sorted out in advance with some design forethought |
| 14:25.21 | brlcad | well, so that's the question right |
| 14:25.43 | brlcad | does it make the API better or cause a problem? |
| 14:26.08 | brlcad | if it causes a problem, is it one that can be acommondated |
| 14:26.29 | zero_level | It doesnt cause a problem. |
| 14:26.48 | zero_level | But It can be sure accomodated. |
| 14:27.11 | brlcad | but there are certainly implications |
| 14:27.13 | brlcad | what are they? |
| 14:27.16 | brlcad | usability-wise |
| 14:33.26 | zero_level | Alright. |
| 14:38.16 | Notify | 03BRL-CAD:mohitdaga * 56326 (brlcad/trunk/include/icv.h brlcad/trunk/src/libicv/CMakeLists.txt): Adding new file libicv/filter.c. This will contain filter utilities. Adding icv_get_kerenl(..) function. This willcontain library of different kernels. |
| 14:40.50 | zero_level | brlcad : Is there a way to compile src code quickly. :-) |
| 14:44.03 | Notify | 03BRL-CAD:carlmoore * 56327 (brlcad/trunk/include/icv.h brlcad/trunk/include/vmath.h and 5 others): fix spellings and wording; remove trailing blanks/tabs |
| 14:44.38 | Izak_ | can someone apply ticket 220 of patches.? |
| 14:45.41 | Ch3ck_ | zero_level: just buy another computer and do some parallel processing :) |
| 14:46.15 | zero_level | Ch3ck_ : thanks |
| 14:46.37 | Ch3ck_ | zero_level: ur welcome :) |
| 14:46.46 | zero_level | I already work on a two screen, i3 machine. |
| 14:47.20 | Ch3ck_ | then guess you just need a supercomputer or mainframe probably to compile code in 10secs :) |
| 14:48.50 | ``Erik | icv_image_save is legacy, bu_image_save() | s/bu/icv/, it can change |
| 14:50.17 | zero_level | ``Erik i was planning to make that commit! |
| 14:50.21 | zero_level | shld i refrain ? |
| 14:50.34 | ``Erik | go for it *shrug* |
| 14:51.17 | zero_level | Although I myself didnt want. |
| 14:51.56 | zero_level | brlcad : final call from u? [y]/[n] ? |
| 14:52.10 | brlcad | zero_level: you can compile more quickly by specifying a target |
| 14:52.17 | brlcad | "make libicv" for example |
| 14:53.01 | brlcad | IFF you know exactly what files you changed and what dependencies need to be rebuilt as a result, you can also specify exactly those targets for compilation |
| 14:53.09 | brlcad | e.g., "make libicv/fast" |
| 14:53.09 | ``Erik | "make libicv/fast" if you know that only libicv has changed |
| 14:53.36 | brlcad | "make rt/fast" will rebuild rt, but not any of the libs that rt uses |
| 14:54.40 | brlcad | zero_level: final call on what? I don't exactly see a clear API plan ... :) |
| 14:55.17 | Notify | 03BRL-CAD:mohitdaga * 56328 (brlcad/trunk/include/icv.h brlcad/trunk/src/libicv/filter.c): Adding icv_filter(). This function performs convolution of image with specified kernel. It is a highly generalized function and can take care of images of any number of channels(1,3 etc.) Kernel size of any dimension. |
| 14:57.46 | zero_level | brlcad : can u wait till thursday. You will probably see half of the api. |
| 14:58.48 | brlcad | what will be different on thursday? |
| 14:59.06 | Notify | 03BRL-CAD:erikgreenwald * 56329 (brlcad/trunk/include/wdb.h brlcad/trunk/src/libged/typein.c brlcad/trunk/src/libwdb/wdb.c): apply http://sourceforge.net/p/brlcad/patches/220/ from Izak to add a mk_hrt() wdb func |
| 14:59.21 | zero_level | I will have a committed the code from my local src. |
| 14:59.33 | zero_level | Its messy. with files here and there. |
| 14:59.50 | brlcad | isn't that what you're working on now? |
| 14:59.57 | brlcad | I'd assumed you were |
| 15:00.03 | zero_level | yes i am. |
| 15:00.22 | brlcad | so it's going to take you two full days to sync your tree? that's very bad if true |
| 15:00.37 | zero_level | It will take some more time. To do all. |
| 15:01.01 | brlcad | that's bad |
| 15:01.11 | zero_level | I am trying to make that as complete as possible. |
| 15:01.34 | brlcad | this is the antithesis of coding complete |
| 15:01.35 | zero_level | Then there was no use of bu_malloc and all. |
| 15:01.55 | brlcad | it's antisocially coding in private and then wasting tons of time merging |
| 15:02.16 | zero_level | so making them in sync with brl-cad version. |
| 15:02.28 | zero_level | but its not two days ? |
| 15:02.46 | zero_level | By thursday u will see. |
| 15:02.51 | brlcad | you should not have gotten so divergent |
| 15:03.04 | zero_level | So i have only wednesday with me. |
| 15:05.46 | brlcad | I get that, this is now the situation |
| 15:05.49 | Notify | 03BRL-CAD:mohitdaga * 56330 brlcad/trunk/src/libicv/filter.c: TODO Note : TO add a get kernel function which will manage an arbitrary size of kernel. |
| 15:05.58 | brlcad | my point is that we should NOT be in this situation at all in the first place |
| 15:06.16 | Notify | 03BRL-CAD:erikgreenwald * 56331 brlcad/trunk/src/libged/typein.c: rt_hrt_internal should be stashed in intern->idb_ptr, not intern->idb_type. |
| 15:06.49 | brlcad | please do not get into a disjoint code tree like this again, it's just not at all efficient or healthy |
| 15:07.06 | zero_level | Hi brlcad, ``Erik : I will have to relook to signal prcoessing class to find a way to get kernels of arbitrary size. |
| 15:07.18 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 15:07.36 | zero_level | his was regarding r56330 |
| 15:07.47 | brlcad | at this point, filtering and different convolution kernels are no longer a concern in the least |
| 15:08.13 | zero_level | i just mentioned because of the commit. |
| 15:10.04 | Izak_ | ``Erik: Were there any issues or typos with the rt_hrt_internal structure ? |
| 15:10.15 | ``Erik | izak: yes, see 56331 |
| 15:10.31 | Izak_ | ok cheking on that... |
| 15:11.09 | brlcad | zero_level: there should not be blank lines after /** */ comments on the function declarations, should be consistent with the other headers |
| 15:11.29 | brlcad | and please run sh/ws.sh on your new files |
| 15:12.51 | brlcad | zero_level: what editor are you using? |
| 15:13.16 | zero_level | vim |
| 15:13.50 | brlcad | http://vim.wikia.com/wiki/Highlight_unwanted_spaces |
| 15:14.14 | Notify | 03BRL-CAD:erikgreenwald * 56332 (brlcad/trunk/src/libged/typein.c brlcad/trunk/src/libicv/filter.c brlcad/trunk/src/libwdb/wdb.c): remove trailing whitespace |
| 15:14.27 | brlcad | nearly every one of your edits is injecting trailing whitespace |
| 15:14.58 | zero_level | Yes 56330 had an issue. |
| 15:15.09 | brlcad | nearly ALL of them have had an issue |
| 15:15.41 | brlcad | no less than three other devs have had to fix commits |
| 15:16.35 | brlcad | do you understand what I meant about /** */ comments? |
| 15:17.30 | zero_level | ``Erik thanks. |
| 15:18.15 | Notify | 03BRL-CAD:mohitdaga * 56333 brlcad/trunk/src/libicv/filter.c: Seperate public and private functions in filter.c. |
| 15:18.38 | zero_level | I was planning to merge ws in 56333. But found a conflict. |
| 15:18.54 | brlcad | ws should usually be a separate commit |
| 15:19.00 | zero_level | ok |
| 15:19.02 | brlcad | don't be shy of making lots of commits |
| 15:19.10 | zero_level | ok |
| 15:19.21 | brlcad | still, my question |
| 15:19.23 | brlcad | do you understand what I meant about /** */ comments? |
| 15:23.01 | Izak_ | ``Erik: I really don't follow |
| 15:27.49 | Izak_ | ``Erik : I have seen the corrections now. thanks |
| 15:30.23 | *** join/#brlcad vladbogo (~vlad@188.25.238.209) |
| 15:34.00 | *** join/#brlcad caen23 (~caen23@92.83.175.0) |
| 15:34.33 | Ch3ck_ | tried installing brlcad on my bz.bzflag.bz account and i've been told "Sorry, user Ch3ck is not allowed to execute '/usr/bin/make install' as root on brlcad.org" Can someone please explain what this implies? |
| 15:38.55 | Notify | 03BRL-CAD:carlmoore * 56334 (brlcad/trunk/doc/docbook/system/man1/en/bwmod.xml brlcad/trunk/doc/html/manuals/libdm/dm_obj.html and 6 others): add missing ending period for 'i.e.', and I assume 'splt' (also among these changes) should be 'split' |
| 15:42.29 | Ch3ck_ | brlcad: finished writing the test for bn_poly_multiply() routine. I need some help integrating into the CMakeLists for libbn. I just need some clarification on how add_test routine works.. |
| 15:44.48 | Notify | 03BRL-CAD:carlmoore * 56335 (brlcad/trunk/doc/docbook/system/mann/en/search.xml brlcad/trunk/src/liboptical/sh_flat.c): fix the 2 cases I could find of 'e.g.' missing final period |
| 15:45.48 | vladbogo | hi Ch3ck_. It seems that you try to run make install as root and you do not have root privileges. |
| 15:47.02 | Ch3ck_ | tried running as normal user |
| 15:47.06 | Ch3ck_ | and it did not work |
| 15:47.18 | Ch3ck_ | thats when I tried sudo Check ... |
| 15:47.27 | Ch3ck_ | and it displayed the message above. |
| 15:47.43 | Ch3ck_ | So I don't know if you can't install brlcad on the server or what? |
| 15:47.52 | Ch3ck_ | just need to be clarified. |
| 15:48.32 | vladbogo | probably you need to be root (or at least have more privileges) to install it that's why it didn't work the first time. |
| 15:49.43 | vladbogo | so if you want to install it probably you have to ask someone who has more privileges. |
| 15:49.47 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5875 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 29 July - 4 August */ |
| 15:51.07 | vladbogo | but after compiling you should have all executables in the bin folder |
| 15:51.31 | Ch3ck_ | yeah.. |
| 15:51.45 | Ch3ck_ | thats what I thought and I'm doing.. thanks :) |
| 16:05.56 | kesha | brlcad: I checked http://brlcad.org/wiki/Deuces#Move_comments_from_source_to_header_files in all 5 subheaders. The last one was done by me. The previous also seem to be completed. |
| 16:06.29 | kesha | I think we should leave a note there or remove that section completely so that noone wastes their time looking up that |
| 16:06.59 | kesha | Whatsay ? |
| 16:09.08 | zero_level | brlcad : I am fixing that. |
| 16:10.53 | *** join/#brlcad mpictor (~mark@2601:d:b280:b5:d63d:7eff:fe2d:2505) |
| 16:19.25 | Notify | 03BRL-CAD:mohitdaga * 56336 brlcad/trunk/include/icv.h: Organizing comments in icv.h |
| 16:20.19 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5876 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 7 */ |
| 16:25.47 | Notify | 03BRL-CAD:mohitdaga * 56337 brlcad/trunk/src/libicv/filter.c: Library kernels for icv_filter3 function. |
| 16:33.09 | Notify | 03BRL-CAD:mohitdaga * 56338 brlcad/trunk/src/libicv/filter.c: Added icv_filter3. like icv_filter this function also does convolution of kernels with images. But it involves neighbouring pixel values of three images. |
| 16:35.08 | Notify | 03BRL-CAD:mohitdaga * 56339 brlcad/trunk/src/libicv/filter.c: Fixing Indentation |
| 16:43.02 | Notify | 03BRL-CAD:mohitdaga * 56340 brlcad/trunk/include/icv.h: Declaration of function icv_filter3 in icv.h |
| 16:49.10 | Notify | 03BRL-CAD:mohitdaga * 56341 brlcad/trunk/include/icv.h: Fixing declaration of function definition |
| 16:52.48 | Notify | 03BRL-CAD:mohitdaga * 56342 (brlcad/trunk/include/icv.h brlcad/trunk/src/libicv/filter.c): Add icv_fade() function. This is an implementation from pixfade utility. |
| 16:58.29 | Notify | 03BRL-CAD:mohitdaga * 56343 brlcad/trunk/include/icv.h: Trailing ws |
| 17:00.48 | zero_level | brlcad : I am trying to organize templetes of files. |
| 17:01.07 | zero_level | I think i missed footnote in files. |
| 17:02.32 | Notify | 03BRL-CAD:mohitdaga * 56344 (brlcad/trunk/src/libicv/crop.c brlcad/trunk/src/libicv/filter.c): Template organization |
| 17:11.47 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 17:17.28 | brlcad | Ch3ck_: you should not be using sudo for anything |
| 17:17.35 | brlcad | especially not for compile/install |
| 17:17.54 | brlcad | you need to specify an install path in your home directory |
| 17:18.19 | Ch3ck_ | ok |
| 17:18.30 | Ch3ck_ | well sinice i already compiled the code |
| 17:18.43 | Ch3ck_ | i could easily have access to the binary files |
| 17:18.44 | brlcad | kesha: yes, much of the Deuces page is out of date |
| 17:18.46 | Ch3ck_ | which is ok |
| 17:18.57 | brlcad | yeah, you don't really need to install |
| 17:19.03 | brlcad | they're sitting in bin/app |
| 17:19.41 | brlcad | kesha: go ahead and remove the comment cleanup ones and anything else that seems to be complete if you like |
| 17:23.27 | ``Erik | Ch3ck_: don't do sudo, you can set your builds install directory someowhere in your home directory if you want, 'cmake -DCMAKE_INSTALL_PREFIX=$HOME/brlcad-install $HOME/src/brlcad' or something |
| 17:24.01 | Ch3ck_ | ok |
| 17:24.38 | Ch3ck_ | just finished writing the unit test for bn _poly_mul() routine to upload code shortly on sf |
| 17:24.40 | Notify | 03BRL-CAD:mohitdaga * 56345 brlcad/trunk/include/icv.h: Added comments for icv_fade function. |
| 17:24.54 | ``Erik | ah, brlcad already mentioned as much heh :) |
| 17:25.18 | Ch3ck_ | yeah |
| 17:25.43 | zero_level | clear |
| 17:25.44 | starseeker | blinks - c and comb are separate commands??? |
| 17:26.26 | zero_level | oops! wrote on the wrong terminal. |
| 17:27.28 | brlcad | starseeker: yep, completely separate iirc |
| 17:27.40 | brlcad | there are a couple others iirc too |
| 17:27.52 | brlcad | each focuses on something a little differently |
| 17:27.54 | zero_level | ``Erik can u suggest me a methodology to fix "fixed size buffers in fileformat.c" |
| 17:27.54 | starseeker | well, crud |
| 17:28.03 | brlcad | that's why my goal is < 100 commands |
| 17:28.15 | brlcad | there's three or four that should collapse to just 'comb' |
| 17:28.15 | starseeker | was assuming c was an alias for comb |
| 17:28.37 | starseeker | may have accidently done part of that... |
| 17:28.39 | brlcad | zero_level: no not worry about the fixed size buffers right now |
| 17:28.48 | brlcad | priority is syncing your tree |
| 17:28.57 | zero_level | alright. |
| 17:29.02 | brlcad | and getting style/ws/indent under control :) |
| 17:29.31 | Ch3ck_ | starseeker: just uploaded the unit test for bn_poly_mul() routine on sf could could you please review? will continue working on the others tomorrow |
| 17:29.48 | starseeker | so comb didn't even have a man page. blegh. Well, unless there is some compelling reason for it *not* to happen, comb is about to encompass the 'c' functionality |
| 17:30.10 | starseeker | Ch3ck_: I'll try to take a look tonight - can't right now |
| 17:30.18 | brlcad | after you finish that, we can revisit and discuss the API design, then you'd do any updates that follow from the discussion, THEN maybe the fixed buffers |
| 17:30.29 | brlcad | Ch3ck_: will do, thanks |
| 17:30.30 | Ch3ck_ | starseeker: ok no prob! |
| 17:30.59 | starseeker | Ch3ck_: you've done the basics, right? (making sure your patch applies cleanly to a clean tree, for example) |
| 17:31.06 | Ch3ck_ | :) will continue with the others tomorrow could have written more than one today. but had some serious debugging to do |
| 17:31.29 | Ch3ck_ | starseeker: yes! done everything necessary patch should apply cleanly :) |
| 17:32.35 | starseeker | Ch3ck_: sounds good |
| 17:32.49 | Ch3ck_ | yeah |
| 17:33.31 | starseeker | brlcad: sorry about that - I was assuming c was just an alias for comb, which is why I wound up re-implementing the -c and -r options (which I had assumed were documented and just not implemented) |
| 17:36.07 | brlcad | starseeker: is your reimplementation better? :) |
| 17:36.52 | starseeker | brlcad: will have to check - don't know how 'c' is implemented, since I just found out it exists as a separate command :-) |
| 17:38.07 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 17:38.14 | Notify | 03BRL-CAD:brlcad * 56346 brlcad/trunk/src/proc-db/cchannel.c: classic bug, char is unsigned on some platforms so this can result in an infinite loop. need an int. |
| 17:43.52 | brlcad | Izak_: did you see r56331 |
| 17:44.31 | Izak_ | brlcad: yes. |
| 17:44.35 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 17:44.43 | brlcad | what's going on there? :) |
| 17:45.36 | brlcad | casting a malloc'd pointer to an int sounds like there's some misunderstanding |
| 17:46.56 | Izak_ | brlcad: Just a typo it had to intern->idb_ptr instead of that cast |
| 17:48.16 | brlcad | seems like more than a typo, you went through the effort to cast the warning/error away |
| 17:48.46 | brlcad | idb_ptr vs idb_type sure |
| 17:48.52 | Izak_ | brlcad: :) |
| 17:49.32 | ``Erik | my guess would be 'did a typo, saw the compiler error, tried to fix the compiler error without understanding the real reason for it', is that about what happened? |
| 17:49.59 | brlcad | i just want to make sure you understand the difference, what it meant |
| 17:50.35 | Izak_ | ``Erik: That's what happened because I wrote idb_type instead idb_ptr |
| 17:51.24 | brlcad | Izak_: what are you working on now? |
| 17:51.53 | Izak_ | brlcad:I am going back to the callback functions for hrt.c |
| 17:52.02 | ``Erik | if you cast something, double and triple check to make sure you're doing the right thing... it's not an operation to be taken lightly... you're twisting the meaning of the bits involved |
| 17:52.16 | brlcad | more specific |
| 17:52.44 | Izak_ | ``Erik: Thanks. I'll apply the correction |
| 17:52.48 | brlcad | and exactly what ``Erik said -- do you know what "int i = (int)malloc(5);" means? |
| 17:55.10 | Izak_ | It means allocating space for 5 bits , casting the number of cells assigned and assigning the result to i |
| 17:55.38 | brlcad | not correct |
| 17:55.45 | Izak_ | ok |
| 17:56.20 | Izak_ | allocated 5 bytes to variable i |
| 17:56.31 | brlcad | closer, but still not |
| 17:56.56 | brlcad | malloc(5) allocates 5 bytes of heap memory |
| 17:57.01 | Izak_ | allocated 5 bytes to variable 5 of type int |
| 17:57.22 | brlcad | it returns a POINTER to the address in memory where those 5 bytes exist |
| 17:57.33 | Notify | 03BRL-CAD:erikgreenwald * 56347 brlcad/trunk/TODO: add ctest issues |
| 17:58.02 | Izak_ | the pointer is casted to an integer and assigned to i |
| 17:58.06 | brlcad | the (int) cast is converting the ADDRESS coming from malloc into a plain integer |
| 17:58.15 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 17:58.38 | brlcad | if you accessed i for anything, you'd be accessing the value of the address, not the 5 bytes of memory |
| 17:58.45 | ``Erik | on an ia64 machine, that cast can cause data loss... a 64 bit address truncated to a 32bit int |
| 17:59.14 | Izak_ | Couldn't describe it so succintly |
| 17:59.53 | brlcad | well you could have, but I'm feeling that you don't yet fully understand the implication there (and that's okay, but we need to be honest where our understandings are at) |
| 18:00.08 | Izak_ | What happened is what ``Erik talked about. Fixed an error which I did not understand |
| 18:00.25 | brlcad | so what's the lesson to be learned then? |
| 18:01.17 | Notify | 03BRL-CAD Wiki:Harman052 * 5877 /wiki/User:Harman052/GSoc2013/Logs: |
| 18:01.27 | Izak_ | To understand why an error occurred, fix it and manually check my patches |
| 18:01.36 | Izak_ | :) |
| 18:02.36 | brlcad | why can be helpful, but you have to understand the problem to fix it |
| 18:03.22 | brlcad | I would have said the lesson was to make sure you understand exactly what the compiler is telling you |
| 18:04.26 | brlcad | when the compiler warns, it's pretty much always right these days |
| 18:04.52 | Izak_ | sure it is |
| 18:05.25 | brlcad | casting is "almost" always wrong, at least when constness is not involved |
| 18:05.42 | brlcad | and opaque void data pointers |
| 18:05.52 | ``Erik | de-consting is almost always wrong, too... :D |
| 18:06.17 | brlcad | Izak_: is 205 updated / ready to be reviewed? |
| 18:06.31 | Izak_ | yes |
| 18:06.50 | brlcad | "is that your final answer?" |
| 18:07.22 | Izak_ | No |
| 18:07.25 | brlcad | heh |
| 18:07.37 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5878 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 29 July - 4 August */ |
| 18:07.54 | Izak_ | That edit was in the applied patch hrt_stub.patch |
| 18:08.27 | Izak_ | I think ticket 205 needs to be closed |
| 18:10.03 | brlcad | looks like you're right |
| 18:10.14 | brlcad | looks like erik fixed your patch too instead of making you do it |
| 18:10.27 | brlcad | I see three errors in 205, can you identify them? |
| 18:10.47 | brlcad | visible JUST by reading the patch file |
| 18:10.58 | Izak_ | brlcad: When I uploaded this patch, I never really understood (as i understand now) what a patch is. I never knew several small edits have to be logically put together |
| 18:11.14 | brlcad | I realize it was a month ago |
| 18:11.28 | brlcad | that's why this is just a discussion, you should be able to see the three mistakes now |
| 18:11.29 | Notify | 03BRL-CAD:starseeker * 56348 brlcad/trunk/doc/docbook/system/mann/en/c.xml: Well, this example doesn't (yet) apply to the c command, since it turns out c and comb are currently different commands... commit it so it's in the repo. Will be looking at merging c and comb - if that can't work for whatever reason, will copy c.xml to comb.xml and sort out the contents accordingly. |
| 18:11.31 | brlcad | what are then? |
| 18:11.48 | Izak_ | brlcad: I would have preferred to fix it but he helped his mentee out :) |
| 18:12.51 | brlcad | if you cannot identify the three errors, he didn't help you :) |
| 18:12.59 | brlcad | if you can, then absolutely ;) |
| 18:13.05 | brlcad | what are they? |
| 18:13.20 | brlcad | no pressure, it's a very small patch file :) |
| 18:14.24 | ``Erik | I didn't do squat with 205, I did apply 207 as r56235 which mucks with the src/librt/primitives/table.c |
| 18:14.28 | Izak_ | Firstly, I really didn't understand what an empty heart is . including all those entries meant that I have written a perfect and tested hrt.c file. |
| 18:15.10 | ``Erik | https://sourceforge.net/p/brlcad/code/56235/ |
| 18:15.14 | Izak_ | Since I had not written these call backs in hrt.c , most of those field had to contain NULL as their values |
| 18:15.23 | starseeker | does some trials to determine if the c boolean expression parser is a superset of comb's syntax |
| 18:16.07 | brlcad | ``Erik: so did 205 |
| 18:16.58 | brlcad | Izak_: okay, so those functions not existing would have been #4 ... there are 3 other far more basic issues with that fie |
| 18:17.50 | brlcad | s/fie/file/ |
| 18:18.21 | Izak_ | That patch file had to include other edits from the other files like rtgeom.h , db5.h, etc |
| 18:18.56 | brlcad | not necessarily, if they were previous patches, this could be the next logical patch |
| 18:19.15 | starseeker | humph |
| 18:19.33 | starseeker | close... |
| 18:20.14 | Izak_ | looking |
| 18:20.45 | Izak_ | I think the patch file had to be generated using svn diff |
| 18:22.04 | Izak_ | brlcad : ``Erik : I also did not have to include the edit associated with the revolve primitive here |
| 18:26.10 | Izak_ | I had to include an opening curly brace on line 14 and NOT a closing curly brace on line 54 |
| 18:27.55 | Notify | 03BRL-CAD:starseeker * 56349 brlcad/trunk/src/libged/comb.c: Add -S option to comb for 'safe' operation (i.e. not changing an existing combination) - allows comb to emulate a current behavior of 'c' command. |
| 18:30.53 | Izak_ | brlcad:hope u've seen my response |
| 18:32.07 | brlcad | Izak_: so i'm not trying to give you a hard time, just hoping you can see the previous mistakes and hopefully get you more comforatable reading patch files |
| 18:32.15 | brlcad | since they are the language of devs |
| 18:32.25 | brlcad | even when you commit, this is what we all see |
| 18:32.57 | Izak_ | ok |
| 18:33.02 | brlcad | the changes are automatically generated, based on your edits, but you should still manually read and check the patch files |
| 18:33.18 | brlcad | line 14+54 looks just fine to me |
| 18:33.41 | brlcad | so you have 1 or 2 style mistakes and one blatant typo that will prevent this patch from even compiling |
| 18:33.56 | brlcad | the typo was probably a copy-paste mistake |
| 18:34.01 | brlcad | can you find it? |
| 18:34.37 | Notify | 03BRL-CAD:erikgreenwald * 56350 brlcad/trunk/src/librt/primitives/table.c: fix indentation |
| 18:34.44 | brlcad | heh |
| 18:35.30 | Izak_ | looking |
| 18:37.15 | brlcad | Ch3ck_: please run sh/ws.sh on your bn_poly_mul_patch |
| 18:37.41 | Ch3ck_ | brlcad:ok |
| 18:37.54 | brlcad | Ch3ck_: looks like you're also a vim user? |
| 18:38.05 | brlcad | https://github.com/bronson/vim-trailing-whitespace |
| 18:38.06 | brlcad | http://vim.wikia.com/wiki/Highlight_unwanted_spaces |
| 18:38.18 | Ch3ck_ | well using gedit actually |
| 18:38.29 | brlcad | hm, maybe it has an option |
| 18:38.53 | ``Erik | https://github.com/dtrebbien/gedit-trim-trailing-whitespace-before-saving-plugin |
| 18:38.55 | Ch3ck_ | emacs is having some issues on my system i don't understand |
| 18:39.06 | Ch3ck_ | ok |
| 18:39.13 | brlcad | looks like there are several plugins: https://wiki.gnome.org/Gedit/Plugins |
| 18:39.47 | ``Erik | emacs and vim are both on bz, but they have a steep learning curve if you're unfamiliar |
| 18:40.46 | brlcad | Izak_: Ch3ck_: and are you guys using 'screen' yet? it's been a week... |
| 18:40.53 | Ch3ck_ | yeah was a regular emacs |
| 18:40.59 | Ch3ck_ | brlcad: I'm using Screen |
| 18:41.03 | ``Erik | (or tmux) |
| 18:41.14 | Ch3ck_ | i'm actually log on irssi using Screen |
| 18:41.46 | brlcad | excellent |
| 18:41.53 | Izak_ | brlcad: Not using screen yet |
| 18:42.10 | brlcad | Ch3ck_: you learned how to detatch and reattach? |
| 18:42.27 | brlcad | and create new windows |
| 18:43.29 | Ch3ck_ | yes |
| 18:43.37 | Ch3ck_ | i am logged out from bz.bzflag |
| 18:43.47 | Ch3ck_ | but i'm still log on |
| 18:43.51 | Ch3ck_ | with Ch3ck |
| 18:44.12 | Ch3ck_ | logging in to do run the sh/ws.sh |
| 18:44.50 | brlcad | the 'rx' alias will reattach you to your previous session |
| 18:46.29 | Notify | 03BRL-CAD:mohitdaga * 56351 brlcad/trunk/include/icv.h: Add Doxygen comments for icv_filter and icv_filter3. |
| 18:47.52 | Izak_ | brlcad: Figured out something about 205 ticket. I did not place a comma after the second entry |
| 18:48.10 | Izak_ | that is value "1" |
| 18:48.31 | Izak_ | brlcad: had to be "1," |
| 18:50.57 | Ch3ck_ | brlcad: ran ws.sh on bzflag server and there is the patch.bak is that the file i'm to upload to sourceforge? |
| 18:51.04 | ``Erik | zero_level: your indentation is a little off; we use C style pointer placement, not C++ style.. (so your "icv_image_t* img" should be icv_image_t *img), and there should be a space between the enum body and enum class name ( "}ICV_FILTER;" should be "} ICV_FILTER;") |
| 18:52.39 | Izak_ | brlcad : ``Erik: Figured out a typo in ticket 205 |
| 18:54.34 | Ch3ck_ | how to I upload a file to brlcad from bz.bzflag? |
| 18:54.40 | Ch3ck_ | I mean sf |
| 18:58.09 | zero_level | ``Erik : so functions should also be icv_image_t *icv_image_create() ? |
| 18:58.20 | ``Erik | zero_level: yes |
| 18:59.43 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:02.57 | brlcad | Izak_: which line was that? |
| 19:04.46 | brlcad | Ch3ck_: tell izak that is why he needs to be on screen+irssi ... |
| 19:05.05 | Ch3ck_ | ok |
| 19:05.16 | brlcad | you guys have these timeouts ALL the time, which disrupts having a proper discussion |
| 19:05.38 | Ch3ck_ | brlcad: but i'm logon to bz.bzflag |
| 19:05.44 | Ch3ck_ | using screen |
| 19:05.51 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:05.52 | Ch3ck_ | + irssi |
| 19:06.23 | brlcad | i know you are |
| 19:06.50 | brlcad | you're not using it right now, but if Ch3ck_ went stale, you could log onto irssi and see what discussion you may have missed with Ch3ck |
| 19:07.13 | Ch3ck_ | yeah |
| 19:07.39 | brlcad | and eventually, you'll come to prefer it if you keep using irc |
| 19:07.46 | Ch3ck_ | ok |
| 19:08.11 | Ch3ck_ | well i have using the ws.sh on bzflag.bz so how do i upload a file from there to sf? |
| 19:08.25 | ``Erik | like a patch? |
| 19:08.27 | brlcad | you do not run ws.sh on the patch, you run it on your sources that you've been editing, and you regenerate the patch |
| 19:08.54 | *** join/#brlcad Izak_ (~Izak@195.24.220.16) |
| 19:08.55 | Ch3ck_ | ok |
| 19:09.04 | Ch3ck_ | installing the plugin for gedit Erik gave me |
| 19:09.31 | brlcad | whatever works |
| 19:09.42 | brlcad | if you work on .bz, you'd scp the file back to your local host to upload it |
| 19:10.24 | brlcad | locally: scp -v Ch3ck@brlcad.org:mypatch.diff . |
| 19:10.44 | Ch3ck_ | ok |
| 19:10.52 | brlcad | but that's just for patches, later you'd just do that before committing |
| 19:11.00 | Ch3ck_ | ok |
| 19:11.01 | ``Erik | <-- doesn't use gedit, so has no idea if that plugin is any good... it just came up on google |
| 19:11.09 | brlcad | which brings me to your patch, it's got lots of trailing whitespace |
| 19:11.14 | Ch3ck_ | ok |
| 19:11.43 | brlcad | function declarations are also inconsistent with our other files |
| 19:11.46 | Ch3ck_ | emacs on my computer is like half dead probably try vim |
| 19:11.50 | brlcad | decls+definitions |
| 19:12.13 | Ch3ck_ | how? |
| 19:12.14 | brlcad | they're both powerful, you should just become an expert in something |
| 19:12.22 | brlcad | return type goes on separate line |
| 19:12.47 | brlcad | main should not be returning negative numbers |
| 19:13.14 | brlcad | <PROTECTED> |
| 19:13.17 | ``Erik | main usually should return either EXIT_SUCCESS or EXIT_FAILURE |
| 19:13.20 | brlcad | <PROTECTED> |
| 19:13.25 | Ch3ck_ | alright |
| 19:13.41 | Notify | 03BRL-CAD:mohitdaga * 56352 brlcad/trunk/include/icv.h: Sanitizes Indentation style |
| 19:13.53 | brlcad | if( bad ) |
| 19:13.55 | brlcad | if (good) |
| 19:14.23 | Ch3ck_ | ok |
| 19:14.35 | brlcad | if( ret == 0){ ... just bad in two ways ;) |
| 19:14.47 | brlcad | if (ret == 0) { |
| 19:15.36 | brlcad | you (and Izak_) need to get up to the level where you can see details like that INSTANTLY when you need to |
| 19:15.40 | Ch3ck_ | yeah HACKING file stated that. just forgot to check sorry |
| 19:15.50 | brlcad | and that ability only comes from READING lots and lots of code, writing to a lesser extent |
| 19:16.34 | brlcad | if you're missing details like that, it means you're probably missing other more important details like if (a = b){ ... |
| 19:17.00 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:17.08 | Ch3ck_ | nahh |
| 19:17.24 | Ch3ck_ | thats actual C programming. it'll be difficult |
| 19:17.46 | Ch3ck_ | well its just the code conformity problems like if ( ) { .. that I may miss |
| 19:18.09 | Notify | 03BRL-CAD:starseeker * 56353 brlcad/trunk/src/libged/comb_std.c: wording tweak |
| 19:18.36 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) |
| 19:18.39 | brlcad | Ch3ck_: they are one in the same |
| 19:18.56 | Izak_ | I identified an error with the ticket 205 alerady |
| 19:19.04 | brlcad | Izak_: which line |
| 19:19.42 | Izak_ | brlcad : line 17 |
| 19:20.12 | Izak_ | brlcad:Missed writing a comma after 1 |
| 19:20.21 | brlcad | okay, thats #5 ;) |
| 19:20.46 | starseeker | thinks some functions in src/libged/combmem.c belong in libbn... |
| 19:21.09 | Izak_ | brlcad: Line #5 or error #5 |
| 19:22.29 | starseeker | yay magic numbers too |
| 19:24.17 | brlcad | Izak_: a fifth error |
| 19:25.06 | zero_level | brlcad, ``Erik for a two liner function? |
| 19:25.07 | zero_level | HIDDEN unsigned char * |
| 19:25.07 | zero_level | data2uchar(const icv_image_t *bif) |
| 19:25.12 | zero_level | is this right? |
| 19:25.26 | brlcad | Izak_: so that patch files defines three "sections" of changes ... can you identify/describe each of those three? |
| 19:25.42 | brlcad | zero_level: that looks right |
| 19:28.04 | brlcad | Ch3ck_: it seems like they're completely different when you're getting started, but they really are one in the same issue, and arguably style is even a bigger issue because the compiler won't tell you when you have a mistake |
| 19:28.38 | Izak_ | brlcad: The first section of that patch declares a ray trace interface for the heart primitive |
| 19:28.40 | brlcad | and that mistake affects maintainability, the ease at which bugs are found years later, the "cleanliness" of the code if it's going to survive and more |
| 19:28.46 | brlcad | goood |
| 19:28.52 | brlcad | second? |
| 19:30.01 | Ch3ck_ | OK |
| 19:31.55 | Izak_ | brlcad:The second section includes an array entry which consists of a set of pointers to the callback functions for the heart primitive in src/librt/primitives/hrt.c |
| 19:35.10 | brlcad | excellent, and lastly? |
| 19:38.42 | Notify | 03BRL-CAD:mohitdaga * 56354 brlcad/trunk/src/libicv/fileformat.c: Sanitizes Indentation style |
| 19:39.09 | Ch3ck_ | brlcad: I don't understand what you mean by my function func & defs don't follow the standard |
| 19:39.13 | Izak_ | brlcad:waiting for your response :) |
| 19:39.26 | Izak_ | brlcad : to the second answer |
| 19:39.28 | Ch3ck_ | following what is on the HACKING |
| 19:40.14 | brlcad | Izak_: I said "excellent, and lastly?" |
| 19:40.24 | brlcad | excellent is the response, that was right |
| 19:41.16 | brlcad | Ch3ck_: looking at the patch file, the function definitions are all 1-liners, but our style specifies the return type on a separate line |
| 19:41.42 | brlcad | minor detail, but this is the entire point of the exercise |
| 19:42.01 | brlcad | someone would have to clean this inconsistency up later, and that's introducing work |
| 19:42.18 | Izak_ | brlcad: The next section is a copy-paste error (Work in progress ) :) |
| 19:42.36 | brlcad | Izak_: bingo, that's what immediately should have jumped out |
| 19:42.42 | Izak_ | brlcad: OK I get it. I will always manually review my patches |
| 19:42.59 | brlcad | and, of course, make sure they compile |
| 19:43.01 | Ch3ck_ | well on the HACKING file |
| 19:43.33 | brlcad | the other issue was on lines 49, 50, and 51 |
| 19:43.34 | Ch3ck_ | its allowed if there are no spaces like int func(void); forexample |
| 19:43.42 | brlcad | what's different about those three? |
| 19:43.57 | brlcad | Ch3ck_: that's a declaration, that's fine |
| 19:44.04 | brlcad | a definition, however, is: |
| 19:44.05 | brlcad | int |
| 19:44.07 | brlcad | func(void) |
| 19:44.07 | brlcad | { |
| 19:44.42 | Ch3ck_ | yeah corrected them |
| 19:44.49 | brlcad | this one is a loose consistency requirement, best to make sure it's at lease fully consistent within a file |
| 19:45.06 | brlcad | c++ files offer additional challenges |
| 19:45.21 | Ch3ck_ | ok |
| 19:45.34 | brlcad | trailing whitespace was by far the biggest offense |
| 19:45.47 | brlcad | so fix that, upload a new patch, and it should be good to go |
| 19:45.54 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) |
| 19:45.55 | brlcad | assuming it compiles and works ;) |
| 19:46.07 | Ch3ck_ | ok |
| 19:46.13 | Ch3ck_ | removing the white spaces |
| 19:46.24 | Ch3ck_ | it compiles. I verified that |
| 19:47.39 | Notify | 03BRL-CAD:starseeker * 56355 (brlcad/trunk/doc/docbook/system/mann/en/CMakeLists.txt brlcad/trunk/doc/docbook/system/mann/en/c.xml): Yeesh. OK, break c.xml and comb.xml into their own commands. Merging looks both possible and desirable, but isn't going to be a ten minute quick fix - in the meantime, leave the man pages in a sane state. |
| 19:47.57 | brlcad | haha, you thought they'd be quick to merge |
| 19:47.58 | Ch3ck_ | brlcad:looking at the output for ws.sh which file do i use the original or the one with .ws.bak |
| 19:48.00 | brlcad | that's rich :) |
| 19:48.24 | brlcad | you can delete any .ws.bak files |
| 19:48.36 | Ch3ck_ | ok so the original is now fine .. |
| 19:48.37 | brlcad | they're just in case something goes horribly wrong, your original is unharmed |
| 19:48.39 | starseeker | brlcad: yeah, yeah... |
| 19:50.05 | starseeker | likes the "boolean expression" evaluator that 'c' uses, and with the exception of the leading operator used by comb et. al. the syntax looks fairly compatible |
| 19:50.32 | Notify | 03BRL-CAD:mohitdaga * 56356 brlcad/trunk/src/libicv/filter.c: Sanitizes Indentation |
| 19:51.16 | brlcad | yeah, it's a proper old school custom parser |
| 19:51.28 | brlcad | with tokenizer and all |
| 19:51.46 | starseeker | almost wonder if it's not worth breaking out into its own librt file or some such |
| 19:52.24 | brlcad | most of the logic in libged really belongs up in libg/librt |
| 19:53.04 | brlcad | it should be almost entirely a layer that does string to in memory representation conversions (and back) along with transactional history |
| 19:53.10 | brlcad | undo |
| 19:53.41 | brlcad | is compelled to rename comb_std.c though.. ugh |
| 19:53.58 | starseeker | is torn... this would be a very nice piece of clean-up/consolidation... |
| 19:54.29 | starseeker | now's probably not the time though |
| 19:54.46 | Izak_ | brlcad:Any other remarks and/or corrections ? |
| 19:57.15 | Notify | 03BRL-CAD:starseeker * 56357 brlcad/trunk/TODO: Documented -w option in new comb man page, using region under region fix for an example use case. |
| 20:01.09 | zero_level | brlcad, ``Erik : do think there shld also be a global defination bw_load bw_Save |
| 20:01.23 | zero_level | similarly for pix_load, pix_save |
| 20:01.25 | zero_level | ? |
| 20:01.45 | zero_level | ^u think |
| 20:02.47 | brlcad | Izak_: I think you've gotten plenty of attention today, thank you for cooperating and yearing to improve |
| 20:03.01 | brlcad | really do just want everyone to be the best possible developer you can be |
| 20:03.29 | brlcad | but that starts with some basic rigor and discipline, so we can focus and talk about much more complicated issues without being distracted |
| 20:04.06 | Izak_ | Okay grand frere :) |
| 20:04.29 | brlcad | it's like bringing dirt into a clean house |
| 20:04.52 | brlcad | sure a little bit might not matter, some people might not even care at all or even realize that their shoes are muddy |
| 20:05.43 | brlcad | but after a while, there's enough dirt that you cannot do anything cleanly, like eating, even if you wanted to, because even the smallest movement stirs up dust |
| 20:05.45 | Izak_ | true |
| 20:05.47 | zero_level | I think we shld not make them publicv. |
| 20:06.18 | brlcad | zero_level: easily agree with you on that |
| 20:06.24 | brlcad | as little as possible should be public |
| 20:06.35 | zero_level | still want a suggestion ? |
| 20:06.54 | brlcad | suggestion for what? |
| 20:07.03 | zero_level | sighs |
| 20:07.14 | Ch3ck_ | brlcad: just finished with the patch and uploaded to sf |
| 20:07.18 | Ch3ck_ | any qualms? |
| 20:07.23 | zero_level | regarding public |
| 20:07.43 | brlcad | Ch3ck_: I'll have to check it later, about to wander |
| 20:08.01 | Ch3ck_ | ok |
| 20:08.09 | Ch3ck_ | gotta go home now .. its late here! |
| 20:09.09 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5879 /wiki/User:Izak/GSOC_2013_logs: /* Mid-term Evaluation week */ |
| 20:09.25 | brlcad | zero_level: I don't understand your question .. I presume "do I have any suggestions regarding public [functions]?" but what does that mean? |
| 20:09.38 | brlcad | lots of suggestions |
| 20:09.44 | brlcad | write them perfect? |
| 20:09.54 | zero_level | brlcad : nevermind. |
| 20:10.11 | brlcad | no, please what are you asking? that's not even a complete sentence |
| 20:10.51 | zero_level | I was seeking suggestion for public functions. (*load, *save) |
| 20:10.58 | zero_level | and u gave in. |
| 20:11.17 | brlcad | suggestion of WHAT though? |
| 20:11.19 | zero_level | too much lag in IRSSI because of late night traffic here. |
| 20:11.27 | brlcad | the naming convention |
| 20:11.32 | brlcad | the calling structure? |
| 20:11.34 | zero_level | suggestion if i was going right |
| 20:11.35 | brlcad | the return types? |
| 20:11.45 | zero_level | hahah :-) |
| 20:11.55 | brlcad | seriously, I cannot guess what you're referring to in the least bit |
| 20:12.08 | zero_level | in not making pix_load bw_load etc. public |
| 20:12.20 | zero_level | :-) |
| 20:12.27 | brlcad | I said that I easily agree with you on that |
| 20:12.46 | zero_level | yes and i asked this b4 u said that :-) |
| 20:12.46 | brlcad | ... is that ambiguous? |
| 20:12.49 | zero_level | no |
| 20:13.38 | Notify | 03BRL-CAD:vladbogo * 56358 (brlcad/trunk/include/dm-qt.h brlcad/trunk/src/libdm/dm-qt.cpp): Implemented qt_loadMatrix and qt_setWinBounds. |
| 20:13.54 | brlcad | you: we shld not make them public; me: easily agree; you: want a suggestion?; me: confused.. |
| 20:14.39 | zero_level | shows different order on my screen |
| 20:14.59 | zero_level | < zero_level> I think we shld not make them publicv. |
| 20:15.00 | zero_level | 16:05 < Izak_> true |
| 20:15.00 | zero_level | 16:06 < zero_level> still want a suggestion ? |
| 20:15.00 | zero_level | 16:06 < brlcad> zero_level: easily agree with you on that |
| 20:15.41 | zero_level | must be due to the lag |
| 20:16.14 | brlcad | so you are offering a suggestion to make them private |
| 20:16.26 | zero_level | no! |
| 20:16.35 | brlcad | why not! :) |
| 20:16.47 | brlcad | this is hilarious |
| 20:17.22 | brlcad | make them private |
| 20:17.23 | zero_level | I was seeking suggestion if I am doing right in not making them public |
| 20:17.32 | zero_level | and you said ues |
| 20:17.39 | zero_level | and the matter closed there. |
| 20:18.03 | zero_level | untill the string was stretched so much. ;) |
| 20:18.15 | brlcad | I suggest we rewrite the library in Go |
| 20:18.40 | zero_level | you mean go language ? |
| 20:19.49 | brlcad | yes, and I was (half) joking .. never mind ;) |
| 20:20.07 | zero_level | hahahha ;) |
| 20:20.23 | brlcad | zero_level: so you know, I only expect you to make libicv into the best library you possibly can make it |
| 20:20.40 | brlcad | you can decide things like scope and I'll speak up on things that concern me or that can be improved |
| 20:20.44 | ``Erik | cl, yo |
| 20:20.48 | brlcad | but the idea is really for you to make it awesome |
| 20:20.56 | brlcad | maintainably awesome ;) |
| 20:21.43 | brlcad | this isn't just code, this is about creating a library that others will want because it does something better or faster or more simple |
| 20:21.46 | brlcad | that's your goal |
| 20:21.49 | Notify | 03BRL-CAD:vladbogo * 56359 brlcad/trunk/src/libdm/dm-qt.cpp: Repaint the window each time drawEnd is called to prevent lag between events and updates. |
| 20:22.41 | zero_level | alright! But I will need a lot of mentoring. I find myself novice. |
| 20:22.49 | caen23 | brlcad: were you making fun of go because of the hype? you don't like it, what do you think of it? |
| 20:23.02 | brlcad | that's why we're all here |
| 20:23.12 | brlcad | caen23: not at all, I actually am really fond of Go as a language |
| 20:23.48 | zero_level | cean23 : sorry for that laugh. No offenses meant. |
| 20:23.53 | brlcad | the joke was merely the suggestion of completely shifting the purpose of his project to something completely disruptively different |
| 20:24.23 | brlcad | I would have said cl, but ``Erik might have taken it seriously |
| 20:24.40 | ``Erik | and/or starseeker... :D |
| 20:25.18 | caen23 | i haven't written anything in go myself yet, but your comment fits in perfectly with all the "how we've rewritten x in go" headlines on hacker news :D |
| 20:26.32 | brlcad | the last 10 years of computer graphics research has been "we rewritten X for the GPU and now it's faster" |
| 20:27.41 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5880 /wiki/User:KeshaSShah/GSoC13/Reports: /* July 30 */ |
| 20:29.02 | brlcad | caen23: so you'll have to share what awesomeness you're working on of late ... and what brl-cad project is on your horizon ;-) |
| 20:29.44 | brlcad | kicks off some builds and wanders south |
| 20:35.48 | caen23 | i'm currently going through clrs, and after that i plan on learning some more languages. as for brl-cad, it would be great if i could figure out how to integrate a python interpreter. i remember we talked about that briefly after gci |
| 20:44.19 | Notify | 03BRL-CAD:starseeker * 56360 (brlcad/trunk/src/librt/search.c brlcad/trunk/src/librt/search.h): Make a stab at adding the ability to look at booleans in the tree as part of the search command - for example, 'search /all.g -bool + ! -type arb8' will find all objects in the tree of all.g that are intersected as part of a comb and are not arb8 primitives. Needs more thought and testing - this may not even be the final |
| 20:44.21 | Notify | approach - but it seems to be a step in the right direction. |
| 20:51.51 | Notify | 03BRL-CAD:starseeker * 56361 brlcad/trunk/src/librt/search.c: Not sure yet what to do with above and below when it comes to booleans, but the toplevel object(s) are viewed as being 'unioned' into the toplevel database |
| 20:53.19 | Notify | 03BRL-CAD:mohitdaga * 56362 (brlcad/trunk/include/icv.h brlcad/trunk/src/libged/screengrab.c and 7 others): Renaming the icv api functions. |
| 20:55.46 | Notify | 03BRL-CAD:vladbogo * 56363 brlcad/trunk/src/libdm/dm-qt.cpp: Implemented the qt_drawVList function. |
| 21:00.07 | Notify | 03BRL-CAD:starseeker * 56365 (brlcad/trunk/src/librt/search.c brlcad/trunk/src/librt/search.h): Use better naming for variables. |
| 21:00.17 | Notify | 03BRL-CAD:vladbogo * 56364 brlcad/trunk/src/libdm/dm-qt.cpp: ws |
| 21:00.57 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5881 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 21:06.04 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5882 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 7 */ |
| 21:06.37 | Notify | 03BRL-CAD Wiki:Vladbogolin * 0 /wiki/File:Sph.png: |
| 21:07.25 | Notify | 03BRL-CAD Wiki:Vladbogolin * 0 /wiki/File:Tor.png: |
| 21:07.58 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5885 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 7 */ |
| 21:08.56 | Notify | 03BRL-CAD Wiki:Level zero * 5886 /wiki/User:Level_zero/GSOC13/logs: /* Week 7 */ |
| 21:11.47 | starseeker | reflects that even a db full path is ambiguous when it comes to boolean operations |
| 21:12.38 | starseeker | almost need a way to hang the boolean op associated with each object in the dfp on the object's representation within the dfp |
| 21:13.49 | starseeker | that would be ideal (and, ironically, let me #define db_node as a dfp again) |
| 21:24.28 | starseeker | brlcad: how invasive a change would it be to add an array of ints to struct db_full_path to hold boolean states for each dir? |
| 21:25.30 | starseeker | the more I think about that the more I like it - it would address the question of the 'above' option in search very well |
| 21:57.24 | *** join/#brlcad mpictor (~mark@2601:d:b280:b5:d63d:7eff:fe2d:2505) |
| 22:28.52 | *** join/#brlcad caen23 (~caen23@92.83.175.0) |
| 23:36.36 | ``Erik | http://corner.squareup.com/2013/07/reversing-bits-on-arm.html |