| 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 |