| 00:47.04 | CIA-38 | BRL-CAD: 03brlcad * r36959 10/brlcad/trunk/src/librt/vshoot.c: |
| 00:47.04 | CIA-38 | BRL-CAD: bring vshoot up-to-date with the current API, eliminating a lot of old cruft |
| 00:47.04 | CIA-38 | BRL-CAD: that has changed. eliminated the duplication with non-vector helper functions |
| 00:47.04 | CIA-38 | BRL-CAD: (they're in shoot.c). updated to bitvs and ptbls except didn't make the |
| 00:47.05 | CIA-38 | BRL-CAD: necessary bookkeeping mods needed for rt_boolfinal() to keep track of finished |
| 00:47.07 | CIA-38 | BRL-CAD: and waiting segments. that means this will NOT actually work, but should at |
| 00:47.09 | CIA-38 | BRL-CAD: least compile cleanly once again. |
| 00:48.53 | CIA-38 | BRL-CAD: 03brlcad * r36960 10/brlcad/trunk/src/librt/Makefile.am: activate vshoot.c so that the file can stay in sync and possibly be worked on again now that it's back to a compiling state. |
| 01:04.47 | CIA-38 | BRL-CAD: 03brlcad * r36961 10/brlcad/trunk/src/librt/primitives/tgc/tgc.c: |
| 01:04.47 | CIA-38 | BRL-CAD: these must be FIXED, not hacked around. can't have DM_* toggles in librt just |
| 01:04.47 | CIA-38 | BRL-CAD: to quell root solver failures. root solver failures are higher priority than |
| 01:04.47 | CIA-38 | BRL-CAD: the display feature (they indicate a low-level solidity failure). |
| 01:06.35 | CIA-38 | BRL-CAD: 03brlcad * r36962 10/brlcad/trunk/src/librt/Makefile.am: more rtgl turd cleanup. librt shall not depend on libdm. |
| 01:09.06 | brlcad | woot, more than 50% of librt |
| 01:14.03 | starseeker | erm - what happened with the tgc? |
| 01:27.31 | CIA-38 | BRL-CAD: 03brlcad * r36963 10/brlcad/trunk/src/librt/ (shoot.c vshoot.c): move the rt_vstub() function into vshoot.c and make it HIDDEN. rename it to vshot_stub() in the process, calling it if a primitive has a null vshot callback. |
| 01:30.23 | brlcad | starseeker: hm? |
| 01:31.24 | brlcad | nothing happened to tgc, just people ignoring the root solver failures when it mattered instead of investigating the problem. |
| 01:32.24 | brlcad | presumably, the printing evaluation failure statements slow down rtgl rendering or were just annoying |
| 01:33.16 | brlcad | so someone commented them out, which is a prioritization failure imho .. that's not something that should get pushed off for "later" |
| 01:33.22 | brlcad | if it's a problem, fix the problem |
| 01:34.28 | brlcad | probably something nick tossed in while working on rtgl, just caught it now |
| 01:35.34 | CIA-38 | BRL-CAD: 03brlcad * r36964 10/brlcad/trunk/src/librt/primitives/ (27 files in 27 dirs): |
| 01:35.34 | CIA-38 | BRL-CAD: eliminate the empty vshot() callbacks. now only primitives that actually do |
| 01:35.34 | CIA-38 | BRL-CAD: something have a non-null callback (which is presently arb8, ell, half, rec, |
| 01:35.34 | CIA-38 | BRL-CAD: sph, tgc, and tor). the rt_vshootray() caller tests for whether it's null and |
| 01:35.34 | CIA-38 | BRL-CAD: calls a shot stub if needed. |
| 01:35.41 | starseeker | ah |
| 01:35.53 | starseeker | ``Erik: heh, this looks like it's up your alley: http://dwim.hu |
| 01:44.06 | Ralith | woah |
| 01:44.09 | Ralith | fancy |
| 01:44.12 | Ralith | slow, though |
| 01:44.33 | starseeker | oh, COOL - someone is looking at an llvm backend for sbcl |
| 01:45.22 | Ralith | I saw that |
| 01:45.32 | Ralith | I'm not entirely sure what benefits it would confer |
| 01:46.14 | Ralith | (other than the generally neat idea of collaborating with users of other languages on a single Sufficiently Smart Compiler) |
| 01:47.28 | starseeker | Well, Stephen Wilson is working on a language called Comma, which targets llvm: http://savannah.nongnu.org/projects/comma |
| 01:48.02 | starseeker | He's developing it with Aldor, SPAD and Ada in mind - should be appropriate for mathematical uses |
| 01:48.14 | starseeker | would like it to be usable with Lisp |
| 01:48.18 | Ralith | I mean, why is it a Good Thing to have a LLVM backend in SBCL? |
| 01:48.20 | Ralith | oh, easy FFI? |
| 01:48.23 | starseeker | bingo |
| 01:48.36 | Ralith | hm, interesting |
| 01:49.00 | starseeker | hopefully, a function call to a Comma function in Lisp (or vice versa) could be handled semi-intelligently at the LLVM level |
| 01:49.08 | Ralith | I wonder if clang would allow that to be extended to C++ support |
| 01:49.17 | starseeker | dunno |
| 01:49.30 | starseeker | it might require designing the compiler(s) with that specific use in mind |
| 01:49.45 | starseeker | but since Stephen is writing Comma from the ground up... :-) |
| 01:50.28 | starseeker | he was part of the Axiom mailing list a couple years ago, had an interest in the language used to describe mathematics in Axiom |
| 01:51.11 | Ralith | surely there are benefits other than easy FFI to specially designed llvm-targeting languages, though |
| 01:51.14 | starseeker | Aldor was the "successor" to SPAD, the original version of the language in Axiom - it's license never became compatible though |
| 01:51.26 | starseeker | Ralith: oh, sure - lots of potential performance goodies |
| 01:51.41 | Ralith | performance <3 |
| 01:52.09 | Ralith | just 'cuz LLVM has lots of shiny optimization magics that native SBCL lacks? |
| 01:52.11 | starseeker | Aldor actually showed the way on how to approach such things - it was able to generate Lisp code for compiling into a Lisp target, or compile directly through gcc |
| 01:52.15 | starseeker | (I think) |
| 01:52.21 | starseeker | maybe had it's own compiler |
| 01:52.34 | starseeker | Ralith: actually, not sure if LLVM will outperform sbcl's own compiler |
| 01:52.51 | starseeker | but it's probably a fair bet llvm will get ported to a lot of platforms |
| 01:52.58 | Ralith | good point |
| 01:53.09 | Ralith | and it's nearly always beneficial to pool effort |
| 01:53.11 | starseeker | kindaaa like targeting the Java virtual machine, but with modern llvm goodness |
| 01:53.37 | Ralith | has always been kind of fuzzy on exactly what modern llvm goodness entails |
| 01:54.08 | starseeker | Apparently a lot of compiler research has taken place since the basic gcc framework was laid out |
| 01:54.28 | starseeker | plus most descriptions of gcc's codebase I've heard are... well... colorful |
| 01:55.14 | Ralith | okay, cleaner and better-designed code is certainly desirable |
| 01:55.21 | Ralith | but where's the "vm" come in? |
| 01:55.33 | starseeker | virtual machine, I believe... |
| 01:55.35 | starseeker | checks |
| 01:55.54 | starseeker | license is another one |
| 01:56.13 | starseeker | the *BSD folks and a lot of commercial folk would LOVE for there to be a Modified BSD licensed compiler chain |
| 01:56.39 | starseeker | yeah - LLVM = Low Level Virtual Machine |
| 01:57.21 | starseeker | I think the virtual machine part allows for certain types of optimizations that would be difficult otherwise, but it's not my specialty |
| 01:57.53 | Ralith | I mean, I knew what VM refers to |
| 01:58.19 | Ralith | but I'm not clear on what the VM portion of llvm is [for]. |
| 01:58.28 | Ralith | sounds like I'm not entirely alone there, though |
| 01:58.55 | starseeker | yeah, that's beyond my knowledge depth |
| 02:02.35 | Ralith | well, whatever the details, it'll be cool if this gets picked up. |
| 02:18.57 | ``Erik | *readreadread* gcc is in it's third incarnation since I started watching... 2.7.x was there... then egcs kinda threw it all to the wind, then 4.0 was a total rewrite for new optimizations |
| 02:19.45 | ``Erik | llvm kinda smells like a jvm that no one cares about :( |
| 02:22.39 | ``Erik | dwim is what, an instance of an everyday software stack? :D I fail to see anything new and impressive :( |
| 02:31.58 | Ralith | could not easily determine what dwim *is* |
| 02:32.09 | Ralith | my best guess is some sort of web toolkit. |
| 02:32.30 | Ralith | ``Erik: "a jvm that no one cares about?" Everyone I've talked to seems to think that it's a Good Thing. |
| 02:32.53 | Ralith | accross several language communities, no less. |
| 02:35.14 | ``Erik | :D |
| 02:35.48 | ``Erik | it seems to be doing what sun already did... and a few language weenies went "ooh", ... |
| 02:52.57 | starseeker | ``Erik: just thought lisp + web might interest you (dwim) |
| 02:54.38 | starseeker | if nothing else, BSD licensed compiler stack will make a lot of people happy |
| 02:58.34 | Ralith | oh, there's plenty of lisp+web stuff out there, and tbh most of it is a bit less ill-defined than dwim >_> |
| 03:03.17 | ``Erik | lisp is nifty, web seems inevitable... ucw is damn sexy, hunchentoot is kinda ok |
| 03:03.55 | ``Erik | faking stateful operation over a stateless protocol using continuations, that's drop dead sexy |
| 03:08.33 | ``Erik | ralith: check out ucw if you get some time, it makes list+web awesome |
| 03:08.40 | ``Erik | lisp+web even |
| 03:14.44 | Ralith | not the sexiest of homepages for a web framework |
| 03:14.46 | Ralith | but it sounds interesting |
| 03:14.48 | CIA-38 | BRL-CAD: 03brlcad * r36965 10/brlcad/trunk/src/librt/primitives/ (eto/eto.c extrude/extrude.c table.c xxx/xxx.c): more quellage. add more extesive parameter testing to the xxx template for the primitive-specific structure, add more data validation. |
| 03:14.52 | Ralith | foods |
| 03:36.38 | *** join/#brlcad talcite__ (n=matthew@69-196-132-129.dsl.teksavvy.com) | |
| 03:37.39 | brlcad | shakes fist at the binunif turds that ripple throughout |
| 03:47.05 | CIA-38 | BRL-CAD: 03brlcad * r36966 10/brlcad/trunk/TODO: |
| 03:47.05 | CIA-38 | BRL-CAD: binary objects need to write out their minor type during export so that the data |
| 03:47.05 | CIA-38 | BRL-CAD: can be properly imported without munging the API for everyone else. this |
| 03:47.05 | CIA-38 | BRL-CAD: unfortunately (probably) cannot be accomplished without breaking protocol, so |
| 03:47.05 | CIA-38 | BRL-CAD: hacking around it for now. |
| 04:14.52 | CIA-38 | BRL-CAD: 03brlcad * r36967 10/brlcad/trunk/ (10 files in 6 dirs): (log message trimmed) |
| 04:14.52 | CIA-38 | BRL-CAD: remove minor_type from the functab interface for import5/export5. this was |
| 04:14.52 | CIA-38 | BRL-CAD: apparently only added for binary objects, which needs to know which minor type |
| 04:14.52 | CIA-38 | BRL-CAD: they are during import. instead of the object writing out it's minor type |
| 04:14.52 | CIA-38 | BRL-CAD: during export, it munged the api to have the minor type passed from the |
| 04:14.54 | CIA-38 | BRL-CAD: raw_external instead. this moves towards undoing that by removing minor_type |
| 04:14.56 | CIA-38 | BRL-CAD: from all other objects and making binunif's a special case in db5_io. once |
| 05:21.00 | CIA-38 | BRL-CAD: 03brlcad * r36968 10/brlcad/trunk/src/libged/put.c: ft_make no longer takes a diameter value |
| 05:23.17 | CIA-38 | BRL-CAD: 03brlcad * r36969 10/brlcad/trunk/src/libged/wdb_obj.c: bah, another ft_make with diagonal/diamter value that needs removing. also start the killage on expm. |
| 05:25.30 | CIA-38 | BRL-CAD: 03brlcad * r36970 10/brlcad/trunk/src/conv/asc/asc2g.c: ft_import5 no longer takes the minor type. fix this outlier. |
| 05:29.18 | CIA-38 | BRL-CAD: 03brlcad * r36971 10/brlcad/trunk/ (8 files in 4 dirs): |
| 05:29.18 | CIA-38 | BRL-CAD: remove the 'experimental' binary object type. this was never implemented beyond |
| 05:29.18 | CIA-38 | BRL-CAD: a few stubs and has a horrible vague name, so kill it. we have to leave the ID |
| 05:29.18 | CIA-38 | BRL-CAD: and functab entry stubbed so that indices offset correctly but mark it as unused |
| 05:29.18 | CIA-38 | BRL-CAD: so some future new object could conceivably reclaim the ID. |
| 06:08.31 | starseeker | hmm... xprocess looks kinda neat but man compiling it... |
| 08:47.45 | CIA-38 | BRL-CAD: 03d_rossberg * r36972 10/brlcad/trunk/src/librt/CMakeLists.txt: updated CMake file to be consistent with Makefile.am (activated vshoot.c) |
| 09:28.44 | *** join/#brlcad docelic__ (n=docelic@78-2-80-138.adsl.net.t-com.hr) | |
| 09:41.05 | *** join/#brlcad ultralazer (n=user3@97-119-214-177.hlna.qwest.net) | |
| 09:46.40 | *** join/#brlcad docelic_ (n=docelic@78-2-110-236.adsl.net.t-com.hr) | |
| 11:19.24 | CIA-38 | BRL-CAD: 03indianlarry * r36973 10/brlcad/trunk/src/libbu/ (bomb.c cmdhist_obj.c): Wrapped debug variable declaration with DEBUG definition. Removed bu_cmdtab struct array 'ch_cmds[]' and 'cho_hist()', look to be un-used copies of existing definitions 'cho_cmds[]' and 'cho_cmd()'. |
| 11:42.27 | *** join/#brlcad Computer (n=Computer@unaffiliated/computer) | |
| 13:21.07 | *** join/#brlcad talcite (n=matthew@69-196-132-129.dsl.teksavvy.com) | |
| 13:33.33 | *** join/#brlcad d_rossberg (n=rossberg@BZ.BZFLAG.BZ) | |
| 13:50.45 | CIA-38 | BRL-CAD: 03brlcad * r36974 10/brlcad/trunk/src/libged/nirt.c: ws cleanup |
| 13:57.19 | *** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1) | |
| 13:57.30 | CIA-38 | BRL-CAD: 03brlcad * r36975 10/brlcad/trunk/src/libged/nirt.c: init vars |
| 14:20.25 | CIA-38 | BRL-CAD: 03brlcad * r36976 10/brlcad/trunk/src/libged/nirt.c: |
| 14:20.25 | CIA-38 | BRL-CAD: there probably be little dragons here. replace the strip_crlf() win32-specific |
| 14:20.25 | CIA-38 | BRL-CAD: hack with a more generalized solution that just trims space on the line parsed |
| 14:20.25 | CIA-38 | BRL-CAD: in. it's not clear why they even matter with bu_fgets() reading in lines |
| 14:20.27 | CIA-38 | BRL-CAD: portably other than it printing \n\r's into the result string (which then also |
| 14:20.29 | CIA-38 | BRL-CAD: just begs for space trimming). untested. |
| 14:46.02 | ``Erik | hm, \r\n is ansi, unix kinda cheats |
| 15:05.12 | brlcad | doesn't change anything |
| 15:05.37 | brlcad | good grief, the step converter code is a headache :) |
| 15:06.58 | brlcad | going through some basic mods and cleanup, and .. d-d-d-damn are the headers/decls in disarray |
| 15:07.17 | brlcad | cascade failures |
| 15:08.50 | brlcad | headers not including what they need, interfaces not coming first, replication of inclusions, ... this is going to take some work .. especially SCL stupidly naming a class BOOL of all things |
| 15:27.46 | *** join/#brlcad Elrohir (n=kvirc@p5B14B923.dip.t-dialin.net) | |
| 15:33.39 | starseeker | note to self - check this out later: http://users.iit.demokritos.gr/~petasis/Tcl/toolbar.tcl |
| 15:36.51 | CIA-38 | BRL-CAD: 03brlcad * r36977 10/brlcad/trunk/src/other/step/src/ (13 files in 3 dirs): |
| 15:36.51 | CIA-38 | BRL-CAD: rename the BOOL and BOOLS classes to BOOLEAN and BOOLEANS respectively so as not |
| 15:36.51 | CIA-38 | BRL-CAD: to conflict with openNURBS (and other codes that commonly use BOOL as a simple |
| 15:36.51 | CIA-38 | BRL-CAD: boolean type). this also conveniently makes the class name lengths match the |
| 15:36.51 | CIA-38 | BRL-CAD: corresponding LOGICAL and LOGICALS classes. unsure about the Bool->Boolean |
| 15:36.53 | CIA-38 | BRL-CAD: declarations and how they come into play, alas, so have to see if those need to |
| 15:36.55 | CIA-38 | BRL-CAD: be unrolled for the actual step parsing. |
| 15:42.03 | brlcad | that commit likely breaks compile when coupled with the previous, fixing |
| 15:42.06 | CIA-38 | BRL-CAD: 03brlcad * r36978 10/brlcad/trunk/src/conv/step/ (13 files): |
| 15:42.06 | CIA-38 | BRL-CAD: beginning of massive header and type inclusion cleanup. header inclusion |
| 15:42.06 | CIA-38 | BRL-CAD: ordering of c++ needs to be cleaned up. avoiding inclusion of std namespace. |
| 15:42.06 | CIA-38 | BRL-CAD: formatting/ws/indent cleanup. opening braces. work in progress with more on |
| 15:42.06 | CIA-38 | BRL-CAD: the way. |
| 15:48.21 | brlcad | wonders how much of this will be for moot |
| 15:48.23 | CIA-38 | BRL-CAD: 03brlcad * r36979 10/brlcad/trunk/src/conv/step/ (19 files): use the updated (Boolean) and (BOOLEAN) instead of (Bool) and (BOOL), so as to avoid a conflict with other codes. |
| 15:50.08 | brlcad | mm, looks like that at least got closer to compile |
| 15:55.24 | CIA-38 | BRL-CAD: 03brlcad * r36980 10/brlcad/trunk/src/conv/step/ (Factory.cpp Factory.h): cleanup, declare interface headers, reorder accordingly; consistent formatting |
| 16:03.18 | CIA-38 | BRL-CAD: 03brlcad * r36981 10/brlcad/trunk/src/conv/step/ (Factory.cpp Factory.h): oops, already had forward decl on STEPEntity. only needed for the implementation. |
| 16:07.21 | CIA-38 | BRL-CAD: 03brlcad * r36982 10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: SurfaceTree is in the brlcad namespace |
| 16:11.26 | *** join/#brlcad indianlarry (n=indianla@BZ.BZFLAG.BZ) | |
| 16:17.56 | *** join/#brlcad Computer_ (n=Computer@209-16-114-100.net.bhntampa.com) | |
| 16:34.35 | CIA-38 | BRL-CAD: 03brlcad * r36983 10/brlcad/trunk/src/conv/step/ (PullbackCurve.cpp PullbackCurve.h): more brlcad namespace qualifications, cleanup ws indent and brace formatting |
| 16:58.01 | starseeker | is rather puzzled... if I uncomment the line *fbp = tk_interface in dm-tk.c, mged initialization failes with a bad alloc without ever hitting that line... |
| 16:58.32 | starseeker | oh, wait... |
| 16:58.36 | starseeker | it's something else |
| 16:58.50 | starseeker | hmm... |
| 17:35.51 | CIA-38 | BRL-CAD: 03brlcad * r36984 10/brlcad/trunk/src/conv/step/step-g.cpp: ws indent cleanup, remove using, comments, etc |
| 17:45.34 | starseeker | o.O |
| 17:45.43 | starseeker | ../src/conv/asc2g ../../brlcad/db/terra.asc terra.g |
| 17:45.43 | starseeker | ERROR: bad pointer x106efb00: s/b rt_db_internal(xdbbd867), was Unknown_Magic(x5625), file ../../../brlcad/src/librt/primitives/dsp/dsp.c, line 256 |
| 17:45.46 | starseeker | ERROR: bad pointer x106efb00: s/b rt_db_internal(xdbbd867), was Unknown_Magic(x5625), file ../../../brlcad/src/librt/primitives/dsp/dsp.c, line 256 |
| 17:54.56 | starseeker | did something with that binary minor type change impact how dsp does its thing? |
| 17:55.07 | starseeker | hunts... |
| 17:57.49 | brlcad | starseeker: very likely |
| 17:58.14 | brlcad | or one of the checks I added is for the wrong object type |
| 18:32.10 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 18:32.10 | *** join/#brlcad Computer_ (n=Computer@209-16-114-100.net.bhntampa.com) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad indianlarry (n=indianla@BZ.BZFLAG.BZ) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad roberthl (n=robert@silentflame/member/roberthl) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad dtidrow (n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad ``Erik (n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT VICTIM] | |
| 18:32.10 | *** join/#brlcad alex_joni (n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT VICTIM] | |
| 18:32.10 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net | |
| 18:42.07 | CIA-38 | BRL-CAD: 03brlcad * r36986 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: compare pointer to NULL, not char |
| 19:22.47 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 19:22.47 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) | |
| 19:22.47 | *** join/#brlcad Computer (n=Computer@unaffiliated/computer) | |
| 19:22.47 | *** join/#brlcad indianlarry (n=indianla@BZ.BZFLAG.BZ) | |
| 19:22.47 | *** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1) | |
| 19:22.48 | *** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl) | |
| 19:22.48 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) | |
| 19:22.48 | *** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no) | |
| 19:22.48 | *** join/#brlcad roberthl (n=robert@silentflame/member/roberthl) | |
| 19:22.48 | *** join/#brlcad dtidrow (n=Don@c-71-238-51-148.hsd1.mi.comcast.net) | |
| 19:22.48 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) | |
| 19:22.48 | *** join/#brlcad poolio (n=poolio@63.246.136.16) | |
| 19:22.48 | *** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ) | |
| 19:22.48 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 19:22.48 | *** join/#brlcad Maloeran (n=maloeran@glvortex.net) | |
| 19:22.48 | *** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) | |
| 19:22.48 | *** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) | |
| 19:22.48 | *** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos) | |
| 19:22.48 | *** join/#brlcad CIA-38 (n=CIA@208.69.182.149) | |
| 19:22.48 | *** join/#brlcad ``Erik (n=erik@c-69-140-109-104.hsd1.md.comcast.net) | |
| 19:22.48 | *** join/#brlcad alex_joni (n=alex_jon@emc/board-of-directors/alexjoni) | |
| 19:22.48 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net | |
| 19:29.43 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT VICTIM] | |
| 19:45.20 | CIA-38 | BRL-CAD: 03brlcad * r36990 10/brlcad/trunk/doc/docbook/Makefile.am: |
| 19:45.20 | CIA-38 | BRL-CAD: create the directory before running xsltproc in order to avoid a race condition |
| 19:45.20 | CIA-38 | BRL-CAD: that causes xsltproc to bail. also make the clean rule not fail on in-dir |
| 19:45.20 | CIA-38 | BRL-CAD: builds (can't just remove the dir, especially if there are still (source) files |
| 19:45.20 | CIA-38 | BRL-CAD: in there) |
| 19:46.50 | starseeker | brlcad: except that doesn't work when we're building the spanish documentation |
| 19:47.54 | starseeker | at least, not for man1 and man3 |
| 19:48.07 | starseeker | would dirname work there too? |
| 19:48.23 | starseeker | no, guess not |
| 19:48.25 | starseeker | hrm |
| 19:49.54 | starseeker | maybe move the xml.1 and xml.3 rules to the system/man/$LANG directory makefiles? |
| 19:50.38 | brlcad | hm? |
| 19:51.01 | starseeker | we have system/man1/en hardcoded into the build rules for .xml.1 and .xml.3 |
| 19:51.19 | brlcad | I didn't modify the ones that are already hard-coded |
| 19:51.27 | starseeker | ah, k |
| 19:51.40 | starseeker | so it's my fault :-) |
| 19:51.42 | brlcad | they're still hard-coded, but presumably a similar trick will work |
| 19:52.36 | starseeker | yes, except I think xsltproc drops the .1 files in the current working directory of xsltproc, rather than a targeted output |
| 19:52.49 | starseeker | kinda sucks |
| 19:53.19 | starseeker | actually though... |
| 19:53.38 | starseeker | the build rule should know where the thing is supposed to go, even if xsltproc doesn't do it |
| 19:53.50 | starseeker | tries it |
| 19:59.59 | *** join/#brlcad kristian-aalborg (n=kristian@2505ds5-abc.0.fullrate.dk) | |
| 20:00.05 | kristian-aalborg | hi all |
| 20:00.30 | kristian-aalborg | is there software available that will render a 3d model from a series of 2d pics? |
| 20:01.00 | brlcad | depends what kind of 2d pics and the desired 3d model |
| 20:01.05 | brlcad | in general, no |
| 20:02.30 | brlcad | starseeker: at a glance, looks like you're only conditionally building the .es fiels |
| 20:02.38 | brlcad | suggest always building all languages |
| 20:05.30 | kristian-aalborg | I'm thinking if I can take some pics of a thing like a cofee cup and have it made into 3d |
| 20:05.34 | CIA-38 | BRL-CAD: 03brlcad * r36991 10/brlcad/trunk/doc/docbook/Makefile.am: try generalizing the dir creation |
| 20:05.52 | brlcad | kristian-aalborg: heh, done much 3d modeling before? |
| 20:06.00 | kristian-aalborg | none ;) |
| 20:06.27 | kristian-aalborg | but I've seen a bunch of sci-fi movies ;) |
| 20:07.42 | brlcad | yeah, it doesn't quite work like that |
| 20:08.18 | starseeker | brlcad: yeah, I was thinking unless a user explicitly asked for all languages they wouldn't want the overhead of doing all the building for all the languagues |
| 20:09.19 | starseeker | heh - beat me to it |
| 20:09.39 | starseeker | well, that's better anyway :-) |
| 20:11.12 | starseeker | brlcad: oh, how do I do a "this OR this" if case in a makefile? I haven't been able to track down an example yet |
| 20:15.03 | starseeker | confirmed - generalizing logic appears to work |
| 20:15.11 | starseeker | that's SWEET |
| 20:17.16 | ``Erik | sits around yelling "enhance" at his computer screen O.o :D |
| 20:17.35 | starseeker | ``Erik: do I get yelled at if I always build all docbook all the time? |
| 20:17.54 | starseeker | is willing to do it if ``Erik promises not to hurt him |
| 20:18.11 | ``Erik | heh, but the dependancy chain is fugly |
| 20:18.21 | ``Erik | xsltproc and java for fop? |
| 20:18.41 | starseeker | no, no - turning on Spanish and English for all docs always |
| 20:19.11 | starseeker | so not only would you be building English, you'd be building the Spanish versions, and the Russian versions, and the Esperanto versions... ;-P |
| 20:19.45 | ``Erik | I imagine klingon would be on that list before russian or esperanto ... :D |
| 20:19.55 | starseeker | probably, given our user audience |
| 20:20.40 | ``Erik | *shrug* I complain about dependancy sets, not product ;) |
| 20:20.59 | starseeker | has observed ``Erik complainin about build time here and there |
| 20:21.29 | ``Erik | noting significant increases, not complaining about |
| 20:21.30 | ``Erik | :) |
| 20:21.39 | starseeker | alrightie |
| 20:21.59 | starseeker | goes for broke |
| 20:34.23 | brlcad | not that big a deal time-wise until there are more than a couple languages, completely translated |
| 20:34.38 | brlcad | and by the time that happens, I doubt compilation time will be the issue |
| 20:34.42 | starseeker | true :-) |
| 20:34.59 | starseeker | I ripped out the lang flags, testing now before committing |
| 20:38.58 | brlcad | hm, the .es conversion I got from the first lesson doesn't render so hot |
| 20:38.59 | brlcad | as html |
| 20:39.21 | starseeker | font issue? |
| 20:43.10 | CIA-38 | BRL-CAD: 03starseeker * r36992 10/brlcad/trunk/ (8 files in 8 dirs): Purge the language configuration option and build all languages all the time, per Sean's suggestion |
| 20:44.08 | starseeker | well, between that and tkpng I now feel rather uselss :-/ |
| 20:44.51 | starseeker | back to framebuffer diving |
| 20:45.10 | brlcad | encoding issue |
| 20:45.18 | brlcad | all accents are junked up |
| 20:45.29 | brlcad | http://brlcad.org/~sean/tmp/mged01_crear_figuras_primitivas.html |
| 20:45.51 | starseeker | ah, that thing |
| 20:46.40 | starseeker | I think that's the htaccess file for Apache - needs AddDefaultCharset UTF-8 |
| 20:47.14 | starseeker | see doc/docbook/README |
| 21:40.23 | brlcad | make[3]: *** No rule to make target `system/man3/en/libfb.html', needed by `all'. Stop. |
| 21:40.38 | starseeker | confound it |
| 21:42.03 | starseeker | ummm.... for me it succeeded |
| 21:42.15 | starseeker | brlcad: what platform are you on? |
| 21:45.49 | brlcad | did you distcheck? |
| 21:46.31 | starseeker | ah |
| 21:46.34 | starseeker | distchecks |
| 21:59.22 | starseeker | hah, cool: http://www.bootchart.org/images/bootchart.png |
| 22:19.04 | starseeker | brlcad: I can reproduce the failure, trying to figure out what's causing it... |
| 22:21.12 | starseeker | oh, der |
| 22:22.13 | CIA-38 | BRL-CAD: 03starseeker * r36993 10/brlcad/trunk/doc/docbook/Makefile.am: Whoops. Add MAN3 sources to EXTRA_DIST so distcheck brings them along for the ride. |
| 22:22.58 | starseeker | hey, cool: http://code.google.com/p/tufte-latex/ |
| 22:23.12 | starseeker | wonders how long before someone tries tufte-docbook |
| 22:43.24 | brlcad | heh, http://people.ucsc.edu/~weissman/MathClubTalk2009.pdf |
| 22:44.46 | brlcad | thinks starseeker should work up a tufte stylesheet |
| 22:45.22 | *** join/#brlcad Nohla (n=jesica@168.226.178.2) | |
| 22:46.51 | starseeker | brlcad: I suppose that would kinda be the ultimate "non-default" look wouldn't it? :-) |
| 22:47.57 | brlcad | ultimate? |
| 22:48.19 | brlcad | certainly different, but of a good kind |
| 22:48.23 | starseeker | crappy default vs. Tufte polished :-) |
| 22:48.36 | brlcad | ultimate would be a lot more glossified |
| 22:49.43 | starseeker | wonders what we would put in the side columns of a layout like that... |
| 22:51.22 | starseeker | also wonders why the best looking gantt chart he's seen from an open source tool is a special purpose java tool for boot process illustration... arrgh |
| 23:05.54 | Nohla | holas |
| 23:05.59 | starseeker | hola :-) |
| 23:06.07 | starseeker | how goes it? |
| 23:10.16 | Nohla | tired :P |
| 23:10.46 | starseeker | heh - school? |
| 23:10.59 | Nohla | no, life :) |
| 23:11.15 | starseeker | did you find a projector that would work? |
| 23:11.58 | Nohla | I think so, a friend bought one two months ago |
| 23:12.16 | Nohla | maybe I'll buy the same in the same place |
| 23:12.55 | Nohla | It's a good one and cost the price I can pay |
| 23:15.07 | starseeker | crosses his fingers that Microvision actually delivers this: http://www.microvision.com/showwx/index.html |
| 23:35.53 | Nohla | starseeker thought I thought maybe translate the menu of the program would be more effective |
| 23:36.07 | Nohla | what do you think? |
| 23:36.46 | starseeker | Nohla: that would be helpful, but you really do need to read the docs to use BRL-CAD |
| 23:36.50 | starseeker | even in English :-) |
| 23:37.03 | starseeker | plus, we aren't set up to use gettext |
| 23:37.49 | Nohla | the most of people try until learn before to read anything |
| 23:38.10 | starseeker | yes, which is why we don't have more users |
| 23:38.21 | starseeker | that doesn't work with our current interface |
| 23:39.30 | Nohla | ok |
| 23:40.07 | Nohla | I'll try to finish the second before next week |
| 23:40.53 | Nohla | and third before my birthday, but I cant promise :P |
| 23:41.16 | starseeker | no problem :-) |
| 23:41.17 | starseeker | no rush |
| 23:42.34 | Nohla | fuck, I hate children, they cry all day!! |
| 23:43.46 | Nohla | sorry, you never expected that from women a woman |
| 23:44.10 | Nohla | sorry, you never expected that from a woman |
| 23:44.59 | starseeker | no problem - stuck with a loud child? |
| 23:45.55 | Nohla | my neighbour :P |
| 23:46.29 | brlcad | Nohla: jaja |
| 23:46.30 | Nohla | and his fuckn backyard |
| 23:47.20 | Nohla | starseeker did you see that PDF has no images again? |
| 23:47.56 | starseeker | hmm? which one? |
| 23:48.15 | Nohla | the one in /lessons/es |
| 23:48.21 | starseeker | erm. |
| 23:48.31 | Nohla | html is ok |
| 23:48.44 | starseeker | I haven't checked lately - perhaps I messed it up somehow |
| 23:49.05 | starseeker | Nohla: you are abile to build successfully? |
| 23:49.09 | starseeker | able even |
| 23:49.42 | Nohla | yes, brlcad helped me |
| 23:49.48 | starseeker | ah, excellent |
| 23:49.58 | starseeker | I will check when I get home - this machine doesn't have fop |
| 23:50.29 | brlcad | you helped yourself, I just pointed |
| 23:51.25 | Nohla | brlcad that was a difficul day :P when I ask for some minutes is because I really need them :P |
| 23:51.45 | brlcad | you did great |
| 23:52.04 | starseeker | brlcad: ah, finally - distcheck passed on my Mac :-) |
| 23:52.23 | brlcad | gets the invoice filled out |
| 23:52.36 | brlcad | starseeker: oh, could have told you that mine passed ;) |
| 23:52.37 | starseeker | invoice? |
| 23:52.47 | starseeker | ah - hehe |
| 23:52.49 | brlcad | gsoc invoice, finally got the purchase order |
| 23:53.00 | starseeker | nods |
| 23:53.14 | brlcad | they got things mixed up the first time around |
| 23:53.20 | starseeker | oh, lovely |
| 23:53.51 | brlcad | nothing bad, just delayed things |
| 23:54.54 | starseeker | well, if my distcheck passes and yours does too, I'm going home :-P |
| 23:55.19 | starseeker | maybe next year I'll manage to do something I won't have to back out within a week :-/ |
| 23:56.37 | starseeker | the problem of passing local library locations to subconfigure systems I think remains very real though - the only "correct" solution I can see is to get TEA and automake to make nice and then send out a bunch of patches to our favorite src/other libraries |
| 23:57.33 | Nohla | starseeker for the xml there is a maximum character length per line |
| 23:57.35 | Nohla | ? |
| 23:57.52 | *** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu) | |
| 23:57.54 | starseeker | Nohla: build system issues |
| 23:58.00 | starseeker | Nohla: not related to docbook |
| 23:58.13 | starseeker | oh, you're asking? |
| 23:58.20 | Nohla | yes |
| 23:58.26 | Nohla | sorry: is there |
| 23:59.01 | starseeker | not really a maximum limit, but try to stay around 80 - readable formatting is more important than max character length |
| 23:59.35 | starseeker | drives home, back on later |
