IRC log for #brlcad on 20140505

01:16.58 *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14)
01:32.11 *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14)
01:38.10 *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14)
01:44.37 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
01:48.26 *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14)
01:57.56 *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14)
02:02.07 *** join/#brlcad hcurtis__ (4ab29b8d@gateway/web/freenode/ip.74.178.155.141)
02:07.19 *** join/#brlcad FreezingAlt (~FreezingC@135.0.41.14)
02:35.50 Notify 03BRL-CAD:starseeker * 60470 brlcad/trunk/doc/docbook/system/man1/en/CMakeLists.txt: Stub in a gdiff2 man page, as much to keep track of options as anything. Nothing of significance added yet, still working out feature set.
03:14.55 Notify 03BRL-CAD:brlcad * 60471 brlcad/branches/RELEASE/include/CMakeLists.txt: break out brlcad_ident() into its own header file. this avoids the cyclic dependency hack that was put in place to quell a warning while letting us keep the function static.
03:34.03 *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee)
03:40.49 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
03:44.17 Notify 03BRL-CAD:brlcad * 60472 brlcad/branches/RELEASE/CMakeLists.txt: end of an era. rebirth anew. rework configuration tests so we can properly support compile-time version API. we start with just stashing the information into config variables. not intended as a permanent solution, but is a workable one that will suffice as long as brlcad_config.h is installed (which it shouldn't). these version values should be a
03:44.19 Notify template (or two, one for version, one for ident), exapanded during cmake.
03:48.44 Notify 03BRL-CAD:brlcad * 60473 brlcad/branches/RELEASE/include/brlcad_version.h: put in place new versioning API that not only supports run-time version testing but also compile-time testing. includes a new BRLCAD_API() macro for use by 3rd party codes (instead of a compound number based on the version triplet). no longer uses the version files directly, now relying on the cmake variables (which are derived from the
03:48.46 Notify version files). intended as a interim method as a better solution will be to make brlcad_version.h and brlcad_ident.h be templates that are expanded during cmake.
03:49.21 Notify 03BRL-CAD:brlcad * 60474 (brlcad/branches/RELEASE/src/conv/dxf/g-dxf.c brlcad/branches/RELEASE/src/conv/g-dot.c and 15 others): utilize brlcad_version.h vs brlcad_ident.h accordingly now that the logic is split
03:51.48 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
04:00.40 *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee)
04:39.09 *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net)
04:53.16 Notify 03BRL-CAD:brlcad * 60475 (brlcad/trunk/CMakeLists.txt brlcad/trunk/include/CMakeLists.txt and 17 others): merge r60470:60474 from the RELEASE branch to trunk implemented in support of compile-time API version testing. this replaces the compile-time integer from r55789, instead providing a BRLCAD_API() call for 3rd party application use. the eventual solution should be to make brlcad_version.h and brlcad_ident.h be
04:53.19 Notify a template, expanded by cmake, but this new API should remain unaffected as long as calling codes adhere to the published API and not the brlcad_config.h symbols.
04:56.36 Notify 03BRL-CAD:brlcad * 60476 brlcad/trunk/TODO: compile-time API is now provided. the integer solution was good, but the new BRLCAD_API() call is little more symantically rich and future-proof.
05:28.20 *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton)
05:53.05 *** join/#brlcad cwstirk (~charlie@c-71-56-216-45.hsd1.co.comcast.net)
07:45.41 *** join/#brlcad ries (~ries@190.9.171.121)
08:36.22 *** join/#brlcad luca79 (~luca@net-37-116-120-78.cust.vodafonedsl.it)
08:37.09 *** join/#brlcad vladbogo (~vlad@86.127.153.104)
08:40.25 *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net)
10:06.31 *** join/#brlcad teepee- (bc5c2134@gateway/web/freenode/ip.188.92.33.52)
10:33.14 *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton)
10:49.26 *** join/#brlcad Anaphaxet0n (~george@unaffiliated/anaphaxeton)
11:05.18 Notify 03BRL-CAD:starseeker * 60477 brlcad/trunk/src/libfb/tcl.c: Need string.h for strlen
11:56.42 *** join/#brlcad caen23 (~caen23@109.97.108.82)
12:00.09 *** join/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro)
12:20.31 mihaineacsu hello everyone!
12:21.32 mihaineacsu I'd like(scratch that, going) to contribute to BRL-CAD this summer
12:22.44 mihaineacsu I've been watching the projects page and there are so many options
12:42.29 Notify 03BRL-CAD:starseeker * 60478 (brlcad/trunk/include/rt/search.h brlcad/trunk/src/librt/search.c): Free the db_ls memory, not the dp pointers - they're not the responsibility of either db_ls or search.
12:44.26 *** join/#brlcad teepee- (bc5c2134@gateway/web/freenode/ip.188.92.33.52)
12:55.31 *** join/#brlcad ries (~ries@190.9.171.121)
13:21.07 d_rossberg mihaineacsu: nice to hear you plan to contribute to BRL-CAD ... so there are many options but what are your priorities? what would you like to do?
13:22.32 mihaineacsu d_rossberg: I liked many ideas, such as the materials database
13:23.11 *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14)
13:24.50 brlcad mihaineacsu: which projects page?
13:25.07 mihaineacsu http://brlcad.org/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas I was looking at this one
13:27.38 mihaineacsu I haven't yet figured what "my thing" is, I enjoy working with a lot of stuff: opengl, web development, mobile development and so on. I'm pretty much open to anything. I know that doesn't help narrow possible projects :)
13:31.21 d_rossberg there are not so many opengl or web development project ideas, but materials database is one of them ;)
13:32.55 d_rossberg maybe you should start with a review of the "proof-of-concept web work"
13:33.05 mihaineacsu you do mention in the project description that there is prior proof-of-concept web work that we can build upon? Can you help me find that?
13:33.18 mihaineacsu :)
13:36.29 d_rossberg havn't you looked at the link on the Project_Ideas page: http://brlcad.org/wiki/Materials_Database ?
13:40.50 mihaineacsu d_rossberg: I did, I'm not sure I understand what it means by "prior proof-of-concept web work" - does it mean there has been some work done on this project on brl-cad? Or I should I review a possible web dev solution such as an already build server/framework?
13:41.54 d_rossberg you could search the developer mailing list:
13:41.57 d_rossberg https://sourceforge.net/p/brlcad/mailman/search/?q=materials+database&mail_list=brlcad-devel
13:43.25 brlcad mihaineacsu: I don't' want to assume, are you applying to socis?
13:43.40 *** join/#brlcad teepee- (bc5c2134@gateway/web/freenode/ip.188.92.33.52)
13:43.59 mihaineacsu d_rossberg: thanks, great tip! I'll check it out
13:45.24 mihaineacsu brlcad: yes, I intend to apply for socis. But I want to contribute whatever the outcome is. I think it's valuable experience
13:45.39 brlcad great, glad to hear it
13:48.36 ``Erik sweet, and http://sophia.estec.esa.int/socis2014/?q=faq#socis_elig_student_who lists Romania as an eligable country
13:55.54 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
14:14.27 *** join/#brlcad hcurtis (b82d1b9c@gateway/web/freenode/ip.184.45.27.156)
14:24.17 *** join/#brlcad Zhao_Anqing (~clouddrif@123.157.213.96)
14:29.45 *** join/#brlcad teepee- (bc5c2134@gateway/web/freenode/ip.188.92.33.52)
14:41.50 *** join/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro)
14:52.36 *** part/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro)
14:52.39 *** join/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro)
14:59.40 *** join/#brlcad teepee- (bc5c2134@gateway/web/freenode/ip.188.92.33.52)
15:04.15 *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14)
15:04.44 Notify 03BRL-CAD:starseeker * 60479 (brlcad/trunk/include/db_diff.h brlcad/trunk/src/gtools/gdiff2.c and 2 others): Still not completely sure this is the right place to do it (instead of per-primitive logic to handle any funky situations that may come up) but add a numerical comparison capability and tolerance setting to gdiff2
15:11.20 Notify 03BRL-CAD:starseeker * 60480 brlcad/trunk/src/gtools/gdiff2.c: Use RT_LEN_TOL instead of VUNITIZE_TOL
15:12.34 Notify 03BRL-CAD:brlcad * 60481 brlcad/trunk/src/gtools/gdiff2.c: use BU_TOL_INIT_ZERO instead of partially initializing the struct.
15:17.48 Notify 03BRL-CAD:brlcad * 60482 brlcad/trunk/src/gtools/gdiff2.c: reduce a scope in diff_summarize(), cleanup
15:18.15 brlcad leaves marking the functions static and const args as an exercise to the reader
15:27.38 starseeker brlcad: does the value-based diffing look workable? It's a little on the "quick and dirty" side but without per-primitive functions I'm not sure what else to do...
15:31.09 Notify 03BRL-CAD:brlcad * 60483 (brlcad/trunk/src/libbrep/test_curve_intersect.cpp brlcad/trunk/src/libbrep/test_point_intersect.cpp): mark internal functions as static
15:41.04 Notify 03BRL-CAD:starseeker * 60484 brlcad/trunk/src/gtools/gdiff2.c: Mark a few more things as const
15:46.43 *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton)
15:56.30 Notify 03BRL-CAD:brlcad * 60485 brlcad/trunk/src/gtools/gdiff2.c: ws
15:58.40 starseeker brlcad: possibly dumb question - is the point of marking functions static in program files (as opposed to libraries) to avoid possible conflict with similarly named library functions?
16:05.19 ankesh11 starseeker: I am not aware of the context, but sometimes it's also due to performance concerns. Static functions tend to perform better due to near calls.
16:15.01 *** join/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro)
16:16.16 Notify 03BRL-CAD:starseeker * 60486 brlcad/trunk/src/gtools/gdiff2.c: Mark some functions as HIDDEN (static)
16:19.32 Notify 03BRL-CAD:brlcad * 60487 brlcad/trunk/src/libbu/affinity.c: allowing movement on a core sounds like a great idea, but apparently too clever for the default linux scheduler. multiple threads are getting assigned to the same core (on the same cpu), leaving one or more cores idle (even though their affinity mask clearly lists all N cores before and after they're set). ugh.
16:22.09 brlcad starseeker: marking functions static does give the compiler a little more information to work with so it can treat them differently
16:23.01 brlcad it can creates a different type of function symbol, inline more readily, different optimizations, doesn't need to be relocatable, etc
16:23.26 brlcad more importantly, though, app functions very often turn into library functions over time
16:23.59 brlcad and even within an app with no potential of getting migrated to a lib, it tells you when you break encapsulation
16:25.02 brlcad so several maintainability benefits
16:25.14 brlcad all around "a good thing" to always do
16:50.53 Notify 03BRL-CAD Wiki:KentAlanMick * 0 /wiki/User:KentAlanMick:
17:05.04 *** join/#brlcad richa (uid11933@gateway/web/irccloud.com/x-ookqjuicuczkeuyf)
17:21.38 *** join/#brlcad mihaineacsu (~mihaineac@p16.eregie.pub.ro)
17:44.21 *** join/#brlcad caen23 (~caen23@109.97.108.82)
18:17.23 *** join/#brlcad javampire (~ncsaba@p4FF703A0.dip0.t-ipconnect.de)
18:21.15 Notify 03BRL-CAD:starseeker * 60488 brlcad/trunk/src/librt/db_diff.c: Whoops - fix errno test
18:42.11 *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton)
18:50.01 Notify 03BRL-CAD:n_reed * 60489 brlcad/trunk/include/brlcad_ident.h: remove inline qualifier from brlcad_ident in response to gcc -Werror=inline "call is unlikely and code size would grow"
18:51.40 n_reed wait, what am I thinking
19:04.21 Notify 03BRL-CAD:brlcad * 60490 brlcad/trunk/NEWS: keith improved the newton solver iteration in r55755 for rays that would occasionally converges just slightly outside the UV domain. it was assumed that they'd get picked up by the adjacent subdivsion bounding box but that wasn't always the case resulting in speckling, particularly for implicits converted to brep. he added a tolerance check that makes sure these hit
19:04.23 Notify points aren't getting dropped. no more speckling.
19:06.49 Notify 03BRL-CAD:brlcad * 60491 brlcad/trunk/NEWS: writh r56192, keith implemented additional grazing hit behavior improvements to nurbs ray tracing. in particular, he uses a tigher dot tolerance.
19:09.29 n_reed nevermind me talking to myself, I was thinking 'what am I doing making a non-trivial function in a header non-inline?', but it's a private function and it wasn't inlined before so I guess it's okay
19:10.05 Notify 03BRL-CAD:brlcad * 60492 brlcad/branches/RELEASE/NEWS: merge 60491 from trunk noting improved grazing hit behavior
19:39.29 *** join/#brlcad LordOfBikes (~armin@dslb-088-066-140-022.pools.arcor-ip.net)
19:59.42 Notify 03BRL-CAD:starseeker * 60493 brlcad/trunk/doc/docbook/system/man1/en/gdiff2.xml: Document the options that are present - lots more to do here, but it's a start.
20:45.16 Notify 03BRL-CAD:brlcad * 60494 (brlcad/trunk/src/gtools/gdiff2.c brlcad/trunk/src/gtools/remapid.c): can just use static; only libs are expected to use HIDDEN.
20:46.34 Notify 03BRL-CAD:brlcad * 60495 brlcad/trunk/include/brlcad_ident.h: no longer violating compiler namespace
20:51.36 brlcad n_reed: yeah, non-inline is fine .. that was leftover from before I broke it out into its own header
20:54.45 Notify 03BRL-CAD:brlcad * 60496 brlcad/branches/RELEASE/include/brlcad_ident.h: merge r60489 from trunk to remove inline (wasn't intentional)
22:53.46 *** join/#brlcad FreezingAlt (~FreezingC@135.0.41.14)

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