| 00:32.50 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 00:34.15 | *** part/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 00:35.58 | *** join/#brlcad Elperion (n=Bary@p54875704.dip.t-dialin.net) |
| 04:01.29 | CIA-28 | BRL-CAD: 03brlcad * 10brlcad/doc/README.IRIX: |
| 04:01.29 | CIA-28 | BRL-CAD: beef up the IRIX readme with addition details encountered with the problem I ran |
| 04:01.29 | CIA-28 | BRL-CAD: into with (yet another stupid) libtool linkage problems/bugs. more |
| 04:01.29 | CIA-28 | BRL-CAD: specifically, libtool was leaving out three librt object files that were in the |
| 04:01.29 | CIA-28 | BRL-CAD: librt_nil.la convenience library. turns out they were getting prelinked into a |
| 04:01.31 | CIA-28 | BRL-CAD: '.al' pre-link archive with just the .l nm symbol instead of .lo causing |
| 04:01.33 | CIA-28 | BRL-CAD: subsequent linkage failures due to the symbols that get left out. |
| 04:19.21 | CIA-28 | BRL-CAD: 03brlcad * 10brlcad/TODO: make byteoffset and run-time byteorder detections necessary in order for Mac OS X universal binaries to actually work |
| 05:27.29 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 05:40.53 | *** part/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 06:18.49 | *** join/#brlcad PrezKennedy (i=Matt@74.86.45.130) |
| 06:19.10 | *** join/#brlcad PrezKennedy (n=Matt@74.86.45.130) |
| 06:23.18 | *** join/#brlcad yukonbob (n=yukonbob@198.235.198.234) |
| 07:45.28 | *** join/#brlcad Defcon (n=def@74.17-246-81.adsl-static.isp.belgacom.be) |
| 08:31.48 | *** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch) |
| 08:44.28 | *** join/#brlcad starseeker (n=CY@ip72-218-17-237.hr.hr.cox.net) [NETSPLIT VICTIM] |
| 10:19.08 | *** join/#brlcad Elperion (n=Bary@p54877BF6.dip.t-dialin.net) |
| 11:00.20 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) |
| 13:14.09 | *** join/#brlcad yukonbob (n=yukonbob@198.235.198.234) |
| 13:55.10 | CIA-28 | BRL-CAD: 03erikgreenwald * 10brlcad/TODO: fix (type)(size_t)val hacks |
| 13:56.28 | CIA-28 | BRL-CAD: 03erikgreenwald * 10brlcad/src/rt/view_bot_faces.c: (type)(size_t)val hack to quell compiler warning... |
| 14:12.07 | CIA-28 | BRL-CAD: 03erikgreenwald * 10brlcad/src/ (53 files in 12 dirs): LOCAL->static, per machine.h deprecation list |
| 15:40.27 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-089-111.pools.arcor-ip.net) |
| 16:26.19 | *** join/#brlcad Elperion (n=Bary@p54877BF6.dip.t-dialin.net) |
| 20:33.15 | *** join/#brlcad Z80-Boy (i=clock@77-56-93-235.dclient.hispeed.ch) |
| 20:47.23 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 20:54.33 | *** join/#brlcad yukonbob (n=yukonbob@198.235.198.234) |
| 20:57.30 | CIA-28 | BRL-CAD: 03erikgreenwald * 10brlcad/src/adrt/libtie/ (tie.c tie.h tie_define.h tie_kdtree.c tie_struct.h): merge of the "other" libtie... |
| 21:07.12 | CIA-28 | libirc: 03JeffM2501 * r350 10/trunk/libirc/examples/stupidBot/ (5 files in 2 dirs): sources go in src |
| 21:12.50 | CIA-28 | libirc: 03JeffM2501 * r352 10/trunk/libirc/examples/stupidBot/vc8/stupidBot.vcproj: add url handler for RSS feed reading |
| 21:15.11 | ``Erik | I'm classy! :D |
| 21:15.41 | yukonbob | ~bzfrag boogers |
| 21:15.42 | ibot | ACTION fries boogers with a laser |
| 22:20.14 | brlcad | ``Erik: you committed a bunch of tclIndex changes again (that clobbered what they are supposed to contain) |
| 22:21.00 | brlcad | looks like your indices were generated from a bad btclsh, didn't have incrTcl properly loaded/initialized so it wiped out things |
| 22:21.26 | brlcad | the tclIndex files throughout src/tclscripts |
| 22:36.53 | yukonbob | brlcad: you and I were having a discussion re: tclIndex's whether they are for runtime or buildtime, right? |
| 22:37.43 | brlcad | mmm.. not ringing a specific bell :) |
| 22:38.03 | brlcad | they are runtime araik |
| 22:38.15 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) |
| 22:39.44 | louipc | it needs some build stub for building |
| 22:39.52 | louipc | in tclConfig.sh |
| 22:43.41 | *** join/#brlcad CIA-28 (n=CIA@208.69.182.149) |
| 22:44.03 | CIA-28 | BRL-CAD: 03bob1961 * 10brlcad/misc/win32-msvc8/ (62 files in 62 dirs): Mods to use the new install tree. |
| 22:44.46 | brlcad | louipc: ah, I do remember us talking about whether the .sh scripts for for run- or build-time |
| 22:45.13 | brlcad | I actually have it using tclConfig.sh and tkConfig.sh now in our configure |
| 22:46.05 | brlcad | I made that change just last night so that I could get the "actual" version number of what we're compiling against without resorting to a test app |
| 22:46.13 | CIA-28 | BRL-CAD: 03bob1961 * 10brlcad/misc/win32-msvc8/tclsh/library/treeInit.sh: Initial check-in (not finished, checking in for safety) |
| 22:46.48 | brlcad | itclConfig.sh is a little more tricky, though, since we don't presently have/use incrTcl's build system |
| 22:47.22 | louipc | hah so that's why it works! |
| 22:48.38 | louipc | yeah I haven't had the initiative to completely learn about building tcl extensions to package them separately so I just let brl-cad take care of it |
| 23:24.30 | starseeker | brlcad: I see the tcl and tk config scripts in configure - cool :-) |
| 23:26.44 | starseeker | Is the plan also to use /usr/lib/itclConfig.sh? |
| 23:26.44 | *** part/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 23:29.15 | louipc | talking about tcl stuff is taxing |
| 23:29.22 | starseeker | indeed |
| 23:30.17 | brlcad | starseeker: problem is that it's not guaranteed to be in that path |
| 23:30.26 | starseeker | brlcad: Ah. |
| 23:30.39 | brlcad | I need incrTcl's m4 file so that it searches for it like tcl.m4 searches for tclConfig.sh |
| 23:31.21 | brlcad | or at least need to replicate the searching logic |
| 23:31.23 | starseeker | Gentoo's install doesn't seem to include the m4 file. Hmm... |
| 23:31.33 | brlcad | yeah, the m4 isn't installed |
| 23:31.35 | brlcad | even for tcl |
| 23:31.38 | brlcad | afaik |
| 23:31.48 | starseeker | Argh. |
| 23:32.08 | brlcad | we just need to try rolling incrtcl back to using the incrtcl build |
| 23:32.43 | brlcad | the biggest problem with that is incrtcl's build is exceptionally weak and was outright broken on several important platforms last I tried |
| 23:32.55 | louipc | gentoo uses some sed lines to change the specified build paths to point to some installed libstubs I think |
| 23:32.55 | brlcad | quite a lot of short-term hacks in it |
| 23:33.28 | starseeker | Ugh. I don't suppose they could be persuaded to fix that? |
| 23:33.54 | brlcad | there's like two guys that work on incrtcl |
| 23:34.11 | starseeker | Ah. |
| 23:34.11 | brlcad | one's a tcl dev that fixes things only as much as he needs to |
| 23:34.31 | brlcad | the other (the main author) is a prof at a uni that works on it really hard for two weeks, and then nothing for 6 months |
| 23:34.57 | starseeker | So the build system isn't likely to be high on the priority list. |
| 23:35.01 | starseeker | Joy |
| 23:35.24 | yukonbob | well -- I'm sure if it's patched and presented to them it'd be considered... no? |
| 23:35.41 | louipc | tcl, itcl, etc seem to have really odd build systems to me |
| 23:35.55 | brlcad | well, I still have to do *something* since right now there's no way to have brl-cad compile incrTcl and have it use anything but the same matching version of tcl installed on the system |
| 23:36.26 | brlcad | yukonbob: I've got patches on incrtcl's patches tracker that remained open for two years before :) |
| 23:36.34 | yukonbob | :P |
| 23:36.57 | louipc | :( |
| 23:37.00 | brlcad | they finally got around to the tracker item after they'd finally ran into the problem themselves and had since changed the interface |
| 23:37.51 | starseeker | brlcad: Would they consider giving you commit access? |
| 23:38.55 | louipc | I bet there a few other ppl that would like commit access too |
| 23:39.01 | yukonbob | re: incrtcl + tcl versions -- it could be nice, but perhaps we should consider that "it makes sense" since incrtcl is so intimate with tcl... so one builds incrtcl w/ tcl (as supplied by brl-cad distro), or supplies a working incrtcl installation (which implies a tcl installation that already works with it) |
| 23:40.45 | brlcad | starseeker: hard to say -- I've had that discussion with the tcl guys several times over the years |
| 23:40.58 | brlcad | probably possible if someone bugged him enough about it |
| 23:41.21 | brlcad | bigger problem seemed to simply be that the tcl devs really (really *really*) don't like incrTcl |
| 23:41.42 | brlcad | even though it is by far the most used OO extension |
| 23:41.52 | starseeker | political? |
| 23:41.57 | brlcad | to the extent that they developed their own, and nobody liked it |
| 23:42.02 | starseeker | Ah. |
| 23:42.05 | brlcad | so now they're redoing it again |
| 23:42.10 | brlcad | but part of the tcl core |
| 23:42.26 | starseeker | Is that one of the reasons for the 8.5 delay? |
| 23:42.29 | brlcad | which was their biggest complaint with incrTcl .. that it hooked into tcl's core |
| 23:43.18 | brlcad | yeah, stupid whiney devs, political issues and posturing |
| 23:43.26 | yukonbob | well, I think that tcl core is providing facilities for OOP, that one can leverage, which are taken from best of incrtcl, snit, etc., for using as resources for future OOP interfaces -- a la X providing facilities, not policies. |
| 23:43.51 | brlcad | yukonbob: yeah, their end result isn't likely going to be bad .. |
| 23:44.03 | brlcad | it was just that they're just now getting to the point where incrTcl was five years ago |
| 23:44.27 | brlcad | feature-wise at least |
| 23:44.38 | starseeker | Well, considering the state of the Axiom community I suppose I'm in no position to comment... |
| 23:44.49 | brlcad | most of the complaints that I know of were implementation under-the-hood details |
| 23:45.17 | starseeker | Hmm. Is there hope then that porting from incrTcl to the new core Tcl stuff would be straightforward? |
| 23:45.23 | brlcad | I mean, I get the complaints about code maintainability and cleanliness.. but the idea was to *integrate* incrTcl into tcl, so it used the core |
| 23:45.42 | yukonbob | well -- so be it... my impression of the development is that there is a really concerted effort for "correctness", and incrtcl _always_ rubbed people the wrong way because of it's tinkering with the core (cheap solution) -- now they're at the place where it's as functional as incrtcl 5 years ago, but the code can be looked at and deemed "correct" or "good looking". |
| 23:45.49 | brlcad | and left plenty of room for refactoring and cleaning up .. they just didn't like the code |
| 23:46.45 | starseeker | Oh, well. So it goes. |
| 23:46.48 | brlcad | yukonbob: correct only moreso because they wrote it and now understand it rather than it actually being architecturally very different code-wise |
| 23:47.01 | yukonbob | brlcad++ |
| 23:47.10 | yukonbob | or [incr brlcad] ;) |
| 23:47.16 | louipc | nooooo |
| 23:47.20 | yukonbob | there is a "Tclish" way to do things |
| 23:48.20 | louipc | L? |
| 23:48.38 | brlcad | heh |
| 23:48.47 | yukonbob | tcl, refactored |
| 23:49.00 | brlcad | set brlcad [expr $brlcad + 1] |
| 23:50.28 | yukonbob | tcl 8.5 gets lambdas |
| 23:50.47 | starseeker | Heh - brlcad is still away - coding at the gym now? ;-) |
| 23:58.31 | louipc | hah they don't? |
| 23:59.05 | louipc | I could get my math exercises via a website in .ps format |
| 23:59.12 | louipc | years ago |