| 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) |