| 01:23.19 | *** join/#brlcad danger_ (6725c94a@gateway/web/freenode/ip.103.37.201.74) |
| 01:31.30 | *** join/#brlcad gpsojswiqapkqczr (~armin@dslb-092-074-224-090.092.074.pools.vodafone-ip.de) |
| 02:32.32 | *** join/#brlcad softcoder32 (~djff@41.202.219.70) |
| 02:51.58 | *** join/#brlcad softcoder32 (~djff@41.202.219.70) |
| 03:21.39 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 03:30.45 | *** join/#brlcad shubham (a5e1683b@gateway/web/freenode/ip.165.225.104.59) |
| 03:45.57 | *** join/#brlcad divamgupta (~divamgupt@103.25.231.102) |
| 03:53.06 | *** join/#brlcad softcoder32 (~djff@41.202.219.74) |
| 05:16.08 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 05:23.12 | *** join/#brlcad kushagra (~kushagra@122.164.114.150) |
| 05:23.31 | *** part/#brlcad kushagra (~kushagra@122.164.114.150) |
| 05:44.26 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 05:44.27 | *** join/#brlcad softcoder32 (~djff@41.202.219.76) |
| 07:05.04 | *** join/#brlcad softcoder32 (~djff@41.202.219.68) |
| 07:52.01 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 08:20.34 | *** join/#brlcad shubham (a5e1683b@gateway/web/freenode/ip.165.225.104.59) |
| 08:26.03 | *** join/#brlcad softcoder32 (~djff@41.202.219.71) |
| 08:32.37 | *** join/#brlcad tandoorichick (b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
| 09:33.42 | *** join/#brlcad jasvir (~jass@75-142-124-111.static.mtpk.ca.charter.com) |
| 09:34.49 | *** join/#brlcad Ch3ck_ (~Ch3ck@154.70.103.178) |
| 10:08.04 | *** join/#brlcad Ch3ck_ (~Ch3ck@154.70.98.175) |
| 10:37.37 | *** join/#brlcad mecale (~yann@154.70.98.175) |
| 11:05.24 | *** join/#brlcad divamgupta (~divamgupt@103.25.231.102) |
| 11:32.24 | *** join/#brlcad tandoorichick (b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
| 12:02.04 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 12:02.24 | tandoorichick | could someone tell me if the 'voxelize' command project will be good enough for GSoC '16, since a lot of work has been done already? or is it better moving onto some other project, like a geometry conversion project (i looked up and found the collada importer project) |
| 12:09.57 | d_rossberg | tandoorichick: i would recommend to look for a project on a prioritized topic (e.g. geometry/image conversion) |
| 12:38.04 | *** join/#brlcad YANICK_ (~YANICK19@154.70.98.175) |
| 12:55.07 | tandoorichick | d_rossberg: thanks for advice, will work on it! |
| 12:55.55 | *** join/#brlcad softcoder32 (~djff@41.202.219.75) |
| 13:03.13 | *** join/#brlcad yorik (~yorik@152.250.221.17) |
| 13:25.36 | *** join/#brlcad shubham (7b88c55a@gateway/web/freenode/ip.123.136.197.90) |
| 13:38.35 | *** join/#brlcad softcoder32 (~djff@41.202.219.70) |
| 13:51.52 | *** join/#brlcad aumkaria (b64b2de1@gateway/web/freenode/ip.182.75.45.225) |
| 13:53.59 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:58.03 | *** join/#brlcad umeshksingla (umeshksing@nat/iiit/x-pdcdlapykpzxnjto) |
| 13:58.18 | *** part/#brlcad umeshksingla (umeshksing@nat/iiit/x-pdcdlapykpzxnjto) |
| 13:59.52 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 14:09.07 | *** join/#brlcad teepee` (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 14:26.33 | *** join/#brlcad guest___ (0e8bf3a3@gateway/web/freenode/ip.14.139.243.163) |
| 14:28.11 | *** part/#brlcad guest___ (0e8bf3a3@gateway/web/freenode/ip.14.139.243.163) |
| 14:41.04 | *** join/#brlcad divamgupta (~divamgupt@103.25.231.102) |
| 14:57.08 | *** join/#brlcad 14WAAE4DD (~divamgupt@103.25.231.102) |
| 15:46.23 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 15:58.22 | *** join/#brlcad localhost_ (~localhost@154.70.99.88) |
| 15:58.52 | *** join/#brlcad 7YUAAHRUO (~divamgupt@103.25.231.102) |
| 16:06.59 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 16:07.48 | *** join/#brlcad tafodinho (~tafodinho@154.70.99.88) |
| 16:19.14 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 16:20.33 | Notify | 03BRL-CAD:starseeker * 67250 brlcad/trunk/src/tclscripts/rtwizard/main.c: Add flags to indicate width/height were set. |
| 16:21.09 | Notify | 03BRL-CAD:brlcad * 67252 brlcad/trunk/CMakeLists.txt: no need to test for symlink support, at least not for bu_same_file(). |
| 16:21.18 | Notify | 03BRL-CAD:brlcad * 67251 brlcad/trunk/src/libbu/file.c: having or not having symlinks has no bearing whether we should stat our files. that said, there should be no harm calling realpath on our arguments before stating them. |
| 16:21.38 | Notify | 03BRL-CAD:brlcad * 67256 brlcad/trunk/src/conv/patch/rpatch.c: be a good citizen on windows, let rpatch create windows-style text files now that patch-g isn't being ignorant. |
| 16:21.41 | Notify | 03BRL-CAD:brlcad * 67253 brlcad/trunk/NEWS: daniel fixed rpatch line ending handling on windows. stdout defaults to text mode, but desirable to set it to binary so that patch-g reads it without issue. need to revisit why patch-g wasn't handling line ending correctly. |
| 16:21.47 | Notify | 03BRL-CAD:brlcad * 67257 (brlcad/trunk/include/bu/mime.h brlcad/trunk/include/bu/path.h and 6 others): bu_path_component and associated enum are missing bu prefix, so start with the enum. reword them without CORE as the word doesn't convey meaning, implicit or explicit. instead of defining, try something that conveys explicit meaning. |
| 16:21.49 | Notify | 03BRL-CAD:brlcad * 67258 brlcad/trunk/TODO: need to quick-test rtg3 |
| 16:21.56 | Notify | 03BRL-CAD:brlcad * 67263 brlcad/trunk/src/libbu/path.c: it's a [mime]:: prefix now, update comments accordingly from 'mime:' |
| 16:21.58 | Notify | 03BRL-CAD:brlcad * 67261 (brlcad/trunk/include/bu/path.h brlcad/trunk/src/libbu/path.c and 3 others): rename a second time for even less inconsistency. the mime type mentions really feel out of place here (and are the remaining inconsistency as the example implies all are without a mime prefix), especially the enum extension hack... as there is mime api, should probably just have a string pass that strips the mime |
| 16:22.00 | Notify | before bu_path_component() gets its hands on it. |
| 16:22.02 | Notify | ... |
| 16:22.05 | Notify | 03BRL-CAD:brlcad * 67255 brlcad/trunk/src/conv/patch/patch-g.c: no need for separate read buffers since both the materials and rpatch data should easily fit. looking at rpatch's printf, the longer of the two, it doesn't look like lines even exceed 120 chars so this should be plenty. |
| 16:22.07 | Notify | 03BRL-CAD:brlcad * 67254 brlcad/trunk/src/conv/patch/patch-g.c: this should make patch-g work properly with rpatch files containing unix or windows line endings, eliminating the need to manually force rpatch output to binary mode. |
| 16:22.09 | Notify | 03BRL-CAD:brlcad * 67260 brlcad/trunk/TODO: tools should work without a batch script, regardless of it meaning convert the runtime (or not). |
| 16:22.11 | Notify | 03BRL-CAD:brlcad * 67259 brlcad/trunk/src/libgcv/plugins/vrml/vrml_read/string_util.cpp: remove dead code |
| 16:22.15 | Notify | 03BRL-CAD:brlcad * 67262 (brlcad/trunk/include/bu/path.h brlcad/trunk/src/libbu/path.c brlcad/trunk/src/util/icv.cpp): go with FULL instead of MIMELESS so the first entry is a simple and positive characterization. more descriptive than the ALL misnomer, and still brief. survivable even if mime prefix handling is decoupled. |
| 16:26.17 | Notify | 03BRL-CAD:n_reed * 67264 brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml: add documentation on tolerance tests |
| 16:43.09 | *** join/#brlcad gagan (~gagan@122.173.25.216) |
| 16:52.11 | *** join/#brlcad tafodinho (~tafodinho@154.70.99.193) |
| 16:54.27 | *** join/#brlcad tafodinho (~tafodinho@154.70.99.193) |
| 17:05.21 | *** join/#brlcad softcoder32 (~djff@41.202.219.73) |
| 17:06.45 | *** join/#brlcad gagan (~gagan@122.173.25.216) |
| 17:09.35 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 17:25.40 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 18:14.53 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 18:53.54 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 19:00.43 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 19:06.10 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 19:12.54 | *** join/#brlcad jasvir (~jass@75-142-109-136.static.mtpk.ca.charter.com) |
| 19:20.15 | Notify | 03BRL-CAD:n_reed * 67265 brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml: add note about 3D point array being used for 2D points |
| 19:20.39 | jasvir | hello there. I was looking into incorporating Qt with mged. There was a project regarding this in GSoC 2013 http://brlcad.org/wiki/User:Vladbogolin/GSoC2013/qt-display-manager. Can anyone please help me to know more about this. |
| 19:36.14 | *** join/#brlcad softcoder32 (~djff@41.202.219.69) |
| 19:45.58 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 19:52.15 | starseeker | jasvir: I believe the conclusion was that it would be better to look at re-implementing MGED in Qt as opposed to trying to make Tk and Qt "play nice" together |
| 19:53.09 | starseeker | jasvir: I know the MGED gui looks pretty simple, but getting a duplicate of MGED fully set up on Qt is actually more work than you would think |
| 19:54.17 | starseeker | jasvir: you would need to identify how MGED translates mouse movements into geometry rotation, translation, etc. and how to do the same things with a Qt widget, how to implement the various dialogs (or at least functionally equivalent replacements - you wouldn't want to duplicate our current background color widget, for example) |
| 19:55.23 | starseeker | make a functional terminal widget to replace the MGED console, which has its own details lurking, etc. |
| 19:56.45 | starseeker | There's a start in the qged branch: https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/branches/qtged/ |
| 19:57.43 | starseeker | that attempt has some things not needed to duplicate MGED as it currently exists (the button panels, for example) but some of it would be relevant |
| 19:58.47 | starseeker | any project proposal for that topic would need to convince us that the proposer has a good grasp of what kind and amount of work would be needed to complete the project - a detailed plan that shows a good understanding of both the MGED and Qt issues involved |
| 20:09.07 | jasvir | starseeker, that seem quite fascinating. I quite familiar with Qt but I don't have that much understanding about MGED right now but I can can get familiar with it really quickly. |
| 20:10.00 | jasvir | starseeker: is qged currently working to some extent? |
| 20:13.42 | Notify | 03BRL-CAD:brlcad * 67266 brlcad/trunk/src/libbu/file.c: add support for determining whether two files are the same file on Windows using the GetFileInformationByHandle call. This is similar to stat(), but requires an open file handle. Calling stat() is nfg on Windows for non-unix filesystems as inode remains unset. This method checks where the file is on disk. |
| 20:17.13 | Notify | 03BRL-CAD:starseeker * 67267 brlcad/trunk/src/libbu/file.c: Spelling fix. |
| 20:17.23 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 20:25.26 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 20:36.08 | *** join/#brlcad softcoder32 (~djff@41.202.219.71) |
| 20:37.08 | Notify | 03BRL-CAD:starseeker * 67268 brlcad/trunk/src/libbu/file.c: Move things around so we only define sb1 and sb2 if we need them (otherwise get unused variable warning under Windows. |
| 21:20.18 | Notify | 03BRL-CAD:brlcad * 67269 brlcad/trunk/src/libbu/file.c: add a note about identical path names would conceivably fail the stat and GetFileInformationByHandle test methods, but we pretend they would result in the same lookup. by that same measure, we could have completely different files actually map to the same thing on disk (i.e., a false positive) on a crazy-fast-changing filesystem. not a case we particularly |
| 21:20.20 | Notify | care about, but worth noting. eliminate an unnecessary scope increase and redundant comment while we're at it. |
| 21:20.22 | Notify | ... |
| 21:22.43 | Notify | 03BRL-CAD:brlcad * 67270 (brlcad/trunk/src/libbu/argv.c brlcad/trunk/src/libbu/b64.c and 13 others): auto ws indent and trailing junk cleanup |
| 21:51.12 | *** join/#brlcad gaganjyot (~gaganjyot@122.173.25.216) |
| 21:52.46 | *** join/#brlcad Gabriel__ (bc1ba547@gateway/web/freenode/ip.188.27.165.71) |
| 22:00.18 | *** join/#brlcad Gabriel___ (567919d7@gateway/web/freenode/ip.86.121.25.215) |
| 22:10.27 | Notify | 03BRL-CAD:n_reed * 67271 brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml: document meaning of a common intersection event loop pattern |
| 22:11.54 | Gabriel___ | Hello, about the "add exec option to search" project, I have 2 more questions: first is how should the commands which are to be executed stored (maybe separate them into tokens and use a linked list?) and second question is could you give me some more important examples about "exec", besides "draw"? |
| 22:31.37 | starseeker | Gabriel___: as to the former, that's something you'll have to figure out as part of your implementation plan. There are numerous possibilities - the important thing is that it works |
| 22:32.07 | starseeker | Gabriel___: as to the second, another example might be wanting to set the color attribute on all objects returned from a search |
| 22:33.14 | starseeker | if you look at example 19 in the MGED man page for search (brlman search from the command line, or man search from the MGED prompt) you'll see a foreach script being used on the results of a search command stored in a tcl list |
| 22:33.37 | starseeker | that's the current "workaround" for the lack of an exec option, so that's another good example |
| 22:35.56 | Gabriel___ | thanks for the answer, that foreach script seems like a good point to research |
| 22:54.30 | starseeker | foreach is a Tcl command - BRL-CAD's default MGED prompt is a tcl shell |
| 23:01.58 | *** join/#brlcad gaganjyot (~gaganjyot@122.173.25.216) |
| 23:11.46 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 23:25.15 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |