| 00:34.20 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 01:30.35 | ``Erik | *readreadread* |
| 01:30.44 | ``Erik | hm |
| 01:31.27 | ``Erik | bah, nascar is still on, I want my cartoons *pout* |
| 01:46.01 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) |
| 01:48.15 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-39.sbndin.btas.verizon.net) |
| 02:13.20 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) [NETSPLIT VICTIM] |
| 02:13.20 | *** join/#brlcad PrezKennedy (n=Matthew@whitecalf.net) [NETSPLIT VICTIM] |
| 02:13.20 | *** join/#brlcad kanzure (i=bryan@66.112.232.233) [NETSPLIT VICTIM] |
| 02:36.16 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 02:36.16 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207) |
| 04:06.54 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 06:08.29 | starseeker | brlcad: I made a test manually of a coil coiling inward: http://bzflag.bz/~starseeker/coil_in_ex.png what do you think? Is it a good enough approximation to be worthwhile? |
| 08:57.02 | archivist | hmm cnc wire bending |
| 09:03.52 | brlcad | starseeker: I'd still probably say not really -- even that test looks oddly shaped enough that I'd think it was a bug instead of an approximated implementation detail |
| 09:05.17 | brlcad | maybe if you could control how approximated it was at the expense of speed (like 100 or 1000 bends just to make one turn) |
| 09:05.35 | brlcad | but yeah, not at the quarter-turn |
| 09:07.07 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 10:19.33 | CIA-40 | BRL-CAD: 03brlcad * r33926 10/brlcad/trunk/src/libged/draw.c: recogized typo and fixd it |
| 10:23.46 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 10:37.39 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 11:24.16 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:50.39 | d-lo | Mornin all! |
| 11:50.53 | d-lo | brlcad: Still awake or just woke up? |
| 12:12.33 | d-lo | ``Erik: Have any essssspertize on decompliation / assembly ? |
| 12:19.18 | *** join/#brlcad TC-Rucho (n=tc-rucho@190.191.172.28) |
| 12:19.32 | TC-Rucho | hello |
| 12:30.51 | brlcad | d-lo: still awake |
| 12:31.53 | d-lo | machine.... |
| 12:32.14 | d-lo | I take it you rcurrent work location will be the work location for the day then ? :)\ |
| 12:32.18 | brlcad | trying to fix a stupid resize bug |
| 12:32.49 | d-lo | as in GUI widget resize? |
| 12:33.06 | brlcad | it'd be tricky to try and get out right now with the snow depth on top of ice |
| 12:33.24 | d-lo | how much snow you get so far? |
| 12:33.33 | d-lo | I got <1" at home :/ |
| 12:33.43 | d-lo | they *said* 5-8" |
| 12:33.49 | brlcad | it iced through most of the night and has been snowing few a few hours since, maybe 4-6" total |
| 12:34.02 | d-lo | I got excited and broke out the sleds :/ I think i cursed it. |
| 12:35.47 | d-lo | brlcad: do you have any exp with disassembly/decompilation? |
| 12:54.09 | brlcad | sure |
| 12:54.53 | brlcad | rarely need it these days, though .. usually just to check out what the optimizer did |
| 12:58.09 | d-lo | I might have to pick your brain when next I see you then. |
| 12:59.24 | brlcad | some knowledge rot, best to just speak and hit me up with tools at my fingertips, and a wider audience if need be |
| 13:00.39 | d-lo | Well i have a binary in which I do not have the source for, but I know that it uses a certain open sourced library |
| 13:01.07 | d-lo | I am trying to find a specific function call so I can hook into it and watch/log the data flow. |
| 13:01.13 | d-lo | (Personal project btw) |
| 13:01.45 | brlcad | hook into it.. |
| 13:01.58 | brlcad | java? |
| 13:02.18 | d-lo | hook's a bad word to use.... um. place a 'watch point' for logging/viewing in a console. |
| 13:02.42 | d-lo | No, not java. I believe the original language was MSVC6.0 |
| 13:04.55 | TC-Rucho | is there a way to hide/erase the objects that are used for boolean subtraction when drawing a region? |
| 13:05.06 | TC-Rucho | all this wireframing is driving me nuts |
| 13:05.14 | brlcad | hm, that's a pretty hefty goal, even to just watch and log without narrowing down and knowing a lot more about that code |
| 13:05.48 | d-lo | *sigh* i know. |
| 13:06.00 | brlcad | TC-Rucho: I believe you can change how the negatives are drawn that might help |
| 13:06.28 | brlcad | "maybe", but there is no way to turn them off outright without switching to a different render mode |
| 13:06.52 | TC-Rucho | hmm |
| 13:07.00 | d-lo | I have tracked down what exact lib its using, gotten the source for that and have found (in the dissassembled asm) where the headers I want are imported...but after that I am at a loss :/ |
| 13:07.09 | d-lo | Okay, I stop the OffTopic banter for now ;) |
| 13:07.57 | TC-Rucho | brlcad: I don't know where to start to change that right now |
| 13:08.03 | TC-Rucho | any more obvious hint? |
| 13:08.13 | brlcad | TC-Rucho: yeah, hold on |
| 13:08.36 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 13:08.36 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207) |
| 13:16.21 | brlcad | TC-Rucho: hm, i'm not finding the option either, only the one that changes all linewidths |
| 13:16.27 | brlcad | TC-Rucho: something else you can do though |
| 13:16.30 | brlcad | two things actually |
| 13:16.53 | brlcad | one is to utilize ray-tracing more -- it's there to help show the evaluated/shaded result |
| 13:17.18 | TC-Rucho | I don't like the mged GUI, I find it ugly, so I use the console style |
| 13:17.32 | brlcad | with the raytrace control panel open, it supposed to be simple enough to render, turn off the framebuffer, turn on and render, repeat, etc |
| 13:17.34 | TC-Rucho | I do raytrace from time to time to see wtf is going on |
| 13:17.48 | TC-Rucho | yeah, already doing that |
| 13:18.17 | brlcad | another thing you can do, which will entirely depend on your objects |
| 13:18.26 | brlcad | is to display them evaluated instead of unevaluated |
| 13:18.45 | TC-Rucho | that sounds interesting, keep talking |
| 13:18.46 | brlcad | what are you using now to display objects? |
| 13:19.02 | brlcad | draw? e? |
| 13:19.06 | TC-Rucho | draw |
| 13:19.20 | brlcad | so instead of draw, you could use either ev or E |
| 13:19.27 | brlcad | subtlely different results |
| 13:19.50 | brlcad | it'll evaluate the booleans in polygonal mode and show an evaluated polygon |
| 13:20.05 | brlcad | some like it more, sometimes too much, just depends on the model |
| 13:20.30 | brlcad | if the geometry gets too complex, there are limitations to what can be evaluated |
| 13:20.52 | brlcad | it'll give you more wireframe instead of less, of course, but it might help |
| 13:21.03 | TC-Rucho | yeah, I'm working with spheres and it's getting really messy |
| 13:21.54 | brlcad | and if you have an open-gl-enabled mged, there's yet a third thing you can try that displays in shaded mode all the time |
| 13:22.10 | TC-Rucho | which would be? |
| 13:23.41 | brlcad | it's an experimental mode, so use at own caution, and only with ogl display manager, but iirc, it is enabled by turning on z-buffering, turning off lighting, run 'set shaded_mode 2' and redraw your objects |
| 13:24.49 | TC-Rucho | already tried that about an hour ago, and all it does is fill the object with a plain color, no shades, so it's really not useful at all imo |
| 13:25.15 | TC-Rucho | want to see a screenshot? |
| 13:25.49 | brlcad | then it's not enabled correctly |
| 13:26.10 | TC-Rucho | http://tc-rucho.homelinux.net/Scrots/crappy-shade.png |
| 13:26.13 | TC-Rucho | that's what I get |
| 13:26.16 | brlcad | those first two enable/disable steps are required |
| 13:26.23 | TC-Rucho | hmm, let's see |
| 13:26.38 | brlcad | yeah, that's just not enabled correctly |
| 13:27.16 | TC-Rucho | I'll try to enable that with mged gui first, brb |
| 13:27.21 | brlcad | it's not meant to be easy yet. you're using a dev hook at this point, so it's all manual |
| 13:28.27 | brlcad | i might have the toggling off on one of them too, easy enough to tell when it works though |
| 13:29.35 | TC-Rucho | z-buffering on |
| 13:29.37 | brlcad | the real fix for that is in the pipeline, part of the bigger BREP support effort |
| 13:29.41 | TC-Rucho | now the light |
| 13:30.24 | TC-Rucho | lighting off and yet the same thing when redrawing |
| 13:30.26 | TC-Rucho | =/ |
| 13:30.39 | brlcad | there's at least four combinations there |
| 13:30.45 | brlcad | to try |
| 13:30.48 | TC-Rucho | yeah |
| 13:30.52 | TC-Rucho | I'm on my way |
| 13:31.04 | brlcad | i don't have an ogl-enabled build at the moment |
| 13:31.34 | TC-Rucho | ok, this can be really haired, but it's Zbuffer off, lighting on |
| 13:31.57 | brlcad | sounds about right |
| 13:32.24 | TC-Rucho | ok, got to get it working in the console based mged |
| 13:32.31 | TC-Rucho | I'll be back in a minute |
| 13:32.52 | brlcad | what are you working on? |
| 13:33.02 | TC-Rucho | oh, Z clipping must be on too |
| 13:33.43 | TC-Rucho | I'm drawing my webcam for the sake of learning how to use BRL CAD. I've had some rough times trying to move objects (actually still haven't figured out how to move regions in space) |
| 13:33.55 | brlcad | oed |
| 13:34.13 | brlcad | there's a whole tutorial geared towards teaching that |
| 13:34.14 | TC-Rucho | I tried sed and ted (which I found awesomely useful) |
| 13:34.35 | brlcad | sed is for primitives |
| 13:34.43 | brlcad | oed is for everything else |
| 13:34.51 | TC-Rucho | I see |
| 13:34.55 | brlcad | object edit |
| 13:35.15 | brlcad | oed / my_region/path/to/primitive |
| 13:35.25 | brlcad | rot 50 0 0 |
| 13:35.28 | brlcad | accept |
| 13:50.24 | TC-Rucho | wouldn't that commandline be for editing a single primitive instead of a whole region? |
| 14:05.40 | brlcad | nope |
| 14:05.56 | brlcad | the primitive is only required to set an explicit keypoint |
| 14:06.53 | brlcad | so it will rotate about the primary vertex point of the given primitive specified, but apply a matrix between the left-hand and right-hand side for a given /arbitrary/path/to/objects |
| 14:08.12 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 14:08.13 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207) |
| 14:23.03 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 14:45.06 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 14:55.50 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 15:03.20 | TC-Rucho | I was wondering, does brlcad have at least a 1 step-only undo? |
| 15:06.09 | TC-Rucho | guess not |
| 15:06.12 | TC-Rucho | =/ |
| 15:06.27 | TC-Rucho | note to self: always triple check before doing a killtree |
| 15:15.12 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 15:16.05 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 15:38.16 | *** join/#brlcad madant (n=madant@117.196.140.99) |
| 15:55.56 | brlcad | TC-Rucho: it's a two-step undo, cp file.g backup.g, later cp backup.g file.g to undo |
| 15:57.39 | brlcad | best practice is to make backups of your .g file every N timeframes (e.g. daily) so that at worst you've never lost more than N work (e.g. a day's worth) |
| 15:58.52 | brlcad | that'll be addressed with the new gui, but it's still simply not a high priority since the geometry command layer is designed just like the unix command line and is intentionally unforgiving |
| 15:59.29 | brlcad | you could just as well create proc overrides that makes backups for you or prompts for confirmation just like some folks do with rm |
| 16:00.20 | brlcad | again, not something being avoided, just not a priority until shaded displays and the new command layer is in place |
| 16:27.45 | ``Erik | d'lo: uh, a little, mostly quite antiquated, though |
| 16:30.42 | d-lo | Hrm, okay. |
| 16:30.53 | d-lo | Looks like I am on my own :/ |
| 16:31.08 | d-lo | ``Erik: You braving the roads or calling today a wash? |
| 16:31.58 | brlcad | d-lo: it's usually infinitely easier to snoop the wires |
| 16:32.36 | brlcad | if there's any net communication, or port protocol i/o, or even file i/o |
| 16:33.02 | brlcad | a lot easier to meter that doesn't require dissassembly or trying to inject man-in-the-middle code |
| 16:33.19 | d-lo | Well, thats just the issue. ;) I need to see the data BEFORE it gets encrypted. |
| 16:33.22 | ``Erik | this is my rdo |
| 16:33.41 | ``Erik | which is good, as they haven't plowed my neighborhood yet :) |
| 16:34.34 | brlcad | d-lo: ah, then your best bet is probably to run the app through a debugger, break it right before the data is encrypted, then step through the assembly one instruction at a time watching how all the register data changes |
| 16:34.50 | brlcad | very tedius, but doable |
| 16:35.21 | ``Erik | hm, I forget if ndisasm attempts to generate labels or just uses offsets |
| 16:36.15 | brlcad | yeah, there are some intelligent tools that will rebuild from symbols and labels if they are there |
| 16:36.44 | brlcad | another toolset to learn though, debugger is simple low-level |
| 16:36.53 | d-lo | brlcad: Right. Thats the approach I am trying to take. As a step before, since I know its using openSSL, then I am trying to grab the offsets for the functions to make my searching in pure asm easier. |
| 16:37.04 | ``Erik | so you're picking that old project up again? heh |
| 16:37.10 | d-lo | yeah. ;) |
| 16:37.53 | d-lo | I am usin IDA. Its doing a pretty good job thus far, but working on a 20MB binary is kicking my laptop in the nuts :( |
| 16:38.03 | ``Erik | there should be something like a _call directive going on that should make it a lot more readoable |
| 16:38.44 | ``Erik | readable, even |
| 16:39.13 | ``Erik | there should be a "wakethefuckuperik" directive that makes my sentences a lot more readable :D |
| 16:42.19 | brlcad | yay, finally! |
| 16:42.34 | brlcad | g'damn that was more difficult than it should have been |
| 16:45.13 | CIA-40 | BRL-CAD: 03brlcad * r33927 10/brlcad/trunk/src/libged/draw.c: add support to ignore a new '-R' option that implies draw should not resize the view. since the actual resize logic is still in the front-end, we just ignore it (and -A, -o) here. |
| 16:46.53 | CIA-40 | BRL-CAD: 03brlcad * r33928 10/brlcad/trunk/src/mged/chgview.c: add a -R option to the edit_com() interface affecting e/draw/B so that they don't resize/autoview the view if the -R option is provided |
| 16:52.32 | *** join/#brlcad Elrohir (n=kvirc@p5B14E5DC.dip.t-dialin.net) |
| 16:53.29 | TC-Rucho | brlcad: wouldn't it be more conveniente to have oed to work like this?: oed /path/to/group-or-primitive-to-work-with /path/to/reference-primitive <br/> What's the point in telling oed where is it contained? (the rlh path). |
| 16:54.05 | CIA-40 | BRL-CAD: 03brlcad * r33929 10/brlcad/trunk/ (NEWS src/mged/chgmodel.c): |
| 16:54.05 | CIA-40 | BRL-CAD: make the 'make' command use the existing view size when creating new objects by |
| 16:54.05 | CIA-40 | BRL-CAD: utilizing the new -R option on the draw command. this is a change to make's |
| 16:54.05 | CIA-40 | BRL-CAD: behavior when there are no objects displayed since previously, it would create |
| 16:54.05 | CIA-40 | BRL-CAD: an object sized to the view, but then autoview to size the view out. this would |
| 16:54.08 | CIA-40 | BRL-CAD: result in unexpected view changes that would get compounded if the user called |
| 16:54.10 | CIA-40 | BRL-CAD: make/draw/kill repeatedly. |
| 16:54.37 | brlcad | TC-Rucho: it'd be easier to just say "oed object" or "oed /path/to/object" but that would imply automatic keypoints based on "something" (perhaps the center of the bounding box for that object) |
| 16:55.16 | TC-Rucho | brlcad: what about just oed /path/to/group/and/reference-primitive |
| 16:55.32 | brlcad | then where does it apply the matrix? |
| 16:55.43 | TC-Rucho | to the greatest group mentioned in the path |
| 16:55.51 | brlcad | "greatest"? |
| 16:56.05 | TC-Rucho | parent? |
| 16:56.13 | TC-Rucho | for example: |
| 16:56.17 | brlcad | if "path" is the object you wanted to change, then that'd be no different than oed / /path/to/group/and/reference-primitive |
| 16:56.37 | brlcad | so you saved two keystrokes and introduced ambiguity :) |
| 16:56.45 | brlcad | there is just one path |
| 16:57.10 | brlcad | the arguments are the left-hand side of that one path, and the right-hand side |
| 16:57.40 | TC-Rucho | if I want to edit group I go with oed group/and/reference-primitive if I want to edit path I go with oed /path/to/group/and/reference-primitive. Is that ambiguous? |
| 16:57.45 | brlcad | every where there is a slash, you can inject a transformation matrix |
| 16:58.35 | brlcad | no, you're still not understanding what it means to be a path I think |
| 16:58.44 | TC-Rucho | maybe |
| 16:59.02 | brlcad | the tutorial does a pretty good job with examples to explain it in detail, fwiw |
| 16:59.12 | brlcad | including the implications and rationale |
| 17:00.23 | brlcad | but even using a filesystem path metaphor as an example, "oed /path/to/group/and/primitive" could imply that you want to edit the 'path' object or the 'primitive' object in that path'ed context |
| 17:00.58 | brlcad | the only reason you specify a path at all is to obtain a keypoint -- you still have to say what object in what context no matter what |
| 17:01.32 | brlcad | e.g. to qualify instance editing versus global editing |
| 17:01.39 | TC-Rucho | it took me a while to get what was it all about since I was getting a shitty error about "Unable to find solid matching path" (later figured out it was because I did not draw one of the objects) |
| 17:02.15 | TC-Rucho | hmm, I'll have to experiment about that |
| 17:02.22 | brlcad | yes, you have to load the objects for editing (via draw/e/B) before you can oed, sed works that way too |
| 17:02.46 | brlcad | 'who' tells you what objects are editable |
| 17:04.01 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 17:04.01 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207) |
| 17:04.03 | brlcad | another simple example, you have a room with a bed and a chair, constructed with some primitives .. there's a "room", "chair", and "bed" object as well as their primitives in the database |
| 17:04.15 | TC-Rucho | I don't yet see the difference in doing oed /combination region/primitive and oed / region/primitive |
| 17:04.40 | brlcad | "oed / room/chair/leg/arb8" means "move the room" |
| 17:04.52 | TC-Rucho | aye |
| 17:05.07 | brlcad | "oed /room chair/leg/arb" means "move just that one chair in that room" |
| 17:05.25 | brlcad | "oed / chair/leg/arb8" would mean "move all chairs" |
| 17:06.11 | TC-Rucho | really?, I would have bet that "oed / chair/leg/arb" meant "move just that one chair" |
| 17:06.34 | brlcad | they are named references |
| 17:06.56 | brlcad | so if you use 'chair' as a name elsewhere and you move /chair, you move everything |
| 17:07.41 | brlcad | depends how your hierarchy is contstructed |
| 17:08.39 | brlcad | it's a basic set of directed acyclic graphs where you can apply a matrix to any node in the graph |
| 17:08.51 | brlcad | same concept as for any other CAD system really |
| 17:09.52 | brlcad | main difference is different terms, assemblies regions parts combinations primitives groups |
| 17:10.28 | TC-Rucho | well, I've used AutoCAD, totally different paradigm, and when I reached the oed part, I was confused as hell, because I thought of it as a referencing system like AutoCAD's move/copy/whatever where one selects a group of objects, then a reference point, and an end point |
| 17:10.54 | TC-Rucho | so I thought of oed as oed /group/to/work/with /path/to/reference-primitive |
| 17:10.58 | ``Erik | ow |
| 17:11.09 | ``Erik | got ~6-7" of snow, just finished shoveling |
| 17:11.11 | brlcad | main difference with a system like autocad is that every object (well, most objects) are automatically wrapped in a container object by default |
| 17:11.34 | brlcad | so to change all instances, it involves a more explicit action usually |
| 17:12.17 | brlcad | TC-Rucho: oed is like "oed /group/to/work/with /path/to/reference-primitive" :) |
| 17:12.31 | brlcad | your words and what those slashes mean are just not connecting |
| 17:12.56 | brlcad | means that this is some valid path: /group/to/work/with/path/to/reference-primitive |
| 17:13.21 | brlcad | and you want to edit the 'path' object instance referenced in the 'with' object |
| 17:13.37 | brlcad | using 'reference-primitive' as the keypoint |
| 17:14.32 | brlcad | (more specifically, the 'reference-primitive' keypoint in the '/group/to/work/with/path/to' context) |
| 17:15.46 | brlcad | it really is one of those lightbulb issues that should suddenly go off eventually and you'll wonder how you ever understood it differently |
| 17:16.12 | TC-Rucho | right, but still, I don't quite see the difference in doing oed / /region/primitive and oed /group region/primitive |
| 17:16.31 | TC-Rucho | hmm |
| 17:16.49 | TC-Rucho | I tried both, and they work the same way |
| 17:17.12 | brlcad | they'll give the same end-result until you have 'region' used in multiple places |
| 17:17.22 | brlcad | (not in 'group') |
| 17:18.44 | TC-Rucho | ok, I have just modelled some basic stuff, now I'll complete the webcam model, and maybe I'll get what you mean once the modell get's bigger and more complex (although I think I would need to reuse some regions in order to see what you mean) |
| 17:18.48 | brlcad | seriously, oed tutorial |
| 17:18.51 | brlcad | it will explain a lot |
| 17:19.12 | TC-Rucho | I've been reading it for a long while now |
| 17:19.30 | TC-Rucho | it's just that it puzzled me out since I had a preconcept about how it should work |
| 17:21.22 | brlcad | hm, that discussion gave me an idea for a terminology doc |
| 17:22.46 | TC-Rucho | yeah, that left hand path and right hand path notation is not what I would call "clear" but anyway |
| 17:24.24 | brlcad | having to specify the path to a primitive for a keypoint is really the point of confusion |
| 17:25.37 | brlcad | that's a technical limitation by the fact that there is no keypoint and deriving an implicit keypoint based on bounding box sizes is questionable (someone will still probably do it eventually) |
| 17:34.14 | d-lo | I say: Take the average of the 8 points of the Boundingbox and make that default keypoint for oed. |
| 17:37.21 | TC-Rucho | brlcad: I got it now, the only way to understand the difference is to group some regions, and implicitly reusing the regions by making copies of the group |
| 17:37.29 | TC-Rucho | it is all clear now |
| 17:40.41 | ``Erik | hrmmm |
| 17:40.55 | ``Erik | *snrkt* |
| 17:47.57 | brlcad | heh |
| 17:48.28 | brlcad | d-lo: that is the idea, what I meant by "someone will still probably do it eventually" |
| 17:49.10 | brlcad | the problem then becomes unexpected behavior issues since that keypoint isn't exactly easily worked with until a variety of other commands are updated too |
| 17:49.21 | CIA-40 | BRL-CAD: 03brlcad * r33930 10/brlcad/trunk/doc/ (2 files in 2 dirs): document the new -R option for e/draw/B in the old htmls docs and for B in the new docbook docs |
| 17:49.45 | brlcad | rotate and translate something around, add an object, reverse the rotation and you find out it's not reversible |
| 17:50.39 | d-lo | Well thats just operator error/dumbness. Code can't fix that ;) |
| 17:51.00 | ``Erik | *nod* plus the issue when you have something like a bigassed box with a tiny little cylinder sticking way out and the keypoint is off in space instead instead of where you think it 'should' be |
| 17:51.49 | ``Erik | ponders allowing keypoints to be manually selected and saved as attr's to be future default for that comb |
| 17:51.51 | brlcad | d-lo: right, but usability and interface design can seriously make is a non-issue vs a major/subtle cause for confusion and unexpected behavior |
| 17:52.41 | brlcad | yeah, some what to manage keypoints more as more than data values, second-class citizens in the db sense would be good |
| 17:53.15 | brlcad | having things like 'l' and analyze report the keypoints would help, visually showing keypoints, etc |
| 17:53.26 | ``Erik | ooh, here's a good case to screw the 'center of bb' approach, imagine a cylinder with one side slightly cupped (rcc - sph), that'd come out close to the center of the sphere, not the physical object :) |
| 17:54.45 | brlcad | negatives are the worst, the expected keypoint is usually the center of mass on the positive evaluated space |
| 17:54.54 | brlcad | s/mass/volume/ |
| 17:55.39 | ``Erik | and "wait while we run rtweight to find the cm" is probably not tolerable :D |
| 17:55.47 | brlcad | :) |
| 17:57.14 | d-lo | ``Erik: that might mess up a center of mass approach, but not for center of BB. especially if the center of BB is being used for a simple default keypoint for oed. |
| 17:57.15 | ``Erik | out of curiosity, when nurbs is working to satisfaction... will it be 'just another primitive', or are we going to push to be kinda a nurbs only engine (mebbe with construction information stored to allow old style editing)? |
| 17:58.20 | ``Erik | um, bb is computed in a way that it should be close to the union of all primitives in the tree, even if there're subtractions, iirc |
| 17:59.46 | ``Erik | if this prims minX < bb minX, bb minX = this prims minX; ... |
| 17:59.57 | d-lo | so a bounding box is *not* maxX, minX, maxY, minY, max Z, min Z ? |
| 18:00.01 | brlcad | just another primitive |
| 18:00.10 | CIA-40 | BRL-CAD: 03brlcad * r33931 10/brlcad/trunk/doc/docbook/system/man1/en/ (Makefile.am g_qa.xml gqa.xml): the mged command is gqa instead of g_qa, rename accordingly |
| 18:00.15 | brlcad | with a bunch of support to go from csg->nurbs on the fly |
| 18:00.44 | brlcad | so we can still leverage the optimizations and guarantees if there are implicits |
| 18:01.05 | ``Erik | try it out, dave, make a sub comb and do make_bb on it :) |
| 18:01.09 | brlcad | but make it even easier to visualize and analyze anything via the bridge |
| 18:02.18 | ``Erik | aight, I was under the impression that nurbs could represent any geometry we currently have perfectly (within floating point fuzz), so *shrug* was just wondering. it's my day off, my brain ain't fully in gear, nor will it be |
| 18:03.01 | brlcad | does a final distcheck, suggests others that might care about release compilation do so as well for their favored environment |
| 18:04.01 | brlcad | ``Erik: it can for the most part .. it's just wildly more complex to store and deal with than other primitives and about an order of magnitude more data values to represent the same thing |
| 18:04.10 | d-lo | ``Erik: Hrm, just tried it and it performed as expected it to :/ |
| 18:04.26 | brlcad | sphere goes from having about 6 values to over a hundred for a decent approximation |
| 18:04.36 | brlcad | similar for arb8's |
| 18:05.12 | d-lo | ``Erik: ah, I see what you mean now. |
| 18:05.21 | brlcad | instead of 24 values, suddenly becomes about 300 values |
| 18:22.36 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 18:23.10 | ``Erik | thought nurbs could do a sphere in 2 patches |
| 18:23.34 | ``Erik | or was it 4 (tetrahedron-like) |
| 18:24.27 | ``Erik | d-lo: how you expect things to work probably isn't how joe blow off the street does :D you're tainted |
| 18:29.56 | d-lo | Well, I think the number of tainted users > number of Joe Blow Off the Streets ;) |
| 18:47.26 | *** join/#brlcad bitminer (n=bitminer@h96-60-82-113.vrnawi.dsl.dynamic.tds.net) |
| 18:47.33 | ``Erik | in the tiny self-selecting community you see here, sure, but there are what, 670,000 known downloads? I'm imagining a fairly large number of those are unvoiced first time users :) |
| 18:54.37 | d-lo | won't mention his script "DownloadMetricPadder.sh" |
| 18:54.43 | d-lo | :D |
| 18:55.55 | d-lo | but you are right, there are prolly alot of first timers that end up shying away :/ |
| 18:58.48 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 18:58.48 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207) |
| 18:58.51 | brlcad | TC-Rucho: you have a full tcl interp there so that can be used |
| 18:58.56 | ``Erik | tcl sub-expressions |
| 18:59.00 | TC-Rucho | I checked some tcl's docs and according to them, [expr {2*2}] should be fine to include in an input line |
| 18:59.02 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) |
| 18:59.08 | brlcad | yep |
| 18:59.11 | TC-Rucho | but it keeps telling me error |
| 18:59.19 | brlcad | only caveat is default globbing |
| 18:59.25 | TC-Rucho | mged> in fuck.s rcc 0 0 0 [expr {2*2}] [expr {2*2*2}] 0 5 |
| 18:59.26 | TC-Rucho | Error: extra characters after close-brace |
| 18:59.31 | ``Erik | * will mess up globbing |
| 19:00.03 | brlcad | we have a globbing evaluation mode enabled by default so that things like "draw *.r" will work |
| 19:00.34 | brlcad | which includes character classes, draw [a-z]*.c |
| 19:00.48 | brlcad | so those conflict with tcl evaluation |
| 19:00.54 | TC-Rucho | seems that I should disable globbing to input stuff, but still, is there a more elegant way? |
| 19:00.55 | brlcad | you can have one or the other, default is globbing |
| 19:00.58 | ``Erik | [expr {2\*2}] works, or you can turn off globbing |
| 19:01.05 | brlcad | you can toggle it off with: set glob_compat_mode 0 |
| 19:01.12 | brlcad | or you can escape the globbing chars |
| 19:01.37 | brlcad | in fuck.s rcc 0 0 0 \[expr {2\*2}\] \[expr {2\*2\*\2}\] 0 5 |
| 19:02.11 | TC-Rucho | I think it would be better to scape globbing rather than tcl expressions |
| 19:02.26 | TC-Rucho | like draw \*.r |
| 19:02.34 | TC-Rucho | and keep [expr {2*2}] working |
| 19:02.37 | ``Erik | odd choice of primitive name O.o |
| 19:02.55 | brlcad | probably a 'part' primitive ;) |
| 19:03.12 | brlcad | ah, rcc, guess it's an approximation |
| 19:03.28 | ``Erik | people are more apt to treat the geometry tree like a filesystem than an expression engine *shrug* |
| 19:03.28 | TC-Rucho | ``Erik: heh, that's because this tcl expression thing was getting on my nerves |
| 19:03.45 | TC-Rucho | lol |
| 19:03.58 | TC-Rucho | @brlcad | ah, rcc, guess it's an approximation <--- lol xD |
| 19:04.06 | brlcad | TC-Rucho: it's been oft-discussed, how to get the best of both worlds -- the folks that want globbing would cry bloody murder, and they're the expert modelers |
| 19:04.06 | ``Erik | if you don't use globbing, turn it off, set that to be default in your .mgedrc *shrug* it's all good |
| 19:04.49 | brlcad | those that know how to write tcl can easily just set the var and be done with it |
| 19:05.50 | TC-Rucho | tcl == ugly mix of C and... bash? anyway, we'll have lisp bindings eventually and everything will be good |
| 19:07.03 | ``Erik | I think tcl is older than bash, but it does take cues from the bourne/korn family |
| 19:08.13 | ``Erik | (dang linux weenies, all not knowin' the history of it all :) |
| 19:09.02 | ``Erik | huh, bash precedes tcl by a year, neat :) |
| 19:10.20 | TC-Rucho | (: |
| 19:18.32 | brlcad | TC-Rucho: awesome -- native bindings? |
| 19:18.49 | TC-Rucho | brlcad: hm? |
| 19:19.15 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 19:21.06 | TC-Rucho | brlcad: well, my usability goal is to get a lisp repl for mged, so that one can use lisp directly to input commands, math and scripting |
| 19:22.05 | bitminer | While were on the topic of TCL... any one have difficulty building lib Bacon Lettus and Tomato ... libBLT in windows. I am getting error : error LNK2019: unresolved external symbol _TclInitSubsystems referenced in function _TkConsoleCreate |
| 19:22.30 | bitminer | Need me a BLT right now. |
| 19:22.43 | TC-Rucho | .. bacon, lettus, tomato... that sounds like a salad |
| 19:22.53 | louipc | sandwich |
| 19:23.00 | TC-Rucho | right, sandwitch |
| 19:23.03 | bitminer | It's more like C soup |
| 19:24.01 | brlcad | TC-Rucho: right, but binding to mged commands how? you can bind straight to the lib, through the mged binary (ugh), through a custom interp, etc |
| 19:24.30 | brlcad | would be awesome to have a swig interface to libged so there'd be bindings available in everything they support |
| 19:24.36 | bitminer | it is externed via extern void TclInitSubsystems _ANSI_ARGS_((CONST char *argv0)); in tkConsole.c |
| 19:24.59 | bitminer | wraped in some suspicous #ifdefs |
| 19:25.14 | brlcad | bitminer: hm, you're compiling using the msvc build files or autotools? |
| 19:25.36 | bitminer | Was trying autotools in Cygwin. I have had more luck in msvc |
| 19:25.41 | bitminer | so msvc for now |
| 19:26.00 | TC-Rucho | brlcad: I have not even started with that, what I've said is the 1st global usability goal. I'm just giving my first steps modelling with brlcad (you may have noticed already). Once I know it enough so as to make improvements I'll grab the source and/or make the lisp repl using bindings to libmged or whatever I see fits best |
| 19:26.16 | brlcad | the msvc8 files should be the most up-to-date and are what are used to make releases |
| 19:26.36 | bitminer | I have done some Swig in the past binding C# to C++ in linux allwoing Windforms apps wirtten in windwos to be run in Linux on Mono |
| 19:26.51 | brlcad | the 9 files shouldn't be far behind, the other dir relies on cmake but only compiles the libs |
| 19:27.19 | bitminer | I have noticed that the msvc files only support release |
| 19:27.32 | brlcad | that's a bob-ism |
| 19:27.39 | brlcad | he got tired of managing both |
| 19:27.45 | bitminer | This was one of my first issues and MSVC defaults to debug on start up. I emailed this to the mailing list |
| 19:28.12 | bitminer | bob-ism? |
| 19:28.24 | brlcad | bob, one of the devs |
| 19:28.38 | brlcad | he does a variety of quirky things :) |
| 19:28.40 | bitminer | Ok |
| 19:29.02 | bitminer | Are you using CMake to generate the VS project files? |
| 19:29.04 | brlcad | doesn't talk much, just likes to quietly code |
| 19:29.10 | brlcad | no |
| 19:29.14 | brlcad | though that would be cool |
| 19:29.26 | bitminer | It is a suposed rumored feature of CMake |
| 19:29.33 | brlcad | yes, it is |
| 19:29.45 | brlcad | and it works -- that's the other cmake-based build I mentioned that we have |
| 19:29.52 | brlcad | it just doesn't build everything |
| 19:30.28 | brlcad | our build system is pretty big.. takes many weeks/months to set everything up that we need with any build tool |
| 19:30.37 | bitminer | Ok so I could possibly use Cygwin autotolls or CMake, Windows env Cmake, or Windows env Visual Studio |
| 19:30.58 | ``Erik | hrm, here's a posting claiming that swig doesn't play with lisps (but does with scheme and erlang) |
| 19:31.00 | brlcad | well yes and no, more no than yes |
| 19:31.11 | ``Erik | though uffi/cffi around libged would be neat |
| 19:31.17 | brlcad | bitminer: you can use autotools or the msvc8/msvc9 project files to get a full build |
| 19:31.25 | brlcad | the cmake build files will only build the libraries |
| 19:31.42 | bitminer | Ok got it thanks |
| 19:31.43 | brlcad | we have like two dozen libraries |
| 19:31.48 | brlcad | and over 400 binaries |
| 19:32.22 | bitminer | holy cats |
| 19:32.28 | brlcad | mged is just one of them :) |
| 19:32.46 | brlcad | granted, it's the biggest by far |
| 19:33.03 | d-lo | heh, binary envy. |
| 19:33.23 | brlcad | most of that 400 are unix-style commands that do one thing and are streamable so you can tie them together for much more powerful functionality |
| 19:34.01 | brlcad | ala cat | awk | sed | grep, ours focus on geometry, images, and data file processing |
| 19:34.22 | bitminer | How do they communicate, MPI, sockets, carrier pigions? |
| 19:34.27 | starseeker | unix pipes |
| 19:34.35 | starseeker | bites us when working on Windows though |
| 19:34.40 | brlcad | pipes and sockets |
| 19:34.54 | bitminer | got it |
| 19:35.06 | bitminer | Look a boost for IPC? |
| 19:35.27 | brlcad | the SGI_Cube example on the wiki shows a couple commands being used for image processing/conversion |
| 19:35.43 | brlcad | yeah, I've looked at it before .. what about it? :) |
| 19:35.51 | bitminer | Inter Process Communication (IPC) |
| 19:36.24 | ``Erik | yeah, we know what ipc is... :) |
| 19:36.33 | bitminer | Most of the code looks to be C. What is your take on C++ in this project and Boost C++ and 0x support |
| 19:37.11 | ``Erik | the work in rt^3 is using boost at the moment, and c++ is starting to creep into the codebase :/ |
| 19:37.15 | brlcad | most of the bigger project infrastructure for the new modeling interface is being done in C++ (using boost and stl heavily) |
| 19:37.26 | brlcad | all the new brep/nurbs work is c++ |
| 19:37.43 | bitminer | So it is an option then? |
| 19:38.11 | brlcad | all of our existing core libs are going to stay pure C (libbu, libbn, librt, libwdb, etc) |
| 19:38.21 | brlcad | but new code, it's an option |
| 19:38.37 | bitminer | OK. Will Boost compile on all your platforms? |
| 19:39.10 | brlcad | it's just not cool to be half-assed about it, using little tidbits of C++ throughout a code that is 95% plain C isn't cool |
| 19:39.16 | brlcad | just makes for bad C++ and bad C |
| 19:39.34 | brlcad | yeah, most of boost compile's fine -- at least no issues so far |
| 19:39.55 | bitminer | Yes I can understand wanting to maintain consistency. |
| 19:39.56 | ``Erik | yeah, if someone commits c++ stuff in a .c file, I'll break their kneecaps O.o I'll try to be gentle about kneecap breaking if it's c99 |
| 19:39.58 | ``Erik | :D |
| 19:40.07 | brlcad | the new parametric constraint solving system that madant has been working on is the closest to causing boost to snap, but it's been fine |
| 19:43.52 | brlcad | ponders gsoc projects |
| 19:44.12 | bitminer | Yes I think I read about this using Spirit? GSOC proj? for parametric modeling |
| 19:44.18 | brlcad | yep |
| 19:45.06 | bitminer | Well I'll keep banging on the Win32 build. |
| 19:45.07 | brlcad | ``Erik: irix64 said he has a patch for you to review on his site if you're interested, dunno when he'll be back on |
| 19:45.30 | louipc | hehe he pms me about the patches too |
| 19:45.36 | ``Erik | ok |
| 19:45.38 | brlcad | bitminer: send the error to the devel mailing list, To Bob or whomever ;) |
| 19:45.39 | louipc | but he disappears before I can respond |
| 19:45.46 | ``Erik | I'll keep an eye out for him |
| 19:45.54 | brlcad | sounds like it might be something new -- tcl was just upgraded |
| 19:46.11 | brlcad | might be easier to install activestate's tcl and then just change the linkage to use that instead of building |
| 19:46.18 | bitminer | Ok will do.. There were multiple. I fixed most just stuck on libBLT at the moment. |
| 19:46.22 | brlcad | louipc: really? jeez |
| 19:46.32 | brlcad | louipc: let me know if it gets to be a problem |
| 19:46.41 | louipc | it's all cool |
| 19:46.49 | brlcad | k |
| 19:47.20 | brlcad | starseeker: the tcl folks liked your archer screenie |
| 19:47.33 | ``Erik | he needs a lot of steering and handholding, I'd hate to see his enthusiasm crushed, though :) |
| 19:47.38 | starseeker | oh, the tire wizard? :-) |
| 19:47.43 | brlcad | they (jokingly) said the gui looked dated, referring to ttk updates |
| 19:48.14 | brlcad | but that the tire looked great ;) |
| 19:48.17 | ``Erik | (does ttk mean that aquatk is now a dead-end) |
| 19:48.20 | starseeker | would love to take a stab at using ttk |
| 19:48.27 | brlcad | ``Erik: hardly |
| 19:48.43 | ``Erik | <-- has managed to avoid that entire chunk for the most part |
| 19:49.16 | ``Erik | I made a button in wish once, otherwise I just imitate code already there for my patches and hope I guessed right :) |
| 19:50.22 | starseeker | had to fight the busting of Archer with the lastest tcl/tk as an excuse to take Archer apart and put it back together using ttk widgets |
| 19:50.39 | starseeker | er, fight using it as an excuse |
| 19:54.14 | starseeker | figures Archer is having enough trouble without me messing with it like that ;-) |
| 19:56.51 | starseeker | brlcad: Are you close to tagging for the release? |
| 20:04.22 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 20:11.19 | ``Erik | reboots brlcad's new machine again |
| 20:11.32 | starseeker | ``Erik: is that the new bz server? |
| 20:11.51 | ``Erik | yeah |
| 20:12.18 | ``Erik | I'm being aggressive about keeping it bleeding edge until everything is migrated to it, so we have a good launch point |
| 20:12.26 | ``Erik | bleeding stable edge, that is |
| 20:12.35 | starseeker | ah |
| 20:12.51 | starseeker | should migrate his stuff to that one and free up some space |
| 20:13.37 | ``Erik | and it's back up |
| 20:13.57 | starseeker | ``Erik: At some point can you show me how to get to that box? |
| 20:14.00 | ``Erik | looks like it has an 80 gig drive in it |
| 20:14.09 | starseeker | er, well nevermind :-) |
| 20:14.25 | starseeker | will just suck it up and get a terabyte drive |
| 20:14.33 | ``Erik | hm, I don't see you in the passwd file |
| 20:14.41 | d-lo | I thought it was supposed to have >80 |
| 20:15.13 | ``Erik | oh, wait, 120g |
| 20:15.41 | ``Erik | that's odd, there may be an unallocated partition |
| 20:18.35 | ``Erik | aah, reading it wrong, 80g for home |
| 20:18.49 | ``Erik | refers back to where he stated his brain would not be functioning today |
| 20:25.43 | starseeker | was dbbinary the one that got renamed to bo? |
| 20:26.26 | starseeker | checks NEWS |
| 20:29.15 | starseeker | ah, yes |
| 20:39.35 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 20:39.35 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207) |
| 20:41.17 | CIA-40 | BRL-CAD: 03starseeker * r33932 10/brlcad/trunk/doc/docbook/system/man1/en/ (9 files): Add more MGED docbook man pages by Janine and Cliff |
| 20:59.39 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 20:59.39 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207) |
| 21:12.56 | *** join/#brlcad cad33 (n=424ca4ee@bz.bzflag.bz) |
| 22:24.34 | TC-Rucho | hey guys, if you like to do inline math just like me and hate that \[expr {mathstuff}\] gay sh*t, you can type in => \[proc unknown args {set ::that \[expr $args\]}\] so you can just do \[mathstuff\] (: |
| 22:25.37 | TC-Rucho | this works by setting the unknown handler to perform an [expr ...] to the screwed up input (math without preceding expr) |
| 22:25.44 | TC-Rucho | hope you like it |
| 22:26.35 | TC-Rucho | note: and desabling globbing it get's even better |
| 22:28.02 | TC-Rucho | brlcad: should I add this to the brlcad-wiki as a tip? |
| 22:28.30 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 22:34.41 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 22:40.51 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-39.sbndin.btas.verizon.net) |
| 23:03.58 | *** join/#brlcad tc-rucho1 (n=tc-rucho@190.191.172.28) |
| 23:05.02 | *** join/#brlcad tofu (n=sean@bz.bzflag.bz) |
| 23:07.56 | *** join/#brlcad tofu (n=sean@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad bitminer (n=bitminer@h96-60-82-113.vrnawi.dsl.dynamic.tds.net) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad smurfette (n=user@c-69-242-189-29.hsd1.mo.comcast.net) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad MinuteElectron (n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) [NETSPLIT VICTIM] |
| 23:07.56 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT VICTIM] |
| 23:09.27 | *** join/#brlcad elite01 (n=omg@cl-213.dus-01.de.sixxs.net) |
| 23:11.06 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1177871980.dsl.bell.ca) |
| 23:27.23 | *** mode/#brlcad [+o tofu] by ChanServ |
| 23:27.50 | ``Erik | *yawn* |
| 23:28.21 | ``Erik | bar commercials on tv heh |
| 23:28.32 | elite01 | some movie on vlc heh |
| 23:29.04 | ``Erik | I was laughing at the existance of, not just commenting on what I was seeing :D vlc is good stuff, though |
| 23:32.57 | *** join/#brlcad bitminer69er (n=bitminer@h96-60-82-113.vrnawi.dsl.dynamic.tds.net) |
| 23:33.05 | brlcad | tc-rucho1: hah, that's a really fantastic way to abuse tcl |
| 23:36.21 | brlcad | great hack/tip |
| 23:57.18 | ``Erik | \[mathstuff\] makes me think LaTeX |
| 23:57.55 | ``Erik | that'd be awesome if tcl were kicked to understand tex math mode, one step closer to literate programming :D |
| 23:58.35 | ``Erik | (or generate tex from the tcl) |
