| 00:05.22 | CIA-23 | BRL-CAD: 03starseeker * r32113 10/brlcad/branches/pre-7-12-6/ (7 files in 5 dirs): r31957-66 misc updates by brlcad |
| 00:18.49 | CIA-23 | BRL-CAD: 03starseeker * r32114 10/brlcad/branches/pre-7-12-6/src/ (4 files in 3 dirs): r31968-77 selective merging of updates to librt and librtserver |
| 00:20.36 | CIA-23 | BRL-CAD: 03starseeker * r32115 10/brlcad/branches/pre-7-12-6/sh/cmakecheck.sh: Add cmakecheck.sh (r31980-81) |
| 00:24.09 | CIA-23 | BRL-CAD: 03starseeker * r32116 10/brlcad/branches/pre-7-12-6/ (11 files in 11 dirs): r31983 - add svn properties for CMake lists |
| 00:26.25 | CIA-23 | BRL-CAD: 03starseeker * r32117 10/brlcad/branches/pre-7-12-6/ (4 files in 4 dirs): r31985-91 various updates - pipe primitive and make logic |
| 00:28.22 | CIA-23 | BRL-CAD: 03starseeker * r32118 10/brlcad/branches/pre-7-12-6/src/librtserver/ (rtserver.c rtserverTest.c): r32059-60 rtserver updates |
| 00:29.33 | CIA-23 | BRL-CAD: 03starseeker * r32119 10/brlcad/branches/pre-7-12-6/src/ (librt/prep.c librtserver/rtserver.c): r32061-62 more rtserver updates |
| 00:30.56 | brlcad | 19:42 < starseeker> stustev: I would suggest looking at clone for patterning geometry |
| 00:31.36 | brlcad | it's invariably more easily scriptable for procedure development than the gui pattern tool |
| 00:32.49 | starseeker | reaches the end of the svn trunk log (give or take the new kill stuff) and stops to see how bad the damages are |
| 00:32.50 | brlcad | almost has mged working so it'll invoke as an icon/shortcut for linux/mac without thinking it's in non-interactive mode |
| 00:33.03 | starseeker | cool! |
| 00:33.11 | starseeker | may have spoken too soon... |
| 00:36.37 | stustev | brlcad: thanks - I will look at it |
| 00:39.00 | stustev | I would still like to learn the pattern commands though. |
| 00:39.52 | starseeker | is more likely at this point to write a new pattern tool and document that - the interface on the old one is non-intuitive even by MGED standards |
| 00:45.00 | stustev | that sounds like a marvelous idea |
| 00:46.51 | starseeker | it's a lot of work though, and brlcad has me doing more useful stuff at the moment... |
| 00:51.12 | CIA-23 | BRL-CAD: 03starseeker * r32120 10/brlcad/branches/pre-7-12-6/configure.ac: First tweaks to configure to let it know about the docbook libpc dirs - start looking at what havoc all the merges did. |
| 00:52.07 | *** join/#brlcad iday (n=jlowens@c-68-55-215-195.hsd1.md.comcast.net) |
| 01:16.36 | CIA-23 | BRL-CAD: 03starseeker * r32121 10/brlcad/branches/pre-7-12-6/include/bu.h: |
| 01:16.37 | CIA-23 | BRL-CAD: Grab the renaming of bu_structparse_get_terse_form, etc. in bu.h from r31595 - |
| 01:16.37 | CIA-23 | BRL-CAD: have this in libbu via one of the updates. If it doesn't harm anything else |
| 01:16.37 | CIA-23 | BRL-CAD: it's a logical renaming based on the use of Tcl_Interp in the functions, |
| 01:16.37 | CIA-23 | BRL-CAD: otherwise need to revert both this and the corresponding libbu changes. |
| 01:35.15 | CIA-23 | BRL-CAD: 03starseeker * r32122 10/brlcad/branches/pre-7-12-6/ (6 files in 5 dirs): Merge in changes r31595 and 31609 - libbu compiles now. |
| 01:45.06 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 02:16.02 | pacman87 | old: https://webspace.utexas.edu/trv82/www/rev_rt20.png |
| 02:16.03 | pacman87 | new: https://webspace.utexas.edu/trv82/www/rev_rt21.png |
| 02:27.51 | Ralith | how's new work? |
| 02:28.05 | Ralith | union? |
| 02:28.12 | pacman87 | yes |
| 02:28.47 | Ralith | that's where you have something like [===|=] where | is x=0? |
| 02:28.54 | Ralith | and rotate it >180 degrees? |
| 02:29.03 | pacman87 | yes |
| 02:29.09 | pacman87 | 270 there |
| 02:29.11 | Ralith | cool |
| 02:37.11 | starseeker | ooooohhh crap |
| 02:41.32 | Ralith | ? |
| 02:46.40 | starseeker | has more of the libged stuff mixed in than he intended |
| 02:50.41 | starseeker | well, I can do it the hard way I suppose - start from the 7.12.4 release and check each change for breakage |
| 03:38.37 | *** join/#brlcad jonored (n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 03:44.48 | CIA-23 | BRL-CAD: 03starseeker * r32123 10/brlcad/branches/pre-7-12-6/current_successful_compile_rev.txt: Add file to record last revision verified to have built - will go away later, just for convenience now. |
| 03:45.37 | starseeker | alright, I'm outta here |
| 03:51.34 | brlcad | ~pacman87++ |
| 03:51.57 | brlcad | teh awesome |
| 03:52.16 | brlcad | almost time for another showcase :) |
| 03:52.51 | pacman87 | showcase? |
| 04:10.13 | brlcad | to share some of the results with users |
| 04:10.26 | brlcad | (nothing for you to do) |
| 04:10.30 | pacman87 | ah, ok |
| 04:10.47 | pacman87 | just fyi, revolve is still limited to straight line sketches |
| 04:11.11 | pacman87 | i wanted to get that all ironed out before it gets too complicated |
| 04:11.26 | brlcad | yep, got that |
| 04:11.39 | brlcad | tis a great approach |
| 04:11.54 | pacman87 | and i'm having some odd 'flipped normals detected' |
| 04:12.14 | pacman87 | i can't quite figure out exactly what's causing them |
| 04:12.18 | brlcad | that usually means that the hit points being returned from shot() aren't sorted |
| 04:13.20 | brlcad | an exit before an entry for the given shotline .. or a problem actually in norm() |
| 04:13.34 | pacman87 | i think it's in norm() |
| 04:13.58 | pacman87 | does it ever ask for the normal for a hit other than the first one? |
| 04:14.13 | brlcad | rt doesn't |
| 04:14.25 | brlcad | but the "first one" might be wrong if they're not sorted right from shot() |
| 04:14.41 | pacman87 | ok, i'll look at that again |
| 04:15.15 | pacman87 | for a revolve about Z, i use x/y coords, plus the slope of the line at the hitpoint |
| 04:16.17 | pacman87 | but that doesnt tell me which way is out from the surface |
| 04:17.46 | pacman87 | so i end up doing my own dot test between normal direction and ray direction to see if i should flip |
| 04:17.58 | pacman87 | which assumes only the first hit's normal is used |
| 04:19.21 | brlcad | noteworthy: "Subversion service will be offline on 2008-07-30 from 17:00 Pacific for not more than 12 hours to permit a rebuild of the storage used by the service, followed by further performance tuning." |
| 04:20.20 | pacman87 | is there a way to check whether a hitpoint is an 'in' or an 'out'? |
| 04:20.24 | brlcad | that should be a fair assumption |
| 04:21.18 | brlcad | obviously shouldn't be going away from the ray direction, should be coming back towards it |
| 04:21.29 | pacman87 | right, that's what i'm doing |
| 04:22.35 | brlcad | there's not really a fixed solution to check, primitive-specific -- usually, though, the logic goes into shot() and it just makes sure there is the right parity and ordering |
| 04:22.45 | brlcad | so norm can just pop off the first hit and return the normal |
| 04:22.53 | brlcad | there is an rt flag to debug normals |
| 04:26.17 | brlcad | various ways to do it using either nirt or rt, the trick being to just fire a single ray so you're not drowned in data and use the -x option |
| 04:26.33 | brlcad | various debug flags listed in include/raytrace.h, -x2 being useful for this |
| 04:26.50 | brlcad | it'll tell you the in/out segments |
| 04:27.39 | pacman87 | the thing is, the normal direction is right, so it's shaded properly; it's just reversed |
| 04:28.06 | brlcad | nirt -x2 something.g your_object .. then there are a slew of interactive commands for shooting from az/el's of interest for example |
| 04:28.37 | brlcad | rt trys to compensate when it gets a flipped normal by flipping it for you |
| 04:28.45 | brlcad | it does the same dot check |
| 04:39.06 | Ralith | hm, something's wrong with nirt's manpage |
| 04:39.45 | Ralith | <standard input>:785: cannot use character `1' as a starting delimiter |
| 04:42.49 | pacman87 | ah, i think i found it |
| 04:43.09 | pacman87 | paying attention to the surfno in the flipped normals error is helpful |
| 04:43.39 | pacman87 | my initial assumption that the sketch was always +x is coming back to bite me |
| 04:57.45 | brlcad | ah |
| 04:57.59 | brlcad | Ralith: there are only so many 1's in there, maybe you can pinpoint it? :) |
| 04:58.46 | brlcad | ah, I found it |
| 04:59.12 | brlcad | knows not what h does |
| 04:59.17 | Ralith | I was going to |
| 04:59.19 | Ralith | but then you found it |
| 04:59.30 | Ralith | commitstealer. >_> |
| 04:59.47 | brlcad | heh |
| 05:07.32 | pacman87 | success! |
| 05:07.50 | brlcad | ~pacman87++ |
| 05:07.56 | CIA-23 | BRL-CAD: 03brlcad * r32124 10/brlcad/trunk/src/nirt/nirt.1: fix the manpage so it doesn't have a \h 1 delimiter error. snarf a .FN macro to list the files |
| 05:08.39 | starseeker | returns to home base |
| 05:11.11 | brlcad | starseeker: wow, long day :) |
| 05:11.16 | CIA-23 | BRL-CAD: 03brlcad * r32125 10/brlcad/trunk/src/fbed/fbed.1: apply the .FN macro |
| 05:11.25 | brlcad | was thinking about maybe heading in soon |
| 05:11.27 | starseeker | is ready to admit he probably went about the release prep the wrong way |
| 05:11.35 | starseeker | heh - figures |
| 05:11.40 | brlcad | my shedule is about 12 hours off sync now |
| 05:11.53 | pacman87 | brlcad: move to new zealand |
| 05:11.59 | starseeker | at this rate, I'll show up about when you leave ;-) |
| 05:12.04 | brlcad | pacman87: heh |
| 05:12.15 | brlcad | usually operates on west coast US time |
| 05:12.45 | starseeker | is agast that subversion will be down - bad timing! |
| 05:13.19 | starseeker | just when I'm going back and checking incrementally |
| 05:13.20 | pacman87 | set up your own svn on brlcad's server? |
| 05:13.34 | starseeker | could grab a git repo |
| 05:13.38 | starseeker | or make one rather |
| 05:14.21 | starseeker | brlcad: At least make fun of my release prep so I don't feel so newbish |
| 05:15.33 | brlcad | or just build up into a bigger commit since you're on a branch, it's probably not worth the effort to do anything else but wait |
| 05:16.02 | brlcad | starseeker: make fun of it? heh |
| 05:16.10 | brlcad | it is rather .. methodical :) |
| 05:16.36 | brlcad | but good experience reviewing/merging changes too |
| 05:16.51 | starseeker | idiotic - I should have checked incrementally. I sucked in some libged stuff without intending to, and now it's well and truly foobared |
| 05:17.21 | brlcad | you can undo individual ranges if you know the revision numbers |
| 05:17.38 | starseeker | nods |
| 05:17.44 | brlcad | svn merge -rstart:end |
| 05:18.14 | starseeker | once I find the first breakage commit, that's probably what I'll do |
| 05:18.15 | brlcad | where start would be the newest and end the pre-commit state -- that reverts the change |
| 05:19.04 | starseeker | cool |
| 05:19.16 | starseeker | did that a couple times when he grabbed the wrong range |
| 05:20.15 | starseeker | I'm guessing I started to go off base when I merged in the primitive reorg - hyp and friends probably snuck in |
| 05:20.47 | pacman87 | aww, poor hyp didn't want to be left out of the fun ;) |
| 05:20.55 | starseeker | heh :-) |
| 05:21.23 | starseeker | it's not quite ready for stable - that's most of the challenge for this release, and the reason it requires a branch |
| 05:21.34 | starseeker | trunk has a lot of stuff in flux right now |
| 05:21.34 | pacman87 | i understand |
| 05:22.52 | pacman87 | if i have spare time during the 'finalize week', i'll look into finishing the todo for hyp |
| 05:22.59 | starseeker | cool :-) |
| 05:23.10 | pacman87 | when's the release date? |
| 05:23.40 | starseeker | whenever I get the branch straightened out and tested - probably sometime next week at this rate |
| 05:24.01 | starseeker | doesn't even want to think about the Windows build... |
| 05:24.38 | starseeker | brlcad: If you do go in soon, watch out for the deer - I must have seen four or five on the way out |
| 05:24.38 | pacman87 | just use (wine)^-1 |
| 05:24.51 | starseeker | heh |
| 05:25.03 | pacman87 | translate from linux to windows calls |
| 05:25.24 | Ralith | that's called mingw |
| 05:25.56 | brlcad | starseeker: yeah, it's always that way after about 10pm |
| 05:26.56 | pacman87 | "Students can begin submitting required code samples to Google" - from gsoc timeline |
| 05:26.58 | brlcad | i don't know that i've ever not seen one traveling between 10pm and 4am |
| 05:27.12 | pacman87 | what's that mean? |
| 05:27.28 | brlcad | pacman87: you upload code you've worked on |
| 05:28.02 | brlcad | that's technically your actual legal responsibility per the arrangement in place, that's what they pay you for |
| 05:28.17 | pacman87 | hmm, don't remmeber reading that part |
| 05:28.25 | pacman87 | and i though i read through the whole think |
| 05:28.27 | pacman87 | thing* |
| 05:28.29 | brlcad | which can be anything really, usually a tarball of files you've worked on, or svn diffs |
| 05:28.37 | starseeker | thinks dark thoughts about venison burgers and realizes he probably needs sleep |
| 05:30.52 | brlcad | crazy talk |
| 05:31.21 | CIA-23 | BRL-CAD: 03brlcad * r32126 10/brlcad/trunk/src/ (7 files in 5 dirs): apply the same FN macro changes consistently to the (surprisingly few) manual pages that have a FILES section. |
| 05:31.36 | starseeker | my grandfather used to hunt - venison meat is actually pretty darn tasty when prepared right |
| 05:32.19 | brlcad | nods |
| 05:33.15 | brlcad | one of the guys (that you haven't met yet) that used to work next to where you're sitting would bring in deer sticks and deer steaks from time to time, delicious |
| 05:33.42 | starseeker | :-) |
| 05:34.26 | starseeker | wants to read the slashdot LaTeX article but remembers he needs to be present at a presentation tomorrow... |
| 05:34.40 | starseeker | brlcad: Incidently, thanks for reviewing that for her |
| 05:34.43 | pacman87 | present and alert, or just present? |
| 05:35.05 | starseeker | snores, so at a minimum I need to be awake |
| 05:35.12 | brlcad | grrrr... |
| 05:35.12 | brlcad | data is pending on stdin |
| 05:35.12 | brlcad | DATA is: [] |
| 05:35.26 | starseeker | that's... odd |
| 05:35.48 | pacman87 | wonders how he lived for so long without knowing shitf+left/right arrow to change konsole tabs |
| 05:48.49 | Ralith | I don't understand the complaints some people have about LaTeX |
| 05:49.41 | Ralith | for me at least, it had very little learning curve (largely thanks to google) and behaved wonderfully for everything short of long URLs, which it can't seem to work out when to break. |
| 05:54.19 | pacman87 | brlcad: i'd rather keep " [ (x*x) / aa^2 ] - [ (y-h)^2 / bb^2 ] = 1 " in a comment in revolve, so i can remember where my variables are used in the formula for a hyperbola |
| 06:01.42 | pacman87 | ctrl+z just saved my life |
| 06:03.39 | brlcad | pacman87: ok .. am I supposed to object to useful comments? :) |
| 06:04.00 | pacman87 | you deleted it with the rest of the old code |
| 06:04.11 | brlcad | many of them spell out their equations, it's a good thing |
| 06:04.15 | brlcad | ooh, that wasn't intentional |
| 06:04.23 | brlcad | it was more the code |
| 06:04.31 | brlcad | sorry about that |
| 06:07.27 | pacman87 | np, but i'm pretty sure that line isnt' valid C when uncommented ;) |
| 06:07.59 | brlcad | depends on what cpp macros are defines ;) |
| 06:08.29 | brlcad | s/defines/defined/ |
| 06:08.56 | pacman87 | ok, maybe. but even if that was valid, it'd be horrible coding practice |
| 06:09.55 | brlcad | indeed |
| 06:10.01 | brlcad | obfuscated fun |
| 06:10.11 | brlcad | ugh, the is horrible .. select says there is data waiting on stdin .. but there's nothing to read |
| 06:10.29 | brlcad | that's seriously screwing with detecting whether we're interactive or not |
| 06:10.56 | pacman87 | how hard would it be to add mged history between sessions? |
| 06:12.02 | brlcad | not too hard, could probably keep a .mged_history file with a few variables to control it |
| 06:12.31 | pacman87 | i find myself exiting to do make && make install |
| 06:12.34 | pacman87 | then restarting |
| 06:12.42 | pacman87 | and wanting to run the same commands again |
| 06:13.05 | pacman87 | i've been using ; to seperate commands on a line |
| 06:13.08 | brlcad | yeah, that's be pretty useful |
| 06:13.10 | pacman87 | and shift+insert |
| 06:22.06 | CIA-23 | BRL-CAD: 03pacman87 * r32127 10/brlcad/trunk/src/librt/primitives/ (revolve/revolve.c sketch/sketch.c): |
| 06:22.06 | CIA-23 | BRL-CAD: change revolve to use a union instead of an xor when the -X and +X sides of a |
| 06:22.06 | CIA-23 | BRL-CAD: revolve overlap (ie, angle > 180). also, modify norm() to give the proper |
| 06:22.06 | CIA-23 | BRL-CAD: vector direction when the start/end surface is hit on a point with a -X |
| 06:22.06 | CIA-23 | BRL-CAD: coordinate. |
| 06:22.12 | pacman87 | that took way longer than it should've |
| 06:22.31 | pacman87 | i need more practice merging |
| 06:23.09 | pacman87 | almost completely wiped out my changes, then wiped out the other updates, and had to merge by hand |
| 06:23.30 | pacman87 | and being past 1am probably had something to do with it |
| 06:23.38 | pacman87 | anyway, goodnight |
| 06:23.42 | brlcad | or could work on a direct checkout too ;) |
| 06:23.53 | brlcad | avoid the hassle altogether |
| 06:24.16 | pacman87 | i usually do |
| 06:24.32 | brlcad | so why not? |
| 06:24.52 | pacman87 | well, if i'm working and you commit changes, i'll have to merge, right |
| 06:24.53 | pacman87 | ? |
| 06:25.25 | brlcad | ah, you mean actually just dealing with svn update merging, conflicts, etc? |
| 06:25.30 | pacman87 | yes |
| 06:25.34 | brlcad | ah, misunderstood |
| 06:25.41 | brlcad | though you were merging from a separate copy |
| 06:25.51 | pacman87 | since i'm usually the only one working on my files, i rarely have to deal with it |
| 06:26.00 | pacman87 | i think maybe three times so far |
| 06:26.04 | brlcad | ah |
| 06:26.11 | pacman87 | and most of those were oneliners |
| 06:26.12 | brlcad | shame that you can actually count the times |
| 06:26.32 | brlcad | what's really cool is seeing a half dozen guys all hit the same file simultaneously trying to get something done fast |
| 06:26.41 | pacman87 | sounds scary |
| 06:26.56 | brlcad | you end up wanting to svn up faster than you save |
| 06:27.18 | brlcad | really cool watching the file grow, though |
| 06:27.37 | pacman87 | so long as everyone know what part they're doing |
| 06:27.47 | brlcad | just wish it could be done live -- like with shared emacs editing sessions very cool to watch code just grow live in front of you |
| 06:27.58 | brlcad | two people editing the same line simultaneously |
| 06:28.00 | pacman87 | that would be cool |
| 06:28.10 | brlcad | it works, it's just a pita to set up |
| 06:28.28 | pacman87 | use comments to discuss code |
| 06:28.34 | brlcad | subethaedit folks also have it working, but for lan-only |
| 06:28.53 | brlcad | yeah, like google docs, but for code |
| 06:29.51 | pacman87 | really should be asleep, have fun playing with/trying to break revolve |
| 06:29.56 | brlcad | now if someone made a module to eclipse for that, I'd seriously revisit a switch .. something that keeps you continuously up to date with live code updates (line by line) |
| 06:30.01 | brlcad | hehe, k |
| 06:30.17 | pacman87 | too bad i can't distcc sleep |
| 06:30.35 | pacman87 | everyone else in the house is asleep, i'd be perfect |
| 06:30.48 | brlcad | :) |
| 06:31.07 | brlcad | the answer to that is to wake everyone else up, then go to bed |
| 06:31.37 | brlcad | yay, progress |
| 06:31.55 | brlcad | stdin has an exception pending in addition to select saying it's ready for reading |
| 06:32.07 | brlcad | even though feof and ferror are clear |
| 06:34.20 | brlcad | and NOW I run across a DDD snippet that does exactly what I just implemented |
| 06:37.30 | brlcad | consults the stevens bible |
| 07:12.38 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 07:13.11 | CIA-23 | BRL-CAD: 03brlcad * r32128 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: restore the other portion of the comment that I accidentally blew away |
| 07:21.36 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 07:26.43 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) |
| 07:52.42 | d_rossberg | pacman87: i would recommend to initialize "angle" in rt_revolve_shot before using it |
| 08:00.52 | CIA-23 | BRL-CAD: 03d_rossberg * r32129 10/brlcad/trunk/src/libged/CMakeLists.txt: some modifications to be consistent with Makefile.am |
| 08:04.44 | CIA-23 | BRL-CAD: 03brlcad * r32130 10/brlcad/trunk/src/libged/CMakeLists.txt: presumably which.c, not which |
| 08:06.54 | CIA-23 | BRL-CAD: 03brlcad * r32131 10/brlcad/trunk/src/mged/mged.c: (log message trimmed) |
| 08:06.54 | CIA-23 | BRL-CAD: significant change to mged's initialization. instead of using the (flawed) |
| 08:06.54 | CIA-23 | BRL-CAD: approach of using isatty() to determine if we're interactive, make interactive |
| 08:06.54 | CIA-23 | BRL-CAD: the default mode and find a reason to not be interactive. this is done by |
| 08:06.54 | CIA-23 | BRL-CAD: checking for command-mode args or redirected standard input. the latter one in |
| 08:06.57 | CIA-23 | BRL-CAD: particular was tricky given some means to invoke the application might leave the |
| 08:06.59 | CIA-23 | BRL-CAD: stdin read fd set even though there may be no data. this was specifically |
| 08:09.55 | CIA-23 | BRL-CAD: 03brlcad * r32132 10/brlcad/trunk/NEWS: |
| 08:09.55 | CIA-23 | BRL-CAD: make it possible to have mged invoked without needing a controlling terminal |
| 08:09.55 | CIA-23 | BRL-CAD: (e.g. as an icon or menu item). this specifically supports sf bug report |
| 08:09.55 | CIA-23 | BRL-CAD: 2019280 (mged incorrectly deduces interactivity) from lode_leroy where he tried |
| 08:09.56 | CIA-23 | BRL-CAD: to create a linux mged.desktop icon. was previously using a flawed approach |
| 08:09.58 | CIA-23 | BRL-CAD: that assumed being invoked from a controlling terminal. |
| 08:24.24 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 08:24.49 | CIA-23 | BRL-CAD: 03brlcad * r32133 10/brlcad/trunk/TODO: |
| 08:24.49 | CIA-23 | BRL-CAD: bu_log() and friends use %S for bu_vls structures. this was |
| 08:24.49 | CIA-23 | BRL-CAD: implemented long before libc decided to use it as an alias for %ls to |
| 08:24.49 | CIA-23 | BRL-CAD: support wchar_t strings. we should migrate to something else unused |
| 08:24.49 | CIA-23 | BRL-CAD: (like %V). somewhat non-trivial effort to deprecate and update even |
| 08:24.50 | CIA-23 | BRL-CAD: our own uses safely. |
| 08:26.30 | CIA-23 | BRL-CAD: 03brlcad * r32134 10/brlcad/trunk/src/mged/mged.c: minor cleanup. quell warnings, add some headers. |
| 08:43.50 | CIA-23 | BRL-CAD: 03brlcad * r32135 10/brlcad/trunk/misc/win32-msvc/CMakeLists.txt: |
| 08:43.50 | CIA-23 | BRL-CAD: stab in the dark. add the entire include directory to the run-time library |
| 08:43.50 | CIA-23 | BRL-CAD: package so that folks can compile against the libraries. this was requested by |
| 08:43.50 | CIA-23 | BRL-CAD: tom browder (ajem) in sf feature request 2019346 (Run-time Library Packaging). |
| 08:51.22 | d_rossberg | if it would be so easy i would have already done it |
| 08:51.28 | d_rossberg | ;) |
| 08:52.04 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 09:02.38 | mafm | hey |
| 09:06.37 | Ralith | hey mafm |
| 09:06.41 | Ralith | got g3d working :] |
| 09:07.00 | Ralith | had fun rotating your occluded wireframe |
| 09:07.15 | CIA-23 | BRL-CAD: 03brlcad * r32136 10/brlcad/trunk/ (5 files in 4 dirs): deprecate the duplicitous '-n' (not-new) option to mged. use -c console/classic/command option instead. |
| 09:07.17 | mafm | yup, I saw it |
| 09:07.21 | mafm | congrats :) |
| 09:07.41 | Ralith | although either your 'zoom' actually moves the camera around or your near clipping plane is set unreasonably |
| 09:07.49 | Ralith | cuz the example object dissapears after very little zooming in |
| 09:08.33 | mafm | I don't set the near clipping plane, so it must be ogre defaults |
| 09:08.42 | Ralith | (also, random though -- perhaps you could optionally render places where the near clipping plane intersects with an object as a specially colored surface?) |
| 09:08.47 | mafm | but the zoom actually moves the camera, yes |
| 09:09.12 | Ralith | mightn't literally zooming in be preferable? |
| 09:09.32 | Ralith | alternatively, consider logarythmic progression of zoom towards/away from the point on which the camera is centered. |
| 09:11.25 | mafm | I only discovered the zooming (by modifying size of window camera) yesterday, so the rest is implemented with distances |
| 09:11.44 | Ralith | but what're your thoughts on the Correct Way? |
| 09:11.57 | Ralith | btw, I'm happy to try implementing this myself, if you like |
| 09:13.30 | mafm | dunno what's the correct way, I'm still fighting to implement some of the MGED's functionalities |
| 09:14.27 | mafm | and trying to mimic them (Blender and MGED), althought the numeric approaches -zoom increments and so on- might not be always the more adequate |
| 09:14.50 | mafm | so maybe things like log() are more adequate, who knows |
| 09:14.55 | Ralith | I think both zoom and camera movement should probably be supported |
| 09:15.07 | Ralith | though I'm not sure how to do so elegantly |
| 09:15.44 | Ralith | for orthographic views it doesn't matter much, but once we start mapping g3d camera -> render config, this might become important |
| 09:16.37 | Ralith | I've got to go for the night -- if you've got any thoughts, including things that I could work on now that I've got commit access, I'd be interested to hear them in email. |
| 09:17.33 | mafm | ok |
| 09:17.51 | mafm | the thing is that I'm still fighting my way to finish some of the milestones for gsoc |
| 09:18.12 | mafm | I don't know if your work in some of the areas would be considered interfering or not |
| 09:18.24 | mafm | probably not from brlcad's (the person) point of view |
| 09:18.32 | Ralith | sean mentioned that collaboration was encouraged by gsoc |
| 09:18.42 | Ralith | I'm not sure of the specifics |
| 09:19.06 | mafm | you have my plans in the wiki page |
| 09:19.11 | Ralith | but I'm eager to work on whatever I can there. |
| 09:19.27 | Ralith | specifics insofar as the difference between collaboration and interference. |
| 09:19.27 | mafm | I'm now trying to make a widget from rbgui, mged mode needs to be finished |
| 09:19.50 | Ralith | I'm hesitant to pick work items off your TODO list for that reason |
| 09:19.58 | mafm | also Sean wants me to make a binary release |
| 09:20.09 | Ralith | tweaks and elaborations on what's already there are another matter |
| 09:20.18 | Ralith | anyway |
| 09:20.19 | mafm | and another thing that I can't remember at the moment |
| 09:20.22 | Ralith | we can discuss this more later |
| 09:20.24 | Ralith | gtg |
| 09:20.27 | Ralith | good luck |
| 09:20.31 | mafm | okay, g'night! |
| 09:20.33 | mafm | :) |
| 09:34.19 | *** join/#brlcad archivist_ub (n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 09:44.57 | *** join/#brlcad Elperion (n=Bary@p5B14F60E.dip.t-dialin.net) |
| 10:53.23 | *** join/#brlcad archivist_emc (n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 11:49.56 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 12:58.15 | yukonbob | morning, cadheads |
| 12:59.55 | brlcad | howdy yukonbob |
| 13:00.14 | brlcad | ponders taking a nap or heading in |
| 13:01.44 | yukonbob | gets ready to head to work... |
| 13:03.48 | yukonbob | ...and heads out. |
| 13:04.10 | yukonbob | bbl. Hope everybody has a good day... |
| 13:07.35 | brlcad | likewise! |
| 13:11.07 | brlcad | mafm: absolutely, you should put him to work given he's interested (and capable) |
| 13:11.44 | brlcad | it's all about grooming new devs, not reaching some end-of-summer project goal |
| 13:13.23 | brlcad | there's nothing he could do that will negatively reflect on you no matter how much you collaborate (nor what he screws up) |
| 13:14.16 | brlcad | ideally if this wasn't such a busy summer, all the devs would have been heavily coordinating with other devs on their projects throughout |
| 13:34.59 | *** join/#brlcad thing0 (n=ric@123.208.126.249) |
| 13:52.55 | starseeker | brlcad: Is there any way to run filemerge on OSX from the command line, supplying the two files as arguments? |
| 13:53.51 | brlcad | dunno |
| 13:53.52 | brlcad | probably |
| 13:54.00 | brlcad | run the binary directly |
| 13:54.54 | brlcad | tries |
| 13:55.39 | brlcad | doesn't look like it |
| 13:55.57 | brlcad | would have to script it via applescript |
| 13:58.23 | starseeker | ick |
| 13:58.33 | starseeker | likes xxdiff |
| 14:00.20 | *** join/#brlcad elmom (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) |
| 14:01.32 | starseeker | brlcad: ah - does opendiff work? |
| 14:02.08 | starseeker | reads man page on web and is hopeful |
| 14:02.23 | starseeker | that would increase the utility of FileMerge considerably |
| 14:02.32 | starseeker | OK, time to get in there |
| 14:13.49 | starseeker | note to self - check this out: http://ssel.vub.ac.be/ssel/internal:fmdiff |
| 14:24.58 | brlcad | ah yeah, opendiff does it |
| 14:25.57 | CIA-23 | BRL-CAD: 03d_rossberg * r32137 10/brlcad/trunk/misc/win32-msvc/CMakeLists.txt: undo previous change, it breaks the CMake build (add_subdirectory has to point to a directory containing a CMakeLists.txt file) and has no effect on the *_devel package |
| 14:26.26 | brlcad | oopses |
| 14:26.36 | brlcad | blind stab ftl |
| 14:29.18 | d_rossberg | commented your commit here in the irc |
| 14:30.01 | d_rossberg | i've created a package which includes the header files |
| 14:32.21 | brlcad | yeah, I read it .. but didn't imply that it was a totally failed attempt :) |
| 14:32.52 | brlcad | took it as "incomplete", was just busy processing to comment at the time |
| 15:02.45 | andrecastelo | good morning all |
| 15:03.15 | pacman87 | morning, andrecastelo |
| 15:03.50 | andrecastelo | i've been looking at the light sources creation, using light_maker(), in sh_light.c and it doesn't set a specific position for the light |
| 15:04.15 | andrecastelo | makes sense, since default light rays give the impression of being parallel.. |
| 15:04.30 | andrecastelo | it does, however, set up the direction of the light |
| 15:04.56 | andrecastelo | is it safe to make the secondary rays point in the opposite direction? |
| 15:06.21 | andrecastelo | when the light list is not empty, I get the first element position though |
| 15:11.52 | pacman87 | secondary rays for shadows? |
| 15:15.54 | andrecastelo | yes |
| 15:16.04 | andrecastelo | the ones that i shoot after the first hit |
| 15:20.23 | pacman87 | then yes, the secondary rays would point opposite to the light direction |
| 15:20.35 | pacman87 | the question now is 'how far away is the light source'? |
| 15:24.25 | andrecastelo | why? i think that at the moment it doesn't matter |
| 15:25.29 | pacman87 | i guess you could assume the light source is infinately far away |
| 15:26.23 | pacman87 | you need distance to the light in order to determine whether the first intersection of your secondary ray is before or after you get to the light source |
| 15:30.09 | andrecastelo | hmm.. true |
| 15:30.55 | pacman87 | though for default illumination, putting it at infinity is probably fine |
| 15:48.52 | mafm | brlcad: so he can chime in and work on *anything*? |
| 16:04.00 | *** join/#brlcad clock_ (n=clock@77-56-91-54.dclient.hispeed.ch) |
| 16:04.37 | pacman87 | primitives/arb8/arb8.c:1771: error: conflicting types for 'rt_arb_calc_planes' |
| 16:41.26 | CIA-23 | BRL-CAD: 03bob1961 * r32138 10/brlcad/trunk/src/mged/mged.c: Minor mods to get things compiling. :-) |
| 16:58.36 | CIA-23 | BRL-CAD: 03bob1961 * r32139 10/brlcad/trunk/ (19 files in 4 dirs): Convert more dg_obj commands for use by libged (i.e. rtcheck, rtabort, importFg4Section and vdraw. |
| 17:58.56 | *** join/#brlcad docelic (n=docelic@78.134.192.19) |
| 18:31.28 | CIA-23 | BRL-CAD: 03davidloman * r32140 10/rt^3/trunk/src/geometryService/: |
| 18:35.51 | CIA-23 | BRL-CAD: 03davidloman * r32141 10/rt^3/trunk/src/geometryService/cpp/: |
| 18:36.28 | CIA-23 | BRL-CAD: 03davidloman * r32142 10/rt^3/trunk/src/geometryService/java/: |
| 18:37.45 | CIA-23 | BRL-CAD: 03davidloman * r32143 10/rt^3/trunk/src/geometryService/java/stractNet/: |
| 18:37.58 | CIA-23 | BRL-CAD: 03bob1961 * r32144 10/brlcad/trunk/src/libged/title.c: Fixed typo. |
| 18:38.08 | CIA-23 | BRL-CAD: 03davidloman * r32145 10/rt^3/trunk/src/geometryService/java/stractThread/: |
| 18:42.29 | CIA-23 | BRL-CAD: 03davidloman * r32146 10/rt^3/trunk/src/geometryService/cpp/stractNet/: |
| 18:58.46 | CIA-23 | BRL-CAD: 03bob1961 * r32147 10/brlcad/trunk/src/libged/tol.c: Mods to allow getting individual tolerance settings. |
| 19:00.48 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 19:05.31 | mafm | hi Ralith |
| 19:05.51 | mafm | I was about to write you, but basically: you can work on anything you want |
| 19:07.54 | *** join/#brlcad paroneayea (n=user@fsf/member/paroneayea) |
| 19:08.11 | mafm | Ralith: preferably if it's not something in what I'm working on without agreement ;) you have the list of what I do in the wiki |
| 19:09.27 | CIA-23 | BRL-CAD: 03bob1961 * r32148 10/brlcad/trunk/src/libged/summary.c: Minor alteration of the error message. |
| 19:09.55 | Ralith | mafm: so leave the stuff on the wiki alone? |
| 19:10.43 | mafm | You can work in things like platform/compilation support, if that pleases you |
| 19:11.00 | mafm | including to make releases, is one of the things that Sean wanted to see |
| 19:11.47 | mafm | if you want to work with cameras as you suggested before, I can also delegate, but it's something that I was working on actively and some things are not finished yet (e.g. some MGED constrained modes) |
| 19:12.30 | mafm | so I think that either you or me do it, but not both at the same time (because I think that involves some possible heavy refactoring/redesign) |
| 19:12.59 | mafm | now I'm trying to create a window to control the camera, using some custom widgets |
| 19:13.15 | mafm | and the last remaining part is to start showing real geometry, using libged |
| 19:14.33 | mafm | Ralith: http://brlcad.org/wiki/User:Mafm#To_finish_GSoC (and the log, in the bottom, might be also interesting for you) |
| 19:14.38 | mafm | I have to go now, see you! :) |
| 19:33.25 | *** join/#brlcad andrecastelo (n=chatzill@189.71.12.203) |
| 19:53.11 | CIA-23 | BRL-CAD: 03bob1961 * r32149 10/brlcad/trunk/src/libged/showmats.c: Flesh out the showmats command. |
| 19:54.15 | *** join/#brlcad clock_ (n=clock@77-56-94-220.dclient.hispeed.ch) |
| 19:54.17 | poolio | stabs a tgc |
| 20:08.50 | *** join/#brlcad Rigolo (n=rigolo@cc14973-d.zwoll1.ov.home.nl) |
| 20:08.57 | Rigolo | good evening ... |
| 20:15.29 | *** join/#brlcad saltan (n=lievensa@d51530284.access.telenet.be) |
| 20:15.45 | Rigolo | good evening ... |
| 20:16.00 | saltan | evening all |
| 20:16.13 | Rigolo | well .. all ... |
| 20:16.29 | Rigolo | has been her now for a few minutes .. and nobody talks :-) |
| 20:16.36 | saltan | evening some |
| 20:16.36 | Rigolo | untill you joined |
| 20:16.57 | Rigolo | saltan: can I ask you a BRL-CAD conversion question? |
| 20:17.11 | saltan | please do but not an expert |
| 20:17.32 | Rigolo | knows noting about BRL-CAD ... so everybody in my is the expert |
| 20:17.45 | Rigolo | have you ever heard about the openmoko project? |
| 20:18.05 | jonored | grins and covets. |
| 20:18.22 | saltan | No, can't say that I have |
| 20:18.26 | starseeker | Rigolo: If you're asking about converting their cad files to BRL-CAD, we can convert the IGES files - sort of |
| 20:18.42 | Rigolo | starseeker: that was indeed my question .. :-) |
| 20:19.15 | Rigolo | on their wiki they are looking for other formats than what they currently have ... so i thought .. let's ask here |
| 20:19.27 | saltan | is off to find openmoko on the net |
| 20:19.54 | Rigolo | saltan: openmoko.org ... they are building a complete "free" mobile phone |
| 20:20.27 | Rigolo | http://wiki.openmoko.org/wiki/Neo1973_case_schematics that is where the CAD drawings for their phone can be found |
| 20:20.29 | starseeker | http://brlcad.org/gallery/s/screenshots/iges-openmoko-conversion.png.html |
| 20:20.49 | Rigolo | see .. I should have googled some more :-) |
| 20:21.28 | jonored | covets because he wants a phone that'll actually let him compile and use SSH and gpsd, and can be casemodded to survive being strapped to the outside of a kayak... |
| 20:21.56 | Rigolo | jonored: well .. then openmoko is your friend :-) |
| 20:22.06 | Rigolo | ssh and gpsd are standard on the new freerunner |
| 20:22.56 | Rigolo | although still under development .... you can make and receive calls, connect via sub to your desktop .. and then ssh into your phone |
| 20:23.01 | starseeker | iges-g is the convertor used - I forget the options |
| 20:23.13 | starseeker | so far i can only get the wireframe though |
| 20:23.20 | Rigolo | it contains a agps device ... |
| 20:23.48 | Rigolo | starseeker: and the other formats .. like those Pro/E files? |
| 20:24.40 | starseeker | Pro/E - not on its own, no |
| 20:25.11 | starseeker | needs other (commercial) libraries |
| 20:25.34 | jonored | I'd expect them to be - unfortunately, family plan with sister where only verizon has coverage for two years. And I've been curious whether it's actually got more computing power than my current laptop (CF-27, 300mhz PII..) - and ssh and phone (X perhaps) are all I need anyways :) |
| 20:25.36 | starseeker | Pro/E formats aren't documented anywhere that I'm aware of, so importing them directly is a tough problem |
| 20:25.42 | Rigolo | starseeker: okee ..because the wikipedia says it can import them ... http://en.wikipedia.org/wiki/Comparison_of_CAD_software |
| 20:26.21 | *** join/#brlcad Elperion (n=Bary@p5B14F60E.dip.t-dialin.net) |
| 20:26.27 | starseeker | Rigolo: You might ask brlcad about that, when he shows up |
| 20:27.21 | Rigolo | jonored: X is also on there .. it has a VGA touchscreen display (640x480 2.8") |
| 20:27.27 | jonored | Rigolo: I think the restriction is something loosely on the order of requiring a copy of Pro-E to do conversions with it's format. |
| 20:28.22 | Rigolo | jonored: okee ... so if the people that made these drawings (apparently using Pro/E) install BRL-CAD .. they could do it them selfs? |
| 20:28.28 | jonored | is aware. He's aware of the device, just stuck not having a service he can run it on for a couple years, and so hasn't ordered one already. |
| 20:28.56 | Rigolo | has one right here .. to the left ... GSM is eveywhere here in .nl |
| 20:29.13 | Rigolo | well ... you could start with the gps bits :-) |
| 20:29.21 | Rigolo | and start using the phone later :-) |
| 20:29.46 | jonored | Rigolo: For that I'm not sure - I was more justifying the listing of being able to convert, as it's as possible as it's reasonable to make it. |
| 20:30.58 | Rigolo | jonored: okee ... well ... I might update the openmoko wiki page and point to BRL-CAD as at least an opensource free software applicaiton that can do something with the CAD files |
| 20:31.50 | Ralith | Rigolo: does the latest model support 3G? |
| 20:32.01 | Ralith | starseeker: 'sort of' import IGES? |
| 20:32.03 | Rigolo | jonored: and ... within 2 years you must be able to design a nice casing for the freerunner |
| 20:32.10 | jonored | There's also the part where it's on the list after college expenses and a reprap :) - and GSM is, unfortunately, not available in the north end of Vermont - hence the sister needing verizon. |
| 20:32.20 | Rigolo | Ralith: no, only GSM with GPRS at the moment |
| 20:32.33 | Rigolo | but is has wifi |
| 20:32.35 | Ralith | Rigolo: call me when they've got 3G, then I want one. |
| 20:32.38 | Ralith | wifi drains battery life like no other. |
| 20:32.39 | starseeker | Ralith: It doesn't quite get you what you're probably expecting - it's not something (so far) that I can raytrace, for example |
| 20:32.53 | Ralith | starseeker: that doesn't sound like a very useful import |
| 20:33.21 | Ralith | it seems silly for me to ask you this, but did you try creating regions of the parts manually? |
| 20:33.39 | Rigolo | Ralith: no idea when that happens ... it is hard to get a "open" 3G chipset at the moment ... and that is not to expensive |
| 20:33.45 | starseeker | no, I was just testing the direct conversion |
| 20:34.02 | Ralith | Rigolo: unless the openmoko becomes incredibly cheap, I don't really care about the 'why' |
| 20:34.14 | starseeker | I rather expect we'll need robust BREP support before we can really handle openmoko importing "properly" |
| 20:34.17 | Ralith | I mean, it sounds like the perfect phone in all other respect |
| 20:34.18 | Ralith | s |
| 20:34.24 | starseeker | again, brlcad is the real expert here |
| 20:34.33 | Ralith | but I might as well wait for a proper commercial android phone |
| 20:35.02 | Rigolo | Ralith: even on androids you can not get to the real low level .. like with the openmoko phones |
| 20:35.18 | Ralith | Rigolo: they're linux. What's stopping me? |
| 20:35.56 | Ralith | jonored: by the way, did you start out here and go to reprap or vis versa? I can't work out where you originated >:| |
| 20:36.08 | jonored | Ralith: Possibly no root, binary kernel modules with tight lockdowns... |
| 20:36.11 | Rigolo | Ralith: start reading about android .... as far as I can tell .. they use a linux framework, but you can not "escape" from the android enviroment .. but I might be wrong |
| 20:36.36 | Ralith | jonored: that sounds kinda ghey |
| 20:36.48 | Ralith | Rigolo: you can escape from any environment when you own the hardware |
| 20:37.35 | Rigolo | Ralith: well, but if you can do anything with it .. that is an other question |
| 20:38.44 | jonored | Ralith: I've been watching the reprap since it was meccano and hot glue guns (and trying a little to get going doing useful things), and looking at BRL-CAD (and playing with it a little) since it hit slashdot... and just started using IRC, so hit the channels :) |
| 20:38.47 | Ralith | it'd be ludicrous if they didn't give you root |
| 20:38.50 | Ralith | even the iphone gives you root |
| 20:38.58 | Ralith | jonored: oh, neat! |
| 20:39.01 | Ralith | a kindred spirit :> |
| 20:39.08 | Rigolo | Ralith: .... software installed by end-users must be written in Java, and will not have access to lower level device APIs ... |
| 20:39.17 | Ralith | Rigolo: that sounds like BS to me |
| 20:39.18 | Rigolo | http://en.wikipedia.org/wiki/Google_Android#Criticism |
| 20:39.35 | Ralith | wikipedia is not my idea of a reliable source :P |
| 20:39.54 | Rigolo | Ralith: and the iphone does not give you real root .... you can not run anything on the iPhone when it is not signed by apple |
| 20:40.56 | Rigolo | http://www.fsf.org/blogs/community/why-free-software-and-apples-iphone-dont-mix .. read this then :-) |
| 20:41.45 | Ralith | Rigolo: people do it all the time; it's called hacking it :P |
| 20:41.50 | Rigolo | but ... this channel is about BRL-CAD .. not iphones and the pro and cons of free software :-) |
| 20:42.04 | Ralith | in practice I don't care if something's locked down if it's a straightforward hack |
| 20:42.04 | Rigolo | Ralith: well .. .the iPhone linux guys are still strugling ... |
| 20:42.15 | Ralith | iphones are already unixy enough for me |
| 20:42.26 | Rigolo | Ralith: okee |
| 20:43.02 | jonored | The openmoko thing is a bit like the differene between having a tivo that's built on linux and hacking into it and having a gentoo box running a media app... |
| 20:43.02 | Ralith | I'm more interested in just where you got the idea that andriod would only support java for third party stuff |
| 20:43.38 | Ralith | jonored: to me, that says "openmoko probably won't work, but at least it'll take all week to set up." |
| 20:43.52 | Rigolo | http://www.theregister.co.uk/2008/02/02/google_android_developers_view/ |
| 20:44.19 | Rigolo | and openmoko at the moment works for basic things like calls and sms .. |
| 20:44.29 | starseeker | uses and likes Gentoo |
| 20:45.03 | Rigolo | openmoko is build using the openembedded framework ... |
| 20:45.31 | Ralith | Rigolo: that says quite clearly that *all* apps run on a VM, not that java is used |
| 20:45.46 | jonored | is quite pleased with his Gentoo machine; it's the one that lives on his back in the CF-27. |
| 20:45.58 | Rigolo | and just like with any linux device .. there are multiple "distributions" already .. so you can choose what you like .. but don't expect the iphone user experiance just yet |
| 20:46.36 | Ralith | Rigolo: I don't mind a unpolished GUI. Ever used windows mobile? |
| 20:46.47 | Ralith | You wouldn't believe how horrible their GUI is. |
| 20:46.48 | Rigolo | Ralith: http://www.betaversion.org/~stefano/linotype/news/110/ |
| 20:47.03 | Rigolo | Ralith: that is why I never user WinMob |
| 20:47.32 | Ralith | What I want is mobile high speed internets in a pocketable form, and with a sufficiently unixy system that I can do fun things like set it up as a wifi access point |
| 20:48.16 | Rigolo | Ralith: well .. that last bit kills the moko for your completly .. their wifi chips do not allow AP functionality .. only client |
| 20:48.33 | Ralith | that can be prevented in hardware? |
| 20:48.38 | Rigolo | but don't expect an android phone to do that either |
| 20:48.41 | Ralith | that sucks |
| 20:48.43 | Ralith | but it was only an example |
| 20:48.46 | Rigolo | Ralith: yes |
| 20:48.50 | Rigolo | Ralith: oke :-) |
| 20:49.02 | Ralith | Rigolo: that agains says that java is not used, and the former article implies that the VM is language independent |
| 20:49.08 | Ralith | really |
| 20:49.17 | Ralith | so long as I can make the thing route traffic from outside sources |
| 20:49.20 | Ralith | I don't mind having to wire it up |
| 20:49.37 | starseeker | Ah, no wonder they hyp primitive got sucked into the reorg - it was there in 7.12.4 |
| 20:49.38 | Rigolo | Ralith: android apps are writen in java .. and then compiles to a google owned VM enviroment |
| 20:49.38 | Ralith | Rigolo: can it do USB host? |
| 20:50.03 | Ralith | starseeker: despite being considered incomplete? |
| 20:50.05 | Rigolo | Ralith: openmoko can do both ... but usb 1.1 on this version |
| 20:50.21 | Ralith | so long as it can be a host |
| 20:50.24 | jonored | Ralith: Being an AP requires capabilities that aren't required for being a client - it's not really surprising that they wouldn't neccessarily include it in a chipset. |
| 20:50.36 | Ralith | jonored: I wasn't sure how much is done in hardware. |
| 20:50.48 | starseeker | Ralith: it happens sometimes - 7-12-4 was a tag, it might have been removed from the tarball |
| 20:51.11 | Ralith | if openmoko can be a USB host, that probably means I could wire up a USB wifi stick that *does* have AP support |
| 20:51.19 | Ralith | even if it's unpowered host, it's not too hard to stick a battery inline |
| 20:51.41 | jonored | Ralith: Depends on the chipset, I think. |
| 20:51.43 | Ralith | then, instant mobile wireless internet for anyone in my vicinity :> |
| 20:51.46 | Ralith | jonored: huh? |
| 20:51.52 | Rigolo | Ralith: yes ... that should work ... |
| 20:52.05 | Ralith | awesomeness. |
| 20:52.15 | Ralith | still needs to have 3G before I spend >$100 on one though |
| 20:52.16 | Rigolo | Ralith: but I already did that with a 50 Euro ASUS wifi router and a UMTS usb card .. |
| 20:52.37 | Ralith | can you make/receive phone calls with that router? :P |
| 20:52.50 | Rigolo | connected a complete computer retails shop like that for over 30 days |
| 20:52.51 | Ralith | one cellular subscription is enough, ty |
| 20:53.03 | Ralith | although |
| 20:53.12 | Ralith | do you know where I could get a USB HSDPA card for not-hugely-expensive? |
| 20:53.25 | Ralith | with north american frequency support |
| 20:53.50 | Rigolo | not straight away .... got mine via my provider .. with a 2 year unlimited data only plan ... |
| 20:54.15 | Rigolo | and cancelled that after 30 days .. (and got money back ..minus one month subscription fee) |
| 20:54.56 | Ralith | US cell phone providers are nowhere near as kind |
| 20:55.05 | Ralith | $200+ cancellation fees |
| 20:55.13 | Ralith | shitty hardware-with-contract deals |
| 20:55.17 | Rigolo | well .. it helped that we had 200 other subscriptions with them :-) |
| 20:55.24 | Ralith | heh |
| 20:55.50 | Rigolo | and .. they were also our DSL provider that scrwed up with installing DSL at a new shop :-) |
| 20:55.55 | Ralith | has a PCMCIA HSDPA card, but his new laptop only has an express card slot >:| |
| 20:56.24 | Rigolo | Ralith: there must be express cards with HSDPA out there .. or not? |
| 20:57.53 | jonored | Ralith: If there are USB ones, then there should be express card ones - same design, just a different connector - USB is one of the lines going to that slot. |
| 20:59.29 | Ralith | there are plenty, they're just all very expensive |
| 20:59.46 | Ralith | $200+ for what I've seen |
| 20:59.57 | Ralith | cellular tech is very price-raped :( |
| 21:00.06 | jonored | Ah, okay. |
| 21:00.38 | Ralith | whereas my PCMCIA card was about $70 on ebay |
| 21:02.49 | saltan | is off now and thanks for fascinating banter |
| 21:04.16 | Rigolo | and Rigolo is also going .. thanks for the update on BRL-CAD and openmoko CAD files :-) |
| 21:08.15 | *** part/#brlcad Rigolo (n=rigolo@cc14973-d.zwoll1.ov.home.nl) |
| 21:09.37 | CIA-23 | BRL-CAD: 03homovulgaris * r32150 10/brlcad/trunk/src/libpc/ (9 files): detemplating the PCSet class. Using a list of VariableAbstract* rather than Variable<T> to hold the set of Variables. noticing valgrind memory leak of 160 bytes : due to pc_pc_set macros/functions |
| 21:12.19 | Ralith | so poolio's working on the code to generate an accurate set of surfaces from an arbitrary region is poolio's WIP, right? Anyone feel able to quantify the state of that project? |
| 21:37.33 | *** join/#brlcad Elperion (n=Bary@p5B14F60E.dip.t-dialin.net) |
| 21:55.50 | CIA-23 | BRL-CAD: 03starseeker * r32151 10/brlcad/branches/pre-7-12-6/current_successful_compile_rev.txt: builds ok to this point with the one exception noted. |
| 22:12.21 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 22:12.49 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) [NETSPLIT VICTIM] |
| 22:13.26 | *** join/#brlcad starseeker (n=starseek@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 22:32.51 | *** join/#brlcad Elperion (n=Bary@p5B14F60E.dip.t-dialin.net) |
| 22:46.26 | CIA-23 | BRL-CAD: 03homovulgaris * r32152 10/brlcad/trunk/src/libpc/ (pcPCSet.cpp pcPCSet.h): forward declaration of Constraint Class and definition of getVariableID function so as to support usage of PCSet methods by the constraint object |
| 22:49.22 | CIA-23 | BRL-CAD: 03homovulgaris * r32153 10/brlcad/trunk/src/libpc/ (pcConstraint.cpp pcConstraint.h solver_test.cpp): specifying PCSet reference in the constraint object and corresponding modification in the constructors |
| 23:05.16 | CIA-23 | BRL-CAD: 03andrecastelo * r32154 10/brlcad/trunk/misc/win32-msvc9/libged/libged.vcproj: Added several missing files to the msvc9 build. |
| 23:09.32 | *** join/#brlcad andrecastelo_ (n=chatzill@189.71.31.114) |
| 23:30.31 | *** join/#brlcad Elperion (n=Bary@p5B14F60E.dip.t-dialin.net) |
| 23:50.53 | *** join/#brlcad andrecastelo__ (n=chatzill@189.71.78.186) |
