| 00:00.43 | dtidrow | haven't had a problem with that here, and the lib we load sucks in a lot of .so's |
| 00:02.20 | dtidrow | you're not trying to pass in the full name of the lib, are you? |
| 00:03.20 | dtidrow | iiuc, System.loadLibrary() expands the name given to it, eg. 'vis' expands to libvis.so |
| 00:03.55 | dtidrow | at least on Linux - all bets are off on OSX ;-) |
| 00:03.58 | brlcad | I'll dig to make sure, but I'm pretty sure it's just the short name |
| 00:04.25 | dtidrow | OSX has some weird packaging schemes |
| 00:04.31 | brlcad | like I said, it works just fine if the .so is resolved, it's only when it's not |
| 00:05.02 | dtidrow | resolved meaning it can find it in the LD_LIBRARY_PATH? |
| 00:05.32 | brlcad | no, meaning that it doesn't have to -- all symbols in the .so are resolved (none undefined if you do an nm) |
| 00:05.40 | dtidrow | ah |
| 00:05.47 | dtidrow | odd |
| 00:07.00 | brlcad | yeah, it's just: System.loadLibrary ("rtserver"); |
| 00:07.09 | brlcad | we have a librtserver in brl-cad |
| 00:07.14 | brlcad | pretty straightforward |
| 00:07.35 | dtidrow | librtserver.so? |
| 00:07.49 | brlcad | on non-mac, yes :) |
| 00:08.15 | dtidrow | it works on non-macs? |
| 00:08.23 | dtidrow | or n ot at all? |
| 00:08.29 | brlcad | iirc, no -- not at all |
| 00:09.36 | dtidrow | gotta be an libpath issue, then - any chance that LD_LIBRARY_PATH was getting reset/changed before java ran? |
| 00:09.53 | dtidrow | like in a script, perhaps? |
| 00:10.02 | dtidrow | jsut brainstorming here... |
| 00:10.36 | brlcad | the ld path is set, it's set to a mass of paths that are otherwise required for other javanessy things it needs (and one of the paths includes the dir that has the .so's in question) |
| 00:11.07 | brlcad | otherwise even System.loadLibrary ("rtserver"); wouldn't work on the fully resolved library |
| 00:11.13 | dtidrow | very odd, then - it _ought_ to work |
| 00:11.44 | dtidrow | and 'ldd' finds all the deps? |
| 00:12.14 | brlcad | yeah, it does |
| 00:12.50 | dtidrow | makes no sense at all then |
| 00:15.11 | dtidrow | anyway, gotta head home - 'nite all... |
| 01:14.34 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/ (407 files in 39 dirs): remove ephemeral data like phone numbers and addresses, including the misleading 'source' statements on code that is continually evolving and receiving contributions from many many sources |
| 02:08.35 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1177680011.dsl.bell.ca) |
| 02:09.39 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/ogl.jpg <---- got my ogl issues sorted out :) |
| 02:15.16 | brlcad | can you quantify exactly what you needed to do? |
| 02:16.04 | IriX64 | for some reason my glx header wasn't being detected im still trying to get configure to find it |
| 02:17.13 | IriX64 | i don't speak configure very well :( |
| 02:18.17 | IriX64 | didint have to touch the code if thats what you're after |
| 02:18.43 | brlcad | i didn't think you would have had to |
| 02:18.50 | IriX64 | aren't build issues fun sigh |
| 02:37.45 | Twingy | http://js.cx/~justin/images/board.png <-- with my 30 degree conical |
| 02:38.41 | louipc | hm? |
| 02:39.10 | IriX64 | cant find page |
| 02:39.34 | brlcad | http://www.makezine.com/blog/archive/2007/07/make_your_own_printed_cir_1.html |
| 02:39.59 | brlcad | with a $10 flat iron ;) |
| 02:40.13 | IriX64 | found it :) |
| 02:41.43 | IriX64 | i used to do things like that then programming lured me :) |
| 02:43.26 | *** join/#brlcad IriX64_ (n=mariodot@bas2-sudbury98-1177680011.dsl.bell.ca) |
| 03:06.48 | Twingy | brlcad, I use a $20 griddle |
| 03:11.53 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177680011.dsl.bell.ca) |
| 03:25.19 | IriX64 | http://sympatico.ca/mario.dulisse2/Singular.jpg |
| 03:25.39 | louipc | 404 |
| 03:25.46 | yukonbob | The requested URL /mario.dulisse2/Singular.jpg was not found on this server. |
| 03:25.47 | yukonbob | Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. |
| 03:25.54 | yukonbob | heh |
| 03:26.48 | Twingy | brlcad, you can't do 10 mil traces with ferric chloride either |
| 03:26.48 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/Singular.jpg (blush) |
| 03:27.02 | Twingy | I have a quart of it left from projects from years ago |
| 05:28.38 | *** part/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 07:01.16 | *** part/#brlcad akreal (n=ak@ll-81-222-164-251.awanti.ru) |
| 08:32.05 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-002-170.pools.arcor-ip.net) |
| 08:52.19 | *** join/#brlcad n9986 (n=nandeep@203.88.11.6) |
| 09:01.38 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 09:43.03 | *** join/#brlcad Laniakea (n=clock@zux221-122-143.adsl.green.ch) |
| 10:01.54 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) |
| 13:26.18 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 13:33.09 | ``Erik | *yawn* |
| 13:33.51 | poolio | wow. I actually just yawned when I read that |
| 13:35.46 | ``Erik | dork :) |
| 14:36.44 | CIA-29 | BRL-CAD: 03erikgreenwald * 10brlcad/misc/Makefile.defs: pass make flags in depends targets |
| 15:49.04 | *** join/#brlcad Elperion (n=Bary@p54874AC6.dip.t-dialin.net) |
| 16:48.00 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-002-170.pools.arcor-ip.net) |
| 16:55.47 | *** join/#brlcad MinuteElectron (i=tlstn6ce@gateway/web/cgi-irc/irc.net/x-ac3fb703067f8396) |
| 17:00.44 | *** join/#brlcad LinuxMafia (n=awatt@CPE001346a4c4cb-CM00159a642d7e.cpe.net.cable.rogers.com) |
| 17:09.58 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 17:10.11 | poolio | grargh. |
| 17:12.04 | MinuteElectron | ? |
| 17:15.24 | poolio | internet went down |
| 17:15.34 | poolio | and i really needed to figure out what i broke in my local cvs |
| 17:22.56 | ``Erik | why'd you break the intarweb? |
| 17:23.35 | poolio | my modem went down |
| 17:23.38 | poolio | and comcast doesn't respond to me |
| 17:23.58 | poolio | because there are only 3 houses in our neighborhood, so if internet goes downt hey don't give a shit |
| 17:25.50 | *** join/#brlcad AchiestDragon_ (n=david@whipy.demon.co.uk) |
| 17:26.43 | ``Erik | sucky |
| 17:28.59 | poolio | luckily it came back on |
| 17:29.02 | poolio | i was gonna go to an internet cafe |
| 17:29.11 | poolio | well, a cafe with wifi internet |
| 17:32.23 | poolio | so I tried to have one generic tree traversal function with lots of switch statements in it, but I feel like that may have been a bad decision...getting segfaults and debuggin it is a pain |
| 17:32.39 | poolio | and the code's probably clearer if I just seperate out the routines |
| 17:33.26 | ``Erik | probably |
| 17:33.40 | ``Erik | I assume you have gdb style stabs compiled in and are using the debugger? :) |
| 17:33.50 | poolio | no |
| 17:33.55 | ``Erik | ... |
| 17:33.58 | poolio | I nver learned the right way to debug |
| 17:34.04 | poolio | well gdb picks up the source code |
| 17:34.06 | ``Erik | might be a good time? |
| 17:34.08 | poolio | and tells me where it is |
| 17:34.31 | poolio | I just fail at figuring out why certain things are happening. Lik ewhere these null pointers keep popping up from |
| 17:34.36 | ``Erik | 'backtrace' and 'print' are good commands |
| 17:34.57 | ``Erik | and you can navigate the frames, too |
| 17:35.01 | poolio | yeah I know the basics, I should really take the time to learn more though, it'd help quite a bit |
| 17:36.16 | ``Erik | 'xxgdb' and 'ddd' provide gui frontends, might be easier than figuring out the syntax |
| 17:36.33 | poolio | maybe, although I've never been a big fan of GUIs |
| 17:36.42 | ``Erik | *shrug* me either :) |
| 17:37.07 | ``Erik | um, efence, dmalloc, ccmalloc, valgrind, ... |
| 17:38.02 | poolio | yeah valgrind doesnt play too nicely with multithreaded stuff though |
| 17:39.20 | ``Erik | choke it back to 1 thread? (or does it go heisenbug when you do that?) |
| 17:39.28 | poolio | heh no |
| 17:39.29 | poolio | I could do that |
| 18:01.06 | ``Erik | ah HAAAAAAA |
| 18:01.40 | ``Erik | he disabled the tclcad bezier canvas |
| 18:17.57 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177871547.dsl.bell.ca) |
| 18:18.28 | LinuxMafia | i can not run mged |
| 18:18.59 | LinuxMafia | it complains about itcltk/itk |
| 18:19.30 | IriX64 | did you build it yourself or are you using binaries? |
| 18:19.59 | LinuxMafia | i emerged it i used gentoo |
| 18:20.28 | IriX64 | any compile time errors or link errors |
| 18:20.33 | IriX64 | or warnings |
| 18:20.54 | LinuxMafia | Can't find a usable itk.tcl in the following directories: |
| 18:21.06 | IriX64 | the question was ... |
| 18:21.15 | LinuxMafia | no |
| 18:21.30 | LinuxMafia | it would not installed otherwise |
| 18:21.34 | IriX64 | did you add /usr/brlcad/bin to your path? |
| 18:21.46 | LinuxMafia | no |
| 18:21.50 | IriX64 | try |
| 18:22.05 | IriX64 | as make install tells you at end of run |
| 18:23.41 | LinuxMafia | i did |
| 18:23.46 | LinuxMafia | let me uptdate |
| 18:23.51 | IriX64 | can also try setting the environment variable to point to itk lib (forget the name at the moment though, anybody) |
| 18:25.04 | LinuxMafia | hum |
| 18:25.34 | LinuxMafia | <PROTECTED> |
| 18:25.58 | IriX64 | theres an envronment variable you can set to pint to that |
| 18:26.04 | IriX64 | point too |
| 18:26.18 | LinuxMafia | so i put this |
| 18:26.53 | LinuxMafia | export ITK_LIBRARY=/usr/lib64/itk3.3/ |
| 18:27.11 | IriX64 | and |
| 18:27.33 | IriX64 | btw what version we talking about here? |
| 18:28.26 | LinuxMafia | 3.3-r1 |
| 18:28.38 | IriX64 | of brlcad |
| 18:28.46 | LinuxMafia | 7.10 |
| 18:29.23 | LinuxMafia | wow |
| 18:29.27 | LinuxMafia | it worked now |
| 18:29.30 | LinuxMafia | i think i need |
| 18:29.32 | IriX64 | heh good |
| 18:29.32 | LinuxMafia | also |
| 18:29.44 | LinuxMafia | do the same for TCL |
| 18:32.17 | LinuxMafia | thanks alot IriX64 |
| 18:33.24 | IriX64 | welcome |
| 18:34.54 | IriX64 | mc |
| 19:29.25 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 20:05.19 | *** join/#brlcad dtidrow (n=dtidrow@host131.objectsciences.com) |
| 20:23.10 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 20:39.18 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 20:42.20 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 20:47.23 | IriX64 | system issues, such fun... bleah |
| 20:52.26 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/overlap <--- on the bright side your overlap tool works |
| 20:57.27 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 21:30.05 | Maloeran | Woah, 1USD = 1.038CAD now. It's peculiar to lose 15% of one's income in an year due to the change rate |
| 21:39.03 | poolio | well there isn't too much inflation internally so it's not that big of a deal |
| 21:39.06 | poolio | as long as you remain in the US |
| 21:42.32 | Maloeran | I'm not in the US! :) I'm in Canada and get paid in USDs |
| 21:44.22 | poolio | eek |
| 21:44.23 | poolio | that sucks :) |
| 21:50.01 | poolio | brlcad: is there a way to clip the depth of a raytrace? like limit the z-axis to some defined max? |
| 21:53.02 | poolio | brlcad: I remember in the past you told me not to modify the rt_i, (when it was clamping the bounding box) but if I need to shoot the same grid for each shape, won't I have to modify the variables inside of the application? |
| 21:53.16 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 21:53.48 | poolio | it looks like I missed that and that could have been why it wasn't working well. the fitness seems pretty arbitrary |
| 21:55.18 | poolio | well actually it was fine before, but that was because they were normalized to the z-depth, so scale was invariant along the z-axis, but I changed it assuming z-depth would be constant and that's where I ran into some problems. So I'm wondering if there's a way to clamp that value basically? |
| 21:57.09 | poolio | although it does eliminate a dimension at the cost of having a distorted object |
| 22:16.59 | brlcad | poolio: there is a_ray_length that will specify at what length the ray should terminate |
| 22:17.04 | brlcad | in the rti |
| 22:17.05 | poolio | brlcad: alright thanks |
| 22:17.08 | poolio | I actually went back to scaling |
| 22:17.11 | poolio | results seem slightly better |
| 22:17.17 | poolio | I now have the fixed-depth crossover working |
| 22:17.17 | brlcad | similar to a_onehit |
| 22:17.26 | poolio | yeah alright, thanks |
| 22:17.31 | poolio | the issue those is if it's offset, I'm screwed |
| 22:17.42 | poolio | Oh wait nevermind..I control where the ray is shot from |
| 22:17.44 | poolio | thanks :) |
| 22:18.54 | brlcad | how do you figure "results seem slightly better" ... |
| 22:19.23 | brlcad | it simply introduces more variability, so it won't necessarily get stuck on a bad answer .. that doesn't mean it's better though |
| 22:19.51 | poolio | slightly better with the crossover that makes sense (for now) |
| 22:20.03 | poolio | and something is up with fitness, give me a minute and Ill have some data to show you |
| 22:20.14 | brlcad | it shouldn't have anything to do with crossover |
| 22:20.23 | poolio | the results shouldn't? |
| 22:21.13 | brlcad | using a scaled size in your fitness function shouldn't have anything to do with crossover |
| 22:21.25 | brlcad | so yeah, the results shouldn't |
| 22:21.36 | poolio | Correct, yes. |
| 22:21.40 | brlcad | if they do, I'd think something else is suspect |
| 22:21.51 | poolio | The issue was that I had undid the scaling, taken the final difference, and divided that by the # of rays |
| 22:22.02 | poolio | the issue was that the rays fired at different lengths so I was getting odd answers |
| 22:22.31 | brlcad | yes, that's a problem confined to the fitness function :) |
| 22:22.56 | brlcad | scaling might make the math work out easier, but I don't think it's right |
| 22:23.18 | poolio | well, I was moving the scaling out, because I was scaling each bit |
| 22:23.20 | poolio | so I had like |
| 22:23.35 | poolio | <PROTECTED> |
| 22:23.51 | poolio | so i was moving it so I stored the non-scaled rays, and then when I had calculated the comparison, then dividing that |
| 22:23.53 | brlcad | take the union of both bounding boxes, that's your absolute length, then compare % matching |
| 22:24.11 | poolio | I could do that too |
| 22:27.01 | poolio | alright I'm doing a larger run and then I'll show you the results. Hopefully it will be better :P |
| 22:30.26 | poolio | brlcad: yeah something is wrong here. fitness is ... decreasing |
| 22:35.45 | brlcad | hehe |
| 22:37.07 | poolio | what a fugly graph |
| 22:38.31 | poolio | brlcad: http://poolio.org/index.php?q=node/8 |
| 22:40.19 | poolio | brlcad: although wait, something has to be wrong with the fitness function. Look at the best individuals...they're different ... |
| 22:40.47 | poolio | Oh that was the other thing, can I raytrace those objects using 'rt' with a specified bounding box instead of an auto-generated one? |
| 22:44.16 | brlcad | what are the three lines in the graph? |
| 22:44.33 | poolio | wrost/average/best individuals for each generation |
| 22:44.38 | poolio | read the description :P |
| 22:45.29 | brlcad | yeah ... that's not at all what it should look like :) |
| 22:45.35 | poolio | yeah I know |
| 22:45.40 | poolio | I'm guessing my fitness function is broken |
| 22:45.47 | poolio | juding from the output of the visual and the output of the graph |
| 22:46.18 | poolio | It was the first thing I did and I trusted it was right but maybe not |
| 22:47.04 | poolio | the questionable code resides in compare_hit() in fitness.c |
| 22:47.12 | brlcad | you can almost ignore the visual for the time being .. average and best won't likely get that close that fast |
| 22:47.50 | brlcad | also, did you implement the "bring best N forward" yet? |
| 22:47.56 | poolio | no |
| 22:47.59 | brlcad | if so, that 70% shouldn't have disappeartd |
| 22:48.00 | poolio | I can whip that up in a minute though |
| 22:48.01 | brlcad | ahh, k |
| 22:48.30 | brlcad | i think you're right, though -- fitness function seems wrong |
| 22:48.51 | brlcad | or some twisted crossover bug is killing off your population |
| 22:49.01 | poolio | I have a family dinner to get to but I'll be back around 9. I'm guessing the isuse has to do with the compare_hit routine I've been trusting |
| 22:49.16 | poolio | I might take that out and run some test cases to make sure it's working right |
| 22:50.00 | brlcad | have a good dinner ;) |
| 22:50.17 | poolio | thanks for the help, hopefully I'll have something good to show you soon |
| 22:52.06 | poolio | :\ |
| 22:52.11 | brlcad | :) |
| 22:52.20 | brlcad | you're not far off |
| 22:52.27 | poolio | in the timeline I am :) |
| 22:52.31 | brlcad | once it starts working, I think it'll be a lot more encouraging ;) |
| 22:52.42 | brlcad | yeah, timeline is the only crunch |
| 22:52.51 | poolio | I _need_ something working |
| 22:53.05 | poolio | Not just for you to show, but also to know I didn't waste away my summer on a broken hunk of code |
| 22:53.16 | brlcad | likewise |
| 22:53.48 | poolio | wow. pretty embarassing how little code there is too |
| 22:53.49 | brlcad | being able to demo your program to dozens of people you've never met ... |
| 22:53.50 | poolio | <2k |
| 22:53.54 | brlcad | that control lots of money :) |
| 22:54.10 | poolio | even if it only works on simple test cases? |
| 22:54.15 | brlcad | yes |
| 22:54.27 | brlcad | the technical aspects are pretty deep |
| 22:54.48 | poolio | but the code and implementation isn't that difficult |
| 22:54.49 | brlcad | probably a little more deep that you know yet, which is part why it's been a lil tricky to implement aside from the coding issues |
| 22:54.56 | poolio | If you had 5 days to spare you could have done it by now |
| 22:55.08 | brlcad | i don't have 5 days to spare :) |
| 22:55.14 | brlcad | contrary to the time I spend on IRC |
| 22:55.32 | poolio | just don't sleep. you'll do fine. |
| 22:55.56 | poolio | your time is also much more valuable |
| 22:56.10 | poolio | but seriously, if you took the time you've spent helping me out / trying to get me the job, it could've been done by now |
| 22:56.22 | poolio | (i'm just slightly pessimistic :)) |
| 22:58.01 | brlcad | getting good people is often way more important than getting the work done |
| 22:58.19 | brlcad | if the work was the #1 priority in your case, you wouldn't be working on this pariticular project |
| 22:58.35 | brlcad | it would have been one of the other tasks .. or worse ;) |
