| 00:08.23 | *** join/#brlcad Ralith (n=ralith@69.90.48.97) | |
| 00:24.38 | *** join/#brlcad indianlarry (n=indianla@BZ.BZFLAG.BZ) | |
| 00:24.38 | *** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT VICTIM] | |
| 00:27.34 | ``Erik | wanders into asc2g's nmg code O.o |
| 00:36.34 | ``Erik | ghuh, v4 nmg asc is fuuuuuugly |
| 00:37.47 | ``Erik | mebbe rt_nmg_adjust() would be better to look at O.o |
| 00:55.25 | starseeker | raises eyebrows - apparently at least some of varkon is LGPL - interesting |
| 00:56.53 | ``Erik | starseeker: didja read http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ ? |
| 00:57.17 | starseeker | yeah |
| 00:57.26 | starseeker | I understand why sourceforge is doing it |
| 00:57.39 | ``Erik | oh, then what were ya asking? |
| 00:58.03 | starseeker | whether there is anything specifically on sourceforge that caused someone to worrry |
| 00:58.43 | starseeker | they've been up for years, and all of a sudden last week they start blocking? what happened? |
| 00:58.56 | ``Erik | ah, *shrug* the tone of the blog and other stuff involved doesn't sound like it, more like they put it off until the last minute |
| 01:01.32 | ``Erik | season premier of top gear is on |
| 01:02.36 | starseeker | ``Erik: how are you doing the grid ray firing for marching cubes? |
| 01:02.54 | starseeker | suddenly wonders if there is overlap here between gqa and marching cubes... |
| 01:04.10 | ``Erik | so far, I'm not... I was going to start iwth a very naive walk, then start looking at caching pertinent rays and if that changes the performance |
| 01:16.00 | starseeker | is endangering himself by thinking about the problem... arrgh... |
| 01:27.33 | ``Erik | heh, wow... they de-helmetted the stig... there goes that aspect of that show O.o |
| 01:31.01 | ``Erik | ahhhh, supposedly he's not the real stig, but ferrari wouldn't let the regular stig drive the fxx... O.o |
| 03:09.29 | ``Erik | hm, für elise is kinda tricky on the gitfiddle O.o |
| 03:51.41 | ``Erik | best. emoticon. ever. http://thefifthamendment.org/images/liteduel.gif |
| 08:55.13 | *** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu) | |
| 11:10.37 | *** join/#brlcad mafm (n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) | |
| 14:25.22 | CIA-82 | BRL-CAD: 03davidloman * r37405 10/rt^3/trunk/src/GS/NetSockPortal.cxx: D-lo: forgot 'delete' |
| 14:45.13 | starseeker | brlcad: is it release 7.18.0 when we rename all the g_ tools? |
| 14:54.23 | *** join/#brlcad Yoshi47 (n=jan@64.235.102.210) | |
| 15:01.17 | brlcad | starseeker: per doc/deprecation.txt yeah, that should be |
| 15:01.55 | brlcad | it was deprecated in 7.14, and while only two minor releases with the deprecation notice (7.14 and 7.16), more than three months have passed |
| 15:02.09 | starseeker | can't wait... |
| 15:05.32 | CIA-82 | BRL-CAD: 03brlcad * r37406 10/brlcad/trunk/TODO: |
| 15:05.32 | CIA-82 | BRL-CAD: stephen *almost* got everything done on the new heat graph lighting model, but |
| 15:05.32 | CIA-82 | BRL-CAD: there are some critical flaws that need to be fixed before it can go live. |
| 15:05.32 | CIA-82 | BRL-CAD: Minimally, the splotches need to get taken care of and it will crash with |
| 15:05.32 | CIA-82 | BRL-CAD: parallel enabled. needs a little more attention, but not likely for 7.16.6. |
| 15:07.25 | CIA-82 | BRL-CAD: 03brlcad * r37407 10/brlcad/trunk/TODO: push down vls wrapping (for annotations) and rt_functab refactoring. might still happen, but release priority should be on fixing the EDITOR bug, mged invocation, and testing wcodes/rcodes/edcodes. |
| 15:07.52 | brlcad | if we get a couple bugs/issues fixed, we can stamp out a release and bump to 7.17.0 for a new minor |
| 15:08.01 | brlcad | this week |
| 15:08.08 | starseeker | nods |
| 15:08.23 | starseeker | I'll see what I can do with the EDITOR bug, if you like |
| 15:08.44 | brlcad | sure, that one isn't too tricky |
| 15:08.48 | brlcad | i already isolated the problem |
| 15:08.50 | brlcad | if you recall |
| 15:08.58 | brlcad | it's just what to do about it |
| 15:09.59 | starseeker | right - the move to libged resulted in the loss of some knowledge needed for the handling of special cases |
| 15:10.24 | brlcad | yeah |
| 15:10.38 | brlcad | the code that talked to libfb that figured out which editor to use was ripped out |
| 15:11.14 | brlcad | so either that logic (in libfb) needs to be moved, or called before we get to libged, or made generic libbu facility, etc |
| 15:11.48 | starseeker | kinda thinks libbu makes the most sense - presumably it's something any app MIGHT care about... |
| 15:12.13 | brlcad | the tricky part is in figuring out which editor to use .. it needs to know how to invoke it |
| 15:12.17 | brlcad | which depends on the GUI |
| 15:12.23 | brlcad | i.e. libfb or libdm |
| 15:12.37 | starseeker | hmm |
| 15:13.34 | brlcad | if it's an X11 app, it needs to invoke EDITOR with something like "xterm -e $EDITOR" |
| 15:13.51 | brlcad | that's something that can be passed to libbu |
| 15:14.11 | brlcad | the old way was limited anyways, it was defined during compile-time |
| 15:14.17 | starseeker | yeah, conditionalize the routine based on a supplied input... |
| 15:14.22 | starseeker | urgh |
| 15:14.23 | brlcad | so even if you were running mged in console, it would xterm -e |
| 15:14.33 | starseeker | O.o |
| 15:14.49 | brlcad | (so long as that mged had x11 support, it figured it was safe) |
| 15:14.57 | starseeker | that would have been entertaining when we got Aqua going... |
| 15:15.36 | brlcad | src/mged/tedit.c is where the old logic resides |
| 15:15.59 | brlcad | src/libged/editit.c is the new stuff |
| 15:16.05 | brlcad | have fun |
| 15:16.45 | starseeker | so, tedit logic to libbu, editit to call libbu to get info, check if anything still calls f_tedit |
| 15:16.48 | starseeker | got it |
| 15:17.20 | brlcad | it won't migrate directly |
| 15:17.57 | brlcad | it has if defined(DM_X) checks |
| 15:18.02 | starseeker | ah |
| 15:18.02 | brlcad | that was the problem moving it to libged |
| 15:18.14 | brlcad | so that has to be refactored and sorted out somehow |
| 15:18.33 | starseeker | OK, so rather than doing checks just have it be told by the calling routine |
| 15:18.51 | brlcad | right |
| 15:19.25 | starseeker | might have to have some info passed to the libged routine it doesn't get now... that'll be routine checking |
| 15:19.48 | brlcad | then either reverting back to the one in mged for now if you keep things tied to libdm() or having "some" means for libged to know how to invoke an editor |
| 15:20.21 | brlcad | yeah, would need to pass the info somehow |
| 15:20.51 | brlcad | I can think of a couple ways to totally cheat if you can't figure something out |
| 15:20.57 | starseeker | hehe |
| 15:21.16 | starseeker | can get Tk to tell him the windowing system in use... |
| 15:21.26 | brlcad | bu doesn't have tk |
| 15:21.42 | brlcad | and the tcl it has in some places is getting removed |
| 15:21.49 | starseeker | I know - get the windowing system value and pass it to libged, which passes it to bu |
| 15:22.31 | brlcad | keeping editit() as an mged function instead of a libged function could be a viable answer too |
| 15:22.43 | brlcad | as it is application specific, how to edit something |
| 15:23.20 | starseeker | nods - that actually would have been my first impulse, but I had assumed you wanted it made generic in case other programs wanted to fire up an editor |
| 15:24.57 | brlcad | affects wcodes/rcodes/edcodes/ted/red |
| 17:33.32 | *** join/#brlcad talcite (n=matthew@dhcp-143-151.mcme-students.carleton.ca) | |
| 17:44.45 | talcite | brlcad: ping? |
| 18:23.24 | *** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu) | |
| 18:46.38 | CIA-82 | BRL-CAD: 03erikgreenwald * r37408 10/isst/trunk/src/ (gui.c isst.h): handle passing mesh list to library for filling |
| 18:47.01 | CIA-82 | BRL-CAD: 03erikgreenwald * r37409 10/brlcad/trunk/src/adrt/ (adrt.h load.c load_g.c): fill mesh name list on load |
| 18:53.13 | ``Erik | hah, exploring the show "heroes" :D http://www.reallifecomics.com/ |
| 19:05.55 | CIA-82 | BRL-CAD: 03erikgreenwald * r37410 10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c: count triangles |
| 19:06.57 | CIA-82 | BRL-CAD: 03erikgreenwald * r37411 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: return # of triangles on success (1-5). Use V3ARGS where possible. start some brain dump on nmg building |
| 19:30.37 | CIA-82 | BRL-CAD: 03brlcad * r37412 10/brlcad/trunk/TODO: the tree command should work with full paths |
| 19:36.27 | brlcad | looks like rcodes/wcodes/edcodes are working nicely with object name >256 and paths >12 |
| 19:44.19 | *** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu) | |
| 20:19.09 | CIA-82 | BRL-CAD: 03brlcad * r37413 10/brlcad/trunk/src/libged/editit.c: print a loud message to let the user know that they need to quit their editor before mged will come back to the land of the living. this restores feedback functionality removed during the libged migration. |
| 20:21.28 | CIA-82 | BRL-CAD: 03brlcad * r37414 10/brlcad/trunk/src/libbu/vls.c: |
| 20:21.28 | CIA-82 | BRL-CAD: wow, OLD OLD bug here. bu_vls_prepend wasn't incrementing the book-keeping size |
| 20:21.28 | CIA-82 | BRL-CAD: of the vls after appending something. this resulted in chars getting nibbled |
| 20:21.28 | CIA-82 | BRL-CAD: off the end until eventually an overflow is encountered. curiously, we weren't |
| 20:21.28 | CIA-82 | BRL-CAD: even using this function before r37413 change to edcodes (at least not any |
| 20:21.30 | CIA-82 | BRL-CAD: more). |
| 20:22.20 | CIA-82 | BRL-CAD: 03brlcad * r37415 10/brlcad/trunk/src/libged/editit.c: minor ws |
| 20:23.01 | CIA-82 | BRL-CAD: 03indianlarry * r37416 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: Fix cases where multiple entrances or exits are encountered along a BOT shotline often an artifact of a surface grazing. Currently implemented a first entrance, last exit approach. |
| 20:23.57 | CIA-82 | BRL-CAD: 03brlcad * r37417 10/brlcad/trunk/TODO: rcodes/wcodes/edcodes seems to be working just fine now with object names >256 and depths >12. verified that previous version failed and that new version works as expected. |
| 20:24.13 | CIA-82 | BRL-CAD: 03erikgreenwald * r37418 10/brlcad/trunk/src/adrt/librender/cut.c: disable mesh marking for now, seems to cause infinite loop... |
| 20:31.32 | CIA-82 | BRL-CAD: 03brlcad * r37419 10/brlcad/trunk/TODO: note to look at the globbing code. noticed some debackslashing/slashing code in there. |
| 20:38.28 | CIA-82 | BRL-CAD: 03brlcad * r37420 10/brlcad/trunk/TODO: nasty non-portable code that needs fixing in src/libged/tables.c and that needs to use bu_temp_file() or some other mechanism. |
| 20:43.10 | CIA-82 | BRL-CAD: 03brlcad * r37421 10/brlcad/trunk/src/libged/ (14 files): remove most all references to MGED, eliminate some dead code, cleanup comments |
| 21:28.06 | CIA-82 | BRL-CAD: 03brlcad * r37422 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: add some additional thoughts about FILO vs LIFO, an example on a concave case as well, and the issue about slipping through cracks without checking neighbors. |
| 21:33.19 | ``Erik | we should go with FINO... first in, never out, /dev/null ftw |
| 21:33.23 | ``Erik | :D *duck* |
| 21:34.34 | *** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1) | |
| 21:59.19 | *** join/#brlcad max1234 (n=max@adsl-223-114-225.aep.bellsouth.net) | |
| 22:00.06 | max1234 | I am looking for a good program to do 2d renderings of datacad houses on, can anyone help me? |
| 22:09.21 | max1234 | hello |
| 22:22.45 | *** join/#brlcad Nohla (n=jesica@168.226.178.47) | |
| 22:23.24 | starseeker | brlcad: is http://sourceforge.net/projects/expect/ relevant to the MGED terminal dicussion? specifically, http://www.mel.nist.gov/msidlibrary/doc/libes96a.ps |
| 22:23.38 | brlcad | mildly |
| 22:24.43 | brlcad | not directly, applicable though -- it would be good for automating interactions with a given tty application |
| 22:25.11 | starseeker | so the libes96a.ps paper is something else? |
| 22:25.28 | ``Erik | nifty, nmgmodel gives me the same error's I've been seeing in my cube crap |
| 22:28.38 | brlcad | starseeker: not exactly |
| 22:28.45 | brlcad | what that paper is doing is basically what we need |
| 22:29.02 | brlcad | the use of expect, though, is basically a "cheat" |
| 22:29.22 | brlcad | most of the useful work he shows there actually has little to do with expect |
| 22:31.34 | brlcad | like I said, the "hard" part is getting something that *portably* acquires a controlling tty (via open_pty() or similar) so that it works on windows too |
| 22:32.17 | brlcad | they use expect to get the tty and also as a pseudo libtermio for handling the character control codes |
| 22:32.30 | brlcad | at least that's what it looks like at a glance |
| 22:32.38 | starseeker | nods |
| 22:32.50 | brlcad | could be usable. expect is a bit of a "large" extension iirc |
| 22:33.48 | brlcad | the bit that expect provides could probably be rewritten with a simple C function or two |
| 22:34.02 | starseeker | cool |
| 22:34.25 | brlcad | you could start similar to how they start, invoking a SHELL, etc |
| 22:34.27 | brlcad | see where things go |
| 22:34.52 | brlcad | just instead of using expect, make your own functions that give a tty, and other functions that do pass-throughs to libtermio |
| 22:34.56 | brlcad | or curses |
| 22:35.10 | starseeker | you said someone had done a tk curses implementation? |
| 22:35.40 | brlcad | yes and no, someone made a curses-like interface |
| 22:36.11 | brlcad | don't think there's a reason you couldn't just have a binding layer to an actual termio library |
| 22:38.59 | starseeker | nods. |
| 22:39.16 | starseeker | finds cTk, which appears to be a curses backend for Tk?? |
| 22:39.21 | starseeker | how very odd |
| 22:40.14 | starseeker | shakes himself - need to get back to actually changing the current code here... |
| 22:42.35 | starseeker | more fun to play with the tkterm ;-) |
| 22:46.45 | starseeker | winces - /usr/X11R6/bin/xterm isn't a universal place to find an xterm |
| 22:47.09 | *** join/#brlcad CIA-34 (n=CIA@208.69.182.149) | |
| 22:55.18 | *** join/#brlcad ibot (i=ibot@rikers.org) | |
| 22:55.18 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs at http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.4 in prep, should be posted 20100114 | |
| 22:56.34 | *** join/#brlcad Stattrav (n=Stattrav@202.3.77.161) | |
| 23:08.55 | starseeker | brlcad: I don't suppose we could include a gen_ptr slot in the ged struct the way the rt application data structure does? |
| 23:12.12 | brlcad | ideally not |
| 23:12.27 | *** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu) | |
| 23:12.39 | brlcad | undefined void pointers on a public interface are usually a deficiency/incompleteness of the interface to support something |
| 23:13.23 | starseeker | crud |
| 23:13.30 | starseeker | well, there goes that idea |
