| 00:11.56 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 00:34.12 | LinuxMafia | i need to export .bs file to .g file |
| 00:46.37 | brlcad | .bs? |
| 00:49.57 | LinuxMafia | brlcad, hi |
| 00:50.09 | LinuxMafia | hi poolio |
| 00:50.22 | LinuxMafia | brlcad, it is makehuman file |
| 01:03.45 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/other/ (tcl/Makefile.am tk/Makefile.am): more items that need to be uninstalled, added since a5 to a6 |
| 01:07.09 | ``Erik | that'd be an awesome tld |
| 01:48.57 | *** join/#brlcad iday (n=iday@c-68-50-191-200.hsd1.md.comcast.net) |
| 02:01.55 | *** join/#brlcad yukonbob (n=yukonbob@199.247.233.116) |
| 02:10.20 | louipc | new release hey? :D |
| 03:13.20 | brlcad | louipc: soon, making sure the dists work |
| 03:14.11 | poolio | brlcad: grargh. found why my program was running fairly slow. I had ncpu hardcoded as 1...d'oh. I have 2 :) |
| 03:15.30 | brlcad | that should make some difference :) |
| 03:16.16 | poolio | brlcad: also, I'm currently not setting a_ray_length and am manually clipping the partitions. Can I trust a_ray_length or no? I recall you saying something about how I should just code it |
| 03:17.31 | brlcad | yeah, I'd just code it yourself |
| 03:17.42 | brlcad | you see the picture? |
| 03:18.06 | poolio | which one? the whole explaining intersection and boudning box and crossover |
| 03:18.33 | brlcad | the only picture I've made for you afair :) |
| 03:18.41 | poolio | yes I saw |
| 03:19.25 | poolio | but I mean, there's no real way around it is there? |
| 03:19.36 | brlcad | there is |
| 03:19.53 | poolio | hmm. lemme dig up that picture again |
| 03:20.53 | brlcad | you expand your shoot grid to encompass the bounds, using the same grid sample size .. and any material found just decreases fitness by that much a ratio |
| 03:21.21 | brlcad | probably not something you need to worry about, but it should probably be documented |
| 03:21.34 | poolio | wait, well I disagree |
| 03:21.50 | poolio | Maybe you only want the corner of the object |
| 03:22.27 | poolio | Like lets say you have a sphere, and your input geometry is the shape of a half a hemisphere. a quarter sphere? my vocabulary fails. but regardless, why should we decrease the fitness? |
| 03:22.43 | poolio | I mean I don't see why it matters what's outside the bounding box as long as what is inside the bounding box is correct |
| 03:23.01 | poolio | Ah wait. d'oh. I guess it _looks_ fine in terms of voxel data but the model would be wrong. I see... |
| 03:23.03 | brlcad | not following your example |
| 03:23.21 | poolio | Well my example is wrong |
| 03:23.33 | brlcad | i mean if it's a half a sphere, with a box subtracted, then the bounding box would be all misses, and youd be fine |
| 03:24.00 | poolio | hmm, i dont quite follow your example either |
| 03:24.03 | poolio | what I meant was this |
| 03:24.11 | poolio | Lets say your input data was in the shape of a hemisphere. |
| 03:24.16 | brlcad | er, my example is just the one on paper :) |
| 03:24.18 | poolio | Now lets say you sample a fixed bounding box |
| 03:24.23 | brlcad | er, s/paper/picture |
| 03:24.35 | brlcad | okay, shape of a hemisphere |
| 03:24.47 | brlcad | bounding box is nice and tight around it |
| 03:25.03 | poolio | now lets say the GA comes up with a solution that is a sphere |
| 03:25.12 | poolio | and the lower half of that sphere is exactly where the input geometry is |
| 03:25.16 | poolio | that sphere is a perfectly fit individual |
| 03:25.35 | poolio | I was thinking, "alright, that's good" but I realize that we don't want that. We need it to match the model and only the model |
| 03:25.52 | brlcad | right, the point is to match the input |
| 03:26.26 | poolio | yeah...I was just thinking matching the voxel data, and ignoring what's outside the bounding box, but yeah that's not right |
| 03:26.53 | brlcad | i mean, you can get away with it -- that's what I meant about it being fine for now |
| 03:27.39 | brlcad | if you found something that did match everything inside the box, you have a "good" solution by just intersecting the result model with the bounding box |
| 03:27.50 | brlcad | not necessarily optimal, but it's good |
| 03:27.54 | poolio | ah yeah, you could do that |
| 03:28.31 | brlcad | so, just document the limitation and don't worry about it :) |
| 03:28.45 | poolio | alright. it's quite trivial to implement though |
| 03:28.57 | brlcad | nah, don't both |
| 03:28.59 | brlcad | bother |
| 03:29.04 | poolio | alright |
| 03:29.15 | brlcad | it gets more complex |
| 03:30.16 | brlcad | e.g. taking your example of a hemisphere.. consider one solution that has a tight-fitted box subtracting perfectly on the bounding box's edge, and another that extracts massive space but giving the same result |
| 03:30.41 | brlcad | their fitness would work out to the same if you only consider positive space, but the tight-fitting result is more desirable |
| 03:31.52 | poolio | yeah. that's where you'd hope the # nodes would do something. but if you have it fixed then ... nope |
| 03:32.15 | poolio | If you allowed variation in #nodes, ideally it would converge on the tight-fitting one with the least amount of wasted space. |
| 03:32.16 | brlcad | the number of nodes are identical in that case |
| 03:32.23 | brlcad | one sphere and one box being subtracted |
| 03:32.42 | brlcad | it's the size of the box (its efficiency as a cutting space) that matters |
| 03:33.05 | poolio | Well, if you include your method of shooting more rays they wouldnt be identical |
| 03:33.14 | poolio | oh wait |
| 03:33.15 | poolio | I see |
| 03:33.16 | brlcad | they would |
| 03:33.19 | brlcad | negative space |
| 03:33.22 | poolio | Yeah yeah |
| 03:33.23 | brlcad | it's a miss |
| 03:33.35 | brlcad | anyways, "don't worry about it" :) |
| 03:33.37 | poolio | So you could have a box that cuts from the hemisphere and goes on forever |
| 03:33.40 | poolio | and wastes tons of space |
| 03:33.42 | brlcad | right |
| 03:33.46 | poolio | hrmph. |
| 03:33.58 | poolio | I'm a bit slow and more than a bit sick, sorry :) |
| 03:34.01 | brlcad | there's an easy metric in that case |
| 03:34.15 | brlcad | even better than looking at the size of the csg tree |
| 03:34.36 | poolio | I would say size of the bounding box? |
| 03:34.50 | poolio | (addition of each individual object) |
| 03:34.56 | brlcad | nope, bigger might be better in a different case |
| 03:34.57 | poolio | well not object, shape |
| 03:35.17 | brlcad | you'd take the evaluation time into consideration |
| 03:35.27 | brlcad | how long does it take to shoot rays at one vs the other |
| 03:35.40 | brlcad | smaller trees and tighter fitting csg will naturally win |
| 03:35.48 | brlcad | as will more efficient primitives |
| 03:35.58 | poolio | hmm, good thought |
| 03:36.14 | brlcad | an advanced idea for later .. much later :) |
| 03:36.38 | brlcad | after it's shown to work or not work on basic parts |
| 03:36.47 | poolio | you'd have to rely on a stable environment though, I feel like there are a lot of factors that could throw it off |
| 03:36.51 | poolio | yes yes |
| 03:37.30 | poolio | I'm doing some code clean up now. Then I'll finish up mutation and the setting of the inclusion of certain upper/lower individuals |
| 03:55.14 | poolio | Hmm wonderful. I spy a race condition. |
| 04:00.51 | poolio | sleepy time. cya brlcad |
| 04:01.54 | CIA-29 | libirc: 03brlcad * r214 10/trunk/libirc/autogen.sh: update to the latest script, version 20070618 from brl-cad |
| 04:03.59 | CIA-29 | libirc: 03brlcad * r215 10/trunk/libirc/COPYING: license is supposed to be LGPL, not GPL .. readme is correct but this file is wrong |
| 04:51.00 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/ (configure.ac m4/Makefile.am m4/restore.m4): |
| 04:51.00 | CIA-29 | BRL-CAD: autogen.sh no longer creates .backup files in an aux directory, so there's |
| 04:51.00 | CIA-29 | BRL-CAD: nothing for us to automatically recover from. this means subsequent clobbering |
| 04:51.00 | CIA-29 | BRL-CAD: automakes may blow away our files, but there's not much we can do about it. |
| 05:25.10 | *** join/#brlcad yukonbob_ (n=yukonbob@199.247.233.116) |
| 06:31.09 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: minor dead code |
| 07:12.33 | CIA-29 | libirc: 03brlcad * r216 10/trunk/libirc/m4/ (. args.m4 cache.m4 mkdirp.m4 search.m4 stage.m4): add a bunch of boilerplate m4 macros to simplify the configure logic a bit |
| 07:13.36 | CIA-29 | libirc: 03brlcad * r217 10/trunk/libirc/Makefile.am: be sure that aclocal searches in the m4 dir for macros, require automake 1.6 and generate all dist formats |
| 07:15.33 | CIA-29 | libirc: 03brlcad * r218 10/trunk/libirc/configure.ac: update to better configure logic, using bc and bz as example |
| 07:26.25 | *** join/#brlcad Laniakea (n=clock@zux221-122-143.adsl.green.ch) |
| 07:30.19 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/ (configure.ac m4/patch.m4 m4/Makefile.am): turn the libtool chunk that patches libtool if it has the -all_load bug on Mac OS X into an m4 macro, BC_PATCH_LIBTOOL |
| 07:35.33 | CIA-29 | libirc: 03brlcad * r219 10/trunk/libirc/misc/ (Makefile.am Makefile.defs): import brl-cad's nifty noprod rules |
| 07:37.17 | CIA-29 | libirc: 03brlcad * r220 10/trunk/libirc/m4/ (Makefile.am patch.m4): bring over BC_PATCH_LIBTOOL too, and add the m4 files to the dist |
| 07:40.39 | CIA-29 | libirc: 03brlcad * r221 10/trunk/libirc/ (Makefile.am configure.ac): use BC_PATCH_LIBTOOL, add m4 to the build path |
| 07:48.12 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/ (configure.ac m4/compiler.m4): move the sanity check to a BC_SANITY_CHECK macro |
| 07:49.18 | CIA-29 | libirc: 03brlcad * r222 10/trunk/libirc/ (configure.ac m4/Makefile.am m4/compiler.m4): import BC_SANITY_CHECK |
| 07:54.46 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/m4/args.m4: add support for --with-cxxflags |
| 07:54.57 | CIA-29 | libirc: 03brlcad * r223 10/trunk/libirc/m4/args.m4: add --with-cxxflags |
| 07:55.59 | CIA-29 | libirc: 03brlcad * r224 10/trunk/libirc/configure.ac: condense the 32 or so lines down to one for the standard --with overrides via BC_WITH_FLAG_ARGS |
| 08:03.55 | CIA-29 | libirc: 03brlcad * r225 10/trunk/libirc/include/net.h: can't have anonymous typedef types used as parameters |
| 08:16.33 | CIA-29 | libirc: 03brlcad * r226 10/trunk/libirc/examples/stupidServer/src/Makefile.am: fix minor copy-paste typo, should be stupidServer not stupidBot |
| 08:17.10 | CIA-29 | libirc: 03brlcad * r227 10/trunk/libirc/ (14 files in 13 dirs): propagate Makefile.defs throughout so that the recursive noprod rule works |
| 08:21.28 | CIA-29 | libirc: 03brlcad * r228 10/trunk/libirc/configure.ac: er, we're using svn for libirc, so check that when determining whether to enable/disable automatic dependency tracking |
| 08:23.42 | *** join/#brlcad cad92 (n=55647250@bz.bzflag.bz) |
| 08:29.30 | CIA-29 | libirc: 03brlcad * r229 10/trunk/libirc/src/Makefile.am: bunch of files added/changed since this was first written, update to match current |
| 08:30.52 | CIA-29 | libirc: 03brlcad * r230 10/trunk/libirc/src/IRCUserManager.cpp: you still can't take a reference to a temporary anonymous type, also fix the handful of erase iterators |
| 08:33.53 | CIA-29 | libirc: 03brlcad * r231 10/trunk/libirc/src/ (irClientCommands.cpp irClientEvents.cpp): more instances of trying to take a reference to a temporary |
| 08:36.09 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) |
| 08:37.51 | CIA-29 | libirc: 03brlcad * r232 10/trunk/libirc/ (4 files in 2 dirs): s/loger/logger/, and fix scope on the default loggers so they don't run into each other in the library. libIRC is now compilation-functional again. |
| 08:42.06 | CIA-29 | libirc: 03brlcad * r233 10/trunk/libirc/examples/simpleIRCConnect/src/simpleIRCConnect.cpp: yet another ref to temp, all examples compile now too |
| 09:07.22 | CIA-29 | libirc: 03brlcad * r234 10/trunk/libirc/ (8 files in 8 dirs): ... and now libIRC even successfully passes a make distcheck again ... ship it! |
| 11:58.28 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-069-108.pools.arcor-ip.net) |
| 12:12.08 | *** join/#brlcad cad09 (n=d8cc12e3@bz.bzflag.bz) |
| 12:54.00 | Maloeran | Ahah, that was really pathetic of me. I reserved my flight tickets for Siggraph in the month of July rather than August |
| 12:59.39 | Laniakea | brlcad: where is the workplace where BRL-CAD is created actually physically based? |
| 13:18.30 | ``Erik | heh, woops |
| 13:18.54 | ``Erik | laniakea: what do you mean? |
| 13:19.30 | ``Erik | oh, the physical location of the original (some most of the current) developers |
| 13:20.11 | Laniakea | let's say that yes |
| 13:20.27 | ``Erik | at the top of every C file should be a 'source' block... |
| 13:20.42 | ``Erik | something like this |
| 13:20.43 | ``Erik | <PROTECTED> |
| 13:20.43 | ``Erik | <PROTECTED> |
| 13:20.43 | ``Erik | <PROTECTED> |
| 13:49.41 | brlcad | not any more on latest head, though not comprehensively reoved either |
| 13:50.57 | ``Erik | hrm? you removed the source entries? O.o |
| 13:54.16 | brlcad | phone numbers and addresses, particularly the ones that were no longer valid |
| 13:54.42 | ``Erik | ah, city/state should still be ok though |
| 13:54.50 | ``Erik | (I pulled that from bu fgets.c |
| 13:54.51 | ``Erik | ) |
| 13:55.11 | brlcad | the zip has changed over the years |
| 13:56.03 | brlcad | yeah, in general it's still okay, but it still the entire premise |
| 13:56.23 | brlcad | a "location" source for something that eventually/often has multiple distributed authors |
| 13:57.11 | ``Erik | true, but it'd be nifty to search the source for valid location info and generate a developer map, like debian and fbsd have |
| 13:57.29 | brlcad | those origins can be (and are) documented elsewhere, the code doesn't necessarily need to reflect that, particularly when they're often wrong |
| 13:57.37 | ``Erik | a la http://www.debian.org/devel/developers.loc |
| 13:58.11 | brlcad | yes, but then afaik they don't generate those maps off of their sources |
| 13:58.16 | brlcad | their devs say where they are at |
| 13:58.20 | ``Erik | no, the developers submit |
| 13:58.21 | ``Erik | yeah |
| 13:58.26 | ``Erik | same with the bsd one |
| 14:58.54 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 15:05.25 | ``Erik | freakin' vacuum always tripping the freakin' circuit breaker |
| 15:06.06 | archivist | Ive seen bad breakers as well |
| 15:09.25 | ``Erik | hum, there're two heavy computer users on this one breaker... I have 3 machines and 4 monitors, the other guy has about the same... |
| 15:09.58 | ``Erik | (overcrowded and organized to siloize based on role...) |
| 15:10.40 | ``Erik | interesting, configures search for system tk fails if there's no valid display to connect to |
| 16:26.46 | LinuxMafia | hi |
| 16:26.54 | LinuxMafia | brlcad, u here? |
| 16:27.17 | LinuxMafia | i need to export makehuman files into brlcad |
| 16:28.32 | brlcad | i'm usually here |
| 16:28.37 | brlcad | i just might not answer if i'm busy :) |
| 16:28.47 | LinuxMafia | oh ok |
| 16:28.52 | LinuxMafia | brlcad, cool |
| 16:28.59 | LinuxMafia | do you know makehuman? |
| 16:29.06 | brlcad | you need something that reads makehuman files or you'll need to scrtip/code something yourself |
| 16:29.06 | poolio | I think makehuman files aren't standard |
| 16:29.31 | poolio | brlcad: I woke up this morning by walking into my bathroom and stepping on a humongous hornet. stung me right at the ball of my middle toe. :( |
| 16:30.23 | brlcad | LinuxMafia, what are their export formats? find one that matches one of BRL-CAD's importers |
| 16:30.40 | brlcad | poolio... ouch! |
| 16:30.46 | brlcad | that had to hurt |
| 16:31.04 | brlcad | makes my hairs stand up just thinking about it |
| 16:31.07 | LinuxMafia | brlcad, it is .bvs |
| 16:31.13 | LinuxMafia | .bs* |
| 16:33.16 | poolio | brlcad: it's still throbbing. makes it hard to concentrate on code :\ oh well. |
| 16:34.32 | brlcad | LinuxMafia: I understand that -- that's their format |
| 16:34.38 | brlcad | pretty much nothing reads their format |
| 16:34.50 | poolio | LinuxMafia: is there a way to export a makehuman file as another format? |
| 16:34.53 | brlcad | so you'll have to export it in makehuman to a format that others understand |
| 16:35.04 | LinuxMafia | brlcad, and there is also objects , but i dont know how to make that |
| 16:35.12 | brlcad | a quick look through their site shows that they export obj format, which is pretty simple |
| 16:35.30 | brlcad | though we only have an obj exporter, not an importer at the moment.. |
| 16:35.43 | brlcad | so you'd still have to use some intermediary tool or write an obj importer |
| 16:36.28 | LinuxMafia | brlcad, how about export it into blender |
| 16:36.39 | LinuxMafia | and from there to brlcad |
| 16:36.47 | brlcad | you can export to obj, then import obj to blender, sure |
| 16:37.29 | LinuxMafia | brlcad, then brlcad can read that ? |
| 16:37.34 | brlcad | then export from blender to dxf or ply or stl, or several other import formas |
| 16:37.39 | poolio | brlcad: any tips on learning how to properly profile software? |
| 16:37.54 | LinuxMafia | oh got it now |
| 16:37.57 | brlcad | poolio, yes, get a good profile :) |
| 16:38.01 | brlcad | er, profiler |
| 16:38.19 | poolio | any suggestions? |
| 16:38.56 | brlcad | depends heavily on which platform and what sort of profiling -- mac os x's chud tools are currently some of the best all around (shark in particular) |
| 16:39.03 | poolio | I'm doing some general code clean up and was just trying to see if there was anything I could do to speed it up. I mean, I can see certain parts of the code and fix it that way, but there's no good reason to try to optimize stuff until i've profiled |
| 16:39.11 | poolio | brlcad: I'm under linux |
| 16:39.12 | brlcad | gprof is pretty run of the mill, and a good starting point |
| 16:39.21 | poolio | If you'd like me to send me a new macbook pro I could profile with that :) |
| 16:39.23 | brlcad | not a great profiler, but enough to get you going |
| 16:39.30 | brlcad | heh |
| 16:39.43 | poolio | I'd even sacrifice a bit and take your old one :) |
| 16:40.56 | brlcad | I have several old vaio's that I'd loan ya ;) |
| 16:41.21 | brlcad | but then it's probably an order slower than what you have :) |
| 16:42.04 | brlcad | beautiful notebooks though, first sub-1" sub-10lbs notebook |
| 16:42.06 | poolio | yar. my laptop's reasonably fast. Just has been having some heat and battery issues recently. I'm now only getting ~1 hour and it gets up to 80C when I test out my software |
| 16:42.15 | poolio | sub-10lbs. haha |
| 16:42.59 | brlcad | ~convert 1.4 kilograms to pounds |
| 16:43.07 | brlcad | sorry, sub-3lbs :) |
| 16:43.36 | poolio | haha. yeah |
| 16:43.46 | brlcad | about 10 years old now |
| 16:43.49 | poolio | I was thinking about getting a new ultraportable for college but it's a lot of cash and I'll survive with what I've got now |
| 16:43.55 | poolio | That's impressive for that time |
| 16:46.20 | poolio | brlcad: I may have asked you this already, but out of curiousity, what do you do most of your coding in? |
| 16:47.25 | brlcad | emacs |
| 16:47.45 | poolio | heh. never could get used to emacs. been using vim forever |
| 16:47.56 | brlcad | I hunkered down for a week after coding for several years with other editors (pico, vi, ..) |
| 16:48.12 | brlcad | and never went back |
| 16:48.24 | poolio | any particular reason? |
| 16:49.44 | brlcad | well, particularly because once you get over that learning curve for the default bindings, it really is more efficient, imo, over vim and just about everything else out there |
| 16:50.18 | brlcad | i mean, putting equal effort into both for a month, someone in emacs will end up being more proficient |
| 16:50.49 | brlcad | and not just for the editing, but the other facilities that emacs brings as an integrated development environment |
| 16:51.36 | poolio | yeah, that was one of my main reasons that I stopped. I like having my text editor just be a text editor, and I work by opening up multiple terminals and editing a file in vim in each of them, another window compiling. It's just a habit |
| 16:52.03 | brlcad | there are some things that vim works very well for even over emacs, but for long-term coding emacs is specifically built for it |
| 16:52.23 | brlcad | yeah, and I used to say the same .. you grow habits |
| 16:52.33 | brlcad | and those habits staple your preferences to what you already know |
| 16:53.35 | brlcad | in the end, it's just a tool and will boil down to the developer's proficiency with that tool -- but that's where I say that after equal investing, your emacs user will generally be far more proficient in the long run |
| 16:55.03 | LinuxMafia | brlcad, how about .mtl? |
| 16:55.30 | brlcad | like I said, I fought it for years -- even after seeing in college that 90% of the "best" coders in the upperclassmen above me were all proficient emacs users (with about 9% using vi, and 1% using something else) -- but then I hunkered down for a solid week (which turned into two) and said I'd give it an honest chance |
| 16:56.02 | brlcad | and with a cheat-sheet beside me for days, I worked through the tutorials, learned the bindings, and then lightbulbs started going off |
| 16:56.13 | brlcad | LinuxMafia: ls -la /usr/brlcad/bin/*-g |
| 16:56.18 | brlcad | those are the importers |
| 16:56.25 | brlcad | no more, no less :) |
| 16:56.34 | LinuxMafia | thanks alot |
| 16:58.26 | poolio | brlcad: lightbulbs? really? I'll have to give it a go then |
| 16:59.49 | brlcad | poolio: it wasn't until about a week of non-stop use, constantly referring to a cheat sheet while I learned, but yes it did eventually happen |
| 17:00.37 | brlcad | it's still not a panacea, every environment has it's limitations |
| 17:00.45 | poolio | My main thing was the key combos were awkward and I didn't bother to change them |
| 17:00.56 | brlcad | I would suggest NOT changing them |
| 17:01.20 | brlcad | learning the defaults is important for reasons that won't matter for quite a while, but eventually will matter |
| 17:01.21 | poolio | get used to awkwardly twisting your fingers? |
| 17:01.46 | brlcad | do you know how to type? |
| 17:01.51 | poolio | not well |
| 17:02.15 | brlcad | hm, then it might seem awkward for some combos I suppose if you use the wrong fingers |
| 17:02.39 | brlcad | not well as in you don't touch type or you just don't touch type fast? |
| 17:02.53 | poolio | Well, mainly the ctrl+ things. The ctrl on my laptop kbd is not the lower left, Fn is lower left, it's to the right of that. So it's kind of awkward. and I never use the lower right shift/ctrl keys |
| 17:03.12 | poolio | I don't touch type fast and I don't make full use of the keyboard |
| 17:03.22 | brlcad | ah |
| 17:04.08 | brlcad | well hitting lower-left control is probably just familiarity, my left pinky hits it without hesitation |
| 17:04.25 | brlcad | i vaguely remember it being awkward the first week too, had to get some muscle memory |
| 17:04.41 | poolio | hehe. yeah maybe I'll have some time to learn later on |
| 17:05.25 | brlcad | learning to use esc for meta instead of alt was another, using ctrl-n,p,f,b for traversal, and a few others |
| 17:06.10 | brlcad | at the time seemed like torture, but then after the familiarity curve, the efficiency (particularly compared to modal editing in vim) was rather blatent after a couple weeks |
| 17:06.12 | poolio | esc for meta? weird |
| 17:06.25 | brlcad | esc is meta |
| 17:06.39 | poolio | i always use alt for meta |
| 17:06.46 | brlcad | esc is a modal meta |
| 17:06.51 | poolio | ah |
| 17:07.04 | brlcad | and considerably more portable |
| 17:07.47 | brlcad | alt generally only works well on x86 |
| 17:08.07 | brlcad | which over the years became important on many occasions |
| 17:08.44 | brlcad | even recently, as that portability extends to keycodes through ssh/terminal sessions for different platforms/environments |
| 17:10.45 | brlcad | anyhow, there's going to be no convincing unless you actually dedicate that week (or more) of your coding life with an unbiased open mind before you'd start to see what all the fuss has been about |
| 17:11.12 | poolio | yes yes. it's also possible after that week or two I stll won't like it. It's all about personal preference in the end |
| 17:11.21 | brlcad | that is true |
| 17:14.23 | brlcad | though I can say that of several experienced coder friends which have gone through the exercise, the result has thusfar been them either giving up before the week ends or they convert |
| 17:15.57 | brlcad | it's also an interesting trend that you rather frequently see coders that convert from vim, pico, or whatever to emacs ... but you rarely ever see an emacs coder convert to anything else |
| 17:18.43 | poolio | cause they're close minded ;) |
| 17:19.36 | brlcad | could be |
| 17:20.04 | brlcad | but then I don't think it'd be so much a trend |
| 17:20.56 | archivist | Ive stuck at vi or syn on windows |
| 17:20.57 | brlcad | I've seen several editors that would give emacs a run for it's money if I were a full-time java developer, for example |
| 17:22.11 | brlcad | i think it's more just ease of use, vi is pretty simple to use, fairly simple to learn .. low barrier to entry so you can get fairly proficient in the environment |
| 17:22.37 | ``Erik | vi strusfrates me almost as much as emacs :) |
| 18:31.34 | *** join/#brlcad Bman (n=erik@bz.bzflag.bz) |
| 18:41.05 | poolio | some people qre quite impatient |
| 18:41.19 | ``Erik | yes, I am |
| 18:42.06 | LinuxMafia | brlcad, i finnally succed |
| 18:42.07 | ``Erik | I was sitting in a machine room with a summer intern trying to figure out if we were in the right machien room and what exactly she was supposed to do O.o ended up calling him :) |
| 18:42.40 | poolio | haha :) |
| 18:43.48 | ``Erik | now I'm back in my comfortable office reading about the latest kernel schedulers while that poor kid is typing the names of a jazillion beta tapes into a spreadsheet or something :) |
| 18:43.48 | *** join/#brlcad dtidrow (n=dtidrow@host131.objectsciences.com) |
| 18:43.51 | ``Erik | ++evil |
| 18:44.35 | dtidrow | moi? |
| 18:47.45 | ``Erik | no, me :) |
| 18:50.26 | dtidrow | ah |
| 18:50.45 | poolio | hehe. |
| 18:50.59 | poolio | ``Erik: is that how they treat summer interns at ARL? |
| 19:00.34 | ``Erik | well, usually the intern projects are a bit cooler |
| 19:01.45 | ``Erik | last year (or was it year before), we had a coder doing something for scripting abstraction, had a couple kids doing a survey of different 3d model generation devices (laser scanners, GPS toucharms, etc), one kid made a fairly detailed model of a residential house, ... |
| 19:02.20 | ``Erik | not sure where the 'catalog ancient media' came from *shrug* |
| 19:03.00 | poolio | yeah. that sucks |
| 19:50.34 | *** join/#brlcad Laniakea (i=clock@217-162-228-71.dclient.hispeed.ch) |
| 20:18.41 | *** join/#brlcad iraytrace (n=iraytrac@cocoa.sci.utah.edu) |
| 20:44.12 | *** join/#brlcad yukonbob (n=yukonbob@dhcp126-164.whthyt.northwestel.net) |
| 21:07.03 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-069-108.pools.arcor-ip.net) |
| 21:18.05 | CIA-29 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/fitness.c: fixed race condition |
| 21:40.01 | *** join/#brlcad yukonbob (n=yukonbob@whthyt232-138.northwestel.net) |
| 21:54.48 | brlcad | no way, her project is pretty cool |
| 21:55.18 | CIA-29 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/ (beset.c population.c beset.h fitness.h population.h): now able to keep an upper % of population and kill a lower %. general code cleanup. |
| 21:56.00 | brlcad | if I could drop this code project, I'd happily do what she's tasked with .. catalogging is just some prep work, the task is to rummage through a ton of historic video (of pretty significant importance) and convert them to digital |
| 21:56.40 | brlcad | one of them is the very first animation ever made with brl-cad, for example |
| 21:56.46 | poolio | cool |
| 21:56.51 | brlcad | the first "real time" ray-tracing video, |
| 21:56.55 | archivist | hopefully before the media dies |
| 21:57.02 | poolio | is pop_rand [0,1] or (0,1) ? |
| 21:57.41 | brlcad | archivist: excatly, I'm already worried that they're starting to degrade |
| 21:57.46 | poolio | archivist: quite the appropriate name |
| 21:58.36 | archivist | I did some work on 1/2" BW on Sony tape recorders and failed |
| 21:58.57 | *** join/#brlcad elite01_ (n=elite01@dslc-082-082-069-108.pools.arcor-ip.net) |
| 21:59.08 | *** join/#brlcad cad38 (n=c950de63@bz.bzflag.bz) |
| 21:59.08 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) |
| 21:59.23 | brlcad | there's content on old u-matic tapes, master broadcast tapes, betacam sp, some of the 'newer' of vhs, old film reels, actual old raw data reels even |
| 21:59.47 | archivist | early video has two basic types one likes to be cold and damp the other likes warm and dry |
| 22:00.20 | archivist | dont ask me which is which though |
| 22:03.02 | archivist | I had a discussion with the archivist at the uk national photography museum about the subject and its evil as the coating comes off and sticks to the video heads |
| 22:03.49 | archivist | umatic may well be ok as by that time things had improved |
| 22:06.42 | brlcad | yeah, this stuff is only 20 years old or newer and has been mostly very very well kept |
| 22:07.17 | brlcad | 5-10 more years and it could eaily be a very different story |
| 22:08.04 | dtidrow_work | good luck with that stuff, would hate to have it lost |
| 22:08.33 | brlcad | some of them naturally "look pretty old" ala 1980's tron graphics quality, but it's still pretty impressive stuff for some of the videos |
| 22:09.02 | dtidrow_work | heh - Tron was cutting-edge back then ;-) |
| 22:09.09 | brlcad | i've had it high on my todo for many years (as well as going through GB's of Mike's data) |
| 22:10.16 | brlcad | getting a student to just get that list of the content, and particularly finding where the *master* copies are .. as there are often a dozen copies in 4 different formats |
| 22:10.48 | dtidrow_work | ah, the joys of rummaging through old stuff :-) |
| 22:10.55 | brlcad | tron rocks, I'd pay someone to build me a faithful csg lightcycle |
| 22:10.59 | poolio | brlcad: shoulda sicked me on that, woulda been more useful :) |
| 22:11.13 | brlcad | poolio: too easy for you :) |
| 22:11.24 | poolio | haha. yeah right. |
| 22:11.54 | brlcad | though the whole digital editing/remastering could be really fun, color correction, repairs |
| 22:13.06 | poolio | writing a GA to correct the reels |
| 22:13.15 | brlcad | heh |
| 22:13.31 | poolio | Removing the noise |
| 22:13.32 | poolio | :) |
| 22:13.52 | brlcad | actually an easier problem space :) |
| 22:14.05 | poolio | much. |
| 22:14.36 | dtidrow_work | heh |
| 22:20.24 | archivist | I might cheat I have a realtime video noise reducer |
| 22:20.39 | poolio | I wrote something along those lines for an SLO last summer |
| 22:23.22 | poolio | brlcad: wait wahhhhhhhhhh did i do wrong |
| 22:25.12 | poolio | brlcad: I'm using them cause it's run in parallel...and I'm changing the variable...right? |
| 22:25.15 | poolio | I'm probably wrong. |
| 22:25.39 | brlcad | there's a variety of ways they can be used |
| 22:26.03 | brlcad | i honestly don't know .. i just glanced for all of 30 seconds to notice that it seemed 'different' on the surface |
| 22:26.08 | poolio | Well, it waits for the semaphore to be available, then does whatever it needs to |
| 22:26.18 | poolio | different from what? |
| 22:26.21 | poolio | from normal usage? |
| 22:26.24 | brlcad | which isn't to say that it's right, wrong, or beautifully creative, or a PoS :) |
| 22:26.30 | poolio | ok ok :) |
| 22:26.44 | poolio | brlcad: are you just giving it a look over? any tips/suggetions/etc... are vastly appreciated |
| 22:27.36 | brlcad | i didn't go that deep just yet |
| 22:27.52 | brlcad | it was just a glance as I processed other e-mail :) |
| 22:27.55 | brlcad | sorry |
| 22:27.59 | poolio | ah I see. the commits :) |
| 23:16.01 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 23:27.39 | poolio | brlcad: so I have everything implemented in terms of spheres and I'm not satisfied with the results. Any ideas? |