| 00:09.22 | brlcad | heh, a cube? :) |
| 00:09.44 | ``Erik | yes. arb8 representin' |
| 00:09.48 | ``Erik | needed a simple geometry to test |
| 00:09.51 | brlcad | how about an eto so you at least know if orientations preserve? |
| 00:09.59 | ``Erik | bah, orientations are for wussies |
| 00:10.03 | ``Erik | I'll do a ktank |
| 00:11.36 | ``Erik | well, ktank looks somewhat reasonable, but it turned it black somewhere in there |
| 00:11.54 | brlcad | it was ze germans! |
| 00:12.00 | starseeker | stealth ktank ;-) |
| 00:12.20 | ``Erik | blitzkrapp |
| 00:13.42 | ``Erik | http://brlcad.org/~erik/stealthtank.png |
| 00:13.53 | ``Erik | g-egg, egg2dxf, dxf-g, rt |
| 00:19.04 | starseeker | cool |
| 00:36.51 | brlcad | neat |
| 00:45.06 | CIA-85 | BRL-CAD: 03erikgreenwald * r37734 10/isst/trunk/src/isst.h: minor default/minimum size tweaks. |
| 01:24.09 | jack | ze eevil germanz |
| 01:24.11 | jack | hehe |
| 01:25.25 | jack | ``Erik: licenses....shrug |
| 01:25.31 | jack | i'm only a packager |
| 01:26.03 | jack | so i don't differ too much besides "proprietary" and "opensourced somehow" |
| 01:29.00 | CIA-85 | BRL-CAD: 03brlcad * r37735 10/brlcad/trunk/src/mged/polyif.c: ws consistency indent style cleanup |
| 01:31.47 | CIA-85 | BRL-CAD: 03brlcad * r37736 10/brlcad/trunk/src/mged/mged.h: quell warnings about index/pipe/free shadow |
| 01:38.10 | ``Erik | obviously ya don't package for debian *cough* :D |
| 02:40.39 | *** join/#brlcad Nohla (~jesica@201.255.236.19) | |
| 03:07.44 | brlcad | ooooof, finally finished! |
| 04:45.18 | CIA-85 | BRL-CAD: 03brlcad * r37737 10/brlcad/trunk/src/mged/points/points_scan.l: flex uses isatty() without including a header that declares it. quell warningage. |
| 04:45.54 | CIA-85 | BRL-CAD: 03brlcad * r37738 10/brlcad/trunk/src/mged/points/process.h: quell other compilation warnings for yacc defines that are not properly being tested, assumed to be defined when they are not. |
| 04:56.03 | CIA-85 | BRL-CAD: 03brlcad * r37739 10/brlcad/trunk/include/common.h: might need sys/types.h for ptrdiff_t so conditionally include it too in the ssize_t section |
| 05:06.29 | *** join/#brlcad Phurl (~mdupont@ip-81-210-228-126.unitymediagroup.de) | |
| 05:28.43 | brlcad | *whoosh* |
| 05:29.40 | CIA-85 | BRL-CAD: 03brlcad * r37740 10/brlcad/trunk/src/mged/ (79 files): (log message trimmed) |
| 05:29.40 | CIA-85 | BRL-CAD: Kaboooom. massive consistency/formatting/ws/indent/comment/deadcode clean-up. |
| 05:29.40 | CIA-85 | BRL-CAD: should be absolutely no logic changes introduced, but when you changes 15k lines |
| 05:29.40 | CIA-85 | BRL-CAD: of code.. damn if I'd swear to it. inadvertent spacing after commas is the |
| 05:29.40 | CIA-85 | BRL-CAD: likely problem case though no further suspects were identified after fixing more |
| 05:29.41 | CIA-85 | BRL-CAD: than 50 such errors. this cleanup took a long time (better part of a day) but |
| 05:29.41 | CIA-85 | BRL-CAD: cleans up the entire mged dir with improved readability, maintainability, and |
| 05:42.44 | jack | :) |
| 05:43.04 | jack | brlcad: has mged evolved much in the past few months? |
| 05:43.26 | jack | last time i built it you said it's pretty immature |
| 05:43.54 | brlcad | I don't beleive I've ever said it was immature |
| 05:43.57 | brlcad | it's very mature |
| 05:44.25 | brlcad | but it does have plenty of room for improvmenet and many features it doesn't implement |
| 05:44.30 | jack | something like that ;) you recommended to disable it, back then |
| 05:44.40 | brlcad | you can't disable mged |
| 05:44.45 | brlcad | so you misunderstood something |
| 05:44.53 | jack | apparently :) |
| 05:45.35 | brlcad | maybe to disable rtgl mode |
| 05:45.46 | jack | yup! that was it |
| 05:46.21 | brlcad | rtgl is just one of about a half-dozen possible render modes that mged can use |
| 05:46.33 | jack | :) |
| 05:46.34 | jack | ok |
| 05:47.29 | brlcad | if you don't know how to use mged, you only need one mode -- the default X11 mode |
| 05:47.50 | brlcad | till you go through the tutorials, start to get a grasp on the basic commands, etc |
| 05:48.00 | jack | yeah |
| 05:48.17 | brlcad | that's at least a week's effort in itself and you'd still be considered an infant modeler |
| 05:49.24 | jack | i doubt i could model pretty infants... |
| 05:49.34 | jack | but yeah, of course you're right |
| 05:51.19 | CIA-85 | BRL-CAD: 03brlcad * r37741 10/brlcad/trunk/src/mged/ (Makefile.am concat.c): remove the empty concat.c file. all it did was add three unused globals, wasting a tiny bit of memory. |
| 05:53.21 | CIA-85 | BRL-CAD: 03brlcad * r37742 10/brlcad/trunk/src/mged/ (Makefile.am utility2.c vdraw.c): also remove the empty vdraw.c and utility2.c files. looks like their guts migrated to libged. |
| 05:57.59 | *** join/#brlcad Ralith (~ralith@216.162.199.202) | |
| 06:11.34 | *** join/#brlcad maddx (~ron@m208-197.dsl.rawbw.com) | |
| 06:17.56 | CIA-85 | BRL-CAD: 03brlcad * r37743 10/brlcad/trunk/src/libbu/parse.c: |
| 06:17.56 | CIA-85 | BRL-CAD: begin the conversion of the undocumented 'i' chaining structparse keyword to a |
| 06:17.56 | CIA-85 | BRL-CAD: '%p' pointer argument. the idea being that the tables are linked together via |
| 06:17.56 | CIA-85 | BRL-CAD: the pointer address of the other table. still a pending concept so don't get |
| 06:17.56 | CIA-85 | BRL-CAD: all annoying with deprecation notices just yet (not that they're strictly |
| 06:17.56 | CIA-85 | BRL-CAD: required either as 'i' wasn't publicly documented behavior). |
| 07:07.31 | *** join/#brlcad Ralith (~ralith@216.162.199.202) | |
| 08:41.32 | *** part/#brlcad maddx (~ron@m208-197.dsl.rawbw.com) | |
| 08:43.46 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:50.22 | d_rossberg | as already mentioned: the %zu equivalent in msvc is %Iu |
| 08:50.57 | d_rossberg | if you want to get a smart detection you have to use C++ |
| 08:54.24 | d_rossberg | %zu only means: 32 bit on 32-bit-machines and 64 bit on 64-bit-machines (which isn't really smart) |
| 09:11.03 | jack | isn't there a gcc for windows? |
| 09:11.21 | jack | i'd never use msvc unless i really, really have to |
| 09:30.24 | d_rossberg | then how do you develop? gcc is only good for compiling but not for developing |
| 09:45.38 | *** join/#brlcad Nohla (~jesica@201.255.236.19) | |
| 10:15.39 | jack | d_rossberg: true of course |
| 10:15.52 | jack | but there are so many decent editors |
| 11:49.20 | Ralith | emacs runs just fine on windows! |
| 11:49.23 | Ralith | ^^ |
| 12:20.42 | ``Erik | jack: look at msys and/or cygwin? |
| 13:22.57 | Ralith | is mingw actively maintained? |
| 13:23.33 | Ralith | every time I look at it the release dates are distressingly old and the tool version numbers older. |
| 13:36.18 | ``Erik | I think msys deprecated mingw32 |
| 13:46.49 | Ralith | I thought msys operated on top of mingw O.o |
| 13:49.33 | ``Erik | might... that's all that windows stuff anyways (gcc is just dandy for developing, it's windows that causes issues O:-) ) |
| 13:50.08 | Ralith | shame it can't be just left at that. |
| 13:50.13 | Ralith | sleeps |
| 13:51.34 | *** join/#brlcad roberthl (~robert@2001:ba8:1f1:f03d::2) | |
| 13:51.34 | *** join/#brlcad roberthl (~robert@silentflame/member/roberthl) | |
| 13:55.15 | brlcad | d_rossberg: I presume from the docs that %llu works for you on Windows? you still compiling with vc6? |
| 13:57.53 | ``Erik | huh, the 'stupid' button on my dash also turns off the antilock brakes, neat |
| 13:59.10 | ``Erik | brlcad: src/mged/concat.c seems to be missing, is that a forgotten svn add, or a Makefile.am oops? |
| 14:10.05 | ``Erik | bah, n/m, auto* forgot to regenerate a file |
| 14:13.49 | d_rossberg | brlcad: BRL-CAD can not be compiled with vc6 any more; i'm working with msvc9 (Visual Studio 2008) |
| 14:14.42 | d_rossberg | %llu is ok for windows (means fixed 64 bit size integer) |
| 14:15.31 | d_rossberg | i.e. it isn't applicable for win32 size_t |
| 14:16.48 | *** join/#brlcad parigaudi (~quassel@pd95b7f5e.dip0.t-ipconnect.de) | |
| 14:20.10 | d_rossberg | whould this work?: #define %zu %Iu |
| 14:26.02 | ``Erik | doesn't think % is legal as a cpp name? |
| 14:26.41 | ``Erik | I also don't thinkk macro's evaluate inside of strings :/ |
| 14:30.19 | d_rossberg | i was afraid of this |
| 14:30.55 | ``Erik | the least painful way might be something like |
| 14:31.37 | ``Erik | #if ... ^M #define thisishowweprintnativesize "%zu" ... printf("some " thisishowweprintnativesize " items\n"); |
| 14:31.47 | ``Erik | (which is pretty painful and ugly) |
| 14:32.16 | ``Erik | (or use %p and stop using size_t/ssize_t for non-pointer stuff) |
| 14:40.42 | d_rossberg | is a macro from C99's inttypes.h applicable? |
| 14:41.21 | d_rossberg | this macro could then defined in config_win.h too |
| 14:43.57 | d_rossberg | e.g. PRIuPTR |
| 14:49.02 | ``Erik | thinks BRL-CAD is still targetting C89 |
| 14:52.00 | d_rossberg | c99 has no priority at microsoft, they are focusing on c++0x |
| 15:05.49 | ``Erik | I thought they were focusing on c#.net O:-) |
| 15:07.46 | d_rossberg | :) |
| 15:23.32 | starseeker | sigh. https://connect.microsoft.com/VisualStudio/feedback/details/526116/c99-support |
| 15:24.02 | starseeker | what about the idea of making bu_log smarter and using that everywhere? |
| 15:25.07 | ``Erik | it'd need shtuff to support printing to memory (sprintf style) as well as selecting streams (fprintf style) |
| 15:25.24 | starseeker | nods - I know |
| 15:26.12 | starseeker | 10:44 < brlcad> "smart bu_printf" is bu_log |
| 15:26.52 | ``Erik | well, bu_log() will try to use stderr, not stdout |
| 15:27.53 | ``Erik | ponders 's/fprintf(stderr,/bu_log(/' |
| 15:28.02 | starseeker | ``Erik: the alternative of not using size_t for non-pointer stuff would essentially force us to the "safe" 32 bit sizes for things, wouldn't it? |
| 15:28.25 | ``Erik | or safe 64b, or safe 'int' |
| 15:28.50 | ``Erik | some day, int will be 64b naturally, int was 16b on a lot of machines for a long time *shrug* |
| 15:29.23 | starseeker | correct me if I'm wrong, but it seems like all roads lead to major work here |
| 15:29.49 | ``Erik | probably :D |
| 15:30.49 | ``Erik | stealing a BSD licensed vprintf set, shoving bu_ ont he front of it all and doing massive search/replace in the code might be doable, but then we're maintaining our own stdio functionality (even more than we do now) |
| 15:31.33 | starseeker | sure, but how much maintainance would that be beyond the initial effort? |
| 15:32.06 | ``Erik | probably not much, vprintf is reasonably old and well used... |
| 15:32.28 | starseeker | nods - that's what I was hoping |
| 15:32.41 | ``Erik | hasn't written too many programs that don't use vprintf somewhere *shrug* :D |
| 15:32.43 | starseeker | that would mean an up front effort and we're "done" |
| 15:35.05 | ``Erik | I d'no, one of the size_t things I actually looked at was summing the number of polygons in a primitive... 2|4 billion polygons in a single primitive is... a lot :) plain old int might be good enough? *shrug* |
| 15:35.26 | ``Erik | because, y'know, 640KB of ram should be enough for anyone :/ |
| 15:35.35 | starseeker | LOL |
| 15:35.58 | starseeker | you just precisely defined both sides of the argument |
| 15:37.15 | ``Erik | (amusingly, the context of billy's statement actually paints ibm as the visionless idjit... they wanted to reserve bunchs of high memory for hw access) |
| 15:37.33 | starseeker | yeah, that's been debunked for years |
| 15:38.15 | starseeker | there's always the classic "there is maybe a market for five computers worldwide" quote, or something like that... |
| 15:38.19 | ``Erik | yeh, I just don't wanna invoke the memory without noting context, lest someone who's not familiar go off with linux style zealotism again |
| 15:38.26 | ``Erik | yeh, that was dec, right? |
| 15:38.46 | ``Erik | oh, no, ibm again |
| 15:39.13 | starseeker | suspects it's not entirely accidental that it was IBM who is responsible for the ubiquity of x86... |
| 15:40.00 | ``Erik | ibm was the only company that had the name to make the notion of a 'personal computer' a business reality... they just happened to choose the 8088 fairly arbitrarily |
| 15:40.12 | ``Erik | (yeh, 8088, not 8086) |
| 15:40.33 | ``Erik | intel may've been the only one with the production capabilities they were looking for at the time :) |
| 15:40.43 | starseeker | winces - bad time for an arbitrary decision, if that was what it was... |
| 15:40.44 | starseeker | yeah |
| 15:42.10 | starseeker | ``Erik: well, my vote, if it matters, would be to snarf the code, wrap it in bu_, and do the search/replace... |
| 15:43.24 | ``Erik | doesn't want a vote, is focusing on unrelated parts at the moment *shrug* just gonna provide ideas :) |
| 15:44.04 | ``Erik | maybe brlcad will have an opinion... this may even be one to turn into a 'card' item |
| 15:44.55 | ``Erik | maybe we should re-write it in java, so an int is 32b, damnit, no matter what hw you have O.o |
| 15:45.04 | starseeker | hehe |
| 15:45.16 | starseeker | or we could switch to C++ compiling for everything... |
| 15:45.24 | ``Erik | hm |
| 15:45.25 | starseeker | waits for the horrible scream... |
| 15:45.32 | ``Erik | start a compile, come back in a week to see if it's done? |
| 15:47.11 | starseeker | gets ready to head in |
| 15:55.27 | brlcad | gets ready to head in too |
| 15:56.24 | brlcad | d_rossberg: okay, good to know (and glad to hear it! .. no more vc6 pains.. ) :) |
| 15:57.27 | brlcad | ``Erik: we should be c89 compliant now, so we can move on to c99isms if we want |
| 15:59.06 | brlcad | the bu_vls printing could also be enhanced if we were to add %z support, so we'd have streams and strings .. |
| 15:59.22 | brlcad | stderr is an implementation flaw/limitation of bu_log that I'm hoping we rectify soon (by allowing a stream to be registered or use callbacks) |
| 15:59.58 | brlcad | we already have vprintf equivalence routines |
| 16:05.44 | ``Erik | brlcad: going to make it up for lunch? |
| 16:09.59 | brlcad | possibly, where? |
| 16:10.04 | ``Erik | dunno yet |
| 16:10.12 | brlcad | starseeker: are there docs posted on the coil primitive? |
| 16:42.29 | starseeker | brlcad: not posted, no |
| 16:42.31 | starseeker | there's a man page |
| 16:43.16 | starseeker | never did finish the article - was trying to figure out how to allow an overall length specification, and that proved difficult - then other things trumped it |
| 16:44.02 | starseeker | (I assume you mean the coil tool? it uses pipe for the primitive) |
| 16:46.06 | starseeker | also, it developed a quirk where it doesn't want to do different spacing regions in one coil anymore - I haven't tracked that down yet |
| 16:46.19 | starseeker | rides |
| 17:32.52 | *** join/#brlcad mac- (~mac@sunrise.pi.net.pl) | |
| 18:45.33 | *** join/#brlcad parigaudi (~quassel@pd95b7f5e.dip0.t-ipconnect.de) | |
| 19:19.31 | jack | ``Erik: i don't have a windows box ;) but yeah, i know cygwin is pretty cool |
| 19:20.35 | ``Erik | heh, ./configure CFLAGS=-mno-cygwin O.o :) |
| 19:21.10 | ``Erik | (that'd probably fail horrible on BRL-CAD, but it's an effective way to get unencumbered binaries on winderz without shelling out for studio) |
| 20:14.59 | jack | haha |
| 20:15.28 | jack | no clue about windows-specific build issues, luckily |
| 20:17.26 | jack | cygwin is for windows what fink is for macos...only difference: we don't need to patch that much since the underlying OS is a sane almost-unix |
| 20:25.10 | ``Erik | favors macports to fink these days |
| 20:49.35 | *** join/#brlcad PrezKennedy (Matthew@whitecalf.net) | |
| 21:10.27 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 21:10.40 | CIA-85 | BRL-CAD: 03starseeker * r37744 10/brlcad/trunk/src/shapes/coil.c: |
| 21:10.40 | CIA-85 | BRL-CAD: Ah hah. Coil tool problem with -S inputs was due to the introduction of the |
| 21:10.40 | CIA-85 | BRL-CAD: left hand winding ability - that ability requires a variable be set that wasn't |
| 21:10.40 | CIA-85 | BRL-CAD: being set by the five inputs to -S, so make it 6 settings - the -S option really |
| 21:10.40 | CIA-85 | BRL-CAD: should be rethought, since you can't currently mix left and right hand windings, |
| 21:10.41 | CIA-85 | BRL-CAD: but at least it will work now. |
| 21:12.44 | CIA-85 | BRL-CAD: 03starseeker * r37745 10/brlcad/trunk/doc/docbook/system/man1/en/coil.xml: Update coil man page with essential changes to -S option. |
| 21:14.20 | CIA-85 | BRL-CAD: 03starseeker * r37746 10/brlcad/trunk/NEWS: Note fixing of coil -S option. |
| 21:34.46 | starseeker | while I'm thinking of it, time to undo one embarassing coding misadventure... |
| 21:37.07 | CIA-85 | BRL-CAD: 03starseeker * r37747 10/brlcad/trunk/src/libged/tire.c: Don't need to truncate and then print manually - that's what bu_vls_sprintf is for. |
| 21:40.01 | starseeker | 166 lines bite the dust :-) |
| 21:40.48 | brlcad | heh |
| 21:48.34 | CIA-85 | BRL-CAD: 03erikgreenwald * r37748 10/brlcad/trunk/ (3 files in 2 dirs): begin stubbing libgcv marching cubes variant |
| 21:53.21 | CIA-85 | BRL-CAD: 03brlcad * r37749 10/brlcad/trunk/src/libbu/vls.c: untested, but add support for %ll long long's. fix what seems to be a bug with short ints matching the field length bitcode. |
| 22:33.34 | CIA-85 | BRL-CAD: 03brlcad * r37750 10/brlcad/trunk/src/libbu/vls.c: similarly, support %hh 'short shorts' including the assumption that the argument is an int. separate out %p from %d/%x as that assumption is flawed on 64-bit. add support for %i. |
| 22:36.28 | CIA-85 | BRL-CAD: 03brlcad * r37751 10/brlcad/trunk/src/libbu/vls.c: %n support, assume we can pass through as void*'s |
| 22:50.22 | CIA-85 | BRL-CAD: 03brlcad * r37752 10/brlcad/trunk/src/libbu/vls.c: expand out support for unsigned types separate from the signed types |
| 22:53.19 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 22:57.26 | CIA-85 | BRL-CAD: 03brlcad * r37753 10/brlcad/trunk/src/libbu/vls.c: expand support for %j intmax_t, %t ptrdiff, and %z size_t specifiers. |
| 23:03.00 | CIA-85 | BRL-CAD: 03brlcad * r37754 10/brlcad/trunk/src/libbu/vls.c: same size_t, ptrdiff_t, intmax_t support for signed types, reduce some of the duplication. |
| 23:03.26 | brlcad | that should add %z support to all our our bu logging and string routines |
| 23:29.24 | ``Erik | oh that poor vls.c file |
