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 |