00:55.05 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
01:10.22 |
*** join/#brlcad poolio
(n=poolio@c-24-131-202-244.hsd1.pa.comcast.net) |
03:13.19 |
*** join/#brlcad poolio
(n=poolio@c-71-206-215-46.hsd1.pa.comcast.net) |
03:24.50 |
*** part/#brlcad poolio___
(n=poolio@c-71-206-215-46.hsd1.pa.comcast.net) |
05:20.40 |
*** join/#brlcad PK
(i=Matt@74.86.45.130) |
05:24.13 |
*** join/#brlcad Z80-Boy
(i=clock@77-56-82-12.dclient.hispeed.ch) |
05:27.59 |
*** join/#brlcad louipc_
(n=louipc@67.68.54.228) |
07:33.00 |
*** join/#brlcad Z80-Boy
(n=clock@zux221-122-143.adsl.green.ch) |
07:51.52 |
*** join/#brlcad
MinuteElectron
(n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) |
08:31.47 |
*** join/#brlcad SWPadnos_
(n=Me@dsl245.esjtvtli.sover.net) |
10:30.40 |
*** join/#brlcad elite01
(n=elite01@dslc-082-082-070-024.pools.arcor-ip.net) |
10:48.09 |
*** join/#brlcad Phantom-X
(i=uwDVWgDS@c2.a108.sto.bahnhof.net) |
11:05.49 |
*** join/#brlcad
MinuteElectron
(n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) |
13:05.01 |
*** join/#brlcad Apathy
(i=Matt@74.86.45.130) |
13:34.46 |
Z80-Boy |
brlcad: with motion of the mouse, one can
rotate the edited object left-right and up down |
13:34.56 |
Z80-Boy |
but one cannot rotate the view in a corkscrew
fashion |
13:35.13 |
Z80-Boy |
but I figured out if I do circles with the
mouse, the view rotates slowly in a corkscrew fashion |
13:48.39 |
*** join/#brlcad yukonbob
(n=yukonbob@CPE001125477e9c-CM0011e6be27b1.cpe.net.cable.rogers.com) |
13:48.57 |
yukonbob |
hello, whirled |
13:49.30 |
yukonbob |
?Is 7.11.0 the same code as 7.10.4 -- I was
using HEAD and getting 7.10.3, but my latest update has mged
showing it's 7.11.0 |
13:58.28 |
``Erik |
<PROTECTED> |
14:00.42 |
``Erik |
and the MINOR for head was bumped on oct
17 |
14:00.57 |
``Erik |
even though the stable branch forked a fair
bit before |
14:20.39 |
yukonbob |
``Erik: ok -- I'll regrab -r 7 |
14:20.51 |
yukonbob |
* -r 7.10 |
14:43.42 |
yukonbob |
``Erik: ?what tag should I be using for
following 7.10.4 (and later stables) |
14:43.55 |
yukonbob |
-r7.10 doesn't look like it ... |
15:04.34 |
brlcad |
-r rel-7-10-4 |
15:04.56 |
brlcad |
cvs status -v README (or any other file) will
tell you the available tags |
15:05.03 |
yukonbob |
;) |
15:05.05 |
yukonbob |
thx |
15:05.05 |
*** join/#brlcad
MinuteElectron
(n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) |
15:06.09 |
yukonbob |
*7.11.0 |
15:16.30 |
``Erik |
ah ha, I understand the tcl version
issue |
15:17.45 |
yukonbob |
brlcad: I should be able to pick -r rel-7-10,
and pick all 7.10.* as they are branched, no? |
15:18.40 |
brlcad |
yukonbob: did you see a branch in the status
-v ? :) |
15:19.00 |
brlcad |
there's not a branch for all revs, only
generally as/if needed |
15:19.18 |
brlcad |
STABLE is the branch 7.10.4 somes
from |
15:20.12 |
brlcad |
and even then, checking out a branch in cvs
isn't like checking out a branches dir in svn where you get all the
revs |
15:20.28 |
brlcad |
you get the endpoint on that branch, whatever
the latest is |
15:31.48 |
*** join/#brlcad Elperion
(n=Bary@p54875DBC.dip.t-dialin.net) |
15:47.37 |
*** join/#brlcad cad31
(n=56c934bb@bz.bzflag.bz) |
16:00.28 |
*** join/#brlcad
MinuteElectron
(n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) |
16:31.57 |
*** join/#brlcad butti
(n=butti@e178090186.adsl.alicedsl.de) |
19:15.01 |
*** join/#brlcad yukonbob
(n=yukonbob@CPE001125477e9c-CM0011e6be27b1.cpe.net.cable.rogers.com) |
19:26.00 |
``Erik |
heh |
19:26.19 |
``Erik |
nice to know that the official release date of
7.10.4 was 2007-10-XX according to the news file :>
*duck* |
19:37.21 |
yukonbob |
for the record, liked w/ 7.11.0 that
errors/warnings went to stdout (err?) from shell where launched,
and not into mged... though there are considerations for Windows
(certainly) and MacOS (is =< OS9 supported?) potentially with
that... |
20:01.24 |
``Erik |
that's a bug, bob |
20:01.41 |
``Erik |
the output to stdout/stderr... it SHOULD be
captured |
20:13.18 |
brlcad |
it is kinda neat for some things, but yeah ..
that's entirely an unintentional bug atm |
20:13.31 |
``Erik |
hrmmmm |
20:13.32 |
yukonbob |
hrmm... feature, bug... ;) |
20:13.39 |
``Erik |
when're you uploading the 7.10.4 source
tarballs? |
20:13.42 |
brlcad |
and pre Mac OS X is only supported if someone
else wants to work on it, we're certainly not |
20:13.54 |
brlcad |
yeah |
20:14.03 |
brlcad |
have to bump the tag on two files |
20:14.04 |
*** join/#brlcad elite01_
(n=elite01@dslb-088-070-023-094.pools.arcor-ip.net) |
20:14.20 |
brlcad |
was uploading when ran into the two
'issues' |
20:14.25 |
``Erik |
doh |
20:14.52 |
``Erik |
what issues? |
20:15.11 |
brlcad |
date and .so |
20:15.54 |
brlcad |
yukonbob: there is a -f flag to not
automatically detach |
20:16.09 |
brlcad |
stays in the (-f)oreground |
20:16.32 |
yukonbob |
brlcad: ah -- there I go ;) |
20:18.34 |
``Erik |
you mean other than the mob of grizzled old
army workers showing up at your door with linolium knives looking
for a chunk?) |
20:19.16 |
yukonbob |
``Erik: heh :) |
20:19.51 |
brlcad |
yukonbob: it's a good idea, been talked about
in the past -- is kinda rather contrary to most open source *nix
software; you see it a lot more common with commercial *nix
software |
20:20.44 |
yukonbob |
Error: to many double negatives to be sure
what you're saying. |
20:21.01 |
yukonbob |
you mean it's normal in commercial *nix to
have things detach... |
20:21.02 |
yukonbob |
? |
20:21.03 |
``Erik |
the src/other directory is also more of a
proprietary-land type move :/ |
20:22.16 |
yukonbob |
*too many double... |
20:30.08 |
brlcad |
yukonbob: yeah, more normal in commercial apps
to detach automatically |
20:30.15 |
brlcad |
particularly for big gui apps |
20:31.07 |
CIA-27 |
BRL-CAD: 03erikgreenwald *
10brlcad/src/other/incrTcl/ (122 files in 17 dirs): Upgrade to
itcl/itk 3.3 |
20:36.21 |
yukonbob |
brlcad: just talking about reverse order of
"default" operations, but "default" depends on commerical vs.
non-comm. apparently, and "contrary", etc., etc... just making sure
I'm clear. |
20:37.19 |
yukonbob |
anyway, we're clear now :) |
20:37.48 |
yukonbob |
I think I got a new error w/ mged and large
dsp maps -- has that code been touched, or is this maybe only a
side-effect from some other code adjustments? |
20:42.31 |
*** join/#brlcad elite01_
(n=elite01@dslb-088-070-011-023.pools.arcor-ip.net) |
20:52.29 |
*** join/#brlcad elite01__
(n=elite01@dslc-082-082-075-121.pools.arcor-ip.net) |
21:24.20 |
yukonbob |
mged-*-bomb.log -- to where should this be
filed? |
21:24.51 |
``Erik |
um, it doesn't say in it? :D |
21:25.46 |
yukonbob |
nowhere obvious... |
21:25.57 |
``Erik |
well poo on brlcad, email it to him
:D |
21:26.02 |
yukonbob |
;) |
21:26.03 |
``Erik |
or paste it into, uh,
pastebin.bzflag.bz |
21:35.28 |
brlcad |
of course it doesn't say - it's just a crash
report -- the next step is bombardier which will give the option to
automatically send in the report |
21:39.06 |
CIA-27 |
BRL-CAD: 03erikgreenwald *
10brlcad/src/other/libpng/ (54 files in 2 dirs): upgrade to 1.2.22
("A new bug with decoding iCCP chunks was fixed.") |
21:39.29 |
``Erik |
tcl85b1 changed how the Var hashing is handled
and the latest incrtcl doesn't cope with that... but it's fixed in
CVS :/ |
21:39.47 |
``Erik |
to import tcl85, we'd have to use bits of incr
from cvs |
21:40.25 |
brlcad |
go for it |
21:40.34 |
``Erik |
blehhhhhhhh |
21:41.10 |
``Erik |
I have tcl and tk 85b1 building ok in my
checkout, but I'm not terribly keen on the notion of picking and
choosing bits from incr's head |
21:41.56 |
brlcad |
would updating to 85b1 in our checkout fix
it? |
21:42.00 |
``Erik |
(oddly enough, it seems to compile if you have
tcl85 installed on the system... I'm wondering if it was snagging
my 84 headers) |
21:42.07 |
``Erik |
no, that's what breaks it |
21:42.35 |
brlcad |
we have a6 in the repo still |
21:42.40 |
``Erik |
I have 85b1 in my checkout, I can commit and
we'd have it... but incr ... is behind |
21:43.17 |
brlcad |
how can it fail saying it wants a6 if there is
no a6? :) |
21:43.30 |
``Erik |
different issue |
21:44.03 |
brlcad |
for the most part, the tcl core guys are
keeping incrtcl up to date |
21:44.09 |
brlcad |
and none of them like incrtcl |
21:44.16 |
brlcad |
with a passion |
21:44.27 |
brlcad |
even though it's by far the most popular
extension |
21:44.46 |
brlcad |
so they keep it up to date, but aren't likely
to make a new release for it |
21:44.51 |
``Erik |
I put ${REINPLACE_CMD} 's/8\.5a6/8.5b1/'
${WRKSRC}/src/other/tcl/library/init.tcl in the post-patch bit for
the port and that fixes it |
21:45.21 |
brlcad |
heh |
21:45.35 |
``Erik |
but I'm off on straight BRL-CAD stuff now,
updating stuff in other... I updated incr to 3.3 earlier, that's
all good |
21:46.06 |
``Erik |
but when I upgrade to tcl8.5b1, the incr stuff
breaks looking for things like refCount in the Var typedef in
tclInt.h, which radically changed between 85a6 and b1 |
21:46.37 |
``Erik |
(Var's are now held inside of a hash table
instead of being part of a linked list) |
21:46.38 |
yukonbob |
http://pastebin.bzflag.bz/m234696fc |
21:48.33 |
``Erik |
erm, afaik, 7.10.4 requires tcl8.5 or
better... 8.4 won't cut the mustard, just the cheese |
21:53.42 |
yukonbob |
http://pastebin.bzflag.bz/m2121d14e |
21:56.05 |
yukonbob |
http://pastebin.bzflag.bz/m71d1814f |
21:57.00 |
yukonbob |
http://pastebin.bzflag.bz/meb2598c |
22:15.29 |
brlcad |
yukonbob: hmmm.. heh. that crash is inside
your 8.4 libtcl :) |
22:15.41 |
brlcad |
maybe it doesn't quite fully work ;) |
22:40.36 |
yukonbob |
brlcad: d'oh :) |
22:43.04 |
yukonbob |
am I reading it right that it's actually a
libpthread issue, called from NotifierThreadProc() in
libtcl? |
22:45.37 |
brlcad |
it's actually hard to say -- the stack doesn't
look right for the primary thread |
22:45.44 |
brlcad |
just happens to be the thread that
crashed |
22:46.04 |
yukonbob |
does brl-cad even take advantage of
multithreading in Tcl? |
22:46.12 |
brlcad |
i'll have to check on the gdb options to see
if I can change that crash report to include all of the running
threads |
22:46.35 |
brlcad |
not in the tcl side, but mged does do some
multithreading |
22:46.59 |
brlcad |
e.g. that detaching from the console is done
through a fork detachment |
22:47.12 |
yukonbob |
(way this happened was to load up
disappointment.dsp (which has always been a problem dsp for me) and
list it "l dspmap") |
22:47.33 |
brlcad |
ah, then I totally don't think that's the
right crash report trace |
22:47.38 |
brlcad |
just the current thread |
22:48.40 |
yukonbob |
with a diff't .g, I can "l" the object no
problem, so it's not strictly an 'l' condition (at least not for
every 'l' condition) |
22:49.20 |
brlcad |
can you repeat it? |
22:49.28 |
brlcad |
or was it random? |
22:50.29 |
CIA-27 |
BRL-CAD: 03brlcad 07STABLE *
10brlcad/src/other/tk/unix/Makefile.in: needs SHLIB_SUFFIX just
like tcl's Makefile.in so we can have/know the suffix independent
of the lib name |
22:51.21 |
yukonbob |
hrmm... not this time on first
try... |
22:52.05 |
yukonbob |
we'll keep this under observation... |
22:53.05 |
brlcad |
yeah, if you find the conditions to reproduce
it, let me know.. |
22:56.04 |
yukonbob |
rock 'n' roll... |
22:57.53 |
poolio |
evenin' |
22:58.11 |
yukonbob |
evening... |
22:58.22 |
CIA-27 |
BRL-CAD: 03brlcad 07STABLE * 10brlcad/NEWS:
released on the 24th |
22:59.48 |
poolio |
woohool |
22:59.56 |
poolio |
You guys should've waited two days and
released with Leopard |
23:00.44 |
brlcad |
we'll probably still be making binaries by
then for various platforms |
23:16.19 |
``Erik |
is it on sf yet? :D |
23:21.59 |
butti |
hello boys |
23:42.26 |
louipc |
good evening |