| 00:01.06 | *** join/#brlcad merzo_ (~merzo@203-37-133-95.pool.ukrtel.net) |
| 00:57.04 | *** join/#brlcad caen23 (~caen23@92.81.188.106) |
| 01:07.05 | *** join/#brlcad caen23 (~caen23@92.81.188.106) |
| 01:12.04 | starseeker | ``Erik: hah, cool! (too bad it's GPLv3, but still cool!) |
| 01:15.54 | starseeker | brlcad: he updated the license to LGPL/GPL on the gdiam code: http://valis.cs.uiuc.edu/~sariel/research/papers/00/diameter/ |
| 02:07.34 | *** join/#brlcad caen23 (~caen23@92.81.188.106) |
| 02:43.02 | brlcad | zero_level: right now this is just design discussion, not dictating changes one way or another |
| 02:43.20 | brlcad | the concern is more that there is at least a couple (minor) usability problems with the current names |
| 02:47.39 | brlcad | ``Erik: I'd argue that rt_new_rti()+rt_free_rti() is just wrong .. should be alloc+free or new+delete |
| 02:50.37 | brlcad | the notion that delete pertains to deleting memory would have come to mind if this were a c++ library but since it's not, gut feeling is that it's specifically misleading for that very reason .. wrong convention |
| 02:53.33 | brlcad | ``Erik: zero_level: what do you think about icv_create+icv_destroy (previously icv_create+icv_free) and icv_read+icv_write (previously icv_load+icv_save)? I think those are the two pairings in question. |
| 03:08.01 | *** join/#brlcad caen23 (~caen23@92.81.188.106) |
| 04:08.27 | *** join/#brlcad caen23 (~caen23@92.81.188.106) |
| 05:08.57 | *** join/#brlcad caen23 (~caen23@92.81.188.106) |
| 07:27.45 | *** join/#brlcad Ch3ck (~Ch3ck@195.24.220.16) |
| 08:41.56 | Notify | 03BRL-CAD Wiki:Level zero * 5969 /wiki/User:Level_zero/GSOC13/logs: /* Week 8 */ |
| 10:25.02 | zero_level | brlcad : I think your last suggestion is nice. |
| 10:26.11 | zero_level | ``Erik : waiting for your consent. :-) |
| 10:36.51 | *** join/#brlcad caen23 (~caen23@92.81.188.106) |
| 10:55.09 | Notify | 03BRL-CAD:phoenixyjll * 56742 brlcad/trunk/src/libbrep/boolean.cpp: Implement a function to check the validity of the outer loop before adding a trimmed face. |
| 10:59.26 | ``Erik | *shrug* ya don't need my consent, dude, you're expected to be an intelligent and thoughtful contributor :) |
| 11:01.04 | ``Erik | read/write vs load/save would have atomicity implications to me, read/write being buffered and load/save being 'do it to completion, then return'... *shrug* pix is streamable, png and jpg tend to want to be all at once... |
| 11:01.37 | ``Erik | brlcad: if new/free is considered wrong, we should document 'right' in HACKING and work towards normalizing our api towards it |
| 11:29.13 | *** join/#brlcad Ch3ck (~Ch3ck@195.24.220.16) |
| 12:07.57 | Notify | 03BRL-CAD:phoenixyjll * 56743 brlcad/trunk/src/libbrep/boolean.cpp: Mark the functions used only within this file with HIDDEN. |
| 13:04.56 | zero_level | ``Erik : Sure. I am trying to develop into an intelligent and a thoughtful contributor. Just my names are bad. |
| 13:05.04 | zero_level | ``Erik : Regarding streaming. |
| 13:13.14 | zero_level | bw_save and pix_save are now modified such that they can stream on stdout or any pipe linked to that. |
| 13:13.40 | zero_level | similarly bw_load and pix_load can read from stdin. |
| 13:22.04 | ``Erik | zero_level: this naming issue seems to be a matter of opinion, what you chose seemed on par with a native english speaker and competent coder... you're doing great! and having 'automagic' streaming of pix and bw data is awesome |
| 13:22.09 | ``Erik | keep up the good work! |
| 13:23.15 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) |
| 13:29.59 | *** join/#brlcad caen23 (~caen23@92.81.188.106) |
| 13:34.27 | zero_level | ``Erik: indeed you could test that on bwrect |
| 13:34.38 | zero_level | take any 512 size image. |
| 13:35.29 | zero_level | type1 : "Read from file save to file" $ bwrect -S256 -o out.bw in.bw |
| 13:36.12 | zero_level | type 2 : "Read from pipe and save to file" $ bwrect -s256 -o out.bw < in.bw |
| 13:36.40 | zero_level | type 2 : "Read from pipe and save to file" $ bwrect -s256 -o out.bw < in.bw |
| 13:36.52 | zero_level | coorection " type 2 : "Read from pipe and save to file" $ bwrect -S256 -o out.bw < in.bw |
| 13:40.31 | zero_level | type 3 : "Read from file save to pipe" $ bwrect -S256 in.bw > out.bw |
| 13:40.49 | zero_level | type 4 : "Read from pipe save to pipe" $ bwrect -S256< in.bw > out.bw |
| 13:42.42 | brlcad | zero_level: your names certainly aren't bad |
| 13:42.55 | brlcad | please don't mistake me questioning them as suggesting that |
| 13:44.01 | brlcad | particularly for a library, I ask myself "can it be better?" |
| 13:44.05 | brlcad | especially for new code |
| 13:45.22 | brlcad | since it's got no maintenance cost yet and is at a stage where it's most efficient to inspect the design (particularly with respect to usability) |
| 13:46.36 | brlcad | names certainly are subjective, but aiming for common or "good enough" is never the bar I aim for |
| 13:47.30 | brlcad | best it can be without changing the purpose / scope / complexity |
| 13:49.24 | *** join/#brlcad Izak (~Izak@66-118-151-70.static.sagonet.net) |
| 13:49.59 | ``Erik | zero_level: rather than I try to concoct some test, what if you do a quick test program to prove it and add it to the ctest suite using the "add_test()" function? |
| 13:50.46 | ``Erik | then we have a button to push to prove if the code is solid in the future, on various platforms and through changes :) |
| 14:11.52 | *** join/#brlcad Ch3ck (~Ch3ck@195.24.220.16) |
| 14:19.28 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) |
| 15:06.43 | Notify | 03BRL-CAD Wiki:Phoenix * 5970 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 8 */ |
| 15:17.52 | Notify | 03BRL-CAD:ejno * 56744 brlcad/branches/opencl/src/librt/primitives/sph/sph.c: experiments with double-precision, memory alignment, memory reading methods |
| 15:29.53 | Ch3ck | brlcad: starseeker: ``Erik: I would like you to please review my patches on sf |
| 15:38.15 | Notify | 03BRL-CAD:iiizzzaaakkk * 56745 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Adding hrt_invsq vector and hrt_invRSSR matrix fields to heart structure |
| 15:38.26 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5971 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 12 August - 18 August */ |
| 15:42.09 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) |
| 15:45.37 | *** join/#brlcad kesha__ (~kesha@14.139.122.114) |
| 16:16.20 | Notify | 03BRL-CAD:iiizzzaaakkk * 56746 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Added rt_hrt_print() routine and removed rt_hrt_??port4() routines pertaining to version 4 of database |
| 16:20.00 | *** join/#brlcad Izak (~Izak@195.24.220.16) |
| 16:39.28 | *** join/#brlcad kesha__ (~kesha@14.139.122.114) |
| 16:54.00 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) |
| 17:02.06 | Notify | 03BRL-CAD:iiizzzaaakkk * 56747 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Added rt_hrt_import5() routine to import the database format to the internal format |
| 17:25.32 | Notify | 03BRL-CAD:ejno * 56748 brlcad/branches/opencl/src/librt/primitives/sph/sph.c: use doubles. The "random dots" problem was caused by the mistake of using the same kernel for each shot; creating a new kernel for each shot is too expensive so librt parallelism is now prevented with a semaphore |
| 17:31.17 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) |
| 17:32.11 | Notify | 03BRL-CAD:ejno * 56749 (brlcad/branches/opencl/src/librt/primitives/sph/aligned_sph.c =================================================================== and 669 others): rm old files |
| 17:42.49 | Notify | 03BRL-CAD:ejno * 56750 brlcad/branches/opencl/src/librt/primitives/sph/sph.c: actually, it can be parallelized by librt |
| 17:46.58 | Notify | 03BRL-CAD:iiizzzaaakkk * 56751 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Added rt_hrt_export5() routine to export from internal format to database format |
| 17:50.26 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5972 /wiki/User:Izak/GSOC_2013_logs: /* August 5th to August 9th */ |
| 18:09.58 | Izak__ | :quit |
| 18:53.54 | Notify | 03BRL-CAD:brlcad * 56752 brlcad/trunk/src/librt/primitives/bot/tieprivate.h: consistency with the other pointer tests, cast through intptr_t and mask against a long |
| 18:55.12 | Notify | 03BRL-CAD:brlcad * 56753 brlcad/trunk/src/librt/primitives/bot/bot.c: some basic sanity checking, hunting a stack smash |
| 19:09.00 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b119:4fd9:0:4a:959d:9001) |
| 19:19.50 | Notify | 03BRL-CAD:brlcad * 56754 brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: do some more cleanup to make sure we don't dereference a null accidentally. almost a few more size_t vs intptr_t casts just they're different. |
| 19:22.54 | Notify | 03BRL-CAD:brlcad * 56755 brlcad/trunk/src/librt/primitives/bot/tie.c: more null dereferencing checks so that we don't segfault and using 0x7L consistently as a long. should not be encountering the INTERNAL ERROR debug line... but we are. definitely a pooched tree. |
| 19:29.32 | Notify | 03BRL-CAD:brlcad * 56756 brlcad/trunk/src/librt/primitives/bot/tie.c: pair bu_malloc()+bu_free() but make sure it's not a null pointer just in case the book-keeping is pooched (which it is). |
| 19:36.56 | *** join/#brlcad mpictor__ (~mpictor_@2601:d:b280:b5:8cc5:331e:ce04:6a2f) |
| 19:38.20 | *** join/#brlcad markp (~mpictor_@c-67-177-102-131.hsd1.in.comcast.net) |
| 19:43.25 | *** join/#brlcad mpictor__ (~mpictor_@c-67-177-102-131.hsd1.in.comcast.net) |
| 19:46.52 | *** join/#brlcad mpictor (~mark@2601:d:b280:b5:d63d:7eff:fe2d:2505) |
| 20:02.03 | Notify | 03BRL-CAD:brlcad * 56757 brlcad/trunk/misc/CMake/CompilerFlags.cmake: fix a bug when checking C and CXX flags sequentially, the latter was always getting the cached result because the same cache variable name was being specified. this was presenting itself as CC: unrecognized option '-Qunused-argument' messages (which is apparently not a valid C++ flag, but is valid for C) and potentially any other flag where the |
| 20:02.05 | Notify | result should be different (obviously). |
| 20:08.12 | starseeker | winces - sorry about that |
| 20:08.22 | Notify | 03BRL-CAD:brlcad * 56758 brlcad/trunk/misc/CMake/BRLCAD_CompilerFlags.cmake: enable stack protection for non-optimized debug-enabled builds. for gcc 4.1+ this is -fstack-protector-all, for clang it's -qstackprotect. wouldn't think we need both, but would need to check the c/cxx flags independently otherwise in case the caller is compiling c with clang and cxx with g++ (for example). easier to just check them both |
| 20:08.24 | Notify | to handle such situations. |
| 20:35.45 | brlcad | thinks he just might understand the TIE 32-bit bug now |
| 20:36.17 | starseeker | O.o |
| 20:48.29 | Notify | 03BRL-CAD:starseeker * 56760 brlcad/trunk/src/libbn/tests/CMakeLists.txt: Add test for bn_poly_sub from sf patch #224 by Nyah Check. Interestingly, seems to be a difference between our routine and Octave - will need to double check that. |
| 20:48.31 | Notify | 03BRL-CAD:mohitdaga * 56759 (brlcad/trunk/include/icv.h brlcad/trunk/src/libged/screengrab.c and 5 others): As per Sean's suggestion, Change the name if icv api (save to write) |
| 21:38.41 | zero_level | brlcad : Does update in bwrect qualifies for NEWS ? |
| 21:38.52 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 21:40.19 | Notify | 03BRL-CAD:mohitdaga * 56761 (brlcad/trunk/include/icv.h brlcad/trunk/src/libicv/bw.c and 3 others): As per Sean's suggestion, Change the name of icv api (load to read). |
| 21:55.38 | Notify | 03BRL-CAD:mohitdaga * 56762 (brlcad/trunk/include/icv.h brlcad/trunk/src/libged/screengrab.c and 3 others): As per Sean's suggestion, Change the name of icv api (free to destroy). |
| 22:03.28 | *** join/#brlcad ``Erik (~erik@pool-173-67-38-235.bltmmd.fios.verizon.net) |
| 22:12.44 | brlcad | zero_level: yes indeed it does |
| 22:13.10 | brlcad | most any user-visible change must be recorded in NEWS |
| 22:14.00 | brlcad | as this is public documentation, note that the format is very strict and must be precise (while being as detailed as possible) |
| 22:19.51 | Notify | 03BRL-CAD:mohitdaga * 56763 brlcad/trunk/include/icv.h: Add comments about new icv_read and icv_write. Also sanitize some comments due to change in name of api. |
| 22:35.29 | *** join/#brlcad merzo (~merzo@103-12-133-95.pool.ukrtel.net) |
| 22:45.47 | zero_level | I see only a one liner comment. |
| 23:09.27 | brlcad | zero_level: it is just a one-liner comment |
| 23:09.40 | brlcad | that's why the format is very specific |
| 23:10.19 | brlcad | past tense, standard keywords, fit within column 70 |
| 23:10.38 | brlcad | as descriptive as possible (from a user's perspective) |
| 23:51.25 | Notify | 03BRL-CAD:brlcad * 56764 brlcad/trunk/src/libbu/heap.c: looks like this straggler didn't get committed. use the new api typedef for the callback |
| 23:56.17 | brlcad | tries fixing TIE |