| 01:18.44 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) |
| 02:46.24 | CIA-55 | BRL-CAD: 03starseeker * r51148 10/brlcad/trunk/regress/dsp.sh: regress-dsp failing in odd pathnames distcheck - add quotes |
| 02:53.31 | CIA-55 | BRL-CAD: 03starseeker * r51149 10/brlcad/trunk/regress/asc2dsp.sh: Add quotes in asc2dsp test as well. |
| 03:29.37 | CIA-55 | BRL-CAD: 03crdueck * r51150 10/brlcad/trunk/src/librt/primitives/arb8/arb8.c: added rt_arb_volume() for arb8 |
| 04:20.40 | brlcad | andrei_: that's looking like good progress -- some changes I'd like involve making the script a little more robust, even if bit is for testing purposes |
| 04:23.28 | brlcad | changing it to /bin/sh and replacing the bash constructs with posix-compliant constructs, adding proper indentation, not assuming tpkg is in current dir (what's wrong with PATH??), and ideally without the sleep (but that's a bit harder) |
| 04:24.20 | andrei_ | brlcad |
| 04:24.39 | andrei_ | could you please tell me where to documment about how to replace sleep |
| 04:25.01 | andrei_ | all that I found was wait, but that didn't do it and I don t know what to search for. |
| 04:25.15 | brlcad | oh, and adding checks for your assumed args, printing usage as needed |
| 04:26.15 | andrei_ | also, should the script create a file that contains on each line <k iterator value > < j iterator value > <number of packages sent > |
| 04:26.22 | andrei_ | seems easier to read / work with |
| 04:26.38 | brlcad | 'wait' won't/can't work as written |
| 04:26.49 | brlcad | wait waits for the process to terminate |
| 04:27.01 | andrei_ | yes, and it never does |
| 04:27.03 | brlcad | if the server terminates, the client cannot connect, no? |
| 04:27.15 | andrei_ | yes |
| 04:27.33 | andrei_ | what I think I need is to " simulate" somehow two different terminals |
| 04:28.18 | brlcad | sounds overly complicated |
| 04:28.28 | brlcad | all you need is to know when the server is started |
| 04:28.57 | brlcad | so you could make tpkg just tell you |
| 04:29.42 | brlcad | either indirectly, like by having it write a message to the log that you could check; or directly by making it respond to a signal handler, for example |
| 04:30.19 | andrei_ | probably the signal handler is more elegant, but it will take a bit of time to see how it works |
| 04:30.33 | andrei_ | I ve done some signal handling in asm, should be somewhat similar. |
| 04:30.36 | brlcad | then you don't start the client until you know the server is started by hecking |
| 04:30.42 | brlcad | s/hecking/checking/ |
| 05:09.19 | CIA-55 | BRL-CAD: 03crdueck * r51151 10/brlcad/trunk/src/librt/primitives/table.c: updated the rt_functab entry for arb to include the new volume callback |
| 05:11.21 | brlcad | crdueck: does that work for other arbs? arb6, arb7's etc? |
| 05:15.07 | crdueck | brlcad: yes i tested it for arb4..8. that commit message is a bit misleading |
| 05:31.51 | brlcad | crdueck: cool |
| 05:32.15 | brlcad | the function looked safe since presumably the arb4 areas would just be zero |
| 05:32.52 | brlcad | (for the non arb8 cases) |
| 05:39.26 | crdueck | brlcad: exactly. for the non arb8 cases, bn_mk_plane_3pts() doesnt return succesfully and the continue takes care of "adding 0" to the volume |
| 05:42.16 | crdueck | i mean, when it tries to find the volume of an arb4 area that isnt there, the for loop just continues |
| 05:46.29 | CIA-55 | BRL-CAD: 03brlcad * r51152 10/brlcad/trunk/NEWS: consolidate the new manual page additions tom worked on into one entry for all four (asc2dsp, dsp, asc2pix, and asc2g). (plus, recommit since r51121 commit message was nondescript) |
| 05:49.33 | CIA-55 | BRL-CAD: 03brlcad * r51153 10/brlcad/trunk/NEWS: Across the board, Tom's made several dozen improvements and corrections to various manual pages in response to issues found by Eric Raymond's doclifter. also tidyed up some spacing and formatting. |
| 05:50.21 | brlcad | starseeker: you know -F has a fairly complex format it supports .. there some reason rtwizard.tcl is trying to parse it out instead of passing it along? |
| 05:50.57 | brlcad | I use remote framebuffers all the time, for example: -Fhostname.brlcad.org:3 |
| 05:52.14 | brlcad | or if_disk file buffers, memory buffers, etc |
| 05:59.24 | CIA-55 | BRL-CAD: 03brlcad * r51154 10/brlcad/trunk/src/libged/wdb_obj.c: put is a new command, reference the right callback |
| 06:00.46 | CIA-55 | BRL-CAD: 03brlcad * r51155 10/brlcad/trunk/src/tclscripts/mged/build_region.tcl: call get/put/adjust directly instead of going through the deprecated wdb_obj db interface |
| 06:01.31 | CIA-55 | BRL-CAD: 03brlcad * r51156 10/brlcad/trunk/TODO: quick-test the build_region command in mged to make sure it works after recent get/put/adjust changes |
| 06:06.08 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 06:38.35 | *** join/#brlcad andrei_ (~andrei_@82.76.146.19) |
| 12:08.46 | CIA-55 | BRL-CAD: 03bob1961 * r51157 10/brlcad/trunk/src/libged/rtwizard.c: Quoting all arguments used to create the string for the call to CreateProcess(). Minor cleanup. |
| 12:17.05 | *** join/#brlcad cristina (~quassel@188.24.50.251) |
| 12:49.43 | brlcad | good morning cristina et al |
| 12:50.11 | cristina | good morning brlcad |
| 13:14.59 | CIA-55 | BRL-CAD: 03bob1961 * r51158 10/brlcad/trunk/src/libged/wdb_obj.c: Removed wdb_put_tcl. |
| 14:04.54 | CIA-55 | BRL-CAD: 03anrgmrty * r51159 10/brlcad/trunk/src/conv/g-voxel.c: ZERO() macro used for comparison with 0.0 instead of previously used inefficient comparison |
| 14:23.33 | starseeker | brlcad: no good reason really - Bob and I had already discussed needing to properly handle/pass through more of rt's args |
| 14:24.01 | starseeker | was just coding for the cases I could think of offhand - didn't realize the -Fhostname.brlcad.org:3 syntax was there even |
| 14:24.27 | brlcad | why handle any cases at all though, that's going to be a maintenance pain |
| 14:24.37 | brlcad | can't just pass everything through? |
| 14:24.52 | starseeker | I wanted the --long-opt style args, for one |
| 14:25.06 | starseeker | the -F case probably can just pass through |
| 14:25.20 | brlcad | if rtwizard has it's own args, just have it recognize them and strip them |
| 14:25.33 | brlcad | then everything else goes through and there's no need for all those lines of code |
| 14:26.45 | starseeker | a lot of the lines have to do with color/ghost/edge object lists |
| 14:26.50 | brlcad | otherwise, it's just going to be crazy brittle in a year after rtwizard is no longer the focus any time an rt arg changes (which has shown to be rather regular) |
| 14:27.12 | starseeker | brlcad: at the moment, we don't support most of the rt args |
| 14:27.21 | brlcad | so those are all rtwizard args, they get stripped and processed |
| 14:27.24 | starseeker | the plan is to just pass them through |
| 14:27.58 | brlcad | "we don't support most of the rt args" .. that's exactly my point! |
| 14:28.02 | brlcad | you shouldn't have to |
| 14:28.06 | starseeker | pretty much - I'd have to think whether rtwizard can live without knowledge of the framebuffer |
| 14:28.16 | brlcad | if rtwizard has to know about rt args, it's already failed |
| 14:28.38 | brlcad | (beyond the implementation details of it setting up rt calls) |
| 14:28.46 | brlcad | rtwizard's arg processing |
| 14:28.55 | starseeker | shakes his head - directing output from multiple distinct tools to the same framebuffer requrires more than passing through args |
| 14:29.19 | brlcad | example? |
| 14:29.30 | brlcad | (as it pertains to an rtwizard arg) |
| 14:33.43 | brlcad | at a minimum, it should be possible to either entirely pass through framebuffer args (-F, -s, -w, -n, etc) or entirely pass through rt args (-p, -j, -P, -x, etc) |
| 14:34.40 | brlcad | but I'd think you could actually pass through most, if not all, as rt args -- especially after a first pass that identifies the pieces rtwizard needs for compositing (like -s, -w, -n, -F) |
| 14:35.15 | starseeker | the problem is, how does rtwizard distinguish rt args (color image) from rt args (ghost image) from rtedge args? |
| 14:36.05 | starseeker | for the ghost image, non-rt tools need to know about the framebuffer |
| 14:36.24 | starseeker | but won't want most of the other args |
| 14:36.42 | starseeker | (sorry about conversational delay, friggin internet went out on me) |
| 14:37.46 | starseeker | I had envisioned an --rt-color-options "-a -b -c" mechanism that lets people specify flags to pass through specifically to each "stage" of image generation |
| 14:38.43 | starseeker | so --rt-color-options --rt-ghost-options and --rt-edge-options (or something like that) where people could specify them |
| 14:41.35 | brlcad | my point was that rtwizard shouldn't even try to distinguish where it doesn't matter (which for most args it doesn't) |
| 14:42.05 | starseeker | that would have to be systematically checked - I didn't want to make the assumption that args wouldn't matter |
| 14:42.24 | brlcad | there certainly are args specific to rtedge, for example, but those would have to be wrapped in an rtwizard arg or otherwise somehow understood by rtwizard anyways |
| 14:42.31 | starseeker | and even if it's true now, what happens if a tool suddenly makes use of an arg in the future? |
| 14:44.38 | brlcad | i'm specifically referring to args that rtwizard actually doesn't need to know about (like -F), or at least doens't need to be aware of their value |
| 14:44.46 | brlcad | perhaps that's the crux of this concern |
| 14:45.46 | brlcad | -F[something_unknown_here] .. I don't see it being any of rtwizard's business to know *anything* about the "something_unknown_here" value |
| 14:45.57 | starseeker | the thing is though, rtimage needs to know the port number for the tools fb-pix and pix-fb |
| 14:46.25 | brlcad | huh? |
| 14:46.36 | starseeker | rtimage is the internal script called by rtwizard |
| 14:46.56 | starseeker | I suppose we could just "grab and store" whatever is in -F... |
| 14:47.21 | brlcad | I don't see why rtimage would need a port number, that sounds like a flawed assumption, or flawed design |
| 14:47.27 | brlcad | there's not necessarily a port |
| 14:47.44 | starseeker | sorry, framebuffer information |
| 14:47.46 | brlcad | that's all libfb's domain to deal with it |
| 14:47.50 | starseeker | port number or not |
| 14:48.03 | starseeker | take a look at src/tclscripts/lib/RtImage.tcl |
| 14:48.26 | starseeker | specifically, around line 220 |
| 14:49.11 | starseeker | rtwizard has to be able to populate that argument template |
| 14:50.17 | starseeker | rtwizard's job is to collect the information needed to drive that script, first and foremost |
| 14:50.57 | brlcad | "rtwizard has to be able to populate that argument template" <-- no it doesn't :) |
| 14:51.12 | brlcad | that's part of the point, it's written that way and that's a rather tight coupling |
| 14:51.31 | brlcad | those are three args that rtImage didn't need to know about |
| 14:51.36 | starseeker | remember, this was basically turning the existing rtwizard into something that can be command line called |
| 14:51.52 | starseeker | we did not undertake to re-think how it was doing what its doing |
| 14:51.55 | brlcad | viewscripts are a good corollary |
| 14:52.06 | brlcad | look at one of the rt viewscripts |
| 14:52.56 | brlcad | it has a few that it needs to know about and needs to specify, but the way they are ordered and the $* that is in the middle allows you to specify more or override |
| 14:53.43 | starseeker | sure - I'm not saying it can't be done better, just that we had enough crud to deal with without getting into that at the same time |
| 14:53.58 | brlcad | there was some rethinking in rtwizard, or you wouldn't have attempted to parse the framebuffer value |
| 14:54.15 | brlcad | how about at least just starting there |
| 14:54.32 | brlcad | what you're calling "port" in there looks like a misnomer, it's just the "framebuffer" |
| 14:54.47 | starseeker | OK |
| 14:54.48 | brlcad | and whatever is provided just gets fed to all the -F's |
| 14:55.12 | CIA-55 | BRL-CAD: 03d_rossberg * r51160 10/brlcad/trunk/src/conv/g-voxel.c: removed numVoxel from hit() function because of a compiler error "variable set but not used" |
| 14:55.20 | starseeker | the contents of -F's args still have to be in a Tcl variable though |
| 14:55.23 | starseeker | for pix-fb |
| 14:55.45 | brlcad | yeah, I realize that |
| 14:56.20 | brlcad | you weren't parsing in rtImage, iirc, it's the caller code in rtwizard that knew too much for its own good :) |
| 14:56.30 | starseeker | so... if I want to tell rt to use /dev/X and also specify a port number at the same time, I take it there's a syntax for that in -F |
| 14:56.44 | brlcad | generally likes that rtImage interface, it's a nice refactoring |
| 14:57.43 | starseeker | alright, let me try something... |
| 14:59.55 | brlcad | in general, yes -- but you may be mixing server and client concepts |
| 15:00.19 | starseeker | rtwizard is responsible for both... |
| 15:00.33 | starseeker | or may be, unless a pre-existing framebuffer is specified |
| 15:00.42 | brlcad | if it starts the server, it specified the port |
| 15:01.00 | CIA-55 | BRL-CAD: 03d_rossberg * r51161 10/brlcad/trunk/src/conv/g-voxel.c: another unused variable: rtip in hit() |
| 15:01.18 | brlcad | if it does that, there's no need for that to even be something the user cares about (or it becomes some sort of rtwizard-specific option) |
| 15:02.19 | brlcad | there's already a "bug" / bad design in fbserv the way it's currently set up where you have to specify the type (should auto-infer) -- that's on my todo to auto-infer the type or properly support -F |
| 15:02.44 | starseeker | if rtwizard get's passed -F/dev/X, is that enough to pass to pix-fb to enable it to communicate with the same framebuffer rt is using? |
| 15:02.45 | brlcad | beside the point, though -- the -F args are still identical across all commands |
| 15:03.47 | brlcad | ill-posed question, depends entirely what that "rtwizard" option is attempting to describe |
| 15:04.31 | starseeker | all I care about is that rt, rtedge, and pix-fb all know to communicate to the same framebuffer. The only way they are going to know what framebuffer is in play is from the -F option |
| 15:04.32 | brlcad | -F/dev/X means open a transient write-only X11 framebuffer |
| 15:04.48 | starseeker | so if someone feeds -F/dev/X to rtwizard, it's an error |
| 15:05.20 | brlcad | if that's something that's supposed to go on the rt* and *fb* tools, yeah -- doesn't make any sense |
| 15:05.39 | starseeker | but as the user, I don't care what rtwizard is doing under the hood |
| 15:05.50 | starseeker | I don't want to need to know that fb tools are being used - doesn't matter |
| 15:06.02 | brlcad | right, so that's why I said it's ill-posed -- depends what that option is attempting to describe |
| 15:06.31 | starseeker | then aren't we back to -F/dev/X being supplied to rtwizard meaning something different from what it means supplied to a naked rt? |
| 15:06.43 | brlcad | what I would expect for our command ecosystem is that I have my own framebuffer server running |
| 15:06.54 | brlcad | so I specify -Fmy_server |
| 15:06.58 | starseeker | by definition, rtwizard will *never* use a transient framebuffer |
| 15:07.11 | brlcad | and it uses it, instead of trying to do whatever rtwizard would have automatically used under the hood |
| 15:07.47 | starseeker | shakes his head - casual users won't even understand the concept of the framebuffer |
| 15:07.57 | starseeker | they won't know to start their own, and shouldn't have to |
| 15:08.11 | brlcad | huh? they don't have to |
| 15:08.22 | starseeker | If I specify -F/dev/X or -F/dev/ogl to rtwizard, I expect that to "just work" |
| 15:08.33 | brlcad | we're going in circles |
| 15:08.51 | brlcad | if you specify -F to rtwizard, you're clearly expecting that to mean something ... what is that something? |
| 15:09.10 | brlcad | the type of framebuffer server to use? |
| 15:09.12 | starseeker | for me, the common usage is "use X" or "use opengl" |
| 15:09.17 | starseeker | yeah |
| 15:09.28 | brlcad | why is that an rtwizard option at all? |
| 15:09.42 | starseeker | because it can matter |
| 15:09.59 | starseeker | if ogl is buggered, I need to be able to specify X |
| 15:10.49 | starseeker | it *also* might specify a specific framebuffer, such as Archer's framebuffer, but that's usually a usage scenario I only encounter when scripting something |
| 15:10.49 | brlcad | now more specifically, when you say "use X" or "use opengl", I presume you mean go through that interface whenever going through libfb, right? |
| 15:11.39 | ``Erik | FB_FILE=/dev/X ./rtwizard |
| 15:12.29 | starseeker | brlcad: I think so - I think of it as "use the X subsystem when displaying this image" |
| 15:12.36 | brlcad | okay, great |
| 15:12.43 | brlcad | so the problem then is this |
| 15:13.02 | brlcad | you're merging the concepts of starting a server with those you're usually familiar with running a client |
| 15:13.57 | brlcad | rtwizard obviously involves both, but they are not one in the same, by design and incompatibly so |
| 15:14.51 | brlcad | sounds to me like you're wanting to specify *fbserv* option(s) to rtwizard, which is not the -F option |
| 15:15.24 | starseeker | ah, OK |
| 15:15.29 | brlcad | that would be an rtwizard-specific option |
| 15:15.49 | brlcad | like --device=X |
| 15:16.22 | starseeker | but if I supply --device=ogl and then pass -F/dev/X through to rt, won't badness ensue? |
| 15:16.43 | brlcad | or --port=3 --device=ogl, which would set up "fbserv /dev/ogl 3" and "rt -F3 ; pix-fb -F3 ; ..." command calls |
| 15:17.04 | brlcad | client doesn't care about the device |
| 15:17.16 | starseeker | ah - that's why you're not expecting to see -F at the rtwizard level |
| 15:17.17 | brlcad | client only cares when it's starting it's own (transient) window |
| 15:17.31 | brlcad | you're probably only used to running rt that way |
| 15:18.13 | starseeker | ok, so basically I need to rename my options |
| 15:19.19 | brlcad | more than that -- the (current) -F parsing still seems entirely unnecessary |
| 15:19.40 | starseeker | right |
| 15:19.49 | brlcad | what I was looking for and expecting to override is that -F3 in that example |
| 15:20.08 | starseeker | on the other hand, if someone feeds an override to -F, all *bleep* is going to ensue |
| 15:20.20 | brlcad | if I specified --framebuffer=whatever, rtwizard would skip the fbserv and just pass 'whatever' to all the rt/pix tools, using my fbserv |
| 15:20.38 | brlcad | (--framebuffer == -F in this case) |
| 15:21.01 | starseeker | wouldn't that be a port number, at the rtwizard level? |
| 15:21.08 | starseeker | (/dev/X would be a no-no) |
| 15:21.14 | brlcad | actually, no *bleep* .. it should work just fine if they know our fbserv client/server interface |
| 15:21.32 | brlcad | yes, /dev/X IS wrong |
| 15:21.42 | brlcad | you can't talk to a /dev/X |
| 15:22.03 | starseeker | so I'd call it a port number at the rtwizard level, to discourage someone (me, like as not) passing --framebuffer=/dev/X |
| 15:22.15 | starseeker | since that would be my initial instinct, based on rt interaction |
| 15:22.17 | brlcad | it would be -Flocalhost:5 or -F/path/to/my/file or something else entirely (all documented in libfb(3) |
| 15:22.32 | brlcad | no no |
| 15:23.04 | brlcad | those are three separate options, three separate concepts |
| 15:23.39 | brlcad | --framebuffer or -F are *client* options |
| 15:24.16 | starseeker | oh, I see what you're saying |
| 15:24.17 | brlcad | /dev/X is simply not a valid client option when you have multiple commands, that's user error |
| 15:24.51 | brlcad | similarly, specifying --framebuffer/-F along with --port or --device would make no sense |
| 15:25.22 | brlcad | port/device are *server* options (from which you can derive client options) |
| 15:26.23 | starseeker | alright, so we've got three options here - one client and two server. If both client and server are simulatneously specified, it's an error |
| 15:26.37 | brlcad | right |
| 15:26.45 | brlcad | I could see you making sense of --framebuffer along with --port/--device .. but that'd be code to write |
| 15:26.58 | starseeker | so *that's* what I'm checking for at the rtwizard level |
| 15:27.22 | starseeker | I'll try to fix it before you tag... |
| 15:27.23 | brlcad | you could make it use port/device as the server, all client commands work with it for processing, but then it mirrors results to the client-specified --framebuffer |
| 15:28.33 | starseeker | shakes his head - I don't know that I'd want to be that fancy for a first cut (that would probably require modding rtimage too) |
| 15:28.44 | brlcad | I could see you *always* starting and using an fbserv |
| 15:29.03 | brlcad | then any framebuffer option just copies progress or the final result to that one specified |
| 15:29.40 | brlcad | for simplicity, I'd just go without a framebuffer option to rtwizrd |
| 15:29.44 | starseeker | maybe, but getting that right, working and cross-platform tested is going to take more than a few hours |
| 15:29.51 | brlcad | since your primary need it really just --device |
| 15:29.58 | brlcad | s/it/is/ |
| 15:30.15 | starseeker | well, device and port (so Archer can tell it what port to use) |
| 15:30.47 | brlcad | unfortunately, yeah |
| 15:30.58 | brlcad | fbserv needs to be modified for that to improve |
| 15:31.13 | brlcad | archer doesn't really care, but needs to because of fbserv |
| 15:32.03 | brlcad | fbserv doesn't have a default device type nor report an auto-sensed port, so you have to specify them to know what they are |
| 15:32.14 | brlcad | rather annoying |
| 15:32.29 | starseeker | nods |
| 15:33.11 | starseeker | kinda hard to auto-sense a port though, isn't it? what if you've got more than one fbserv of the same type up? |
| 15:33.22 | starseeker | then you pretty much have to tell it which one to use |
| 15:33.40 | brlcad | so yeah, if you peek at fbserv's usage, that's really what rtwizard needs to know about -- and if it starts the server, it KNOWS what all the client -F's are (no parsing needed) |
| 15:33.51 | starseeker | right |
| 15:33.53 | brlcad | not hard at all, you look for the first available |
| 15:34.46 | brlcad | starting an fbserv doesn't know/care about other fbservs (unless you're chaining, which we do support) |
| 15:35.25 | brlcad | it's just a "is this socket in use" check |
| 15:35.59 | brlcad | the "port" is just an offset from tcp socket 5558 |
| 15:36.38 | starseeker | oh - so you're thinking when archer starts up its own fbserv, it will get the port number in use back from the fbserv itself rather than specifying it up front? |
| 15:36.58 | starseeker | and archer will then tell it's "client" rt programs which port to use? |
| 15:37.12 | brlcad | that's what it does now |
| 15:37.15 | brlcad | mged too |
| 15:37.28 | starseeker | I'm missing something then... |
| 15:37.56 | brlcad | when you "enable" the embedded framebuffer in either archer or mged, it attempts to start an fbserv |
| 15:38.16 | brlcad | starts with port 0 (5558), then port 1 (5559), then port 2 (5560), etc |
| 15:38.43 | brlcad | once it finds one open, that fbserv is running, mged/archer make note of the port that worked, and then that number is fed to any rt invocation |
| 15:39.08 | brlcad | bob's doing the same thing with rtwizard |
| 15:39.19 | starseeker | right... so what did you mean by "auto-sensed" port? |
| 15:39.51 | brlcad | mged/archer will know the port it's using for the embedded framebuffer, so it'll need to specify that to rtwizard |
| 15:40.15 | brlcad | the auto-sensing is to avoid that manual search by mged/archer/rtwizard to find an available port |
| 15:40.47 | brlcad | just start an fbserv and tell me where it's at, mged/archer can take it from there to reuse it |
| 15:41.19 | brlcad | that's how it SHOULD work, not how it currently works .. it's a manual loop inside mged/archer |
| 15:41.30 | starseeker | ah, k |
| 15:41.41 | brlcad | for rtwizard to work standalone, it needs the same search |
| 15:42.16 | starseeker | got it |
| 15:42.18 | brlcad | at least UNTIL fbserv is fixed to perform auto-sensing |
| 15:42.58 | brlcad | I think that even is/was a bug in rtwizard, didn't handle fbserv port already in use |
| 15:46.26 | starseeker | hates to be swapping these options around right before release... |
| 15:46.37 | starseeker | need to though |
| 15:46.46 | starseeker | don't want to release with gummed up opts |
| 15:46.54 | starseeker | (sorry Bob...) |
| 15:59.31 | starseeker | brlcad: should I do the extra work to support both X and /dev/X style device specifications for --fbserv-device ? |
| 16:00.03 | starseeker | (looks like fbserv wants /dev/X...) |
| 16:00.36 | starseeker | well, better test first |
| 16:00.47 | starseeker | glowers at slow computer |
| 16:25.40 | brlcad | starseeker: there's merits to both, but I wouldn't support both |
| 16:25.51 | brlcad | just pass it through it you want to keep in simple |
| 16:26.24 | brlcad | and it won't need to get fixed if we ever change the /dev/ prefix |
| 16:30.35 | brlcad | that's looking better |
| 16:30.44 | brlcad | pokes CIA-55 |
| 16:39.19 | CIA-55 | BRL-CAD: 03starseeker * r51162 10/brlcad/trunk/ (2 files in 2 dirs): Fix rtwizard options to better match what they're actually doing under the hood. |
| 17:34.55 | CIA-55 | BRL-CAD: 03bob1961 * r51163 10/brlcad/trunk/src/tclscripts/lib/RtImage.tcl: Put back the previous specification of occlusion objects to rtedge. |
| 17:43.46 | CIA-55 | BRL-CAD: 03brlcad * r51165 10/brlcad/trunk/src/libbu/test_ctype.c: typo, mime type is text/plain |
| 17:45.16 | CIA-55 | BRL-CAD: 03brlcad * r51166 10/brlcad/trunk/src/libbu/test_ctype.c: clean up ws & style, mark ac/av as UNUSED |
| 17:45.44 | brlcad | ~seen anuragmurty |
| 17:45.51 | ibot | anuragmurty <~anurag@14.139.128.14> was last seen on IRC in channel #brlcad, 11d 4h 32m 4s ago, saying: 'ohh.. this depends on how sparse our object is, right? as in (filled) to (total in bounding box) ratio..'. |
| 17:48.45 | CIA-55 | BRL-CAD: 03brlcad * r51167 10/brlcad/trunk/src/conv/g-voxel.c: ws |
| 18:01.27 | CIA-55 | BRL-CAD: 03bob1961 * r51168 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): |
| 18:01.28 | CIA-55 | BRL-CAD: This fixes some of the issues that were encountered using the rtwizard interface |
| 18:01.28 | CIA-55 | BRL-CAD: in Archer. The fix was to compute the eye_pt (i.e. a call to get_eyemodel |
| 18:01.28 | CIA-55 | BRL-CAD: computes this) whenever the display changes and convert it to view coordinates |
| 18:01.28 | CIA-55 | BRL-CAD: before comparing to the mSavedViewEyePt. The eye_pt with the largest Z value |
| 18:01.28 | CIA-55 | BRL-CAD: wins. This value, if set, is used to override libged/rtwizard.c. |
| 18:08.46 | CIA-55 | BRL-CAD: 03brlcad * r51169 10/brlcad/trunk/ (include/bu.h src/libbu/vls_internals.h): revert r50816 and 50817. cannot just move declarations into public headers as it pollutes the public API. moreover, it's not necessary (and doesn't address the real problem) |
| 18:09.11 | CIA-55 | BRL-CAD: 03brlcad * r51170 10/brlcad/trunk/src/libbu/vls_internals.h: declare extern |
| 18:11.29 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) |
| 18:12.16 | *** join/#brlcad jbschw_ (~jbschw@ool-4355ee10.dyn.optonline.net) |
| 18:14.54 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) |
| 18:17.49 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) |
| 18:18.24 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) |
| 18:19.17 | starseeker | brlcad: where is bu_argv0_buffer normally set? |
| 18:19.57 | starseeker | oh, I see it |
| 18:21.45 | brlcad | there be dragons there... tread carefully :) |
| 18:22.13 | starseeker | no worries - don't want to monkey with the logic |
| 18:22.23 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) |
| 18:23.52 | *** join/#brlcad andrei__ (~andrei@5-12-78-192.residential.rdsnet.ro) |
| 18:23.57 | andrei__ | hello |
| 18:24.22 | CIA-55 | BRL-CAD: 03starseeker * r51171 10/brlcad/trunk/src/fb/fblabel.c: fblabel needs to use bu_setprogname, since it relies on bu_brlcad_data to find vfont. |
| 18:24.56 | starseeker | brlcad: was rather surprised when fblabel was failing based on where I was running it from |
| 18:25.44 | starseeker | especially since I was pretty sure we'd hammered that part fairly flat - we had, but fblabel wasn't doing its part |
| 18:26.37 | starseeker | I suppose technically that might be user visible, but only if using fblabel in a BRL-CAD that isn't in its final make install location |
| 18:26.40 | *** join/#brlcad jbschw_ (~jbschw@ool-4355ee10.dyn.optonline.net) |
| 18:30.12 | CIA-55 | BRL-CAD: 03brlcad * r51172 10/brlcad/trunk/src/libbu/vls_internals.h: mark them with BU_EXPORT so they'll dllexport/dllimport correctly, but keep them in this internal header so they're not published |
| 18:31.38 | CIA-55 | BRL-CAD: 03starseeker * r51173 10/brlcad/trunk/doc/docbook/system/man1/en/rtwizard.xml: Add some examples to rtwizard man page - could probably stand to have some more, given the number of options available |
| 18:32.22 | brlcad | yeah, I wouldn't call that a "proper" installation in terms of user-visibility |
| 18:33.34 | brlcad | steps outside for a couple minutes as he hears the blue angels roaring nearby |
| 18:36.01 | brlcad | pretty cool, shot strait up for a while, curved down, graceful stalled spin, then recovered shortly before reaching the water |
| 18:37.09 | brlcad | if you're within earshot of bob or a windows box, r51172 could use a compilation test |
| 18:38.00 | andrei__ | brlcad , regarding the posix compliant issue |
| 18:38.08 | andrei__ | I have to replace for (( i=0; i < max; i++ )), right? |
| 18:38.59 | andrei__ | on stackoverflo it says " it s not totally POSIX" so I m not sure if I can keep it |
| 18:41.02 | CIA-55 | BRL-CAD: 03WadelinlofybzobuqxqdvqebvtfzgalodwzyrknBoyde 07http://brlcad.org * r3895 10/wiki/WadelinlofybzobuqxqdvqebvtfzgalodwzyrknBoyde: New page: Search Engine Marketing is not only about putting websites in search engines to get listed on their result pages, but also about promoting and improving their rankings in order to make the... |
| 18:42.41 | brlcad | andrei__: if you replace /bin/bash with /bin/sh, does "for (( i=0; i < max; i++ ))" work? |
| 18:43.19 | andrei__ | I did replace it but I haven't tried |
| 18:43.50 | brlcad | kind of answers your question if it doesn't work ;) |
| 18:43.55 | andrei__ | it does |
| 18:44.02 | brlcad | if it does work, doesn't really answer your question -- but one step at a time |
| 18:46.14 | andrei__ | I believe I should use "test", just need to figure out how |
| 18:49.09 | brlcad | you should, great tool to learn |
| 18:49.16 | brlcad | lots of examples in our sh/ directory |
| 18:50.03 | brlcad | test and expr will reproduce most of what you're doing in your script |
| 18:52.58 | ``Erik | metaball facetization does work, it's just rrrrreally slow in the _fuse() |
| 18:55.13 | brlcad | related to weiss' "optimizations" ? |
| 18:56.03 | brlcad | I noticed the conversion.sh script taking about 200% longer after all his nmg work last fall (1/3rd) |
| 19:06.31 | ``Erik | it's in nmg_model_fuse(), rich asserts that nmg_model_break_e_on_v() is what's killing the performance |
| 19:07.33 | ``Erik | commenting out the fuse call and passing -n to facetize allows it to finish fairly quickly |
| 19:09.35 | ``Erik | might hit it with shark or something later to see where |
| 19:11.43 | CIA-55 | BRL-CAD: 03brlcad * r51174 10/brlcad/trunk/src/libged/brep.c: ws |
| 19:19.26 | CIA-55 | BRL-CAD: 03brlcad * r51175 10/brlcad/trunk/src/libged/red.c: |
| 19:19.26 | CIA-55 | BRL-CAD: revert r51012. it's unclear how the comment is true, improving reliability on |
| 19:19.26 | CIA-55 | BRL-CAD: Windows, because the casts are not right. they describe an array of character |
| 19:19.26 | CIA-55 | BRL-CAD: pointers (char*[]), but then that's repeatedly used as a 'char *' with casts |
| 19:19.26 | CIA-55 | BRL-CAD: forced everywhere. needing casts pervasively like that is a sign something is |
| 19:19.26 | CIA-55 | BRL-CAD: fundamentally wrong. casts should be rare. |
| 19:22.40 | CIA-55 | BRL-CAD: 03anrgmrty * r51176 10/brlcad/trunk/src/conv/g-voxel.c: EQUAL used for equality of two floating pt. numbers instead of roundabout way using ZERO |
| 19:24.26 | brlcad | does anyone know any of the details around r51054? changes to our libregex reportedly somehow in support for win64 |
| 19:26.58 | CIA-55 | BRL-CAD: 03brlcad * r51177 10/brlcad/trunk/src/other/libregex/engine.c: partial revert of r51054. passing ssize_t to %ld is not portable nor follows the documented type. |
| 19:32.15 | ``Erik | hah |
| 19:35.46 | ``Erik | I may've found the nmg performance culprit, verifying something... |
| 19:42.00 | brlcad | caught up on commit review |
| 19:42.35 | CIA-55 | BRL-CAD: 03Mesut 07http://brlcad.org * r3896 10/wiki/User:Mesut/Reports: |
| 19:48.41 | crdueck | brlcad: the analyze command for an arb provides a very detailed per-face analysis with its own implementation of a surface area function for each face, and then summing the areas to provide the total at the end. also, there's already an rt_arb_centroid() which is in use in a few places. i'm not sure how much i want to/can touch these, but it makes arb a little inconsistent compared to the rest of the primitives using (or soon to be using) t |
| 19:49.33 | brlcad | clean linux builds on 64-bit (x86_64 and power7), so far good on 32-bit mac 10.5 |
| 19:50.01 | brlcad | crdueck: make 'em consistent |
| 19:51.24 | brlcad | rt_arb_centroid() isn't properly published, so it can be changed |
| 19:51.53 | brlcad | you can make it have the right argument types, for example, and update the callers to go through the functab instead of calling it directly |
| 19:52.04 | brlcad | then you should be able to remove its declaration from raytrace.h |
| 19:52.58 | crdueck | centroid isnt too difficult, but the surface area function isnt even its own function, its just a part of the per face analysis |
| 19:53.13 | brlcad | most of those rt_PRIM_*() functions are fair game because there shouldn't be any in the public API |
| 19:53.31 | brlcad | so refactor it into a function or write one and replace it |
| 19:53.52 | brlcad | good thing to leverage the code that's there at least as a starting point |
| 19:53.57 | brlcad | then can see if you can improve upon it |
| 19:55.46 | crdueck | okay, i'll work on it |
| 20:13.46 | CIA-55 | BRL-CAD: 03erikgreenwald * r51178 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: remove unnecessary blather |
| 21:35.13 | CIA-55 | BRL-CAD: 03bob1961 * r51179 10/brlcad/trunk/ (4 files in 3 dirs): Added functions for save_all, delete_all and restore_all hooks and log_hooks. Used by wdb_cmd to eliminate blather when a command is not found in wdb_newcmds. |
| 21:56.59 | *** join/#brlcad crdueck (~cdk@d173-238-127-19.home4.cgocable.net) |
| 22:39.24 | CIA-55 | BRL-CAD: 03Stattrav 07http://brlcad.org * r3897 10/wiki/User:Stattrav/GSoC2012_log: Updation of the logs. |
| 23:22.32 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) |
| 23:37.43 | *** join/#brlcad xth1 (~thiago@201.82.132.241) |