| 00:08.44 | brlcad | looks like the optimizer does do much better, but there is still about a 5% slowdown to use vars |
| 00:09.58 | brlcad | 4.1% to be more precise on this particular configuration (linux, ia64, gcc4.1.2) |
| 00:10.29 | brlcad | consistent enough to be significant, so it looks like that change is a no-go |
| 00:13.47 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 00:14.03 | brlcad | starseeker_: the changelog is moderately useless as-is .. how about just including all changes since r30789 |
| 00:19.34 | starseeker_ | ok |
| 00:20.03 | brlcad | maybe up to where you branched, then your branch commits |
| 00:20.35 | starseeker_ | sure, not a problem |
| 00:21.02 | brlcad | better to have too much than too little for it to be useful |
| 00:21.09 | starseeker_ | :-) |
| 00:21.45 | brlcad | i know some projects just include their entire project changelog .. that'd be hilarious |
| 00:22.17 | starseeker_ | hehe - we'd probably noticeably increase the file size of the tarball |
| 00:22.37 | brlcad | also, don't know if there is an option -- see if it can be in reverse chrono order |
| 00:22.47 | starseeker_ | mans svn2cl |
| 00:23.33 | brlcad | so newest is on top |
| 00:23.44 | brlcad | if not, no biggie |
| 00:23.46 | starseeker_ | Hmm, maybe reverse the r args? |
| 00:23.51 | starseeker_ | tries |
| 00:24.08 | brlcad | good idea :) |
| 00:32.37 | starseeker_ | bingo |
| 00:32.45 | starseeker_ | now the other half... |
| 00:37.07 | CIA-23 | BRL-CAD: 03starseeker * r32269 10/brlcad/branches/pre-7-12-6/ChangeLog: Add more informative version of Changelog |
| 00:37.13 | starseeker_ | brlcad: OK, give that a look-see |
| 00:39.59 | starseeker_ | wonders if parse_file in if_remote.c could use a little regex love |
| 00:47.09 | CIA-23 | BRL-CAD: 03brlcad * r32270 10/brlcad/trunk/TODO: implement mged globbing so that it matches tcl's globbing interface (so glob_compat_mode can die). there's already all the pieces in place that would need this, though they don't presently behave. |
| 00:47.56 | brlcad | starseeker_: more than likely, it's a bu_ call that is off-by-one |
| 00:48.02 | starseeker_ | brlcad: my money is on it getting broken in r30030 |
| 00:50.09 | starseeker_ | looking at the history, it was changed from strcpy -> strncpy -> bu_strcpy |
| 00:50.35 | brlcad | it's almost guaranteed related to that change |
| 00:50.46 | starseeker_ | should it have been bu_strncpy? |
| 00:51.16 | starseeker_ | er bu_strlcpy |
| 00:51.21 | starseeker_ | was was was used |
| 00:51.37 | starseeker_ | not bu_strcpy |
| 00:51.59 | starseeker_ | can't test any changes to that locally, but at least it's a place to look |
| 00:52.07 | starseeker_ | should we try to get that fix into 7.12.6? |
| 00:52.34 | brlcad | sure |
| 00:53.11 | starseeker_ | <grin> OK, what's one more? ;-) I'll take a stab at it tomorrow. |
| 00:53.57 | brlcad | if you can't find it, then forget it |
| 00:54.12 | starseeker_ | k |
| 00:54.20 | starseeker_ | would be kind of a nice turnaround though :-) |
| 00:54.50 | starseeker_ | is thinking a few judicious bu_log outputs should tell the tale |
| 00:55.06 | starseeker_ | Is there a strncpy analog in libbu? |
| 00:55.33 | brlcad | bu_strlcpy |
| 00:55.39 | starseeker_ | heh |
| 00:55.55 | starseeker_ | OK. |
| 00:56.15 | brlcad | reading it now -- it's probably in this: http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libfb/if_remote.c?r1=30030&r2=30029&pathrev=30030 |
| 00:56.35 | starseeker_ | though so too |
| 00:56.59 | starseeker_ | line 208 looks most relevant |
| 00:57.22 | starseeker_ | or possibly 217 |
| 01:00.20 | starseeker_ | Wait - after 217, the prefix[colon-rest] = '\0'; was removed - was that intentional? |
| 01:00.47 | starseeker_ | bu_strlcpy takes care of the \0? |
| 01:01.59 | brlcad | strlcpy guarantees a null-termination |
| 01:02.12 | brlcad | that was part of why that change was made across the board |
| 01:02.19 | brlcad | hundreds of calls |
| 01:08.55 | starseeker_ | How come line 208 didn't have one before the change? |
| 01:10.52 | starseeker_ | itches to replace this with regex ;-) |
| 01:19.17 | brlcad | that's just part of the nature of using strcpy, strcat, strncpy, strncat |
| 01:19.43 | brlcad | some code would null-terminate, some wouldn't (relying on the null in the string being copied) |
| 01:19.56 | brlcad | other issues happen if you hit the end of a buffer |
| 01:20.15 | brlcad | it's a common way to have a security flaw |
| 01:20.43 | brlcad | the semantics on strlcpy() are much better, hence the change |
| 01:21.08 | brlcad | but it's behavior isn't 100% identical of course (otherwise what would be the point), so you have to review every use case by case |
| 01:21.52 | brlcad | which was done.. took several painstaking days of reviewing, but some slipped through |
| 01:26.16 | CIA-23 | BRL-CAD: 03brlcad * r32271 10/brlcad/trunk/src/libfb/if_remote.c: pointer arithmetic string length fun. strlcpy copy size includes the null terminator, so have to +1 |
| 01:26.22 | brlcad | that should be it, give it a test |
| 01:26.33 | starseeker_ | will do - thanks! |
| 01:26.43 | starseeker_ | is impressed :-) |
| 01:27.03 | brlcad | missed it because the arith operator was smashed in .. was reading it as a var |
| 01:27.15 | starseeker_ | Ah |
| 01:29.36 | starseeker_ | would have been mucking around with bu_log for half an hour ;-) |
| 01:30.19 | brlcad | nods |
| 01:30.25 | brlcad | you'll have plenty of other opportunities ;) |
| 01:30.35 | starseeker_ | <grin> |
| 01:32.38 | brlcad | fwiw, what's going on there is that it splits the string based on ':' using strchr() -- strctr returns a char* to the place in the string where the : is at, so if you subtrace the colon string from the input string, you get the length of the input up to the : since it's linear memory |
| 01:34.04 | starseeker_ | nods |
| 01:34.39 | brlcad | so e.g. input is "hello:tommy" at address 0x00000001, strchr will return char* to address 0x00000006 (":tommy") .. subtract the two pointers and you get 5 .. |
| 01:34.53 | brlcad | which is wrong for strlcpy since it will copy n-1 characters and then null-terminate the result |
| 01:34.59 | brlcad | so it copies 4 and null terminates |
| 01:35.07 | brlcad | hell |
| 01:35.23 | starseeker_ | ? |
| 01:35.28 | brlcad | "hell" :) |
| 01:35.35 | starseeker_ | Ah :-) |
| 01:35.46 | starseeker_ | thought brlcad was cussing out a report or a bug |
| 01:36.01 | brlcad | returns you to your regularly scheduled release programming |
| 01:36.26 | starseeker_ | and as a result, all remote connections fail (and even ones where localhost:0 is supplied, which should be a test case) |
| 01:36.55 | starseeker_ | returns brlcad to his regularly scheduled stressful stuff |
| 01:36.57 | brlcad | i should review that mega-diff yet one more time to see if there are any more smashed-variables that I glossed over as a var |
| 01:37.10 | starseeker_ | <wince> |
| 01:39.09 | starseeker_ | heh - I guess I have been CIA spamming of late. Well, that should be pretty much done now |
| 01:39.24 | yukonbob | hello, cadheads :) |
| 01:39.33 | starseeker_ | heya yukonbob |
| 01:39.38 | brlcad | howdy yukonbob |
| 01:39.56 | yukonbob | what's shaking, friendly neighbourhood h4x0rs? |
| 01:40.10 | starseeker_ | on the brink of release :-) :-) |
| 01:40.23 | yukonbob | mmmm... release |
| 01:40.44 | yukonbob | needs to get his completely "unstable" system stable-ish -- I've been away too long |
| 01:40.58 | yukonbob | *sniff* :~( |
| 01:41.01 | brlcad | yukonbob: and not coding for too long ;) |
| 01:41.17 | brlcad | code code type type |
| 01:41.53 | starseeker_ | dem bugs they need afixin |
| 01:41.58 | yukonbob | gah -- you know it -- I think I've contributed less than 20lines total (of code, not docs), but I'd sure love to really get into it... |
| 01:42.26 | yukonbob | oh |
| 01:42.29 | yukonbob | speaking of which |
| 01:42.34 | brlcad | starseeker_: so the last change is the 'binary' command |
| 01:42.44 | brlcad | i need to rename it once again |
| 01:42.47 | yukonbob | have either of you (or any other listeners) heard of the "reprap" machine |
| 01:42.47 | yukonbob | ? |
| 01:42.52 | starseeker_ | binary command... |
| 01:42.55 | starseeker_ | greps logs |
| 01:43.03 | starseeker_ | oh, a new change? |
| 01:43.04 | brlcad | yukonbob: absolutely |
| 01:43.10 | yukonbob | ...nice |
| 01:43.11 | brlcad | a few of their guys are/were in here from time to time |
| 01:43.25 | yukonbob | wants to build one, and set it up w/ brlcad |
| 01:43.32 | brlcad | you should! |
| 01:43.44 | brlcad | wants an m35 |
| 01:43.58 | brlcad | starseeker_: it was 'dbbinary' |
| 01:44.03 | starseeker_ | ah |
| 01:44.04 | yukonbob | our .stl support is good? |
| 01:44.05 | brlcad | related to the _DENSITIES |
| 01:44.19 | starseeker_ | brlcad: It needs to be dbbinary again? |
| 01:44.20 | brlcad | yukonbob: pretty good |
| 01:44.20 | yukonbob | believes it takes .stl |
| 01:44.24 | brlcad | it's an utterly horrible format |
| 01:44.36 | brlcad | starseeker_: I hate 'dbbinary' as a name |
| 01:44.55 | brlcad | it's so ambiguous |
| 01:44.55 | starseeker_ | ah |
| 01:45.05 | brlcad | and misleading |
| 01:45.25 | brlcad | is it supposed to make my .g binary? I thought it was already binary |
| 01:45.34 | starseeker_ | nods |
| 01:45.39 | jonored | grins, and needs to get started on his machine. |
| 01:46.16 | brlcad | and what does it have to do with dbconcat? if dbconcat concatenates a db, then surely dbbinary binarifies a db |
| 01:46.50 | starseeker_ | makes sense. What's the proposed replacement? |
| 01:47.06 | brlcad | 'binary' was merely a compromise, it was familiar with the old and removed the db confusion |
| 01:47.11 | brlcad | but that conflicts with tcl |
| 01:47.30 | starseeker_ | mmm |
| 01:47.44 | jonored | yukonbob: I've actually been doing a bit towards just going from a .g to g-code for a reprap... |
| 01:48.34 | brlcad | so i'm thinking of changing it either back to dbbinary (ugh) or to either a generalized 'import' or 'data' command |
| 01:48.51 | brlcad | jonored: that would be awesome |
| 01:49.00 | brlcad | a g-gcode converter |
| 01:49.48 | jonored | not nearly enough to be ready, and currently messing around with perl because I've been having trouble getting stuff to compile cleanly, but trying. |
| 01:50.16 | brlcad | jonored: try the STABLE branch instead of head -- that should compile fine |
| 01:50.42 | brlcad | or post the compilation problems -- they should be fixed |
| 01:50.47 | yukonbob | jonored: nice -- are you strictly playing w/ software, or do you have the hardware, too? |
| 01:50.47 | brlcad | s/be/get/ |
| 01:51.55 | brlcad | starseeker_: thoughts? |
| 01:51.58 | brlcad | (or others) |
| 01:52.28 | starseeker_ | importdata ? |
| 01:52.38 | jonored | brlcad: I'm not convinced that any of them weren't from grabbing an ebuild from gentoo's scientific overlay, and messing with it a bit to try to get it to build a newer version... |
| 01:52.40 | yukonbob | brlcad -- what is the function of this to-be-named command? |
| 01:52.42 | starseeker_ | I agree dbbinary isn't so hot |
| 01:53.19 | jonored | Especially because the weird thing with configure eating my processor for an hour or two didn't happen when I did it manually... |
| 01:53.21 | brlcad | yukonbob: it's a command that is presently used to marshall files into and out of your .g |
| 01:53.36 | brlcad | e.g. you can use it to shove an msword .doc into the .g |
| 01:53.47 | starseeker_ | <wince> |
| 01:53.49 | brlcad | or more usefully, use it to import terrain data or texture files as objects |
| 01:54.02 | brlcad | that can then be used without needing the external files |
| 01:54.02 | yukonbob | that's one place to shove a .doc |
| 01:54.34 | brlcad | and in the case of the g_qa command, it is used to import a material properties table (text file) |
| 01:54.46 | starseeker_ | wonders when someone will stuff a pdf documenting the model into the model, then request a command to open it |
| 01:55.02 | jonored | yukonbob: I haven't quite gotten to the point of getting the hardware on an undergraduate's budget yet ;) |
| 01:55.12 | brlcad | why not? :) |
| 01:55.36 | yukonbob | give up beer for a month... |
| 01:56.51 | jonored | bah, I don't drink much, certainly not beer... |
| 01:57.01 | starseeker_ | hmm - well, the name is right now |
| 01:57.10 | yukonbob | is tossing around command-names like "jam" "slurp" |
| 01:57.25 | starseeker_ | anything special needed to make fbhelp -F localhost:/dev/X work? |
| 01:58.17 | yukonbob | "stow"? |
| 01:59.53 | starseeker_ | pkg_open(localhost,remotefb): unknown service |
| 01:59.53 | starseeker_ | pkg_open: client connect: errno=111 |
| 01:59.53 | starseeker_ | rem_open: can't connect to remotefb server on host "localhost". |
| 01:59.53 | starseeker_ | fb_open: can't open device "localhost:/dev/X", ret=-4. |
| 01:59.53 | starseeker_ | fbhelp: Can't open frame buffer |
| 01:59.56 | starseeker_ | grr |
| 02:00.25 | yukonbob | jonored: get a friend to give up beer for a month and give you the money? :) |
| 02:00.53 | yukonbob | tell them you'll craft them a custom bong... |
| 02:01.37 | yukonbob | is taking uni stereotypes too far... |
| 02:02.08 | CIA-23 | BRL-CAD: 03starseeker * r32272 10/brlcad/branches/pre-7-12-6/src/libfb/if_remote.c: Adjust libfb string copying - may be related to problem with remote FB display. |
| 02:02.10 | jonored | yukonbob: I'm more likely to go for finding cheap motors somehow and getting the friend with the laser cutter in his apartment to cut parts out on it... |
| 02:02.31 | starseeker_ | wonders what those power bills are like... |
| 02:03.14 | jonored | He's not gotten it all the way set up yet. Probably smaller power bills than buying laser cutter time, though... |
| 02:03.34 | starseeker_ | can the apartment building handle it? |
| 02:04.49 | yukonbob | "hitch"? |
| 02:04.59 | brlcad | starseeker_: yeah, there has to be an /etc/services entry for remotefb |
| 02:05.09 | starseeker_ | ah |
| 02:06.01 | brlcad | remotefb 5558/tcp # BRL-CAD remote frame buffer |
| 02:06.21 | jonored | Hopefully. It's not a hugely powerful one, won't do even thin metal... He says he's expecting it to be able to do up to about a half-inch of acrylic. |
| 02:06.42 | brlcad | and then /etc/inetd.conf needs: remotefb stream tcp nowait nobody /usr/brlcad/bin/fbserv fbserv |
| 02:06.44 | jonored | goes and sees if he can find a power rating for the beastie somewhere. |
| 02:07.44 | starseeker_ | hmm - gentoo doesn't have /etc/inetd.conf |
| 02:08.17 | jonored | starseeker: I'd expect that to depend on which inetd you use... |
| 02:09.36 | starseeker_ | hmm xinetd has some stuff here... |
| 02:10.24 | starseeker_ | will try at work tomorrow - a rebuild will be needed after brlcad picks the new name for dbbinary anyway |
| 02:10.46 | jonored | ...dbblob? |
| 02:10.48 | starseeker_ | brlcad: I'll vote for something other than *binary - do you have a hard preference there? |
| 02:11.14 | jonored | sees "blob" used to refer to that sort of chuck-a-binary-thing-in a lot... |
| 02:11.17 | brlcad | starseeker_: some newer linux use xinetd, so an /etc/xinet.d/fbserv file |
| 02:14.59 | yukonbob | also has "alien" in mind, referencing putting an "alien" file into the .g... |
| 02:15.42 | brlcad | could live with an sqlishy 'blob' command |
| 02:16.18 | starseeker_ | adddata? |
| 02:16.27 | yukonbob | heh |
| 02:16.31 | yukonbob | lol |
| 02:16.44 | yukonbob | what a mouthful... just a funny word.. not laughing at the suggestion. |
| 02:16.49 | brlcad | nnno? :) |
| 02:16.55 | yukonbob | sounds like gattaca |
| 02:17.20 | starseeker_ | would prefer something slightly more descriptive than "blob"... |
| 02:17.20 | yukonbob | is still laughing... |
| 02:17.25 | brlcad | presently, it is used to both import and export |
| 02:17.36 | brlcad | so if the name implies just one, there has to be a matching for export |
| 02:17.46 | starseeker_ | would that be bad? |
| 02:17.57 | brlcad | no |
| 02:18.11 | starseeker_ | would intuitively expect that, come to think of it |
| 02:18.37 | brlcad | that's actually why I was leaning towards import/export .. could make it a generalized command to import/export anything |
| 02:19.10 | starseeker_ | likes that |
| 02:19.16 | starseeker_ | far more intuitive |
| 02:19.32 | yukonbob | ...though an OO-type command with sub-commands is kinda nice, too -- esp. if the noun + verb are the same... |
| 02:19.49 | brlcad | e.g., import/export another .g file (maybe replaces dbconcat/keep) |
| 02:20.10 | starseeker_ | base it on the file type? |
| 02:20.12 | yukonbob | saves looking for the "un" "de" "anti" etc version of one command |
| 02:20.49 | starseeker_ | heh - is "io" taken? |
| 02:22.14 | brlcad | blob import file.doc mydoc or blob -i uc file.doc mydoc, etc |
| 02:22.39 | starseeker_ | blob just sounds so... undignified |
| 02:22.52 | starseeker_ | ah, well - I must admit I have also seen it in this context |
| 02:23.05 | brlcad | data import mydoc file.doc |
| 02:23.13 | starseeker_ | :-) |
| 02:23.58 | jonored | Isn't it something along the lines of "binary large object"? |
| 02:24.00 | starseeker_ | yes, I like that - but if it's going to also replace dbconcat, shouldn't it wait til after the release? |
| 02:24.12 | CIA-23 | BRL-CAD: 03brlcad * r32273 10/brlcad/trunk/NEWS: |
| 02:24.12 | CIA-23 | BRL-CAD: fixed a bug that caused remote framebuffers (specified via -F or FB_FILE) to |
| 02:24.12 | CIA-23 | BRL-CAD: fail. this bug was reported (in person) by r.lai and v.cericole after |
| 02:24.12 | CIA-23 | BRL-CAD: encountered during ray-trace tests. fortunately, you could work around the |
| 02:24.12 | CIA-23 | BRL-CAD: problem by using DISPLAY, but this should fix it. |
| 02:24.50 | brlcad | yes, I'm just thinking where to go for the right fix |
| 02:25.09 | brlcad | for release, might just revert to dbbinary :( |
| 02:25.15 | starseeker_ | fair enough |
| 02:25.30 | starseeker_ | like the generic "data" command |
| 02:25.33 | brlcad | right now it's: binary -i u c _DENSITIES filename |
| 02:25.43 | starseeker_ | ick |
| 02:25.51 | yukonbob | "data" has no "personality" |
| 02:26.08 | yukonbob | could be anything... |
| 02:26.18 | starseeker_ | what about having g_qa and rtweight and whoever else needs it ask for a filename if _DENSITIES isn't found? |
| 02:26.41 | yukonbob | like "blob" -- besides, the objects don't need to be blobs, do they? |
| 02:27.22 | brlcad | starseeker_: those commands have no support for (or expectation of) user-provided interactive input |
| 02:27.42 | brlcad | and it's not deterministic behavior |
| 02:27.51 | brlcad | it does check for the file now, it could bitch better |
| 02:28.32 | brlcad | yukonbob: right now, they all get imported into the .g file as a "binary object" |
| 02:29.03 | yukonbob | mmm. But that's an implementation detail to the user of the command... |
| 02:29.17 | brlcad | all it knows is the type of data -- e.g. it's an array of unsigned characters or an array of short integers or an array of floating point integers, etc |
| 02:29.23 | brlcad | sure |
| 02:29.31 | jonored | hellcattrav: you want ">"... "ipconfig > ip_address.txt" |
| 02:29.39 | jonored | ...wrong channel. |
| 02:29.57 | brlcad | ~nickometer hellcattrav |
| 02:30.05 | starseeker_ | brlcad: I suppose - I like the idea of using the context of the command to avoid needing to specify something like _DENSITIES manually, but it could be a problem if interactive behavior is a no-no" |
| 02:30.10 | yukonbob | ..and you want /etc/passwd, not ip_address.txt |
| 02:30.25 | brlcad | hehe |
| 02:30.27 | starseeker_ | lol |
| 02:30.48 | jonored | hides in shame. |
| 02:31.02 | starseeker_ | could have the "blob" or "data" command look in the file for a optional target object name? |
| 02:31.16 | brlcad | starseeker_: I could see mged or a gui prompting after checking for the file, the command-line commands are (all?) non-interactive though |
| 02:31.26 | starseeker_ | OK. |
| 02:32.02 | brlcad | and I agree, _DENSITIES needs to die |
| 02:32.30 | brlcad | more to the point, it should be better integrated, a hidden detail at best if it's an object, but not a binary_obj |
| 02:32.39 | starseeker_ | nods |
| 02:32.55 | brlcad | maybe make it official attributes on _GLOBAL if we have to |
| 02:33.00 | yukonbob | matryoshka <-- russian stacking doll |
| 02:33.29 | starseeker_ | I can see multiple density objects, and specifying an rtweight calculation with different ones to compare density tables, but that's more a debugging feature than anything - theoretically most densities have a "right" answer |
| 02:33.40 | yukonbob | "borg", for assimilation... |
| 02:33.49 | starseeker_ | hehe |
| 02:33.50 | yukonbob | borg in myfile.txt myfile |
| 02:33.59 | yukonbob | borg out myfile myfile.txt |
| 02:34.11 | yukonbob | hrmm... |
| 02:34.28 | yukonbob | "Hey -- borg that .doc into the db and let's ship!" |
| 02:34.38 | starseeker_ | likes it better as the univeral *->g converter - "resistance is futile, your CAD file will be assimilated" |
| 02:35.37 | starseeker_ | should get chores done and sleep... |
| 02:38.02 | brlcad | actually "bo in myfile.txt myfile" or "bo -i u c myfile.txt myfile" was one of the ideas I've been considering |
| 02:38.39 | brlcad | makes a mental note to do laundry before leaving so he actualy has clothes to wear |
| 02:39.24 | yukonbob | stephen colbert last night: "Hey America, I wear the pants in this relationship. [glances down] Most of the time." |
| 02:42.06 | yukonbob | is feeling that his colourful names are getting traction ;) |
| 02:42.57 | starseeker_ | doesn't want to have to answer the question "so why did you call this command "blob" again?" |
| 02:43.45 | brlcad | yeah, I'd lean away from blob -- though for different reasons |
| 02:44.00 | yukonbob | thinks blob is too generic; sees starseeker_'s POV re: attrativeness, but mostly doesn't like it because it could apply to so many diff't aspects of BRL-CAD |
| 02:44.23 | brlcad | with sql, blob types are "untyped" data that you don't know much about |
| 02:44.31 | brlcad | with us, we know what they are |
| 02:44.35 | brlcad | to some extent |
| 02:45.08 | brlcad | and if we get to adding mime-types and handlers, we could deal with them -- bring in a pdf, display it, etc |
| 02:45.36 | yukonbob | still likes "alien" or similar... |
| 02:45.51 | yukonbob | "visitor" -- anybody remember that TV show "V"? |
| 02:45.58 | brlcad | data is generic enough that it's borderline on too generic, but still would do the trick as would import/export |
| 02:46.01 | yukonbob | wasn't allowed to watch it :P |
| 02:46.13 | brlcad | bo is quirky brief like most of our commands and directly pertains to what it is/does |
| 02:46.31 | brlcad | yukonbob: yeah.. vaguely :) |
| 02:46.32 | yukonbob | kinda likes 'bo' for it's Unix-yness |
| 02:46.33 | starseeker_ | nods |
| 02:46.59 | yukonbob | assumes it's for _B_inary _O_bject |
| 02:47.04 | brlcad | yep |
| 02:47.06 | jonored | suggests that blobs usually are mostly unknown only to the database software, not the app using it, but likes bo better. |
| 02:47.59 | brlcad | mm.. so perhaps bo ftw for now |
| 02:48.07 | brlcad | dissenters?! |
| 02:48.14 | yukonbob | beau |
| 02:48.27 | brlcad | (burn them!) |
| 02:48.35 | yukonbob | :) |
| 02:48.42 | yukonbob | raises glass of OJ to "bo" |
| 02:48.43 | jonored | ...bob? |
| 02:48.55 | yukonbob | heh |
| 02:48.58 | brlcad | mged so needs a 'bob' command |
| 02:48.58 | jonored | ducks. |
| 02:49.14 | brlcad | i'm just not sure what it'd do :) |
| 02:49.22 | yukonbob | duck and weave. |
| 02:50.08 | brlcad | could make it randomly pick a command and alias it to some other random command |
| 02:50.24 | yukonbob | awesome... |
| 02:50.39 | brlcad | notes that the name of the dev that has written most of mged is named 'bob' |
| 02:50.47 | yukonbob | "and from around the lab, one would occasionally hear 'fscking bob!'" |
| 02:51.00 | brlcad | has heard that :) |
| 02:51.13 | brlcad | (in good fun usually) |
| 02:51.26 | yukonbob | "usually" |
| 02:51.27 | yukonbob | :) |
| 02:51.36 | brlcad | bob rocks |
| 02:52.19 | yukonbob | is this the bob that I still see commit msgs from in here? |
| 02:52.23 | yukonbob | *Bob |
| 02:52.25 | brlcad | oooh, 'bob' could increase the font size +1 each time you run it |
| 02:52.41 | yukonbob | on that note, we need better font handling in mged. |
| 02:52.44 | brlcad | he likes big fonts |
| 02:52.55 | brlcad | yeah, same bob |
| 02:53.12 | yukonbob | had a script that he'd source/run to fix the fonts when he was more regularly running BRL-CAD |
| 02:53.39 | brlcad | you know you could set the fonts, then run "update/create .mgedrc" on the File menu, no? ;) |
| 02:54.04 | brlcad | that should say "Save Preferences" |
| 02:54.25 | yukonbob | never thinks of the menu :P -- I'll keep in mind, though :) |
| 02:54.39 | brlcad | there's a font panel on the menu |
| 02:54.44 | brlcad | how were you changing the fonts? :) |
| 02:55.06 | yukonbob | introspection, creating a default tag, adjusting tag :P |
| 02:55.22 | yukonbob | "tag" is wrong word, but I don't have a manual handy, nor script. |
| 02:56.44 | yukonbob | something like font create foo "*-*-*-helvetica-10-l-whatever", and then adjusting appropriate items to use this font... then can update the "foo" and everything that was using it would be automagically updated. |
| 03:04.31 | brlcad | heh |
| 03:06.08 | brlcad | looks like using const int's for the indicese on ia32 is a 4-8% hit for both optimized and unoptimized |
| 03:06.27 | brlcad | deletes the patch and associated changes |
| 03:06.40 | yukonbob | expensive |
| 03:17.09 | starseeker_ | brlcad: Do you want me to implement the binary -> bo change tomorrow? |
| 03:19.49 | brlcad | starseeker_: I'm almost done |
| 03:19.56 | starseeker_ | ah :- |
| 03:20.02 | starseeker_ | ) |
| 03:21.07 | starseeker_ | starts - cat jumped on back of chair |
| 03:21.16 | starseeker_ | she's never done that before, at least not with my chair |
| 03:21.27 | starseeker_ | we must be feeding her wheaties |
| 03:22.16 | brlcad | ever put a piece of tape on her back? |
| 03:22.26 | starseeker_ | no |
| 03:22.46 | starseeker_ | it'd be a tossup as to whether the cat or the boss would kill me first |
| 03:23.09 | brlcad | :) |
| 03:23.31 | yukonbob | tape sounds like fun... |
| 03:23.38 | starseeker_ | she has however (of her own accord) jumped into the washer/dryer when it was warm after clothes were removed |
| 03:23.41 | yukonbob | is "cat sitting" two cats atm. |
| 03:23.45 | starseeker_ | needs to get a picture of that... |
| 03:24.21 | starseeker_ | is actually allergic to cats, but after a few months with an initial anti-allergy assist tolerance seems to be building |
| 03:24.53 | brlcad | thinks the news section could use some wordsmithing .. it doesn't say much different than the bullets |
| 03:25.01 | starseeker_ | yukonbob: TWO cats? |
| 03:25.03 | brlcad | yeah, i'm somewhat allergic myself |
| 03:25.04 | starseeker_ | how do they get along? |
| 03:25.12 | yukonbob | nods |
| 03:25.21 | yukonbob | <- not a cat fan. |
| 03:25.31 | starseeker_ | brlcad: please! I didn't know quite what to do with that part |
| 03:25.39 | brlcad | it was the first thing I discovered I was ever allergic to (at the age of 20 or so) |
| 03:25.44 | starseeker_ | ! |
| 03:25.57 | brlcad | aside from poison ivy that is.. :) |
| 03:25.58 | starseeker_ | found out he didn't get along with various pollens early on... |
| 03:26.02 | starseeker_ | hehe |
| 03:27.09 | brlcad | stayed with a buddy down in georgia.. the small apartment had this viscious cat that controlled the domain and whose smell, fur, and dander permeated every inch of the place |
| 03:27.22 | starseeker_ | ick |
| 03:27.35 | brlcad | it would like under a chair and take swipes at anyone passing by (drawing blood) |
| 03:27.48 | starseeker_ | oh, lovely |
| 03:28.01 | starseeker_ | never ran into one quite that bad |
| 03:28.13 | brlcad | I mean it was a normal 'cat place' .. but first I'd slept/lived in extensively with a cat that couldn't go outdoors |
| 03:29.12 | starseeker_ | looks at previous NEWS entries and tries again... |
| 03:29.12 | brlcad | took me several weeks to realize why I woke up every morning feeling utterly miserable, thought it was a cold, but then I'd get better after I left the house going to the gym, to work, dinner, etc |
| 03:29.37 | starseeker_ | nods |
| 03:29.46 | starseeker_ | that's nasty |
| 03:31.20 | brlcad | starseeker_: think of it like you're explaining what all those bullets mean to someone who maybe knows very little about BRL-CAD specifically, or that doesn't want to follow all the bullet items and wants the big picture |
| 03:31.37 | brlcad | plus it's a good place to put the "why" and "what does this mean" |
| 03:41.49 | starseeker_ | brlcad: Were you actually able to test the fbhelp option? I didn't get it working here yet |
| 03:46.53 | CIA-23 | BRL-CAD: 03starseeker * r32274 10/brlcad/branches/pre-7-12-6/NEWS: First try at tweaking NEWS wording |
| 03:47.30 | brlcad | of course not :) |
| 03:47.38 | starseeker_ | heh |
| 03:47.52 | brlcad | rather, I'm "able" .. but I didn't |
| 04:14.13 | PrezKennedy | never had too much doubt when im allergic to something |
| 04:15.29 | PrezKennedy | a day at a place with a cat and id probably need to be hospitalized |
| 04:15.31 | PrezKennedy | :P |
| 04:34.06 | CIA-23 | BRL-CAD: 03brlcad * r32275 10/brlcad/trunk/ (11 files in 8 dirs): |
| 04:34.06 | CIA-23 | BRL-CAD: after some discussions on the channel, rename the 'binary' command in mge to the |
| 04:34.06 | CIA-23 | BRL-CAD: 'bo' command (for binary object). this was done due to the fact that Tcl |
| 04:34.07 | CIA-23 | BRL-CAD: already has a 'binary' command and ours ends up masking it - a cnflict that |
| 04:34.07 | CIA-23 | BRL-CAD: mysteriously didn't surface during early 8.5 testing but is still there. this |
| 04:34.09 | CIA-23 | BRL-CAD: relates to tom browders sf bug 1532699 that prompted th initial change. other |
| 04:34.11 | CIA-23 | BRL-CAD: options considered: import/export, data, blob, borg, dbblob, adddata, ... |
| 04:53.31 | CIA-23 | BRL-CAD: 03brlcad * r32276 10/brlcad/trunk/src/proc-db/bottest.c: put semicolons so it indents correctly |
| 05:13.31 | *** join/#brlcad jonored (n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 05:14.24 | starseeker_ | growls at the merge tools for Linux |
| 05:14.39 | starseeker_ | 'course, perhaps I shouldn't be at subversion 1.5 just yet... |
| 05:15.52 | CIA-23 | BRL-CAD: 03brlcad * r32277 10/brlcad/branches/pre-7-12-6/ (10 files in 8 dirs): (log message trimmed) |
| 05:15.52 | CIA-23 | BRL-CAD: sync with r32275 changes on trunk. after some discussions on the channel, |
| 05:15.52 | CIA-23 | BRL-CAD: rename the 'binary' command in mge to the 'bo' command (for binary object). |
| 05:15.52 | CIA-23 | BRL-CAD: this was done due to the fact that Tcl already has a 'binary' command and ours |
| 05:15.52 | CIA-23 | BRL-CAD: ends up masking it - a cnflict that mysteriously didn't surface during early 8.5 |
| 05:15.56 | CIA-23 | BRL-CAD: testing but is still there. this relates to tom browders sf bug 1532699 that |
| 05:15.58 | CIA-23 | BRL-CAD: prompted th initial change. other options considered: import/export, data, blob, |
| 05:16.10 | starseeker_ | heh - thanks :-) |
| 05:16.32 | starseeker_ | decides to see what subcommander is like... |
| 05:17.16 | brlcad | untested :) |
| 05:17.35 | starseeker_ | brlcad: No worries - I'll put it through one more cycle tomorrow |
| 05:17.45 | starseeker_ | and test bo |
| 05:17.59 | brlcad | make test will test bo |
| 05:18.07 | starseeker_ | cool |
| 05:18.23 | brlcad | make sure the mged create menu works though |
| 05:18.35 | starseeker_ | k |
| 06:04.43 | *** join/#brlcad Ralith (n=ralith@c-71-197-213-172.hsd1.or.comcast.net) |
| 06:15.53 | brlcad | howdy Ralith |
| 06:16.22 | brlcad | i finished testing the const int replacement, it was definitely a no-go .. |
| 06:16.37 | brlcad | anywhere from 4 to 40% performance hit, even on optimized |
| 06:16.56 | brlcad | but I think I have something that should be a suitable fix in the works now |
| 06:17.17 | Ralith | :/ |
| 06:17.22 | Ralith | alright; what're you thinking? |
| 06:17.56 | brlcad | basically adding a switch that turns them off (rather, hides them) |
| 06:18.25 | Ralith | there's always const _X_ = X; #undef X \n const X = _X; |
| 06:18.38 | brlcad | that you define, akin to _POSIX_C_SOURCE and similar defines |
| 06:18.40 | Ralith | a switch where? |
| 06:18.46 | Ralith | ah. |
| 06:19.15 | Ralith | that's not necessarily helpful |
| 06:19.19 | Ralith | all the vmath macros depend on them |
| 06:19.34 | Ralith | so I'm left doing very ugly and space-consuming operations everywhere |
| 06:19.53 | brlcad | huh? |
| 06:20.02 | Ralith | e.g. VSETALL |
| 06:20.12 | Ralith | doesn't work without X, Y, Z defined or set somehow |
| 06:20.33 | brlcad | i'm talking about a switch that changes that... |
| 06:20.38 | Ralith | ooh! |
| 06:20.46 | brlcad | what did you think I meant?? |
| 06:20.58 | Ralith | a switch that just disabled the definition of X, Y, and Z |
| 06:21.11 | brlcad | no, the macros obviously still have to work |
| 06:21.19 | brlcad | otherwise it's a broken header |
| 06:22.40 | Ralith | yeah. |
| 06:23.26 | Ralith | that'll do well enough, although the usage still seems pretty inelegant compared to your standard C++ fare. |
| 06:25.21 | brlcad | i'll take efficiency over elegancy in this situation :) |
| 06:26.17 | Ralith | still wonders if there's no way to hack a struct on top of the array data |
| 06:26.49 | Ralith | using a C++ class would induce overhead, wouldn't it? |
| 06:27.15 | brlcad | yep |
| 06:27.19 | brlcad | quite a lot actually |
| 06:27.25 | Ralith | suspected that. |
| 06:27.26 | Ralith | >:| |
| 06:27.38 | Ralith | stupid performance sensitivity. |
| 06:28.09 | brlcad | subtle too, doens't show up easily on a profile (e.g. gprof) since it's distributed unless you observe overall time or use a sampling profiler (maybe) |
| 06:28.40 | Ralith | if you've got the time to explain, how does it induce the overhead? |
| 06:28.46 | brlcad | it's hard to get much faster than directly accessing memory in order marching through memory |
| 06:30.12 | Ralith | ah. |
| 06:30.25 | Ralith | so not so much a case of extra overhead as a case of comparison to absolutely no overhead. |
| 06:30.31 | brlcad | a struct is an interesting one -- a really good compiler optimization "should/could" make that a fairly minimal approach except that there are memory alignment issues based on how an array of structs can be packed into memory, how individual elements are positioned, alignment paddings, compilation settings |
| 06:30.53 | Ralith | depending on compiler features is silly, anyway. |
| 06:31.43 | brlcad | there are egregious overheads you can have with OO vector math classes that often go unnoticed, like implicit data copying, vtable dereferencing, pointer dereferencing, etc (for various naive implementations) |
| 06:32.46 | Ralith | a real shame, given all the wonderful syntax that OO impls allow. |
| 06:32.48 | brlcad | it's actually somewhat non-trivial to make a c++ vector/matrix class that is optimal |
| 06:33.35 | brlcad | doesn't mean we can't use it or make one, just means have to be pretty careful about it and that still doesn't mean the C code shouldn't be as tight as possible :) |
| 06:33.42 | Ralith | yeah |
| 06:34.27 | Ralith | still, even a simple naive implementation that wraps and can convert to the C one might be really nice to keep performance-insensitive code like the new GUI clean and elegant. |
| 06:36.20 | mac- | re |
| 06:36.56 | mac- | starseeker_: i suppose that, in the past i`ve compiled several programs and i`m familiar with problems during this |
| 07:05.48 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) |
| 07:26.43 | brlcad | gets back to his task at hand |
| 07:45.18 | *** join/#brlcad smurfette (n=Pandora@c-69-243-244-154.hsd1.mo.comcast.net) |
| 08:07.58 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 08:08.44 | CIA-23 | BRL-CAD: 03d_rossberg * r32278 10/brlcad/branches/pre-7-12-6/ (11 files in 10 dirs): revive the CMake build (brlcad.dll) |
| 08:54.18 | *** join/#brlcad Elperion (n=Bary@p5B14C460.dip.t-dialin.net) |
| 09:05.50 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 09:19.54 | brlcad | arf |
| 09:20.05 | Ralith | arf indeed! |
| 09:21.07 | brlcad | Ralith: what timezone are you in? |
| 09:21.54 | Ralith | pacific |
| 09:21.59 | brlcad | heh, nice |
| 09:22.07 | brlcad | woots on the night owl |
| 09:22.58 | Ralith | o/ |
| 09:23.02 | Ralith | coding isn't coding if it's not done after midnight |
| 09:23.47 | brlcad | =) |
| 10:48.46 | CIA-23 | BRL-CAD: 03davidloman * r32279 10/rt^3/trunk/src/geometryService/java/stractNet/docs/stractNet.eap: |
| 10:54.44 | archivist_ub | fresh svn checkout on ubuntu what have I missed or what dependency is missing from configure http://pastebin.ca/1093661 |
| 11:00.41 | CIA-23 | BRL-CAD: 03davidloman * r32280 10/rt^3/trunk/src/geometryService/java/geometryService/src/geometryService/subsystems/GED.java: |
| 11:04.00 | *** join/#brlcad mac`u (i=mac@linux.slackware.in) |
| 11:04.03 | mac`u | re :) |
| 11:18.05 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 11:19.05 | mafm | hi |
| 11:19.36 | Ralith | hey |
| 11:20.32 | mafm | what's up Ralith? |
| 11:20.56 | Ralith | idling around |
| 11:21.18 | brlcad | howdy mafm |
| 11:21.18 | Ralith | g3d switch to libbn vectors is almost ready, pending some updates from brlcad |
| 11:21.26 | Ralith | also |
| 11:21.31 | Ralith | I've been meaning to ask you, mafm |
| 11:21.44 | Ralith | why do you limit vertical camera rotation? |
| 11:22.38 | mafm | when you switch from almost-top to top-post (and same with bottom), the camera makes a strange turn |
| 11:23.10 | brlcad | sounds like a bug :) |
| 11:23.13 | Ralith | so force roll to a more reasonable value? |
| 11:23.24 | mafm | not really, it's because of the mathematical ecuations |
| 11:23.32 | mafm | afaik |
| 11:23.35 | Ralith | strange turns can be overriddent |
| 11:23.39 | Ralith | overridden* |
| 11:23.45 | Ralith | I'll see if I can do so |
| 11:23.55 | mafm | yes, they should, I just did a quick fix |
| 11:24.15 | mafm | probably you only have to change the sign of the vertical rotation or something like that |
| 11:24.37 | Ralith | kk |
| 11:24.49 | Ralith | was hesitant to play with it cuz I thought it might have been a conscious UI decision |
| 11:24.52 | Ralith | I'm no UI designer |
| 11:25.20 | mafm | http://en.wikipedia.org/wiki/Spherical_coordinates#Definition |
| 11:25.38 | mafm | 0 ? ? ? ? |
| 11:25.46 | mafm | 0 ? ? < 2? |
| 11:25.57 | Ralith | spherical coords are used? O.o |
| 11:26.03 | Ralith | that's very strange. |
| 11:26.54 | mafm | it's the easier way that it ocurred to me :) |
| 11:27.27 | Ralith | never thought I'd hear spherical coords referred to as easy. |
| 11:28.27 | mafm | well, I started implementing orbital mode |
| 11:28.36 | mafm | which is continuous, not in discrete steps |
| 11:29.10 | mafm | so while you maintain a key pressed, the amount of rotation goes up of down, in horizontal or vertical |
| 11:29.18 | Ralith | yeah, I played with that |
| 11:29.19 | Ralith | was neat |
| 11:29.30 | mafm | and zoom changes the ratio |
| 11:29.42 | Ralith | ratio of what? |
| 11:29.49 | mafm | radius* |
| 11:29.53 | Ralith | ah. |
| 11:29.56 | mafm | so the camera is basically in a point of the sphere looking to the center |
| 11:30.12 | Ralith | kk |
| 11:30.23 | Ralith | I've *really* gotta get some sleep now |
| 11:30.27 | Ralith | thanks for the explanations |
| 11:30.30 | mafm | soo... that's why I thought that it would be the more natural way to implement it :) |
| 11:30.35 | mafm | oki, see you around ;) |
| 11:30.55 | Ralith | conceptually simple, but doesn't strike me as mathematically straightforward. |
| 11:30.58 | Ralith | seeya. |
| 11:31.21 | brlcad | cya Ralith |
| 11:31.27 | Ralith | 'nite |
| 11:34.22 | mafm | feels a math nerd for the 1st time :D |
| 11:35.07 | archivist_ub | thats one thing I shall never be |
| 11:36.49 | mafm | I usually failed tests in math, although I like them in general |
| 11:39.30 | archivist_ub | I can program and use maths, but useless at generating the equations |
| 11:43.55 | mafm | heh |
| 11:44.05 | mafm | well, I think that I never did that either |
| 12:15.42 | CIA-23 | BRL-CAD: 03davidloman * r32281 10/rt^3/trunk/src/geometryService/cpp/stractNet/ (106 files in 2 dirs): Phase 1 of code conversion effort. |
| 12:47.29 | *** join/#brlcad PrezKennnedy (i=Matthew@whitecalf.net) |
| 12:47.50 | *** join/#brlcad thing0 (n=ric@58.171.152.14) |
| 13:13.47 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 13:17.09 | mafm | all hail network admins! |
| 13:39.48 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 13:54.02 | CIA-23 | BRL-CAD: 03homovulgaris * r32282 10/brlcad/trunk/src/libpc/ (Makefile.am TODO pcParameter.cpp pcParameter.h): Adding skeleton files for Parameter classa abstraction over the Variables |
| 14:01.27 | CIA-23 | BRL-CAD: 03davidloman * r32283 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/ (11 files): |
| 14:08.08 | CIA-23 | BRL-CAD: 03davidloman * r32284 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/wiki/ (. index.html): Library addition for GeometryService |
| 14:12.15 | CIA-23 | BRL-CAD: 03davidloman * r32285 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/ (13 files in 3 dirs): |
| 14:14.04 | CIA-23 | BRL-CAD: 03davidloman * r32286 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/release/ (6 files): |
| 14:14.57 | CIA-23 | BRL-CAD: 03bob1961 * r32287 10/brlcad/trunk/ (4 files in 3 dirs): Mods for automatically setting the version for asc2g.vcproj and brlcad.nsi |
| 14:17.25 | mafm | brlcad: do you conceive any possible use of Tcl/Tk in g3d? |
| 14:18.25 | CIA-23 | BRL-CAD: 03bob1961 * r32288 10/brlcad/trunk/src/external/ProEngineer/win32-msvc8/: This was mistakenly added with other mods. |
| 14:18.42 | brlcad | mafm: yes |
| 14:18.53 | brlcad | not for the near-term though |
| 14:19.10 | brlcad | other than as a requirement to link against the geometry engine libs |
| 14:19.36 | brlcad | but eventually, the ability to plug in and switch between scripting engines (ala script-fu) is in the plan |
| 14:20.03 | mafm | I just mean because ralith included some new things in the CMakeFile |
| 14:20.24 | brlcad | so as a scripter, you could use any of the common interactive shells as your scripting interface (posix sh, tclsh, maybe others) |
| 14:20.25 | mafm | and I don't know if the TCL/TK part should be there or not |
| 14:21.01 | brlcad | I believe that was to be able to link/use the brl-cad geometry libs |
| 14:21.24 | brlcad | they have bits of tcl integrated, so the dep gets carried forward |
| 14:21.33 | brlcad | tk shouldn't be needed |
| 14:21.35 | brlcad | just tcl |
| 14:22.58 | mafm | I see |
| 14:23.06 | mafm | I'll leave them then |
| 14:27.32 | mafm | another thing... I am creating the widget but I'm having a few problems, and I don't think that I'm doing very complicate things compared to what we're going to do |
| 14:36.46 | CIA-23 | BRL-CAD: 03d_rossberg * r32289 10/rt^3/trunk/ (2 files in 2 dirs): IsRegion() is const throw() |
| 14:39.20 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) [NETSPLIT VICTIM] |
| 14:47.48 | brlcad | "the widget"? |
| 14:47.51 | brlcad | what widget? :) |
| 14:48.24 | brlcad | presume you mean something customized in the gui? .. it's more proof of concept to evaluate rbgui |
| 14:48.35 | brlcad | if it's really hard, that's a huge negative on the toolkit |
| 14:48.58 | brlcad | since we do have some rather complicated things that we'll want to be able to do |
| 14:49.48 | mafm | I can get things painted, but not all of them |
| 14:49.57 | mafm | some rectangles work, some others don't |
| 14:50.10 | mafm | lines don't seem to work |
| 14:50.58 | mafm | and the text has that problem sometimes of drawing also all glyphs |
| 14:51.16 | mafm | I guess that the library is a bit undertested |
| 15:00.23 | mafm | sooo I'm now trying to compose a radial control via drawing rectangles of 1 pixel :) |
| 15:00.48 | mafm | it would be easy to manage if the widget would use 10 textures depending on the progress, though |
| 15:32.39 | CIA-23 | BRL-CAD: 03davidloman * r32290 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/regression/ (11 files in 2 dirs): Library addition for GeometryService |
| 15:33.58 | CIA-23 | BRL-CAD: 03davidloman * r32291 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/regression/xsl_reports/xsl/ (39 files in 5 dirs): Library addition for GeometryService |
| 15:34.48 | CIA-23 | BRL-CAD: 03davidloman * r32292 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/regression/xsl_reports/utils/ (14 files): Library addition for GeometryService |
| 15:36.06 | CIA-23 | BRL-CAD: 03davidloman * r32293 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/regression/xsl_reports/test/ (10 files): |
| 15:37.37 | CIA-23 | BRL-CAD: 03davidloman * r32294 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/regression/test/ (43 files in 12 dirs): Library addition for GeometryService |
| 15:39.47 | *** join/#brlcad mas3773 (n=mas3773@75-13-4-215.lightspeed.kscyks.sbcglobal.net) |
| 15:41.14 | CIA-23 | BRL-CAD: 03davidloman * r32295 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/regression/ (31 files in 5 dirs): Library addition for GeometryService |
| 15:45.01 | CIA-23 | BRL-CAD: 03homovulgaris * r32296 10/brlcad/trunk/src/other/boost/ (178 files in 25 dirs): boost update and additional files for using shared_ptr and indirect_iterator |
| 15:47.10 | mas3773 | before I put in a bug report, I wanted to make sure it's not something on my end... Anyone want to check it out? |
| 15:49.54 | mas3773 | I put up a copy of the terminal at http://dirtykdx.is-a-geek.net/files/brlcad_bug.txt this is from the command line only interface [mged -c choosing the null output] |
| 15:50.19 | mas3773 | basically a tra gives a mged_players error |
| 15:50.27 | *** join/#brlcad Elperion (n=Bary@p5B14C460.dip.t-dialin.net) |
| 15:53.30 | CIA-23 | BRL-CAD: 03davidloman * r32297 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/quickbook/ (36 files in 7 dirs): |
| 15:58.24 | CIA-23 | BRL-CAD: 03davidloman * r32298 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/quickbook/ (80 files in 13 dirs): Library addition for GeometryService |
| 16:08.45 | CIA-23 | BRL-CAD: 03davidloman * r32299 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/ (25 files in 3 dirs): Library addition for GeometryService |
| 16:10.27 | CIA-23 | BRL-CAD: 03davidloman * r32300 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/jam/ (24 files in 3 dirs): Library addition for GeometryService |
| 16:16.51 | CIA-23 | BRL-CAD: 03davidloman * r32301 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/jam/src/ (96 files): Library addition for GeometryService |
| 16:45.14 | CIA-23 | BRL-CAD: 03davidloman * r32302 10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/tools/jam/src/ (202 files in 9 dirs): |
| 16:59.26 | *** join/#brlcad starseek1r (n=starseek@bz.bzflag.bz) |
| 17:02.31 | starseeker | there we go |
| 17:08.16 | *** join/#brlcad starseek1r (n=starseek@bz.bzflag.bz) |
| 17:29.35 | CIA-23 | BRL-CAD: 03bob1961 * r32303 10/brlcad/trunk/src/libged/rtcheck.c: Fixed argument to bu_vls_printf. |
| 17:53.50 | CIA-23 | BRL-CAD: 03homovulgaris * r32304 10/brlcad/trunk/src/libpc/ (Makefile.am NOTES pcMathVM.h solver_test.cpp): beginning work on Math Virtual Machine for evaluation of arbitrary expressions, would be useful only in the case of explicit constraints |
| 18:03.23 | *** join/#brlcad andrecastelo_ (n=chatzill@189.71.30.223) |
| 18:05.27 | starseeker | exit |
| 18:05.29 | starseeker | quit |
| 18:06.36 | starseeker | heh opps |
| 18:15.22 | mafm | brlcad: would be a slider enough? :) |
| 18:31.03 | CIA-23 | BRL-CAD: 03bob1961 * r32305 10/brlcad/trunk/src/libged/ypr.c: Fixed typo. |
| 18:37.17 | CIA-23 | BRL-CAD: 03bob1961 * r32306 10/brlcad/trunk/src/mged/inside.c: Mods reflecting a signature change of rt_arb_calc_planes |
| 18:45.16 | CIA-23 | BRL-CAD: 03bob1961 * r32307 10/brlcad/trunk/include/ged.h: wdb_binary_cmd has changed to wdb_bo_cmd |
| 18:57.13 | archivist_ub | <PROTECTED> |
| 19:12.53 | CIA-23 | BRL-CAD: 03mafm * r32308 10/rt^3/trunk/src/g3d/ (CameraMode.cxx CameraMode.h): Adding methods to retrieve the relative rotations, so (in example) they can be shown in windows |
| 19:19.28 | *** join/#brlcad cad79 (n=caaf8794@bz.bzflag.bz) |
| 19:20.03 | *** join/#brlcad brls (n=caaf8794@bz.bzflag.bz) |
| 19:21.08 | brls | hi there anyone can consult on mater command? |
| 19:26.12 | brls | mater command enyone? |
| 19:26.50 | archivist_ub | basicly in IRC just ask the real question |
| 19:28.33 | brls | hi there anyone can consult on mater command for BRL-CAD? |
| 19:29.31 | brls | using mater to specify plastic as a material, how I can specify wood for e.g or metal etc and render to see the sructure ? |
| 19:30.29 | mafm | have to go, bye |
| 19:32.11 | CIA-23 | BRL-CAD: 03mafm * r32309 10/rt^3/trunk/data/g3d/RBGui/themes/brlcad_camera_rotation.png: Change icon appearance |
| 19:44.51 | CIA-23 | BRL-CAD: 03davidloman * r32310 10/rt^3/trunk/src/geometryService/java/stractNet/docs/stractNet.eap: EA Update. |
| 19:51.00 | brls | so much for the tech discussion ..see you all |
| 19:52.01 | archivist_ub | irc is not instant! |
| 19:56.08 | *** join/#brlcad Elperion (n=Bary@p5B14C460.dip.t-dialin.net) |
| 20:06.52 | CIA-23 | BRL-CAD: 03bob1961 * r32311 10/brlcad/trunk/ (8 files in 4 dirs): Added edcodes, rcodes, wcodes and which_shader to libged. |
| 20:45.12 | brlcad | archivist_ub: you expect anything more from cgi:irc? :) |
| 20:45.51 | archivist_ub | who me was a comment about brls |
| 20:46.22 | archivist_ub | but you could look a few lines above :) |
| 20:46.33 | archivist_ub | then you see my question |
| 20:50.23 | brlcad | i'm referring to brls |
| 20:50.45 | brlcad | he was on a cgi:irc connection |
| 20:51.39 | brlcad | tend to be the worst offenders of impatience, bad irc netiquette, not ~ask'ing, and overall just being annoying |
| 20:51.48 | archivist_ub | heh |
| 20:52.06 | archivist_ub | I see a few in #mysql |
| 20:52.55 | brlcad | and just about when I'm ready to take the web interface down, someone shows up who is a normal joe and the cgi:irc helped get them into the channel to figure out their next step |
| 20:54.19 | archivist_ub | actually had a face to face IRC moment on sunday, volunteer steam engine driving and someone aske was I a volunteer, yes, he then berated me for a single word reply! |
| 20:54.30 | archivist_ub | asked |
| 20:54.55 | brlcad | then you say.. |
| 20:55.00 | brlcad | ok, how about "no" then |
| 20:55.08 | archivist_ub | hehe |
| 20:58.53 | archivist_ub | anyway what rule builds libitk.la |
| 21:03.48 | brlcad | brlcad/src/other/incrTcl/Makefile.am |
| 21:05.12 | archivist_ub | I assume there's a missing dependency so its not built yet |
| 21:07.28 | *** join/#brlcad Ralith (n=ralith@c-71-197-213-172.hsd1.or.comcast.net) |
| 21:08.51 | archivist_ub | hmm its there |
| 21:18.48 | *** join/#brlcad prasad_ (n=psilva@h-72-245-122-226.mclnva23.covad.net) |
| 21:34.09 | archivist_ub | it wasnt there and Makefile.am depends on WITH_X11 being set and this has XORG so some digging , will have to wait as its home time |
| 22:19.18 | brlcad | archivist_ub: check the summary block near the bottom of config.log and see if a) x11 support is enabled and b) whether itcl and itk are enabled and c) whether tcl and tk are enabled or off -- it could be some problem mixing some system tcl-stuff with some built tcl-stuff |