IRC log for #brlcad on 20130521

00:31.08 ``Erik effin' awesome http://fab.cba.mit.edu/classes/862.13/students/brandon/index.html laptop sonar
00:33.03 ``Erik the future improvements section talks about using the technique in combination with a smartphones accelerometer to map surroundings
02:06.15 *** join/#brlcad crdueck (~cdk@24.212.219.10)
04:32.31 *** join/#brlcad jasleen (~chatzilla@117.255.246.73)
05:45.48 *** join/#brlcad zero_level (0e8b5206@gateway/web/freenode/ip.14.139.82.6)
05:51.01 Notify 03BRL-CAD Wiki:Navdeepbagga * 0 /wiki/User:Navdeepbagga:
06:04.02 Notify 03BRL-CAD Wiki:Navdeepbagga * 5302 /wiki/User:Navdeepbagga: Created page with "Personal Information Name: Navdeep Bagga Email Address: gottarocknow@gmail.com IRC Username: navdeep Phone number: +91 981 556 4887 Blog Address : http://www.navdeepbagga..."
07:07.24 *** join/#brlcad kesha (~kesha@49.249.18.127)
07:26.42 *** join/#brlcad priyanka (~priyanka@202.164.53.117)
07:34.12 priyanka Hello, I want to know which files are showing output on console. I changed fb_log of if_ogl.c file, if_debug.c file, but what I see is that output on console are not from these files. I checked for ogl_getmem error on running rt command. How could I know which file is responsible for output on console. Am I doing something wrong?
07:53.27 *** join/#brlcad witness__ (uid10044@gateway/web/irccloud.com/x-ocegrcajhjnrpmbl)
07:54.15 *** join/#brlcad priyanka (~priyanka@202.164.53.119)
08:55.17 *** join/#brlcad priyanka (~priyanka@202.164.53.117)
10:06.38 *** join/#brlcad priyanka (~priyanka@202.164.53.119)
11:08.51 ``Erik 'output on console'? you could try a recursive grep to match the string you're seeing... quite a bit uses bu_log()
11:50.32 *** join/#brlcad kanzure (~kanzure@131.252.130.248)
12:57.27 Notify 03BRL-CAD:bob1961 * 55517 brlcad/trunk/src/libtclcad/tclcad_obj.c: Call DM_MAKE_CURRENT before calling DM_GEN_DLISTS in libtclcad.
13:02.16 Notify 03BRL-CAD:bob1961 * 55518 brlcad/trunk/src/libged/erase.c: Can't assume that display lists are contiguous in gdl_headSolid. This was the culprit/bug that was causing geometry to mysteriously disappear from the display in MGED and Archer.
13:07.35 Notify 03BRL-CAD:bob1961 * 55519 brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: By default, Archer will use display lists.
13:12.15 *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net)
13:28.10 *** join/#brlcad zero_level (0e8b5206@gateway/web/freenode/ip.14.139.82.6)
13:34.03 brlcad starseeker: did you ever read this about the mark iv? http://blog.nikonmetrology.com/2011/01/24/modeling-a-world-war-i-mark-iv-tank/
13:42.08 *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua)
13:52.53 Notify 03BRL-CAD:bob1961 * 55520 brlcad/trunk/src/mged/dozoom.c: Added a call to DM_MAKE_CURRENT to mged's createDList and freeDListsAll functions.
14:11.08 *** join/#brlcad kesha (~kesha@49.249.18.127)
14:23.34 *** join/#brlcad navdeep (75c76ad4@gateway/web/freenode/ip.117.199.106.212)
14:23.53 brlcad d_rossberg or``Erik or starseeker: can one of you attend the gsoc deduplication meeting on friday?
14:24.29 brlcad right now we don't have any duplicates, but someone is required to attend and I'll be in a car at that time (1900 UTC, 3-4pm EDT)
14:25.03 brlcad required to attend just in case a duplication results from resolving some other org's duplication
14:27.03 ``Erik I'll be driving as well
14:33.47 d_rossberg I can do it
14:35.28 brlcad d_rossberg: thank you, it's held in #gsoc
14:36.08 brlcad you basically just make a quick decision whether to keep or let another org have a student, if a conflict arises (very unlikely)
14:37.56 d_rossberg ok, i subscribed to the gsoc calendar, it contains all the details
15:15.21 *** join/#brlcad phoenixyjll (8c71fd66@gateway/web/freenode/ip.140.113.253.102)
15:33.28 starseeker brlcad: I knew about the scanning effort, but I didn't know they'd published an article on it
15:34.08 starseeker don't supposed they published the data set somewhere?
15:38.43 *** join/#brlcad navdeep (75c76ad4@gateway/web/freenode/ip.117.199.106.212)
16:51.09 *** join/#brlcad kesha (~kesha@49.249.19.49)
16:59.47 *** join/#brlcad jasleen (~chatzilla@117.253.202.91)
17:34.43 *** join/#brlcad harmanpreet (~chatzilla@210.56.121.193)
17:39.31 brlcad starseeker: not that I ever heard of, the paper doesn't link it
17:41.26 *** join/#brlcad kesha (~kesha@49.249.19.49)
17:49.38 *** join/#brlcad avneet (~avneet@202.164.53.122)
18:13.32 *** join/#brlcad jasleen (~chatzilla@117.255.243.223)
18:42.59 *** join/#brlcad merzo (~merzo@73-183-132-95.pool.ukrtel.net)
18:45.32 *** join/#brlcad kesha_ (~kesha@49.249.19.49)
19:00.14 *** join/#brlcad jasleen (~chatzilla@117.255.243.223)
19:18.45 *** join/#brlcad rays2pix (~deepak@14.139.226.34)
19:43.07 jasleen brlcad: currently LIBDM display manager library has canvas specific DM
19:44.26 jasleen I am proposing, not to extend LIBDM, rather create a seperate path for this cross platform DM.
19:44.34 jasleen Is this ok?
20:01.22 Notify 03BRL-CAD:brlcad * 55521 brlcad/trunk/src/librt/db_anim.c: validate our input parameters before assuming they're non-null
20:09.45 Notify 03BRL-CAD:brlcad * 55522 brlcad/trunk/src/librt/test_bot2nurbs.cpp: style cleanup, ws
20:10.18 *** join/#brlcad rays2pix (~deepak@110.234.229.2)
20:10.35 Notify 03BRL-CAD:brlcad * 55523 brlcad/trunk/src/librt/prep.c: make rt_clean() work even if it's an rtip that no longer has a dbip handle (instead of crashing)
20:15.37 Notify 03BRL-CAD:brlcad * 55524 brlcad/trunk/src/librt/db_open.c: behave more user-friendly gracefully if we attempt to close a null dbip. let it mean we have nothing to do instead of halting the application.
20:34.06 ``Erik hm, sbcl core had a fit of x86_64 simd improvements just now O.o
20:57.48 Notify 03BRL-CAD:brlcad * 55525 brlcad/trunk/TODO: turns out at least the one instance being used with rt_new_rti()+rt_free_rti() does result in zero leaks (so long as you close the cloned dbip). still needs more TLC w.r.t. duplicate geometry and usage of the rt_uniresource/global memory pools, but no longer seems like a release barrier.
20:59.25 brlcad jasleen: I'm highly skeptical that you have enough time to change your proposal in such a drastic way that it could be evaluated with any confidence
20:59.41 brlcad that's something that should have come up in discussion literally a month ago
21:00.39 brlcad if this is because you're having such trouble with your libdm patch, that's a problem in itself that should be discussed
21:01.14 jasleen well.. the more i search, the more i get ideas. that's why updating my proposal.
21:01.39 jasleen yes i want to discuss
21:02.08 brlcad we can do that in a few hours if you have the time
21:02.26 brlcad it's probably an involved discussion :)
21:02.53 jasleen I have time. Just give me few minutes . I am updating scheduling in it
21:03.05 jasleen yah... i feel the same
21:04.00 brlcad in general, it doesn't sound like a great plan (to me), perhaps it does to others though
21:04.50 brlcad a primary rule of risk reduction (and debugging) is to only change one thing at a time
21:05.16 brlcad completely circumventing libdm probably cascades FAR more work than there is time to consider within the GSoC timeframe
21:06.16 brlcad "maybe" if you were already very experienced in libdm and our mged front-end code, you could successfully propose a "de-wire" proposal to circumvent libdm altogether
21:06.57 brlcad doing it all at once sounds like a recipe for disaster... or not even half-finished unusable code
21:07.19 rays2pix brlcad: I have updated my schedule to have only image format conversions. Request you to review it
21:07.31 brlcad rays2pix: you don't have to request anything
21:07.38 brlcad all proposals get reviewed over and over
21:09.28 brlcad it's pretty much assumed that you will respond to questions, comments, and requests posted as feedback with something satisfactory
21:09.37 jasleen can you tell about de-wire
21:09.50 brlcad if we find later that it's not, then ... we have a problem :)
21:10.09 starseeker brlcad: a tar.gz of my Haiku virtual machine (shows the off_t issue) is about 800 megs - would that be of use to you?
21:10.10 brlcad rays2pix: so best I can suggest is to re-read the feedback you have and make sure you really did address all questions/comments
21:10.38 brlcad starseeker: maybe, I have several haiku images too -- just haven't tried a compile since beginning release prep
21:10.43 jasleen brlcad: I am not getting what you want to say
21:10.56 brlcad jasleen: of course I could, but to what end?
21:11.48 starseeker brlcad: ah, k - you had mentioned needing access to a machine showing the issue, and that was the best idea I've had thus far... ironically enough, it's an issue I'm only seeing at the moment in virtual machines
21:12.37 brlcad starseeker: then before you consume the bytes uploading, let me just try a compile on my box
21:12.42 brlcad i can do that this evening
21:12.58 jasleen brlcad: Gave me few minutes. I Have to go now.
21:13.13 starseeker brlcad: k, thanks. I'd be willing to take a stab at it, but headcold + fatigue do not a good developer make :-/
21:13.18 jasleen Then i will discuss.
21:13.38 brlcad starseeker: no worries, it's now our very last release issue that I'm aware of
21:13.52 starseeker sweet
21:14.13 starseeker one thing I can do...
21:14.15 brlcad and arguably not major, just worth looking into
21:14.24 starseeker starts bringing up virtual machines and firing off distchecks
21:14.35 brlcad ah, yeah, that'd be good
21:15.39 starseeker brlcad: FreeBSD i386 is probably the most worrisome - Haiku is a niche target and OpenIndiana (and presumably other Solaris derivatives) have other issues
21:16.15 rays2pix brlcad: Are you expecting more details on test tools?
21:16.23 starseeker only has Windows 8 + Visual Studio 2012 Express here, so someone will need to do that test
21:18.37 brlcad starseeker: it's almost certain that 32-bit linux will be a problem
21:19.13 brlcad rays2pix: tools? no. testing? depends, but yes you should account for proper testing.
21:20.35 rays2pix I proposed to develop example code which also serves to test every added feature
21:27.06 rays2pix as per current plan, as I develop code for every format, I will also have example converter utils and test the same before taking up a new format
21:27.51 ``Erik speaking of slowaris derivatives, anyone done opensolaris lately? I signed up for a dvd when they announced a completely open source x86 version, but never recieved it :/
21:28.12 starseeker ``Erik: my understanding was opensolaris is effectively defunct?
21:28.14 ``Erik I have a 32bit linux ubuntu 12.04 box I can grind a test on
21:29.18 starseeker illumos and its derivatives seem to be where the action is - I've got OpenIndiana, and I think brlcad was interested in taking a look at SmartOS
21:29.44 starseeker ``Erik: that'd be cool - I have the latest 13.04 (or whatever) in my own 32bit Ubuntu image
21:29.45 ``Erik is ignorant of the current status of the solaris tree :(
21:30.22 starseeker http://en.wikipedia.org/wiki/OpenSolaris
21:30.32 starseeker looks like it got "Oracled"
21:30.46 ``Erik Linux putrid 3.5.0-30-generic #51~precise1-Ubuntu SMP Wed May 15 08:50:20 UTC 2013 i686 i686 i386 GNU/Linux
21:30.52 ``Erik model name : Intel(R) Celeron(R) CPU 450 @ 2.20GHz
21:31.48 ``Erik $200 at bj's, yo... with a 500g sata, couple gigs of ram, kbd, mouse, etc
21:33.01 ``Erik illumos, openindiana and smartos are probably the family I'd be looking for... bsd as at&t and berkeley did it is long gone, fbsd/obsd/netbsd/pcbsd/dragonfly are the descendants
21:35.29 ``Erik illumos does seem like the nexus for post-opensolaris activities
21:36.54 starseeker yeah, I think they're all building on that core
21:37.51 starseeker at least in principle, we might be able to download the latest Solaris for testing - I haven't scoped out their new license
21:38.30 starseeker the "sun studio" compiler is likely to be a test we still don't pass
21:39.44 Notify 03BRL-CAD:carlmoore * 55526 brlcad/trunk/src/fb/fb-rle.c: replace -h with '-S 1024' so -h can be used for help; also, implement -?
21:39.49 starseeker is quickly reminded that he needs more ram if he wants to run large numbers of VM's simultaneously
21:43.04 starseeker ah, bugger
21:43.15 starseeker installs autoconf, automake and friends
21:58.11 ``Erik hm, we used to be cool with sunw pro on sparcIIi I think, an e420 or something
21:58.28 starseeker nods - I think that was pre openNURBS days
21:58.33 ``Erik oh, yeah, it was
21:58.39 ``Erik pre-cmake, too
21:58.45 starseeker and stepcode :-)
21:59.22 *** join/#brlcad mpictor (~mark@99-93-104-202.lightspeed.iplsin.sbcglobal.net)
21:59.25 ``Erik yeah, all the imported c++ stuff might cause a fit... hopefully not much of one since we're ok with gcc, clang and msvc
22:00.08 starseeker I remember tweaking openNURBS to at least build with Sun Studio - don't think I ever tried stepcode
22:01.06 ``Erik stepcode comes from nist, right? I'd assume it'd be much more solaris friendly than openNURBS, which comes from a very very win32 background
22:01.19 starseeker could be
22:01.58 starseeker problem is stepcode pre-dates a lot of modern C++ standards, and sunstudio seems to be real big on strict standard adherence
22:02.21 starseeker on the other hand, they may have ended up using a "simple" subset too - would just have to try it
22:03.03 ``Erik hm, is stepcode old enough to be consumable by the old c++ to c compilers? :D
22:09.32 jasleen brlcad: I just updated my proposal. Please give time to review it.
23:29.06 *** join/#brlcad rays2pix (~deepak@14.139.226.34)
23:38.42 *** join/#brlcad zero_level (0e8b5206@gateway/web/freenode/ip.14.139.82.6)

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