| 00:08.07 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 01:08.40 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 02:09.08 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 02:37.54 | kanzure | brlcad: i have msvcr100.dll from some other projects, but where would brlcad users get it from? |
| 03:09.32 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 03:46.44 | kanzure | oh i see. if i manually load msvcr100.dll and then tcl.dll into 64-bit python then importing libbu.dll is fine. |
| 03:47.27 | kanzure | i suppose i need to find a way to automate this. this seems like a special case on windows? why don't i have to do this on linux? |
| 04:10.02 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 05:10.23 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 06:10.51 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 06:26.35 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 07:11.16 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 07:25.56 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) | |
| 08:11.50 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 08:59.44 | Notify | 03BRL-CAD:d_rossberg * 58152 brlcad/trunk/src/libdm/CMakeLists.txt: the BRLCAD_ prefix was removed from the checking macros |
| 09:43.01 | Notify | 03BRL-CAD Wiki:Yogeshkulkarni * 0 /wiki/User:Yogeshkulkarni: |
| 10:35.51 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 11:10.21 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 14:15.58 | *** join/#brlcad merzo (~merzo@125-129-132-95.pool.ukrtel.net) | |
| 14:17.34 | *** join/#brlcad Gaganjyot (~gagan@106.192.44.227) | |
| 16:03.21 | *** join/#brlcad merzo (~merzo@125-129-132-95.pool.ukrtel.net) | |
| 16:36.05 | *** join/#brlcad Gaganjyot (~gagan@1.38.23.228) | |
| 17:09.18 | Notify | 03BRL-CAD:carlmoore * 58153 brlcad/trunk/src/shapes/window.c: various changes: new h? (old 'h' is now 'H') |
| 19:32.12 | *** join/#brlcad merzo (~merzo@125-129-132-95.pool.ukrtel.net) | |
| 19:37.08 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 19:42.37 | *** join/#brlcad caen23 (~caen23@92.83.186.251) | |
| 19:57.13 | starseeker | hah, interesting: http://hdl.handle.net/10380/3262 |
| 20:31.11 | Notify | 03BRL-CAD:carlmoore * 58154 brlcad/trunk/src/shapes/window_frame.c: similar changes for window_frame.c |
| 20:45.23 | starseeker | something about r57861 seems to have weakened bu_brlcad_root - if I run btclsh outside of the build directory without installing it's not finding the right path anymore |
| 20:45.39 | starseeker | or rather, bu_brlcad_root within btclsh isn't |
| 21:42.36 | Notify | 03BRL-CAD:carlmoore * 58155 brlcad/trunk/src/shapes/wire.c: remove some unneeded braces, and put together an if-(then)-else |
| 23:28.31 | Notify | 03BRL-CAD:brlcad * 58156 brlcad/trunk/src/libbu/progname.c: cliff encountered a bug that I even thought about when rewriting all of this but forgot to revisit. if you call bu_getprogname() even once, it will wipe out a full-path setting and bu_argv0_full_path() will only work if the progname is in the PATH. this fix stashes the result in a local buffer before returning (in leu of creating another static global). |
| 23:56.04 | Notify | 03BRL-CAD:brlcad * 58157 brlcad/trunk/src/libbu/progname.c: another issue, unclear whether intentional or not but if we have program_invocation_name, only use it if the bu_progname buffer doesn't already have a full path recorded (from bu_setprogname()) |