| 00:09.54 | *** join/#brlcad roberthl (~robert@2001:ba8:1f1:f03d::2) | |
| 00:09.54 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 01:22.47 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 01:25.27 | CIA-42 | BRL-CAD: 03brlcad * r41116 10/brlcad/trunk/src/libpc/ (26 files): ws style indent consistency cleanup |
| 02:46.02 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:37.25 | starseeker | hmm, time to update the "replace you with a shell script" joke: |
| 04:37.28 | starseeker | http://www.good.is/post/automation-insurance-robots-are-replacing-middle-class-jobs/ |
| 04:37.46 | starseeker | now it's "go away or I will replace you with a very cheap robot" |
| 05:13.01 | CIA-42 | BRL-CAD: 03starseeker * r41117 10/brlcad/branches/cmake/src/other/ (6 files in 4 dirs): Not working yet, but toss in CMake logic for tcl and tk. |
| 05:30.39 | brlcad | finally |
| 05:30.55 | brlcad | got an impl for ulp() |
| 05:31.06 | brlcad | at least an initial one |
| 05:50.16 | CIA-42 | BRL-CAD: 03brlcad * r41118 10/brlcad/trunk/src/libbn/ (Makefile.am ulp.c): |
| 05:50.16 | CIA-42 | BRL-CAD: add an initial ulp.c implementation to provide a variety of routines useful for |
| 05:50.16 | CIA-42 | BRL-CAD: comparing numbers. this is completely preliminary and needs a variety of |
| 05:50.16 | CIA-42 | BRL-CAD: changes so don't even enable the file for compilation. for now, it implements |
| 05:50.16 | CIA-42 | BRL-CAD: ulp() and a variety of run-time variants of the float.h constants |
| 05:50.17 | CIA-42 | BRL-CAD: ([flt|dbl]_[min|max] and [epsilon|epsilonf]). |
| 05:51.52 | CIA-42 | BRL-CAD: 03brlcad * r41119 10/brlcad/trunk/src/libbn/ulp.c: yeah, assumes IEEE too |
| 07:52.28 | *** join/#brlcad mafm_ (~mafm@81.32.97.198) | |
| 07:56.22 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 07:56.22 | *** join/#brlcad d-lo (~claymore@BZ.BZFLAG.BZ) | |
| 07:56.22 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 09:14.13 | *** join/#brlcad d-lo (~claymore@BZ.BZFLAG.BZ) | |
| 09:14.21 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 11:21.50 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 12:05.34 | *** join/#brlcad Elrohir (~kvirc@p4FC59720.dip.t-dialin.net) | |
| 12:29.50 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:32.33 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 14:57.01 | *** join/#brlcad guillermina (~guillermi@8-129-231-201.fibertel.com.ar) | |
| 16:14.17 | starseeker | makes a note to look into this code later: http://www.cs.jhu.edu/~misha/Code/PoissonRecon/ |
| 16:58.08 | brlcad | convex hull algorithms will do a similar job if you're looking for techniques to go from points to surfaces |
| 16:58.45 | brlcad | http://meshlab.sourceforge.net/ might work for her |
| 16:58.56 | starseeker | nods |
| 16:58.57 | brlcad | or rather, for you to get a surface to give her |
| 17:01.54 | starseeker | I was just thinking for longer term point->* abilities in BRL-CAD |
| 17:02.55 | brlcad | that's what my convex hull comment was towards as well |
| 17:03.10 | brlcad | it wouldn't be hard to implement one of them for basic capability |
| 17:26.42 | *** join/#brlcad mafm_ (~mafm@81.32.97.198) | |
| 17:35.16 | CIA-42 | BRL-CAD: 03starseeker * r41120 10/brlcad/branches/cmake/src/other/ (CMakeLists.txt tcl/CMakeLists.txt tk/CMakeLists.txt): |
| 17:35.16 | CIA-42 | BRL-CAD: Generalize the tcl/tk logic a bit, and try hooking it up to src/other. It's not |
| 17:35.16 | CIA-42 | BRL-CAD: functional yet, and won't be without a fair number of tests being implemented to |
| 17:35.16 | CIA-42 | BRL-CAD: define variables correctly, but techniques developed for BRL-CAD are mapping to |
| 17:35.17 | CIA-42 | BRL-CAD: that problem fairly well. |
| 19:19.48 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 19:51.29 | brlcad | if anyone is mystified by how to fire rays in parallel, here's a simple example: http://brlcad.org/~sean/tmp/rtparallel.c |
| 21:46.42 | starseeker | brlcad: what's the script you use to check usage of things like HAVE_STDC? |
| 21:47.47 | starseeker | ah, enumerate.sh? |
| 21:47.51 | starseeker | tries it |
| 21:50.06 | starseeker | oh, OK that's just file level |
| 21:50.36 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 21:50.37 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 22:31.14 | *** join/#brlcad Ralith (~ralith@d142-058-093-104.wireless.sfu.ca) | |
| 23:26.50 | ``Erik | http://failblog.org/2010/10/21/epic-fail-photos-movie-description-fail/ |
| 23:27.50 | Ralith | ``Erik: have you seen XCL? |
| 23:32.19 | ``Erik | as in http://www.cliki.net/XCL ? |
| 23:33.09 | Ralith | yes |
| 23:33.24 | Ralith | apparently it might have some interesting C++ FFI stuff |
| 23:33.38 | ``Erik | hm, GPL, makes it hard to deal with nongpl stuff... :) |
| 23:34.06 | Ralith | I don't think a GPL compiler is a problem |
| 23:34.15 | Ralith | see also: gcc |
| 23:35.02 | ``Erik | if the compiler is included in the created executable (required to be compliant at this time), then ... |
| 23:35.54 | Ralith | yeah, that can be a problem; I doubt that's the intent of the author, though |
| 23:35.56 | ``Erik | unless there's a really awesome treeshaker and you never try to expose a repl or the compile or eval symbols |
| 23:36.14 | Ralith | I think it'd be worth looking into |
| 23:36.23 | ``Erik | possibly |
| 23:37.09 | ``Erik | for the little project I'm on, ecl has weaknesses, clozure had license issues, sbcl seems... optimal on the free side |
| 23:37.14 | ``Erik | :) |
| 23:37.48 | ``Erik | thanks for pointing that out, though, might have to clone it just to see what it's up to... and then make starseeker build it into BRL-CAD :D *duck* |
| 23:38.28 | Ralith | a good FFI would certianlny save effort. |
| 23:39.19 | ``Erik | perhaps |
| 23:40.50 | ``Erik | exposing the libraries API's using a standardized fashion (like, uh, the standardized C interface) would be better |
| 23:41.25 | Ralith | Ogre *has* a standard C API? |
| 23:41.28 | ``Erik | blob libraries that require you to use a certain version of a certain compiler ftl :( |
| 23:41.33 | ``Erik | no, it doesn't, that's the issue :D |
| 23:41.36 | Ralith | :P |
| 23:41.43 | Ralith | and Bullet's only technically exists. |
| 23:41.49 | ``Erik | at least ogre is open source, so you can compile it |
| 23:41.51 | Ralith | exposes barely a fraction |
| 23:41.52 | ``Erik | yeah, I noticed |
| 23:42.43 | ``Erik | <-- has almost been wondering if he should write little packages of functionality he cares about in C funcs instead of wrapping each C++ method/member in a C func and making lots of calls across that divide :/ |
| 23:43.06 | ``Erik | but then you're back at requiring a c++ compiler all every build platform :/ |
| 23:45.49 | Ralith | realistically, that is a sane requirement. |
| 23:46.03 | Ralith | and you can get the extensions accepted upstream. |
| 23:46.20 | Ralith | most projects are quite happy to have C API extensions. |
| 23:56.08 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |