| 00:06.16 | *** join/#brlcad docelic (n=docelic@212.91.113.204) |
| 02:00.59 | Rangar | yo erik, brl |
| 02:04.15 | Maloeran | The ia32 and amd64's shl and shr instructions only consider the lower 5/6 bits for logical shifts ; does anyone know if C garantee correct behavior if I were to shift an int32_t by 32? ( clearing it to zero ) |
| 02:06.02 | Maloeran | Ah there it is, undefined behavior as usual |
| 02:10.01 | Rangar | see, now if it had ben in C++ ;) |
| 04:08.15 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1088753792.dsl.bell.ca) |
| 04:08.50 | louipc | greetings |
| 06:03.52 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: whoops, that was just testing on the opt/optimized. go ahead and add an alias for enable-opt anyways. |
| 06:06.12 | brlcad | yo |
| 07:18.51 | *** join/#brlcad clock_ (i=clock@84-72-94-44.dclient.hispeed.ch) |
| 08:33.28 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 10:06.25 | *** join/#brlcad docelic (n=docelic@212.15.171.171) |
| 10:38.40 | brlcad | ``Erik: interestingly enough, the x11 linking test works correctly on an os x that does have X11 installed, so *shrug* .. don't care (at this point) why it's not clear why it "works" on a default os x config.. |
| 10:39.14 | brlcad | it at least works as one would hope, so good enough |
| 13:18.14 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 14:11.57 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 16:25.10 | *** join/#brlcad docelic (n=docelic@212.91.114.245) |
| 18:35.40 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] |
| 21:14.13 | *** join/#brlcad clock_ (i=clock@84-72-63-118.dclient.hispeed.ch) |
| 21:19.12 | dtidrow_work | anybody awake here? |
| 21:30.19 | Maloeran | If you have a question, you better just ask away |
| 21:31.55 | dtidrow_work | heh |
| 21:32.34 | dtidrow_work | remember my X problem from yesterday? well, I compiled the program in question on a different box, and it works fine there :-\ |
| 21:32.47 | dtidrow_work | exact same code |
| 21:33.31 | Maloeran | Any signifiant differences in the libraries each box is loading? |
| 21:33.47 | ``Erik | ssooooo something is foobarred with your X install or something under that... different X install? different kernel? different hw? checked md5sums if it should all be the same? |
| 21:33.49 | Maloeran | ( with ldd ) Assuming you want to find out what the problem is |
| 21:34.44 | dtidrow_work | haven't analyzed what the differences are yet - spent the time actually using the program for what I dl'ed it for :-) |
| 21:36.07 | dtidrow_work | weird thing is that I haven't had a problem running just about any other type of X11-based app |
| 21:39.44 | Maloeran | I'm tempted to believe that the software is doing something wrong, not the X libraries |
| 21:41.49 | ``Erik | mal: I'm already getting requests from other groups here for your source so they can start building their apps against it O.O |
| 21:42.25 | Maloeran | Really? Hrm, I'm not sure how to react to that |
| 21:42.27 | ``Erik | <-- gonna let leebert take care of all that, though, some possible recipients are contractors... |
| 21:42.38 | Maloeran | If they want to use the native API, be my guest |
| 21:42.57 | ``Erik | that's what they want... to see if the api is close enough to what they think they want |
| 21:43.08 | Maloeran | Oh, neat |
| 21:44.00 | ``Erik | but I'm not gonna make the call to just shovel your stuff over, I'll let someone who makes more than me assume the risk o.O :) |
| 21:44.18 | Maloeran | I think it's too early still, though |
| 21:44.33 | Maloeran | Some features of the API are incomplete or untested |
| 21:45.00 | dtidrow_work | Maloeran: the fact that the code compiles/works okay on another box would indicate (to me at least) that the problem is in the X libs on this box |
| 21:45.16 | Maloeran | I'm still working on the major features before cleaning up the details, and testing all possible combinations of settings and features |
| 21:46.07 | Maloeran | dtidrow_work, code can appear to run correctly in some circumstances while still being faulty |
| 21:46.27 | dtidrow_work | hmmm, I wonder if there's some issue with the compiler - FC4 uses gcc4 by default, but I also have gcc3.2.3 installed here, so could try that and see if there's still a prob |
| 21:46.33 | Maloeran | The fact that all the other X software runs fine makes me believe the program might be to blame |
| 21:47.08 | ``Erik | *shrug* maybe his look at your api could help you focus your api and feature set, it's good having people look at your ideas and comment on 'em, as long as they're logical comments... doesn't mean ya blindly do what they say, though... just listen and consider :D *shrug* |
| 21:47.27 | dtidrow_work | but the function params look fine, afaict |
| 21:47.30 | Maloeran | Erik, I'm all for people having a look at the API and ideas! |
| 21:47.50 | Maloeran | It's just that if people are going to use the library already, I got some clean up and bits of code to do |
| 21:47.54 | ``Erik | if it was the user app feeding xlib bad data, xlib should return an error so the app can appropriately respond. segging down in the bowels isn't cool |
| 21:48.17 | ``Erik | I mean, if you called read() with a bad file id, you'd want it to throw you an error ssaying it's a bad id, not panic the kernel |
| 21:48.27 | dtidrow_work | yeah |
| 21:48.47 | Maloeran | Erik, could you keep me informed if anyone is going to use the library? I could use 2-3 days before then to complete and test various pieces of code |
| 21:49.44 | ``Erik | sure, I won't get to talk to lee about it until tomorrow, I think... then to either get him cvs access or prepare a tarball, that might not be until monday or tuesday at the earliest? *shrug* |
| 21:49.48 | Maloeran | And write a proper demo of the library, not something quickly hacked together for testing purpose |
| 21:50.02 | ``Erik | and the first thing he's gonna do is look at your installed headers |
| 21:50.17 | ``Erik | (otherwise, he has to try to hack adrt/libtie into what he wants) |
| 21:52.37 | Maloeran | I don't really "clean up and polish" before all the more fundamental code is done |
| 21:52.43 | dtidrow_work | heh |
| 21:52.51 | dtidrow_work | does anybody? ;-) |
| 21:53.28 | ``Erik | *shrug* his current goal is just to look at the headers to use the library to see if it supports (and exposes) the fundamental notions he needs |
| 21:53.54 | Maloeran | Okay. RT/rt.h is what he needs |
| 21:54.06 | Maloeran | Plus the very long Doxygen page describing the API in details |
| 21:54.50 | ``Erik | if I get someone else to approve it, I'll try to remember that just those two things are needed for him at the first step :) |
| 21:55.18 | ``Erik | (since two seperate contracting agencies are involved, I wanna do some cya...) |
| 21:55.32 | Maloeran | Some "cya"? |
| 21:56.06 | ``Erik | 'cover your ass' |
| 21:56.26 | Maloeran | Oh :) |
| 21:56.43 | ``Erik | if I gave him the code, then your employer sued me, it'd make me a sad panda |
| 21:56.48 | Maloeran | Hum, I got to write Doxygen doc for the RT_EXT_MULTIPLE_HITS extension, I think that's something they would want |
| 21:57.40 | Maloeran | Well, I own copyright on the code and it's to be covered by a GPL license. I don't think anything could happen |
| 21:58.03 | ``Erik | hm, I think he wants iterative trace capability... the overhead of that might be more expensive than just shooting the ray all the way through and only using what ya care about, though *shrug* |
| 21:58.35 | Maloeran | The API is defined to be a generic, flexible and efficient raytracing API independant on the underlying engine... so additional features are exposed by extensions, OpenGL-style |
| 21:59.08 | Maloeran | It's iterative but can return more than one hit per callback |
| 22:02.49 | Maloeran | You can tell him to look at rtirenderblend4sse.c for the transparency demo with multiple hits per ray, SSE optimized |
| 22:03.12 | Maloeran | or rtirenderblend.c for the scalar non-SSE version |
| 22:05.40 | ``Erik | mebbe next week :D |
| 22:34.20 | brlcad | erm, gpl would be highly problematic if it's going to the parties I believe it'll be going to |
| 22:34.32 | brlcad | not only highly problematic, but an outright non-starter for some |
| 22:37.04 | brlcad | any library that used your library in anything other than linking to a dynamic library at runtime would be subjected to gpl clauses, and there are still issues with dynamic libs too |
| 22:37.11 | Maloeran | Oh? Well, if needed, a copyright holder can release under any other license I guess |
| 22:37.24 | Maloeran | I'm sorry, I should have said LGPL |
| 22:37.33 | brlcad | ah, that's entirely different :) |
| 22:37.48 | brlcad | no problems then |
| 22:38.42 | dtidrow_work | heh |
| 22:43.21 | dtidrow_work | pretty sure brlcad has a file ;-) |
| 22:43.40 | dtidrow_work | oops, shouldn't have said that.... |
| 22:45.42 | louipc | haha |
| 23:09.46 | *** join/#brlcad docelic (n=docelic@212.91.113.90) |