IRC log for #brlcad on 20150727

00:31.09 starseeker http://sourceforge.net/blog/subversion-repository-gap-notifications-by-email/
00:31.13 starseeker confound it
00:31.29 starseeker they shouldn't have enabled committing without doing that
00:34.27 starseeker ``Erik, brlcad: should we put out an email not to commit until we get this fixed?
00:37.23 starseeker I've got patches for most of the missing commits to master thanks to the brlcad.org git repo, but that doesn't cover branches and it's missing a couple at the end
00:38.19 starseeker those will probably have to be reconstructed from the brlcad-commits emails
00:39.17 starseeker not sure what will happen to local checkouts that already have these commits when they svn up after we rebuild them - may have to tell people to do new checkouts
01:38.25 *** join/#brlcad infobot (ibot@69-58-76-73.ut.vivintwireless.net)
01:38.25 *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || Congrats to all GCI 2014 winners Peter & Marc! || Congratulations to our 12 GSoC students! || Don't ask if someone is here, just ask your questions and wait for a response. ;-)
02:00.40 *** join/#brlcad gurwinder (~chatzilla@117.220.148.234)
02:20.49 Notify 03BRL-CAD Wiki:Gurwinder Singh * 9109 /wiki/Povray:
02:22.49 Notify 03BRL-CAD Wiki:Gurwinder Singh * 9110 /wiki/Povray:
02:40.08 Notify 03BRL-CAD Wiki:Gurwinder Singh * 9111 /wiki/Povray:
02:41.43 Notify 03BRL-CAD Wiki:Gurwinder Singh * 9112 /wiki/Povray:
02:42.49 gurwinder brlcad: Hi, please check the page http://brlcad.org/wiki/Povray
02:43.45 gurwinder brlcad: I have written it according to your given instructions.
03:37.47 *** join/#brlcad gurwinder (~chatzilla@117.220.148.234)
04:50.50 *** part/#brlcad dracarys983 (dracarys98@nat/iiit/x-mxvjyvetkymbrxiv)
05:32.52 brlcad starseeker: I have a more detailed e-mail from sourceforge on exactly which commits are missing and am passing it along to everyone
05:35.41 brlcad as this is essentially a revert with a day and a half of commits dropped, individual authors will just have to replay their commits (one at a time or they can diff to a new checkout and collapse to fewer commits)
05:37.11 brlcad what will likely happen to existing checkouts that were up-to-date is that they'll first report no such revision .. then when that revision exists, it'll likely report a checksum mismatch and have to get checked out again
05:40.04 gurwinder brlcad: please check http://brlcad.org/wiki/Povray
05:40.18 brlcad gurwinder: yes, I saw your link, patience please :)
05:40.24 brlcad kind of have a major issue going on right now
05:40.35 gurwinder brlcad: ok :)
05:57.20 brlcad gurwinder: okay, took a quick look and that looks great -- of those that are incomplete, here are a few in a rough priority order: ellg/ell1 (these are simply ell), tec/trc (these are simply tgc), half, pipe, arbn, ehy, epa, rhc, rpc, bot, and then probably extrude and revolve (which requires sketch)
05:58.01 brlcad you don't have to do anything special for the ell/tgc specializations, just write them out as ell/tgc
05:58.27 brlcad the same shape should result -- how you get there is somewhat unimportant for povray export
05:59.35 gurwinder brlcad: Ok, I will do these two first
06:00.28 gurwinder and want to know about my patch submittion
06:01.01 brlcad gurwinder: all patches are on hold for a couple days until we get the repository back online and up-to-date
06:01.11 gurwinder brlcad: How to submit my work? One by one or by submitting it as a single file
06:01.22 brlcad sourceforge restored our repository, but we lost 4 days of commits that we have to re-do
06:01.37 gurwinder brlcad: Ok, I undertand :)
06:02.29 brlcad gurwinder: ah, whether to combine or keep separate -- it depends
06:03.02 brlcad you have a couple pending already that need to be reviewed
06:04.08 brlcad as you complete additional work, it'll probably be easier for you and your reviewer if all your work is in one patch file
06:04.22 brlcad BUT that means you will have to work even harder to make sure there aren't any problems in your patches
06:05.15 gurwinder Ok, I will submit it with my additional work. And the patch that I have submitted is working well on my system.
06:05.28 brlcad if you see anything that can be improved in the code you wrote, you should make sure your patch has the improvement
06:05.37 brlcad if you see something that can be improved, I will almost certainly see it too
06:06.33 brlcad for that, I mean coding style, indentation, proper names, proper comments, etc ... the issues listed in HACKING and more
06:06.59 brlcad basically be CONSISTENT ;)
06:09.43 gurwinder ok, If anything left I think re-viewer's comment is good way to get it :)
06:10.41 brlcad it's not .. anything left that the reviewer finds disqualifies that patch as demonstrating commit competency
06:12.12 gurwinder oh, Ok then :)
06:12.22 brlcad the reviewer IS a good source for feedback on the design, intent, scope, etc ..
06:13.54 brlcad but your job is to make sure your work is "complete" (remember the acceptance requirements you agreed to) such that nothing you submit will have to get "cleaned up" by someone else or (worse) undone
06:14.53 brlcad gurwinder: in addition to the coding style issues in HACKING, you can see a specific review checklist in doc/code_review.txt ... ask yourself each question
06:16.18 brlcad if you don't understand any of them, just ask
06:17.50 gurwinder brlcad: thank I will check my patch by going through all those questions. I will ask If I have any problem :)
06:27.22 brlcad thx
06:28.43 brlcad starseeker: can you snarf the individual patches from the git mirror into a web folder (from r65597 forward) to individuals can replay their commits?
06:35.02 brlcad starseeker: never mind, already did it
06:35.28 *** join/#brlcad shaina (~shaina@59.89.44.182)
07:42.48 Notify 03BRL-CAD:brlcad * 65646 brlcad/trunk/TODO: test commit after sourceforge backup recovery (4 days lost + down 8), mention ovoid shape a new primitive as our existing solvers should easily handle it
07:57.36 Notify 03BRL-CAD:brlcad * 65647 brlcad/trunk/TODO: correction, only 1.5 days lost (13 commits, 4 devs impacted). this is a replay commit of what was r65658 - some more thoughts on extending libbu's parallelism functionality.
08:02.33 Notify 03BRL-CAD:brlcad * 65648 brlcad/trunk/src/librt/primitives/datum/datum.c: replay of r65649 following major Sourceforge service outage (hard file store failure, filesystem corruption, full backup restoration): update copyright to inception, even though it was derived from the template.
08:06.36 Notify 03BRL-CAD:brlcad * 65649 brlcad/trunk/src/librt/primitives/datum/datum.c: replay of r65650.document what's going on here better with the buffer size padding, so simple changes to datum data don't end up leaving pockets of dead objects throughout the .g file. also fix a bug in the size where we weren't allocating space for the decode size bytes.
08:07.13 *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-vqlyjnllsckpdlvi)
08:41.58 *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl)
08:55.27 *** join/#brlcad merzo (~merzo@92.60.189.225)
09:50.10 *** join/#brlcad andrei_il (~andrei@109.100.128.78)
10:32.57 *** join/#brlcad sofat (~sofat@202.164.45.204)
10:39.17 *** join/#brlcad teepee-- (bc5c2134@gateway/web/freenode/ip.188.92.33.52)
11:42.00 *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net)
12:12.50 *** join/#brlcad luca79 (~luca@host4-221-dynamic.5-87-r.retail.telecomitalia.it)
12:13.24 *** join/#brlcad sofat (~sofat@202.164.45.204)
12:30.13 *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl)
12:30.25 *** join/#brlcad sofat (~sofat@202.164.45.204)
12:34.42 *** join/#brlcad ih8sum3r (~deepak@122.173.5.55)
12:36.43 *** join/#brlcad shaina (~shaina@59.91.92.89)
12:42.22 *** join/#brlcad sofat_ (~sofat@101.208.64.209)
12:59.04 *** join/#brlcad teepee-- (bc5c2134@gateway/web/freenode/ip.188.92.33.52)
13:11.57 Notify 03BRL-CAD:starseeker * 65650 brlcad/trunk/src/libbrep/shape_recognition.cpp: Replay of commit r65653 - This test was known to be insufficient/incorrect from the outset - it's going to take a raytracing based approach to resolve this question generally. Will have to punt and return the to-be-evaluated cases in a struct, so bu_ptbl won't cut it as a return type either.
13:12.48 Notify 03BRL-CAD:starseeker * 65651 brlcad/trunk/src/libbrep/shape_recognition.cpp: Replay of commit r65654 - This'll be a job - has to be done in libged land (or possibly libanalyze/librt) but make some notes for now on how we'll have to go at it.
13:13.40 *** join/#brlcad andrei_il (~andrei@109.100.128.78)
13:13.47 Notify 03BRL-CAD:starseeker * 65652 brlcad/trunk/src/libged/nmg_cmface.c: Replay of commit r65655 - Apply patch #390 from Brad Hollister, removing unused tmp variable.
13:14.26 Notify 03BRL-CAD:starseeker * 65653 brlcad/trunk/src/libged/nmg_cmface.c: Replay of commit r65656 - Apply patch #390 version 2 from Brad Hollister
13:25.35 *** join/#brlcad sofat_ (~sofat@101.208.64.209)
13:26.46 *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl)
13:36.55 *** join/#brlcad Shubham (6719e766@gateway/web/freenode/ip.103.25.231.102)
13:39.15 starseeker brlcad: that should be all of mine
13:46.13 *** join/#brlcad sofat_ (~sofat@101.208.64.209)
13:57.11 Notify 03BRL-CAD:ejno * 65654 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: recommit r65646 after sourceforge outage: 'write CCONE1 records'
13:58.39 Notify 03BRL-CAD:ejno * 65655 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: recommit r65647 after sourceforge outage: 'write a CCONE2 if the CCONE1 internal radii are zero'
14:01.23 Notify 03BRL-CAD:ejno * 65656 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: recommit r65657 after sourceforge outage: 'remove unnecessary try block'
14:13.03 *** join/#brlcad sofat_ (~sofat@202.164.45.212)
14:19.45 Notify 03BRL-CAD:ejno * 65657 brlcad/trunk/src/conv/3dm/3dm-g.cpp: check argc to ensure that there are no excess arguments; free brep on exception; remove unused options
14:21.11 Notify 03BRL-CAD:ejno * 65658 brlcad/trunk/src/conv/gcv/gcv.cpp: fix typo in comment
14:23.55 Notify 03BRL-CAD:ejno * 65659 (brlcad/trunk/src/libgcv/gcv_test.c brlcad/trunk/src/libgcv/plugin.c): check for excess arguments; simplify loop
14:26.26 Notify 03BRL-CAD:ejno * 65660 brlcad/trunk/src/libgcv/facetize.c: move BU_UNSETJUMP to correct location
14:30.16 Notify 03BRL-CAD:ejno * 65661 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_read.c: return error rather than exiting on unexpected EOF; free all memory before returning
14:33.05 Notify 03BRL-CAD:ejno * 65662 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: fix truncate_float(); refactoring
14:36.54 *** join/#brlcad shaina (~shaina@61.0.202.88)
14:39.35 Notify 03BRL-CAD:ejno * 65663 (brlcad/trunk/src/librt/primitives/bot/gct_decimation/auxiliary/cc.h brlcad/trunk/src/librt/primitives/bot/gct_decimation/auxiliary/cpuconfig.h and 11 others): formatting; replace math3d.h macros with those from vmath.h; fix so that if tri_count/1024 == 0, use one thread
14:44.52 Notify 03BRL-CAD:ejno * 65664 brlcad/trunk/src/librt/reduce.c: use direct comparisons when checking 0.0 <= reduction_level <= 1.0
14:47.06 Notify 03BRL-CAD:brlcad * 65665 brlcad/trunk/doc/docbook/presentations/en/brlcad-app-devel.xml: sub-bullet presentation cleanup made obvious by sofat's automatic rendering
14:47.55 *** join/#brlcad sofat_ (~sofat@101.208.64.209)
15:00.27 Notify 03BRL-CAD:ejno * 65666 brlcad/trunk/src/librt/primitives/bot/decimate.c: use direct comparison for feature_size
15:06.17 *** join/#brlcad arno (~luca@host17-111-dynamic.4-87-r.retail.telecomitalia.it)
15:21.27 *** join/#brlcad libero (~luca@host129-20-dynamic.4-87-r.retail.telecomitalia.it)
15:23.02 Notify 03BRL-CAD:ejno * 65667 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_read.c: close fpin on failure to open the plot file
15:48.13 Notify 03BRL-CAD:starseeker * 65668 brlcad/trunk/TODO: Need to fix MGED clear command - giving Error: can't read "PRIV\(console\)": no such element in array
15:55.40 Notify 03BRL-CAD:starseeker * 65669 (brlcad/trunk/src/libanalyze/CMakeLists.txt brlcad/trunk/src/libanalyze/raydiff.c): Begin refactoring of libanalyze raydiff pieces - these will be useful for other logic as well.
16:07.18 Notify 03BRL-CAD:starseeker * 65670 (brlcad/trunk/src/other/openscenegraph/CMakeLists.txt brlcad/trunk/src/other/openscenegraph/src/CMakeLists.txt): Enable the building of osgQt - not quite sure this version of Qt/OSG integration will work with the latest Qt5, but enable what is available as a starting point.
16:19.56 Notify 03BRL-CAD:starseeker * 65671 (brlcad/trunk/db/nist/CMakeLists.txt brlcad/trunk/db/nist/README): NIST has released a number of additional public domain NURBS CAD files - incorporate into build. The 7-10 assembly files are currenly too slow as STEP files, so they've been added as a single 3dm file which attemps to place them in assembly positions.
16:27.48 Notify 03BRL-CAD:carlmoore * 65672 brlcad/trunk/TODO: fix a spelling in TODO
16:40.42 Notify 03BRL-CAD:starseeker * 65673 brlcad/trunk/TODO: Start mapping local git commits back into trunk. Make a note to investigate CmakePushCheckState macros
16:45.13 Notify 03BRL-CAD:starseeker * 65674 (brlcad/trunk/src/other/stepcode/CMakeLists.txt brlcad/trunk/src/other/stepcode/src/exp2cxx/CMakeLists.txt brlcad/trunk/src/other/stepcode/src/express/CMakeLists.txt): Don't do the fancy version trick when SCL is a subbuild - it causes problems with continual rebuilding with newer GCC compilers.
16:48.07 Notify 03BRL-CAD:starseeker * 65675 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c brlcad/trunk/src/libanalyze/util.c): Move grazing elimination into util.
16:48.51 *** join/#brlcad bhollister2 (~brad@2601:647:cb02:7a00:f04d:35ac:f0ba:5880)
16:52.53 Notify 03BRL-CAD:starseeker * 65676 (brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp =================================================================== and 479 others): Forgot to add this one
16:53.31 Notify 03BRL-CAD Wiki:Shaina7837 * 9113 /wiki/User:Shainasabarwal/GSoC15/logs: /* 25 July */
16:54.15 Notify 03BRL-CAD:starseeker * 65677 (brlcad/trunk/src/libanalyze/CMakeLists.txt brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp): Convert util to C++
16:55.21 Notify 03BRL-CAD:starseeker * 65678 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c brlcad/trunk/src/libanalyze/util.cpp): Try to make the solid ray filter a bit more generic from a data type standpoint.
16:56.29 Notify 03BRL-CAD:starseeker * 65679 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c brlcad/trunk/src/libanalyze/util.cpp): Inching slowly towards a generic analyze_gen_worker function
16:57.37 Notify 03BRL-CAD:starseeker * 65680 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c): Another step towards a generic gen_worker
16:59.26 Notify 03BRL-CAD:starseeker * 65681 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c brlcad/trunk/src/libanalyze/util.cpp): Make a universal libanalyze worker generator, with better CPU utilization characteristics.
17:00.04 Notify 03BRL-CAD:starseeker * 65682 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/util.cpp): Start rework of get solid partitions function
17:01.09 Notify 03BRL-CAD:starseeker * 65683 brlcad/trunk/src/libanalyze/util.cpp: more updating of the solid partitions func to the new approach
17:01.59 Notify 03BRL-CAD:starseeker * 65684 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/tests/CMakeLists.txt brlcad/trunk/src/libanalyze/util.cpp): Get the solid partitions function printing out some info.
17:02.42 Notify 03BRL-CAD:carlmoore * 65685 brlcad/trunk/HACKING: fix a spelling
17:02.44 Notify 03BRL-CAD:starseeker * 65686 brlcad/trunk/src/libanalyze/util.cpp: Infinite loops are a bad thing... make sure they can't happen here.
17:03.11 *** join/#brlcad sofat_ (~sofat@202.164.45.204)
17:03.46 Notify 03BRL-CAD:starseeker * 65687 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/raydiff.c): Fiddle with libanalyze rt prep - something funny going on here.
17:04.45 Notify 03BRL-CAD:starseeker * 65688 brlcad/trunk/src/libanalyze/raydiff.c: Put some timers in for debugging gdiff performance
17:05.28 Notify 03BRL-CAD:starseeker * 65689 brlcad/trunk/src/libanalyze/util.cpp: Start working on bookkeeping of hits and overlaps.
17:06.23 Notify 03BRL-CAD:starseeker * 65690 brlcad/trunk/src/libged/shape_recognition.cpp: Start thinking about how we're going to handle managing using the raytracer to augment the comb definition from the libged side of things.
17:07.25 Notify 03BRL-CAD:starseeker * 65691 (brlcad/trunk/include/brep.h brlcad/trunk/src/libanalyze/analyze_private.h and 4 others): Checkpoint work towards using raytracing to do subtraction evaluations.
17:08.04 Notify 03BRL-CAD:starseeker * 65692 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/util.cpp): More work on solid partition collecting
17:09.09 Notify 03BRL-CAD:starseeker * 65693 brlcad/trunk/src/libanalyze/util.cpp: Get the filtered results into the results bu_ptbl.
17:10.01 Notify 03BRL-CAD:starseeker * 65694 (brlcad/trunk/src/libanalyze/analyze_private.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libanalyze/util.cpp): Start thinking about how the raytracing and the partition checking will interact
17:10.40 Notify 03BRL-CAD:starseeker * 65695 (brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libged/shape_recognition.cpp): checkpoint
17:11.34 Notify 03BRL-CAD:starseeker * 65696 (brlcad/trunk/include/analyze.h brlcad/trunk/src/libanalyze/CMakeLists.txt and 3 others): Stub in actual functions to do subtraction evalutions. Quite a bit of logic needed here.
17:12.26 Notify 03BRL-CAD:starseeker * 65697 (brlcad/trunk/include/brep.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp brlcad/trunk/src/libbrep/shape_recognition.h): More work on preparing for ray subtraction analysis. Realized the subbrep_bbox function actually already does what we need for this...
17:15.42 Notify 03BRL-CAD:starseeker * 65698 brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp: Checkpoint of most recent git changes.
17:16.33 starseeker phew
17:20.20 *** join/#brlcad shaina (~shaina@117.214.243.253)
17:25.03 *** join/#brlcad Gurwinder (75dc94ea@gateway/web/freenode/ip.117.220.148.234)
17:25.47 *** join/#brlcad sofat (~sofat@202.164.45.204)
17:28.24 *** join/#brlcad gurwinder_ (~chatzilla@117.220.148.234)
17:28.53 brlcad starseeker: thanks -- looks like we're good to go
17:29.35 brlcad lee has three on the ert branch, but otherwise back on track
17:29.53 sofat brlcad, hello
17:30.13 brlcad sofat: all done with everything?
17:30.28 brlcad or almost
17:31.00 ih8sum3r brlcad: I have dropped an email to you. Please check once.
17:31.25 gurwinder_ brlcad: I'm working on ell1 ellg, I think they comes under ell. And tec under tgc. Right?
17:31.30 sofat I need some help regarding google custom search.
17:33.45 brlcad gurwinder_: that sounds correct, yes -- though I'm not sure those are actually distinguishly different types
17:35.27 gurwinder_ brlcad: Thanks :). I just want to confirm as I also check them using mged. Thanks :)
17:35.34 brlcad i.e., if you open a .g file ...there is no such thing as a tec/ell1/ellg
17:36.08 brlcad they only are an option on creation via the in/make commands as they take different parameters
17:36.29 brlcad basically can think of them like alternative constructors, like C++ classes
17:37.14 gurwinder_ yes
17:37.23 brlcad so ... you may be done already
17:37.48 gurwinder_ brlcad: yes I have done with them.
17:39.10 gurwinder_ brlcad: As by your priority order next is half? Right?
17:39.33 brlcad I gave you the list, your responsibility to track it ;)
17:40.07 brlcad if you don't have the list, you should pull the IRC log
17:40.24 gurwinder_ Yes, I have that list in my system.
17:40.43 *** join/#brlcad sofat (~sofat@202.164.45.204)
17:40.45 gurwinder_ So I'm going to work on that list
17:40.49 gurwinder_ :)
17:41.15 brlcad ih8sum3r: I'd like to see your work set up running somewhere before proceeding differently
17:43.08 *** join/#brlcad konrado (~konro@41.205.22.7)
17:43.20 ih8sum3r You mean production ready thing or front-end and back-end merged branches? Or Both.
17:43.31 *** join/#brlcad sofat_ (~sofat@202.164.45.204)
17:43.32 brlcad ih8sum3r: so if you have the VM working, either make the web server available somewhere or make the disk image available
17:44.03 brlcad i mean your work
17:44.31 sofat_ I also update the language work, presentation work, and working on google custom search.
17:44.34 brlcad the merged mess would be useful to see in comparison, but need to see either a before or after for that to matter much
17:44.49 brlcad sofat_: url? the ones I'm testing no longer seem to be there
17:45.50 sofat_ <PROTECTED>
17:45.56 brlcad sofat_: to be clear, you should be working on google custom search specific to the documentation only, not the entire website
17:46.23 sofat_ <PROTECTED>
17:47.08 sofat_ this is presentations links :- http://202.164.53.122/wordpress/presentations/en/brlcad-app-devel_2.html#/
17:47.28 sofat_ http://202.164.53.122/wordpress/presentations/en/intro-to-tcltk_2.html#/
17:47.31 brlcad sofat_: what did you change?! ... google translate is working now :)
17:47.48 ih8sum3r brlcad: I'll try to make it available somewhere, the size of image is to large (around 3-4GB) so it will take bit time. Report you asap.
17:48.19 brlcad ih8sum3r: why is it that big?
17:48.21 sofat_ I am made some changes in google translator plugin code.
17:48.44 brlcad sofat_: and those changes were? ... can you explain the fix?
17:48.57 sofat_ yes i explain.
17:50.11 sofat_ you send some links. regarding this work . in these links have some code. so then use this code.
17:51.08 sofat_ but this code not work on your side , and gave the error . so I now what i do.
17:51.32 ih8sum3r brlcad: This is the size of .vdi file let me check after converting it into .vmdk. Above I wrote .vdi file size.
17:52.48 brlcad sofat_: when I provide links to code, that is not ever direction to simply use that code -- it's to understand possible solutions to a given problem, related information
17:53.11 brlcad ih8sum3r: I know it's the size of the vdi file -- my question is why is it that big :)
17:53.16 sofat_ i Have google translator plugin which i am used before this work , because last time you said " when you convert the style of languages then it stop the working before this its working on my side " so that's means I goging to update the code of plugin instead using other code now I online update the layout os plugin and it working .
17:53.45 sofat_ s/goging/going
17:54.05 sofat_ s/online/only
17:54.12 sofat_ s/os/of
17:54.16 brlcad back up ...
17:54.21 ih8sum3r brlcad: I installed the required packages side by side and also did the updates after that it shows me this much size.
17:54.34 brlcad "but this code not work on your side , and gave the error . so I now what i do." ... what did you do? what was the error?
17:54.42 brlcad what was the fix?
17:55.24 sofat_ error is library which i used its old version .
17:55.24 brlcad ih8sum3r: if you do a df -k inside the vm, what does it report being in use?
17:55.37 brlcad sofat_: which library?
17:57.08 sofat_ which is using for google translator.
17:57.28 brlcad you're not being specific
17:57.35 brlcad give me a name or a url or something
17:57.52 brlcad is it code you wrote?
17:57.59 brlcad *completely*
17:58.17 brlcad or code that calls a library someone else wrote?
18:00.50 ih8sum3r brlcad: Here is the output : http://pasteboard.co/2hccOlfF.png
18:02.07 sofat_ there is plugin code
18:02.08 sofat_ http://202.164.53.122/wordpress/wp-content/plugins/google-language-translator/
18:02.37 sofat_ I only made the changes in layout because this plugin already works
18:03.26 sofat_ I only update this file google-language-translator.php
18:08.35 sofat_ brlcad, please check presentation work and tell changes.
18:13.28 brlcad ih8sum3r: what is that df telling you?
18:15.29 *** join/#brlcad konrado (~konro@41.205.22.53)
18:16.33 sofat_ brlcad, I facing problem with google custom search it is not working with my docs means its not search these docs.
18:16.48 sofat_ I also upload the sitemap on webmaster tools
18:16.54 brlcad sofat_: okay, so you changed it from the code copy-pasted from StackOverflow with the official wordpress google-language-translator plugin
18:17.02 sofat_ yes
18:17.21 brlcad you should have started by saying that :)
18:17.46 sofat_ so this is not working properly
18:17.48 ih8sum3r 34% used for home and 19
18:17.51 ih8sum3r % for boot
18:18.00 brlcad so effectively, we don't know why it was broken and didn't directly fix the error, but you switched it to a plugin where it is working
18:18.06 ih8sum3r I am right. This is what I can see.
18:18.50 brlcad ih8sum3r: percentage doesn't matter .. the question is surrounding how much disk space is in use and why that much :)
18:18.54 sofat_ problem is that which error you show me I solve this error (javascript )
18:19.09 brlcad ih8sum3r: so how much is in use within the disk image?
18:19.19 sofat_ after that its not working
18:19.53 brlcad sofat_: I don't understand -- are you saying it no longer works for you?
18:19.55 sofat_ so then you told me your old part is working fine then i switch to old and made some changes in this only layout changes
18:19.59 sofat_ yes
18:21.10 brlcad the current version does not work for you?
18:21.11 sofat_ I am saying which error you send me in image on mail. I solve this error but after that its not work on your side.
18:22.19 brlcad problems are only solved when it is working correctly for everyone
18:22.27 brlcad "solved" is not the right word
18:22.29 sofat_ I think you not understand
18:22.44 ih8sum3r 6.6G is in use + 42MB. I think I have done something wrong while assigning memeory space. Total size is of 21G.
18:22.55 sofat_ ok i explain again .
18:23.05 ih8sum3r On which 6.6G is in use.
18:23.54 brlcad ih8sum3r: right, about 6.6 GB in use ... and that's obviously being compressed if the vdi/vmdk is 3-4 GB
18:24.19 brlcad sofat_: what is the purpose of the explanation?
18:24.50 sofat_ how i solve this problem
18:25.26 brlcad ih8sum3r: so the question of why is the vdi 3-4 GB is because the disk data is 6.5 GB of data ... so then the NEW question is why is there 6.5 GB being used in the image -- where is most of that space going?
18:25.57 brlcad sofat_: before you explain again, then ... is it working for you now?
18:26.05 brlcad because if it's not, then it's not solved
18:26.10 sofat_ yes
18:26.15 sofat_ its working now
18:26.21 brlcad okay .. you just told me that it was not working for you :)
18:26.28 ih8sum3r brlcad: Questions seems intresting let me find answer for this.
18:26.53 sofat_ so now on google custom search so i need some help
18:27.22 sofat_ I upload my sitemap on webmaster tool but after that it could not search my docs
18:27.41 brlcad ih8sum3r: if you're willing to wait a long while (hours), something like this will tell you the biggest folders: find / -type d -exec du -ks {} \; | sort -n | tee dir_sizes.txt
18:27.48 sofat_ i set this url for search 202.164.53.122/wordpress
18:30.25 sofat_ and also check my presentation work and tell me about changes
18:31.15 brlcad sofat_: before changing subject, I want to be clear about something -- namely that you did not learn why it google translate wasn't working
18:31.35 brlcad with the prior solution
18:33.11 brlcad you got it working again by reverting to the WP plugin, which is fine -- but in responding to my question of "what was wrong?", the answer should have been "I don't know. I worked around the problem by using the plugin, which worked."
18:33.31 brlcad I say that only because it took almost an hour to get that understanding
18:34.19 sofat_ <PROTECTED>
18:34.42 sofat_ because after removing all error its not working
18:34.54 brlcad that's fine
18:35.01 sofat_ so then I again switch to plugin and customize it
18:35.15 brlcad but that's the answer, not that it's solved ;)
18:35.21 brlcad solved means something else
18:35.29 sofat_ hmm
18:35.31 sofat_ :-(
18:35.52 brlcad this is just a language issue, not a quality of work question
18:35.58 brlcad you got it working, which is great
18:36.45 sofat_ okay
18:37.07 brlcad there are still some changes I'd like to see to translation but they are minor
18:37.24 sofat_ ok tell me
18:37.58 brlcad later, lets move on to the presentations
18:38.21 sofat_ ok
18:38.50 brlcad they look much better now
18:38.56 sofat_ okay
18:39.01 brlcad you did not need to match the style and blue color, but that's a stylesheet issue we can fix
18:39.15 brlcad the issues I mentioned by e-mail were structural xml transformation problems
18:39.28 brlcad there is still at least one issue I see, images are duplicated
18:39.30 sofat_ what please explain
18:40.30 brlcad ah, you fixed it! never mind
18:40.44 brlcad I was looking at intro-to-tcltk.html, not intro-to-tcltk_2.html
18:40.53 sofat_ hahah
18:41.12 brlcad er, hrm
18:41.27 brlcad no, the images are still duplicated :)
18:41.46 brlcad neat that you have the navigation going down on them though
18:41.48 sofat_ this is in xml document also
18:41.54 brlcad yes it is
18:42.05 brlcad but they are just one image
18:42.09 brlcad one mediaobject
18:42.19 sofat_ ok no problem its not big problem
18:42.29 sofat_ ok
18:42.30 brlcad different images for different output formats (fo vs html)
18:42.52 sofat_ ok
18:43.35 brlcad when you're dealing with images, you want to have web resolution (e.g., 1024x768) and print resolution (e.g., 8192x6144)
18:44.08 brlcad they happen to be the same for that presentation, but they should be different size images
18:44.15 sofat_ hmm
18:44.23 brlcad and only one should get used
18:45.14 brlcad since it's web, you want the role=html mediaobject imageojects only
18:45.32 sofat_ ok
18:45.33 brlcad if it were for pdf, you'd want the role=fo version
18:46.27 sofat_ ok
18:47.19 brlcad the color theme should match the main site
18:48.05 sofat_ ok
18:48.10 sofat_ no problem
18:48.14 sofat_ next
18:48.17 brlcad the rest of the problems I see are problems in the original xml
18:48.32 brlcad yes, so that's good
18:48.51 brlcad is it possible to make the link be more interesting?
18:49.03 brlcad the link to the presentation from the presentation overview page
18:49.38 sofat_ hmm yes i try to do some interesting
18:49.52 brlcad i'm talking about the "Read More"
18:50.05 sofat_ so now next changes for language translator .
18:50.18 brlcad wait, must make sure we understand each other :)
18:50.21 sofat_ yes i will change change this
18:50.27 brlcad I'm talking about this page: http://202.164.53.122/wordpress/presentations/en/intro_intro-to-tcltk.php
18:50.34 sofat_ I know that
18:51.00 brlcad I think the fix requires a change in the repo
18:51.09 sofat_ if explain some thing interesting ?
18:51.24 sofat_ which type you want for this
18:51.25 brlcad that there needs to be an overview xml file for each presentation separate from the presentation itself
18:51.34 sofat_ yes
18:51.48 brlcad probably an article
18:52.08 sofat_ yes
18:52.23 brlcad and that overview page would maybe have a small image preview of the presentation title page
18:52.43 brlcad the preview image and "Read More" would both link to the presentation
18:52.54 brlcad not sure how to embed that into the article
18:53.30 sofat_ ok
18:53.39 brlcad let me add a simple overview page for one of those presentations and you can try to figure out how to link them?
18:53.57 ih8sum3r brlcad: I used the command you gave me it gives to long output. I used another command and it shows me the following output: http://pasteboard.co/2hfzibef.png. Still there is a mystery that where rest of the space is being used.
18:54.36 brlcad sofat_: oh, I take that back -- we are working in docbook land, so maybe the overview and the presentation can be combined sort of like how it's working now
18:55.04 brlcad sofat_: we just need to separate out some section in the xml file to be the overview
18:55.12 brlcad not the first page
18:55.25 brlcad and not include that overview in the presentation itself
18:55.39 sofat_ means i can't understand now please explain in simple english
18:56.35 brlcad ih8sum3r: that implies you used a 5 GB linux image?
18:56.52 brlcad sofat_: okay
18:57.11 brlcad sofat_: specific example, consider doc/docbook/presentations/en/intro-to-tcltk.xml
18:57.28 sofat_ <PROTECTED>
18:57.36 brlcad right now, you use that to make http://202.164.53.122/wordpress/presentations/en/intro_intro-to-tcltk.php
18:57.51 sofat_ yes
18:57.54 brlcad and http://202.164.53.122/wordpress/presentations/en/intro_intro-to-tcltk_2.html
18:58.12 sofat_ yes
18:59.04 ih8sum3r brlcad: I used iso file (approx. size 625MB) and maybe after installing it expands to this much size.
18:59.25 brlcad that's good, that works -- the only problem is that the overview page (intro_intro-to-tcltk.php) needs an introduction and preview of the presentation BUT we do not want that intro in the presentation itself (intro_intro-to-tcltk_2.html)
18:59.51 brlcad ih8sum3r: that's where knowing what that 5GB is would be helpful
18:59.56 brlcad did the command I gave you complete?
19:00.09 ih8sum3r Yes completed.
19:00.17 brlcad okay, so just run less on the file
19:00.25 brlcad less dir_sizes.txt
19:00.43 brlcad (and "man tee" since you apparently don't know what that did) ;)
19:01.26 brlcad copy-paste the top 100 or so dirs into a text pastebin
19:01.27 sofat_ for that i need to update your xml docs separate the intro part from presentation i am right ?
19:01.38 brlcad sofat_: right!
19:01.54 sofat_ okay now for language translator ?
19:02.07 brlcad sofat_: I'm not sure exactly how to do that, but hopefully you can figure it out ;)
19:02.26 sofat_ ok
19:02.38 brlcad okay, last issue -- I assume you mean google search not translation?
19:02.47 sofat_ ok
19:03.15 sofat_ both
19:03.27 brlcad okay, so translation first -- what?
19:04.02 brlcad my earlier comment about a couple more changes?
19:04.04 sofat_ you also told me you need some changes in translation so which changes you want?
19:04.08 brlcad okay, yes
19:04.19 brlcad couple minor issues
19:04.24 sofat_ tell me
19:04.31 brlcad getting there :)
19:05.02 sofat_ hmm ?
19:05.16 brlcad it means be patient, I'm trying to type :)
19:05.23 brlcad the language list is all in english
19:05.32 brlcad that's not very helpful if you don't speak english...
19:06.10 sofat_ okay
19:06.56 Notify 03BRL-CAD Wiki:Bhollister * 9114 /wiki/User:Bhollister/DevLogJuly2015:
19:07.20 brlcad the languages should all be with native character set and spelling
19:07.53 brlcad e.g., ?????? instead of hindi
19:07.54 sofat_ means ?
19:08.37 brlcad e.g., http://piwigo.org/screenshots/piwigo-2.2-language_switch.png
19:09.27 brlcad I also think the flag on the left of the name will work better for layout, just like in that image
19:09.44 sofat_ ok
19:10.00 brlcad which icon set are you using?
19:10.45 sofat_ this plugin fetch the icons automatically .
19:10.55 brlcad from where?
19:11.23 sofat_ form server
19:11.31 brlcad of course
19:11.40 sofat_ i don't know which server
19:11.40 brlcad you're not being specific
19:12.16 brlcad we need to know which server, what license of use they are under
19:12.24 sofat_ ok
19:13.56 sofat_ okay you want the language not in english they must ve in original name like hindi is written in hindi language not english i am right ?
19:14.07 sofat_ s/ve/be
19:14.50 brlcad the other issue is minor, but surprising ... when the page is loaded, it first displays all the flags while they are loaded and THEN it hides them ... can you make them hidden first?
19:15.07 brlcad right, each language written in that language
19:15.14 brlcad and flag on left
19:15.17 sofat_ ok
19:15.34 sofat_ yes i use hidden first
19:16.21 brlcad also, when the language list is expanded, the "Move to Top" disappears
19:17.26 *** join/#brlcad vasc (~vasc@bl12-167-71.dsl.telepac.pt)
19:17.53 sofat_ hmm
19:18.07 vasc kewl. the svn is up again.
19:18.34 sofat_ ok i will do this
19:19.10 sofat_ now last one is google custom search this is not working
19:19.11 brlcad sofat_: the list of languages displays before it's hidden for me, both with chrome and safari
19:19.17 brlcad see http://snag.gy/Or9Jt.jpg
19:19.38 brlcad it only displays for about 0.5 seconds
19:19.40 vasc hm cmake isn't working
19:20.15 sofat_ you need to scroll down
19:20.33 brlcad sofat_: what do you mean?
19:21.02 sofat_ means scroll down the page and then you get other language which not show you
19:21.18 vasc CMake Error at CMakeLists.txt:154 (_message):
19:21.19 vasc <PROTECTED>
19:21.19 vasc <PROTECTED>
19:21.21 brlcad no, you misunderstand
19:21.51 sofat_ hmm
19:21.52 brlcad vasc: hm, that's easy to fix (just remove that file from CMakeLists.txt) -- almost certainly related to recent changes by starseeker
19:22.02 brlcad sofat_: that image is showing you the page loading
19:22.11 sofat_ hmm
19:22.13 sofat_ i see
19:22.18 brlcad the list of languages should NOT be displayed at all
19:22.24 brlcad it shows the list, and then it hides
19:22.33 brlcad for about 0.2-0.5 seconds
19:23.12 sofat_ yes then click on additional language
19:23.24 sofat_ link and then its show you
19:23.27 brlcad right
19:23.31 brlcad that part is fine
19:23.37 sofat_ hmm
19:24.04 brlcad the problem is that is first draws the whole list and THEN hides
19:24.11 brlcad instead of drawing the list hidden
19:24.18 sofat_ ok so what you want there ?
19:24.46 brlcad to not show the list of languages until the additional languages or arrow are selected
19:25.24 sofat_ ok
19:25.33 sofat_ i will check this issue
19:25.39 brlcad please don't say ok if you don't understand :)
19:25.51 brlcad do you understand the issue?
19:27.21 sofat_ yes you said on loading time this part not show(meas not work like show/hide). when user click on additional language the n it wi ll sho w to user
19:27.41 sofat_ <PROTECTED>
19:28.15 brlcad that doesn't sound right...
19:28.55 sofat_ hmm ?
19:28.56 brlcad the page once loaded is working okay NOW ...
19:29.11 brlcad clicking additional languages works
19:29.21 brlcad hiding additional languages works
19:29.38 brlcad the problem (and it's minor) is ONLY during page loading
19:30.38 sofat_ hmm
19:30.38 brlcad while it's loading the page, it displays the EXPANDED list and THEN it hides the list (during loading)
19:30.38 sofat_ means when page loading you don't want language shoe to 0.5 second and then gone
19:30.38 brlcad and it only does it the first time the page is loaded
19:30.38 sofat_ s/shoe/show
19:30.41 brlcad the second time it doesn't show
19:30.47 sofat_ ok
19:31.08 brlcad right, it shouldn't show the list during loading (if it can be easily fixed)
19:31.22 sofat_ means i need some state store work like menu
19:31.34 brlcad if it cannot be easily fixed, don't worry about it -- but try, maybe 1-3 hours at most
19:31.42 sofat_ <PROTECTED>
19:31.48 sofat_ <PROTECTED>
19:31.57 sofat_ <PROTECTED>
19:32.50 brlcad eh, it should not require a cookie!
19:32.50 brlcad this is a resource loading issue
19:32.50 sofat_ ok
19:32.50 brlcad probably jquery-related
19:32.54 sofat_ I will check this issue
19:33.16 ih8sum3r brlcad: This is what I get top 100 : https://gist.github.com/anonymous/c0b7a6a5dfd117b3794b
19:33.31 sofat_ so now move further next problem with google search
19:33.50 brlcad sofat: sounds like this issue: http://stackoverflow.com/questions/2801032/jquery-hide-elements-before-they-rendered-best-practice
19:34.08 vasc hm
19:34.31 brlcad setting initial css to display:none and then display may work
19:34.52 brlcad ih8sum3r: heh, that's the bottom 100 :)
19:34.54 sofat_ ok
19:36.00 brlcad ih8sum3r: or rather, you're looking at the top of the file and you need to reverse sort the list or look at the bottom
19:36.00 brlcad sort -r file | less
19:36.00 bhollister is there a way to get at 'view_state' from within libged?
19:36.52 vasc did you guys change the compiler flags or something? the compiler is being more anal than usual.
19:36.52 sofat_ so need some help in google search I am using this link to search my document content 202.164.53.122/wordpress/ and i also upload the sitemap in google webmaster tools but its not working . you have any solution ?
19:36.52 brlcad bhollister: no, that's an mged construct
19:36.52 brlcad bhollister: what do you need?
19:37.26 brlcad vasc: not that I'm aware of, but it's supposed to be VERY anal to be compliant with our code standard
19:38.53 brlcad vasc: depending on what state your checkout was in, you may want to obtain a fresh checkout and reapply your changes
19:39.05 vasc i didn't get any 'M' or 'G' file hits so it should be ok in that regard
19:39.06 brlcad need to get you working on a branch now that svn is back up... remind me later this week if I don't get to your patches beforehand
19:39.12 vasc i mean G
19:39.19 brlcad no, that's the point
19:39.28 vasc ok
19:39.41 brlcad you're not going to because the repo was ripped out from under that checkout and restored in a different state
19:41.38 brlcad so locally you are consistent but not with the server (in theory, it'll eventually give you a checksum error if/when you ever tried to commit)
19:42.18 vasc so i should download everything again?
19:42.27 brlcad but it essentially means the checkout cannot be fully trusted if you ran svn update after the Wed when the filesystem corrupted
19:42.40 brlcad for your work, I would recommend it yet
19:42.45 brlcad s/yet/yes/
19:42.56 vasc when we do the branch i'll just do it from a clean slate then
19:43.01 vasc and apply patches on it
19:43.23 brlcad might not make a difference, but can't say for certain that there's not a stateful build issue lurking
19:44.22 vasc i'm just removing some consts here and there. if its important to keep the consts i'll rewrite this differently later.
19:44.46 vasc 3 lines
19:45.19 sofat_ brlcad, need some in google search please help me in that .
19:46.17 sofat_ need some help
19:47.07 vasc the most important patch to apply is the sph patch. it fixes a compilation error in current svn.
19:47.24 vasc you can also apply the arb8, ehy patch fine
19:47.56 vasc don't apply the grid patches because they change the way the rendering is done so the output ain't the same
19:48.10 vasc it uses a simplified rendering engine
19:48.36 vasc which is WIP
19:49.17 vasc brlcad
19:50.40 vasc well the svn compiled with the changes to the CMakeLists.txt
19:51.16 vasc Index: src/libanalyze/tests/CMakeLists.txt
19:51.16 vasc ===================================================================
19:51.16 vasc --- src/libanalyze/tests/CMakeLists.txt(revision 65698)
19:51.16 vasc +++ src/libanalyze/tests/CMakeLists.txt(working copy)
19:51.16 vasc @@ -1,6 +1,6 @@
19:51.17 vasc <PROTECTED>
19:51.19 vasc <PROTECTED>
19:51.21 vasc -BRLCAD_ADDEXEC(tester_sp solid_partitions.c "libanalyze;libbu" NO_INSTALL)
19:51.25 vasc +#BRLCAD_ADDEXEC(tester_sp solid_partitions.c "libanalyze;libbu" NO_INSTALL)
19:59.32 ih8sum3r brlcad: Here it is : https://gist.github.com/anonymous/a182acb4b8e0438e89bf
20:01.43 brlcad ih8sum3r: good lordy... what's in that db?
20:03.03 ih8sum3r I think these are collections, OGV.
20:03.07 brlcad vasc: best practice is obviously to propagate const, not remove them, but it obviously depends what you're doing
20:03.50 brlcad if someone went through the effort to mark something const, it is 'usually' intentional
20:04.10 brlcad which 3 lines?
20:05.01 brlcad sofat_: for search, we need a different URL base so you can limit it to just documentation
20:05.13 sofat_ means
20:05.14 brlcad when it comes time to publish, we will not be exposing "wordpress"
20:06.03 brlcad sofat_: means right now you're limiting it to 202.164.53.122/wordpress/ and this is NOT limiting the search to just documentation
20:06.20 brlcad it's desirable to have a search box that is limited to documentation
20:06.44 brlcad there will be a different main site search that will search everything
20:06.45 ih8sum3r What I can see in that db folder there are binary files like prealloc.0, meteor.0, meteor.ns etc. which most probably are the collections.
20:07.12 brlcad ih8sum3r: I don't know what collections means in this context
20:07.27 sofat_ ok now means i need full domain for this like ww.abcd.com
20:07.29 brlcad 3.2 GB of data is a lot of data
20:07.41 sofat_ www.abcd.com
20:07.44 brlcad sofat_: it'll be on brlcad.org
20:07.51 sofat_ ok
20:07.57 brlcad you just have to make sure the logic translates when it's moved
20:08.15 brlcad that the logic still works
20:08.21 sofat_ ok
20:08.48 ih8sum3r What say should I try installing one more time from scratch just to cross-check whether output again will be of 3.5G or less.
20:08.55 sofat_ ok
20:09.42 brlcad so our two prime candidates will be to use something like docs.brlcad.org or brlcad.org/docs/
20:10.07 brlcad ih8sum3r: sure, or use mongodb tools to inspect what is in the database
20:10.20 brlcad that's a lot of data to be unaccounted for
20:10.30 vasc i can keep the const but now i just wanna get something working. it won't be in the final version.
20:11.05 vasc the weird thing is it compiled before
20:11.09 vasc so i guess it wasn't const
20:11.27 ih8sum3r brlcad: Okay, on it. Will report you asap.
20:11.51 brlcad "i just wanna get something working" <-- do you know just how many times I've heard that over the past two years only to find that was effectively the final state? :)
20:12.11 brlcad almost every time ;)
20:12.14 vasc i never submit the initial version of anything to anyone
20:12.25 vasc the patches are always 3rd gen code
20:12.28 brlcad well you have a hard submission deadline coming up really fast :)
20:12.39 brlcad 3 weeks remaining?
20:12.52 vasc i thought it was more than that
20:12.56 vasc ah
20:13.22 brlcad don't remember the exact date but it is soon
20:13.27 vasc 24 aug
20:13.50 brlcad okay, and that's after the suggested pencil's down date which is the week prior
20:14.00 vasc oh oh crap
20:14.13 brlcad you can keep coding all the way up to the deadline
20:14.15 vasc yeah i didn't see that one
20:14.25 brlcad it's just a suggestion to motivate procrastinators
20:14.40 Notify 03BRL-CAD:carlmoore * 65699 brlcad/trunk/src/util/bwcrop.c: fix subscript to eliminate some memory-fault errors
20:14.59 brlcad heck you can keep coding after the deadline, but the evaluation is only on code up to the deadline date
20:15.13 vasc well this is like 1-2 weeks behind schedule
20:15.23 vasc so i think in the worst case i might like drop the bot code
20:15.33 brlcad drop it now
20:15.54 vasc but i want to do the full rendering pipeline. even if i only get it working 100% in opencl after the deadline
20:16.09 brlcad really, it's probably going to be more valuable to start wrapping up in about 1-1.5 weeks time
20:16.33 vasc right now we got a bunch of primitives implemented and a simplified rendering pipeline with grids
20:16.50 brlcad getting what you have in some useful state either as a clear path forward or as a working demo or bits of functions hooked back into the production code
20:16.50 vasc but it still does those expensive calls to the gpu all the time
20:17.04 brlcad and docs... writing up where you got to and what's next
20:17.04 vasc it already is a working demo
20:17.08 vasc but its slow
20:17.33 vasc i want the whole pipeline in opencl so don't have all this call overhead
20:17.48 Notify 03BRL-CAD:starseeker * 65700 (brlcad/trunk/src/libanalyze/tests/solid_partitions.c =================================================================== and 95 others): Forgot to svn add this file
20:18.01 brlcad nods
20:18.01 vasc there it is
20:18.52 brlcad it's not necessarily your case as you have a different class of open source experience, but historically..
20:19.30 brlcad gsoc research projects tend to die shortly after gsoc ends despite authors best intentions
20:19.53 vasc well
20:20.09 brlcad hence the focus and desire to scavenge whatever small or big piece of the effort into progress
20:20.21 vasc its possible to retrofit the grid accel to work with the current way the code is structured. but its gonna be a step backwards from what i have now.
20:20.41 vasc i think in that case its better to put that in the branch
20:20.47 brlcad basically coding deep on some pinpoint feature/capability, not wide where it's useless until the whole trench is dug
20:21.52 brlcad step backwards from what you have doesn't matter -- would it be a step forward for the current code
20:21.52 *** join/#brlcad sofat_ (~sofat@202.164.45.204)
20:22.28 brlcad e.g., implementing just the opencl shot for ell was a step forward, even though practically useless for production
20:22.48 vasc its actually worse than useless for production because it makes the rendering slower
20:22.58 brlcad it validated behavior, demonstrated how to transcode a real example, etc
20:23.13 vasc i can get why it was done that way
20:23.38 vasc well think about this again in 2 weeks then
20:23.39 brlcad it did exactly what it was scoped to do and very little has to be "undone" to do a next step
20:23.53 brlcad that's huge
20:24.15 brlcad not a dead effort that required the original author to keep at it for another N weeks/months/whatever
20:24.20 vasc i did a bunch of coding to make a simplified pipeline and that should be stored somewhere too
20:24.35 vasc as it is the code can render stuff
20:24.49 vasc it has some warts and duplicates things and its slow but it renders stuff
20:25.20 brlcad can anything you have be merged into rt or librt (in the opencl branch) without eliminating functionality?
20:25.30 vasc like i said
20:25.37 vasc merge the sph and arb8, and ehy patches
20:25.52 vasc the grid patch reimplements its own rendering pipeline
20:25.58 vasc so don't put that in yet
20:26.04 brlcad yeah, the prims are easily keepers
20:26.32 brlcad could the grid pipeline be reworked to sit beside the old one?
20:26.36 brlcad (even slow)
20:26.51 vasc it could but like i said it would only mean the next guy will have to redo what i did again
20:27.26 vasc basically i did a completely new mostly self-contained rendering pipeline in ansi c
20:27.30 brlcad it's not an unfair assumption that they will likely have to do that anyways
20:27.31 vasc simplified
20:27.45 Notify 03BRL-CAD:carlmoore * 65701 (brlcad/trunk/src/util/bw-ps.c brlcad/trunk/src/util/pix-ps.c): make cosmetic changes to bw-ps.c and pix-ps.c so that they look more alike
20:28.03 brlcad because at the end of the day, this all has to get hooked back into rt/librt
20:28.05 vasc the alternative is someone just writing it and putting it in without looking at how the code works
20:28.15 vasc the present code
20:28.40 vasc what i did was i tried to simplify the current rendering pipeline in a way that it can be digested and simplified for later opencl or whatever porting
20:29.11 vasc you can call it the 'simple' rendering pipeline....
20:30.13 vasc it is still WIP
20:30.48 vasc like the boolean eval isn't simplified yet
20:30.59 vasc and that's critical
20:31.17 brlcad I entirely get what you did, why you did it, etc ... it's what to do with it before it's done
20:31.25 vasc well
20:31.50 vasc i think one way is to have optional compilation for different rendering pipelines in librt
20:32.01 brlcad such that it isn't wasted effort in the long run because, oh, say your simplification goes too far and completely fails validation
20:32.25 brlcad or just sits in a branch and is never merged because it was hooked into a skeleton rt2 instead of rt
20:32.31 vasc i actually have two versions of the grid construction code you know
20:32.36 vasc one is ANSI C the other is OpenCL
20:33.03 vasc so we can compile the ANSI C one by default if someone selects the simplified pipeline and doesn't have OpenCL
20:33.11 brlcad boolean eval is critical for performance, it's not critical for leveraging/integrating other code in this pipeline
20:33.18 vasc right
20:33.47 vasc we had a similar issue in freeciv at one point
20:33.59 vasc our only graphics client was written for the X Athena Widgets
20:34.13 vasc i did the first port to a 'modern' graphics toolkit i.e. Gtk+
20:34.25 brlcad we're still at the point that I frankly DO NOT CARE about performance, I care about the survivability of code that will eventually result in performance gains :)
20:34.38 vasc eventually someone else realized we should also have a bare non-toolkit client so the next time someone did a port they could refer to that
20:34.42 brlcad the point is performance, but it's not the goal, if that makes sense
20:35.05 vasc yeah i know
20:35.17 Notify 03BRL-CAD:carlmoore * 65702 brlcad/trunk/doc/docbook/system/man1/en/bwcrop.xml: add 'clockwise-from-upper-left' remark, to provide a summary
20:35.29 vasc man when i did the gtk+ client in Freeciv it took me a year to get SOMETHING in CVS
20:35.41 vasc it worked but it had all the memory leaks in it
20:35.44 vasc these
20:35.56 Stragus Ouch, never do that :)
20:36.00 brlcad nods
20:36.02 Stragus Don't write code with memory leaks "to fix later"
20:36.16 vasc well some of them i didn't realize they were memory leaks
20:36.27 vasc because they were deep inside the gtk+ library code itself
20:37.04 vasc anyway nothing a few rounds of valgrind didn't work
20:37.14 vasc i ended up reimplementing a couple of gtk+ widgets because of that
20:37.39 vasc s/didn't/did/
20:37.42 vasc the
20:37.56 vasc i caught them all with valgrind and i forget the other tool
20:38.22 vasc right memprof
20:39.27 vasc so we had noticeable memory leaks in 15minutes, then it was 30 minutes, then it was 3 hours of gameplay, and then no leaks
20:40.34 brlcad we'd all be lucky if memory leaks were the entent of the problem here ;)
20:40.43 Notify 03BRL-CAD:starseeker * 65703 brlcad/trunk/TODO: Note that this is to replace existing manual code
20:41.03 vasc well i had to do a lot of things still that was actually a pretty barebones client
20:41.16 brlcad starseeker: give poor carl a break, typo ;)
20:41.19 vasc i think the whole port took close to 2 years
20:41.33 starseeker brlcad: heh, sorry
20:41.40 vasc but yeah i was an undergrad so i guess i had more patience back then
20:41.47 brlcad and time
20:41.58 brlcad and motivation, all new interesting different
20:42.06 vasc time too yes
20:42.16 Notify 03BRL-CAD:starseeker * 65704 brlcad/trunk/TODO: typo
20:43.02 vasc but now i have something i didn't have back then. masters students to coherce in working for me.
20:43.04 vasc muhahahaha
20:43.10 vasc into
20:43.21 brlcad at a minimum, we'll end up with an "rt2" or "rtcl" or whatever you're calling your harness, but the more that can be integrated, the better
20:43.29 brlcad that is all
20:43.37 vasc yeah that's the idea
20:44.38 vasc i'm presently supervising like 2 masters students, and two more in like 3 months. and maybe another one in 6 months or 8
20:44.46 vasc co-supervising anyway
20:45.14 vasc they are all doing GPU ray tracing.
20:45.26 brlcad if all we end up with, though, is rt2 ... then we'll be in a world of hurt once your faculty impose different priorities on your time
20:45.40 vasc that's the problem i have
20:45.55 vasc in the end of this year or start of next year i'm going to work on something else
20:46.06 vasc i could try convincing a masters student to work on this but i dunno
20:46.31 brlcad boolean eval on gpu is easily paper-worthy imo
20:47.05 vasc half my students aren't doing their thesis now because they started working part-time
20:47.16 vasc i had one dropout a couple months back because of that
20:47.36 vasc the economic situation is bad here
20:47.37 brlcad can do nothing with that information :)
20:48.05 vasc yeah me neither :-)
20:48.20 vasc i can just wish them good luck
20:48.40 brlcad so do you think end-to-end opencl pipeline is achievable in two weeks?
20:48.47 vasc no way
20:48.49 brlcad (NOT opimized)
20:49.15 vasc there's a really big issue here. which is the dynamic memory allocation the current code keeps insisting on doing
20:49.25 vasc a big no no in opencl or cuda or whatever
20:49.39 Stragus nods to that
20:49.41 brlcad which code
20:49.53 vasc you can call malloc inside the gpu. unless you implement your own malloc... and you don't wanna do that anway
20:50.07 vasc you can't call malloc inside the gpu
20:50.11 brlcad that big no-no is not at all unique to cuda/opencl/gpu
20:50.36 brlcad you're not answering my question.. I know malloc is nfg
20:50.49 vasc yes which is why i want to do a simplified ANSI C pipeline without the mallocs first
20:51.12 vasc well
20:51.22 brlcad what piece of the pipeline is problematic in the current code such that it's a problem?
20:51.27 vasc in the multi-hit traversal code the hits are stored in this doubly linked list
20:51.42 vasc dynamic doubly linked list
20:51.51 brlcad so the hit record-keeping portion
20:51.55 vasc which is then processed by the boolean evals
20:52.28 vasc the boolean eval processing is seemingly split in two portions. one works every time you advance the traversal, and then there's an rtfinal call once the traversal ends
20:52.35 vasc which traverses the whole hit list i think
20:53.03 brlcad sounds about right, yes
20:53.30 vasc well the best option would be if somehow you could incrementally compute the rtfinal thing and not need dynamic memory allocation
20:53.43 vasc or at least that's what my gut tells me
20:54.28 brlcad it would not be hard to eliminate the dynamic memory allocation there
20:54.43 Stragus Static per-ray buffer?
20:54.51 brlcad hits could easily be stored in an array/buffer, yes
20:55.16 vasc but we would like not to use a lot of memory if we could too
20:55.22 Stragus You would need some kind of dynamic allocation of bundles of 4/8 hits, from some big static buffer, managed by atomics
20:55.23 vasc gpus have tiny caches
20:55.26 brlcad pages of them to avoid some arbitrary #-of-objects-along-ray limit
20:55.32 Stragus Stop shooting rays when the buffer is too full, process results, resume
20:55.47 vasc right
20:56.04 vasc i thought of doing it that way
20:56.12 vasc and for that actually we should be using a bvh instead of a grid
20:56.41 brlcad vasc: by the time this is all done being implemented, we'll probably have a TB on the video card ;)
20:56.41 vasc coz in a bvh you can guarantee the max amount of object in a cell.
20:56.53 starseeker I think the assertion is that this approach is so foreign to the assumptions and design of our existing code that fitting it in involves a virtual rewrite?
20:56.57 Stragus The idea would be to stop raytracing before the big static buffer runs out
20:57.12 Stragus If you run out, drop the rays, process buffered rays, then restart
20:57.17 starseeker vasc: with csg though you can't make any assumptions about the maximum number of hits in a cell
20:57.42 brlcad starseeker: it is a rewrite, but we want to gut the cathedral from the inside out, not build a new one ;)
20:57.55 starseeker even an individual csg primitive may produce unpredicitable numbers of hit points
20:58.00 vasc all the primitives i've seen so far are manifolds so at most you have two intersections per object
20:58.12 starseeker vasc: take a look at nurbs ;-)
20:58.23 starseeker even a torus can have 4 intersections
20:58.34 brlcad so can a tgc
20:58.34 vasc yeah coz it has a hole
20:58.49 vasc so much for that idea
20:59.02 starseeker bots are another one that's not predictable
20:59.17 starseeker dsp, ebm...
20:59.21 brlcad same idea as the hit tables though -- you just keep track of pages of results
20:59.30 vasc hmpf
20:59.54 vasc i didn't want to keep the dynamic memory allocation but i guess i'll have to stomach it
21:00.05 starseeker vasc: what about a memory pool?
21:00.05 vasc it seems kind of like a low tech solution to the problem
21:00.17 vasc yeah we would have to do it like that yes
21:00.18 Stragus Properly managed dynamic memory allocation with atomics is all right
21:00.22 starseeker minimze the dynamic part, even if we can't totally eliminate it?
21:00.54 brlcad it can be "practically" eliminated for most models
21:00.58 Stragus has had to use dynamic memory on CUDA with atomics
21:01.09 brlcad then there will be atypical models that break the mold
21:01.11 vasc like i said i have a gut feeling we don't need dynamic memory to solve the problem at all
21:01.31 Stragus You don't need dynamic memory if you can process the hits right away as they come
21:01.50 starseeker vasc: we can probably avoid it for many cases, but it's trivial to construct a model that will break any static assumptions we care to make
21:01.54 Stragus Which is also a lot faster... but all code calling the raytracer isn't designed for that
21:02.33 starseeker Stragus: as I understand boolweave that's not actually possible (processing hits right away)
21:02.39 starseeker Stragus: at least, not for solid raytracing
21:03.14 Stragus You could end up buffering just few hints to process "segments", which would a lot lighter on memory requirements
21:03.27 Stragus You could store the hits in shared memory, no global memory stores involved
21:03.34 vasc i could just use the memory pool and if it gets exausted i abort the processing, realloc more chunks and try again
21:03.38 brlcad so vasc, we're again back to gsoc scoping ... goal towards the finish line, what useful things will result
21:03.44 starseeker vasc: doesn't mean it's not worth optimizing for the "common" situations which will be most models, but it's important that there be a working fallback (even if it is slow) for the harder cases
21:04.02 brlcad this discussion would have been great had the gsoc goal been "implement coherent boolean weaving" ;)
21:04.28 brlcad it was a given that this would not be achieved in the timeframe given the other aspects
21:04.48 vasc yeah it would take the entire timeframe just to get a good solution to this specific problem
21:05.16 brlcad certainly not enough time in 2 weeks -- my earlier question about full pipeline was whether something really trivial could be done
21:05.39 brlcad like "don't weave, sort, take the first hit"
21:06.30 vasc well
21:06.38 brlcad having a testing pipeline that went end-to-end would be a useful end state as that could be used down the road for the next step(s)
21:07.13 bhollister brlcad: regarding 'view_state'... trying to turn on vertex labeling when subcommand "kill V" is invoked on the CLI. this appears to be done in f_labelvert (overlay.c) after entering solid edit mode.
21:07.15 vasc wouldn't that bork the csg?
21:07.32 brlcad sure, we're talking about opencl pipeline though, not correctnesss
21:07.49 vasc well a single-hit ray tracing pipeline is rather simpler yes
21:07.50 brlcad doing both is impossible in the timeframe
21:08.05 vasc yeah i should be able to do that in the timeframe
21:08.06 brlcad assuming doing both will happen later is super high risk
21:09.07 brlcad quasi single-hit
21:09.17 brlcad it could still do all hits and simply throw them away
21:09.27 vasc yeah that
21:09.38 vasc the hit intersection routines would still compute all the intersections
21:09.44 vasc but we only store one
21:09.47 vasc hm
21:09.48 brlcad that's arguably the correct thing to do that wouldn't have to be changed/undone when coherent booleans materialize
21:10.31 brlcad currently, there's a flag in the application structure that says whether we care only about the first hit or all hits
21:11.15 brlcad it currently evaluates all of them (for most primitives) and decides at the end whether to return all segments or just the first
21:11.17 vasc wouldnt that also require dynamic memory?
21:11.30 vasc its like you said the torus can have 4 hits and so on
21:11.54 brlcad back to what the goal/point is
21:12.03 *** join/#brlcad merzo (~merzo@170-0-133-95.pool.ukrtel.net)
21:12.17 vasc i think we should just do an ANSI C pipeline
21:12.20 brlcad if it's to get a pipeline, then the record keeping strategy doesn't matter as it's not the goal
21:12.26 vasc which we'll get to simplify more later
21:12.38 brlcad so use a fixed array or try to do efficient dynamic pages, etc
21:13.19 brlcad why C pipeline?
21:13.50 vasc in my experience trying to code a complex algorithm in CUDA or OpenCL direct usually leads to wasted time
21:14.02 vasc you should have a C implementation first
21:14.20 vasc it also helps because then you have something you can compare against on debugging
21:14.21 brlcad which ... we do :)
21:14.51 vasc yeah but its not something you should implement on CUDA or OpenCL.
21:15.16 brlcad not transcoded directly, sure
21:15.43 vasc its also kind of opaque
21:16.10 vasc i kind of get it but the design but its a bit overengineered.
21:16.18 brlcad that's more familiarity, I think ... if anything the datastructures and layerings are quite exposed
21:16.41 vasc its lasagnified
21:16.54 brlcad you're referring to the spatial partioning if I'm not mistaken?
21:17.01 vasc the traversal
21:17.17 brlcad traversal of the spatial partitioning, yes
21:17.28 vasc its almost like i'm programming Java EE.
21:17.51 vasc almost as lasagnified.
21:17.59 brlcad now that's an exaggeration :P
21:18.07 brlcad and a mean one
21:18.39 brlcad if the code had feelings, you would have hurt them
21:18.41 vasc it all makes sense because of all the options
21:18.59 vasc conditional this and conditional that
21:19.31 vasc so having seen this gordian knot i felt like cutting it. my 2nd name is alexander after all.
21:19.45 vasc :-P
21:19.53 brlcad that's how production codes evolve, espeically when they are highly actively developed and expanded
21:20.04 vasc yeah
21:20.09 vasc it always like that
21:20.12 brlcad then the next guy comes along and just see's dozens of options on the periphery of what they care about
21:20.26 brlcad but pull together 20 other users, and suddenly all options are in use
21:20.33 vasc or not
21:20.37 brlcad that said, rt does have too many options (exposed)
21:20.56 brlcad most actually do get used (at least the ones that are not compile-time)
21:21.15 vasc i mean it should be used someplace but sometimes man
21:21.21 brlcad so cutting a feature means having to negotiate and consider the impact with/on users
21:21.41 vasc which is why i propose a simplified pipeline which can be select someplace
21:21.49 vasc instead of trashing what is there
21:21.59 vasc what is there is there for a reason
21:22.13 vasc and any replacement, if there is one, should cover all the necessary use cases
21:22.31 vasc what i have is too simplified to do that
21:22.44 brlcad I would assert that until demonstrated otherwise, the production code defines the necessary use cases :)
21:22.49 vasc but too complicated and it all becomes unmanageable to port. at least at this point.
21:23.29 brlcad otherwise "starting fresh" is hardly defensible from a pragmatic standpoint
21:23.44 brlcad the value is in the complexity and depth of features
21:23.45 vasc good luck trying to port the current setup to CUDA
21:23.48 vasc or OpenCL
21:24.03 vasc and getting good performance out of it to boot
21:24.45 vasc it uses dynamic memory and it has way too many function calls, and uses way too much memory
21:24.48 brlcad if I only got performance because I ripped out all functionality or correctness, that's not at all interesting or valuable
21:25.19 vasc ah but the thing is i don't think you need to write the algorithms like that to produce the required functionality
21:25.32 vasc its just noone bothered doing it before
21:25.53 vasc because at the time the code was written the hardware performance optimization parameters were different
21:25.56 brlcad sure
21:26.02 vasc memory was fast and computations were slow
21:26.06 vasc now its the other way around
21:26.15 brlcad old news
21:26.31 vasc so an extra malloc do prevent doing a dot product is no longer a good optimization
21:26.35 brlcad now == a decade ago
21:27.27 vasc yeah but you can still sense that in the code
21:28.04 vasc it looks a lot like the raytracer i wrote in 2001
21:28.11 vasc 2000 actually
21:28.15 brlcad I don't quite understand the logic you're using -- nothing ever stated implied that "port the current setup to CUDA" meant keep malloc
21:29.19 brlcad this is all a question of how to go about instituting an upgrade on very old infrastructure
21:29.20 vasc let's examine one case
21:29.25 vasc the current code has mailboxing in it
21:29.43 vasc so do you do the mailboxing or do you just recompute the intersections?
21:30.13 Stragus Some primitive intersections are very expensive to compute, like NURBS
21:30.20 brlcad there's plenty of research papers demonstrating both quite fast, so fast that I frankly wouldn't care
21:30.51 vasc see there's all this context i don't have because i didn't reimplement all the primitives yet
21:31.00 brlcad is it the absolute fastest for a given test case, dunno and *really* don't care
21:31.34 brlcad and you wouldn't have time to anytime soon, and that's part of the point of doing things incremental like this
21:31.44 vasc exactly
21:31.54 brlcad NURBS is a good example because that's not going to be rewritten in less than a year
21:32.18 vasc i should have a student working on that next year
21:32.27 brlcad and it's kind of useless to a user if I had one renderer that was blazing fast for all primitives but I had to use a different tool if there were nurbs
21:32.42 vasc not necessarily
21:32.48 brlcad it's got to be the same tracer, just some models result in slow performance
21:32.50 vasc take the wireframe mode for an example
21:33.14 brlcad and slow is relative
21:33.17 vasc if i can get a more accurate preview that can have some value in itself
21:33.43 Stragus I would have considered writing a raytracer that just returns "hits" to some callback
21:33.55 Stragus Then, in a second phase, someone can plug something that buffer the hits into that callback
21:34.01 brlcad if we're taling about accuracy, I don't trust the results one bit without incredibly expensive verification and validation
21:34.44 brlcad analogy time
21:34.47 vasc that's why i don't work in the medical sector
21:34.49 Notify 03BRL-CAD:starseeker * 65705 (brlcad/trunk/include/analyze.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp and 2 others): Put the control comb prep in the subtraction search function. Need to think about where/how/if to store preps for later validation diffing...
21:35.03 brlcad much of what is in BRL-CAD is like the Louvre
21:35.09 vasc i had enough of that when i worked in telecoms
21:35.15 brlcad it's a big old building filled with old artwork
21:35.53 Stragus Then you want to transform the Louvres into a modern space station?
21:35.53 brlcad but shitty dangerous wiring, bathrooms with holes in the ground, and solid marble walls
21:35.59 Stragus :)
21:36.35 brlcad not at all, just into a modern museum, up to code
21:36.49 vasc http://cdn4.sol.pt/fotos/2014/11/21/393092.jpg
21:36.53 brlcad Stragus: your approach would certainly be: I'll build my own damn museum
21:36.58 Stragus Damn right!
21:37.21 Stragus Just kidding, I appreciate the monstrous amount of work into BRL-CAD
21:37.22 brlcad and I'd say, that's great -- anyone can and will and have done that
21:37.38 brlcad but then it's not the Louvre
21:37.39 bhollister brlcad: okay, i suppose that that 'labelvert' can be used before calling 'kill V'. i'm getting coords as labels (not billboarded). but i believe i've seen this as vertex numbering before in some other context.
21:37.44 brlcad it's a modern art building
21:38.13 brlcad a lot of the modern tracers are exactly like that -- very sleek polished, very little art but what is there is impressive
21:38.28 brlcad the bathrooms and wiring are AMAZING *cough*
21:38.45 vasc until they aren't. see you in 300 years.
21:38.53 brlcad in the end for BRL-CAD, we have a big old building that needs the wiring upgraded
21:40.09 vasc that building in the picture i posted, they just nuked the interior. they built a glass building and kept the facade.
21:40.21 Stragus And we can't sanely renovate the bathroom without upgrading the hallways falling apart into modern moving walkways
21:40.46 brlcad vasc: that is certainly another approach
21:41.24 brlcad one that has some appeal, but one that we can't afford to stop to build so it's up to some contractor/builder to remain motivated and do a good job for that to happen
21:41.39 bhollister starseeker: besides http://brlcad.org/wiki/MGED_CMD_labelvert, is there a way to label vertex number on an object instead of coords.
21:42.21 brlcad Stragus: I certainly can -- and figuring out how to do that without disrupting the day-to-date operations of the museum is exactly the sort of engineering concerns I think about all the time :)
21:42.32 Stragus I would be interested in working on a GPU CSG raytracing, but the interfaces currently leading to the rt code are... problematic
21:42.40 Stragus Indeed brlcad :)
21:42.41 brlcad it presents it's own set of challenges
21:42.51 brlcad and takes time
21:43.05 Stragus GPU CSG raytracer*
21:43.07 brlcad but I find it both more rewarding and ultimately more impacting / important to users
21:43.19 Notify 03BRL-CAD Wiki:Bhollister * 9115 /wiki/MGED_CMD_permute: /* Argument(s) */
21:44.01 vasc well i simplified those interfaces quite a lot
21:44.34 vasc that was my problem too
21:44.52 brlcad that's why my comments were centered around what can we salvage because there's never going to be enough time to entirely gut the building (even though I live in a magical world where I can clone the Louvre and work on it)
21:45.12 vasc quite
21:45.20 vasc which is why i think the should have rt and rt-simple
21:45.25 vasc we
21:45.32 Stragus rt-archaic and rt-modern
21:45.56 brlcad Stragus: and the tool keeps an internal timer and renames itself down the road?
21:46.09 Stragus That works. :)
21:46.09 brlcad "modern" is so overused
21:46.26 vasc something is only "modern" until it isn't.
21:46.27 Stragus Obviously, there was a hint of sarcasm in that suggestion
21:46.34 brlcad I know
21:47.10 brlcad but it's a good point -- what we consider modern today was really an architecture shift that happened about 20 years ago, popularlized about 10 years ago
21:47.22 Stragus Agreed
21:47.37 vasc https://en.wikipedia.org/wiki/Modern_art
21:47.41 brlcad and will likely be obsolete 10 years from now for one reason or another
21:48.01 vasc so you have modern and postmodern and postpostmodern
21:48.51 Stragus ultranewpostmodern or nothing
21:49.22 vasc neomodern
21:49.32 brlcad vasc: it's too late now to do much else about things, but in terms of your gsoc project -- what do you see the end state being?
21:49.58 vasc every primitive we talked about except the bot, gpu side database storage
21:50.03 vasc the grid construction
21:50.35 vasc the traversal and rendering is something else which i think should be kept in a separate pipeline that the user selects if he wants to use it i.e. rt-simple
21:50.51 vasc i'm still interested in doing a paper out of this
21:51.03 vasc and for that the rendering pipeline needs to be made properly efficient
21:51.10 vasc but i don't know how my time will be
21:52.04 brlcad well we're talking gsoc timeframe
21:52.19 brlcad that'd easily be after (gladly support you in any way needed)
21:52.22 vasc so the primitives are : ell, ehy, arb8 (done)
21:52.25 starseeker bhollister: I don't know of one offhand
21:52.53 brlcad as I see it, the only decision is whether to a) spend the next 2 weeks working on completing a pipeline transform demo (with whatever limitations), or b) spend 2 weeks merging the traversal features of your demo with the rt/librt code as a runtime option (as the intention is migration as more pieces fall into place)
21:53.02 vasc tor, tgc i'll do it in the timeframe too
21:53.17 brlcad o.O
21:53.21 vasc what i'm working on now is gpu side database storage
21:53.24 brlcad how are you going to do tor? :)
21:53.42 vasc and then i'll do opencl shot code for the tor and tgc
21:54.05 brlcad I doubt you'd get tor done before the deadline if you started now...
21:54.19 brlcad tgc is even highly debatable
21:54.21 vasc its just a cone with a couple of planes right?
21:54.42 brlcad just a cone, a fully generalized mathematical model of one, yes
21:54.57 brlcad s/fully/mostly/
21:55.03 vasc i did a ray cone intersector in 2000. so i kinda know the problem.
21:55.12 vasc its not gonna be that much more complicated than ehy was
21:55.13 brlcad heh
21:55.25 brlcad well then it should have been obvious to you how 4 hits are possible
21:55.36 vasc no just two
21:55.45 brlcad if it's not, then you almost certainly didn't work with something this generalized
21:55.46 vasc 4 in the torus
21:55.52 brlcad tgc is also 4
21:55.52 vasc but the tgc only 2
21:56.00 brlcad 2 or 4
21:56.03 vasc i don't see how. it has no holes
21:56.05 vasc does it?
21:56.08 brlcad nope
21:56.24 vasc you either hit the caps or the walls
21:56.39 vasc man
21:56.56 vasc i don't see how you get more than 2 valid hits
21:57.15 vasc you are going to have 4 results
21:57.19 vasc but some won't be valid
21:57.24 brlcad you can hit a cap, come out a wall, go through another wall, come out another cap
21:57.38 brlcad or in a wall, out a wall, in a wall, out a wall
21:58.05 brlcad what's that whiteboard site?
21:58.14 bhollister starseeker: how does 'permute' determine which vertex has a particular vertex index then? 'sed' doesn't appear to turn on the billboarded overlay of vertex-list indices.
21:59.01 vasc so the problem is because you need to return the ins and outs
21:59.12 vasc no but that doesn't make a lot of sense
21:59.22 vasc in that case you needed 4 for the sphere too
21:59.24 vasc and you don't
21:59.46 Stragus Four hits on a cone? I'm not following that either
21:59.47 brlcad vasc: you're not visualizing the right shape -- like I said, this is a cone generalization
22:00.06 vasc its just a truncated cone
22:00.07 brlcad the code is defined as a ruled surface with two elliptical ends
22:00.12 vasc its like a frustum except its round
22:00.14 Stragus Any convex shape is two hits, the end
22:00.19 vasc right
22:00.21 vasc it has no holes in it
22:00.22 Stragus Ah, so two cones on top of each other
22:00.22 vasc genus 0
22:00.32 vasc oh that?
22:00.32 brlcad no, one cone -- one single equation
22:00.38 vasc see genus 0
22:01.15 brlcad pinch the top ellipse so it's wide
22:01.28 brlcad pinch the bottom ellipse so it's narrow
22:01.47 brlcad the resulting conic is higher order and requires a solve
22:01.57 ih8sum3r brlcad: I just installed ubuntu server 14.04 and run update command, nothing else. I check .vdi file size it's about 1.8G. Huge!
22:04.54 brlcad I forget the ratio required, but just construct a cone with ends orthogonally stretched 10x and you easily can go in and out twice as you clip the top and bottom
22:05.35 vasc the code does use a quartic equation in some cases
22:05.47 vasc but i never heard of someone doing the ray-cone intersection like that...
22:05.50 brlcad that's the case
22:06.05 brlcad it figures out when that happens
22:06.31 brlcad obviously specializes the faster simpler cases
22:07.42 brlcad vasc: that's why I say tor is also unlikely -- notice the call to rt_poly_roots() in both tor and tgc
22:07.50 vasc now i get it
22:07.54 vasc no i still don't
22:08.03 brlcad you need a polynomial root solver to handle the quartic equations
22:08.15 brlcad doing that via opencl is going to be fun
22:08.20 vasc are the split planes enforced to be parallel or not?
22:08.31 vasc the top and bottom split planes
22:08.34 brlcad I think they are, but doesn't matter
22:08.38 vasc it does
22:08.53 vasc when
22:08.54 vasc well
22:08.56 brlcad that's one more generalization that was discussed, but little value
22:09.10 brlcad and really would complicate things
22:09.41 vasc www.geometrictools.com/Documentation/IntersectionLineCone.pdf
22:10.25 vasc they don't use the quartic either
22:10.40 brlcad that's our "REC" case, right elliptical cone
22:11.58 vasc well in the torus its evident that you can get 4 hits because of the hole
22:12.06 vasc in the truncated cone i just can't visualize it
22:13.45 brlcad if you have brl-cad compiled, just run mged test.g and make tgc tgc
22:13.56 brlcad I believe the default can have 4 hits
22:14.16 brlcad or edit the ends to stretch them out so it's more obvious
22:14.28 brlcad the difference from what you're used to is having elliptical ends
22:14.49 brlcad not circles, and the ellipses don't have to align
22:15.48 Stragus doesn't get it either
22:16.05 Stragus Unless it's two cones on top of each other, defined by the same equation
22:16.53 vasc http://news.povray.org/povray.advanced-users/thread/%3C379F3F96.48A201E8@isd.net%3E/?ttop=340620&toff=1500
22:18.03 vasc the surface of revolution isn't axis symmetrical with the vertical axis
22:18.10 vasc but it will sounds strange that you need 4 hits
22:18.35 vasc still
22:18.51 vasc does it somehow get in an hourglass shape?
22:22.07 brlcad here we go, check out this ancient rendering: http://brlcad.org/gallery/var/albums/historic/primitives_old.jpg
22:22.20 brlcad next to the terrain-looking object is a TGC
22:22.41 starseeker bhollister: I believe the vertex indicies are implicit in the data structures, but that may be only for arbs...
22:22.41 brlcad notice how on both sides, you can barely slice through both the top and the bottom
22:23.21 vasc the top most red one?
22:23.22 brlcad that generalization dates back to at least the 70's
22:23.25 brlcad yes
22:23.50 vasc well it looks interesting
22:24.11 brlcad Tron used that same notion of a cone (which was based on Comgeom, which BRL-CAD was also based on)
22:25.02 vasc its because it's concave
22:25.23 vasc calling that a cone is a bit of a stretch though :-)
22:25.49 *** part/#brlcad ih8sum3r (~deepak@122.173.5.55)
22:26.15 brlcad the conical surface is the same equation as seen in the other three forms
22:26.27 brlcad their equations just simplify to quadratic because of alignments
22:26.42 vasc that doesn't have rotational symmetry
22:26.51 brlcad i'm not sure it's technically concave
22:27.08 vasc if it wasn't you wouldn't get more than 2 hits
22:27.17 vasc its bent and concave
22:27.18 brlcad yes
22:27.49 starseeker maybe a good way to say it is the shape does not define its own convex hull?
22:28.06 brlcad I had a discussion with one of our mathematicians years ago and vaguely recall arguing the same point and him going into detail how it was not mathematically
22:28.26 brlcad at least not the mathematical definition of concavity
22:28.27 Notify 03BRL-CAD:ejno * 65706 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: verify section volume/plate modes
22:28.39 brlcad there was some other way to characterize it
22:29.11 starseeker it *is* a ruled surface, IIRC
22:29.30 brlcad but that's also goggles from about 10 years ago, I could be mistaken
22:30.29 brlcad yeah, and there was some aspect of how this particular surface is constructed iirc
22:30.49 brlcad that each "outline of the surface" is actually a straight line
22:31.07 starseeker maybe some form of generalized cone? http://mathworld.wolfram.com/GeneralizedCone.html
22:31.40 brlcad maybe, but I think that might be different meaning to the word generalized
22:31.52 brlcad fully generalized to nonelliptical ends is pretty nuts
22:32.02 starseeker vasc: well, the upshot is it's going to be a challenge ;-)
22:37.32 vasc well it can't have more than four
22:38.17 vasc so i guess it is more complicated than i thought
22:38.24 vasc damn
22:38.44 vasc still it was interesting
22:40.09 vasc you say this is a commonly used primitive?
22:40.53 vasc are there some physical processes which can generate this easily?
22:43.16 Notify 03BRL-CAD:starseeker * 65707 (brlcad/trunk/include/brep.h brlcad/trunk/src/libbrep/shape_recognition_util.cpp brlcad/trunk/src/libged/shape_recognition.cpp): Not working yet, but try to delay comb finalization so we can be sure all necessary objects are in place.
22:44.15 starseeker vasc: you mean machining or some such?
22:44.45 vasc it seems kind of like something you could do with bending
22:44.52 vasc ah well
22:45.06 vasc i'll just finish this database thing it's been taking too long
22:51.42 vasc i'll redo my schedule though
22:52.09 vasc its probably not a good idea to do the opencl rendering pipeline until we know how we can process the multiple hits without the mallocs
22:55.44 Notify 03BRL-CAD:starseeker * 65708 brlcad/trunk/src/libged/shape_recognition.cpp: Helps to pass the right pointer...
23:03.40 Notify 03BRL-CAD Wiki:Konrado DJ * 9116 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 27 JULY 2015 */
23:12.38 vasc this is using obscene amounts of memory. need to pack the data more.
23:19.02 vasc its amazing how bad the standard packing is
23:21.20 vasc 384 bytes if i use the standard types and 160 bytes if i pack things myself
23:31.26 *** join/#brlcad konrado (~konro@41.205.22.56)
23:46.29 bhollister starseeker: is there a preferred way to visit all the vertices in an nmg model? is there a use case somewhere showing nmg_visit_* to search for a vertex with a given coord?
23:56.31 Notify 03BRL-CAD Wiki:Bhollister * 9117 /wiki/MGED_CMD_nmg: /* Proposed subcommands */

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