IRC log for #brlcad on 20100126

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``Erikwanders into asc2g's nmg code O.o
00:36.34``Erikghuh, v4 nmg asc is fuuuuuugly
00:37.47``Erikmebbe rt_nmg_adjust() would be better to look at O.o
00:55.25starseekerraises eyebrows - apparently at least some of varkon is LGPL - interesting
00:56.53``Erikstarseeker: didja read http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ ?
00:57.17starseekeryeah
00:57.26starseekerI understand why sourceforge is doing it
00:57.39``Erikoh, then what were ya asking?
00:58.03starseekerwhether there is anything specifically on sourceforge that caused someone to worrry
00:58.43starseekerthey've been up for years, and all of a sudden last week they start blocking?  what happened?
00:58.56``Erikah, *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``Erikseason premier of top gear is on
01:02.36starseeker``Erik: how are you doing the grid ray firing for marching cubes?
01:02.54starseekersuddenly wonders if there is overlap here between gqa and marching cubes...
01:04.10``Erikso 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.00starseekeris endangering himself by thinking about the problem... arrgh...
01:27.33``Erikheh, wow... they de-helmetted the stig... there goes that aspect of that show O.o
01:31.01``Erikahhhh, supposedly he's not the real stig, but ferrari wouldn't let the regular stig drive the fxx... O.o
03:09.29``Erikhm, für elise is kinda tricky on the gitfiddle O.o
03:51.41``Erikbest. 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.22CIA-82BRL-CAD: 03davidloman * r37405 10/rt^3/trunk/src/GS/NetSockPortal.cxx: D-lo: forgot 'delete'
14:45.13starseekerbrlcad: 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.17brlcadstarseeker: per doc/deprecation.txt yeah, that should be
15:01.55brlcadit 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.09starseekercan't wait...
15:05.32CIA-82BRL-CAD: 03brlcad * r37406 10/brlcad/trunk/TODO:
15:05.32CIA-82BRL-CAD: stephen *almost* got everything done on the new heat graph lighting model, but
15:05.32CIA-82BRL-CAD: there are some critical flaws that need to be fixed before it can go live.
15:05.32CIA-82BRL-CAD: Minimally, the splotches need to get taken care of and it will crash with
15:05.32CIA-82BRL-CAD: parallel enabled. needs a little more attention, but not likely for 7.16.6.
15:07.25CIA-82BRL-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.52brlcadif 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.01brlcadthis week
15:08.08starseekernods
15:08.23starseekerI'll see what I can do with the EDITOR bug, if you like
15:08.44brlcadsure, that one isn't too tricky
15:08.48brlcadi already isolated the problem
15:08.50brlcadif you recall
15:08.58brlcadit's just what to do about it
15:09.59starseekerright - the move to libged resulted in the loss of some knowledge needed for the handling of special cases
15:10.24brlcadyeah
15:10.38brlcadthe code that talked to libfb that figured out which editor to use was ripped out
15:11.14brlcadso either that logic (in libfb) needs to be moved, or called before we get to libged, or made generic libbu facility, etc
15:11.48starseekerkinda thinks libbu makes the most sense - presumably it's something any app MIGHT care about...
15:12.13brlcadthe tricky part is in figuring out which editor to use .. it needs to know how to invoke it
15:12.17brlcadwhich depends on the GUI
15:12.23brlcadi.e. libfb or libdm
15:12.37starseekerhmm
15:13.34brlcadif it's an X11 app, it needs to invoke EDITOR with something like  "xterm -e $EDITOR"
15:13.51brlcadthat's something that can be passed to libbu
15:14.11brlcadthe old way was limited anyways, it was defined during compile-time
15:14.17starseekeryeah, conditionalize the routine based on a supplied input...
15:14.22starseekerurgh
15:14.23brlcadso even if you were running mged in console, it would xterm -e
15:14.33starseekerO.o
15:14.49brlcad(so long as that mged had x11 support, it figured it was safe)
15:14.57starseekerthat would have been entertaining when we got Aqua going...
15:15.36brlcadsrc/mged/tedit.c is where the old logic resides
15:15.59brlcadsrc/libged/editit.c is the new stuff
15:16.05brlcadhave fun
15:16.45starseekerso, tedit logic to libbu, editit to call libbu to get info, check if anything still calls f_tedit
15:16.48starseekergot it
15:17.20brlcadit won't migrate directly
15:17.57brlcadit has if defined(DM_X) checks
15:18.02starseekerah
15:18.02brlcadthat was the problem moving it to libged
15:18.14brlcadso that has to be refactored and sorted out somehow
15:18.33starseekerOK, so rather than doing checks just have it be told by the calling routine
15:18.51brlcadright
15:19.25starseekermight have to have some info passed to the libged routine it doesn't get now... that'll be routine checking
15:19.48brlcadthen 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.21brlcadyeah, would need to pass the info somehow
15:20.51brlcadI can think of a couple ways to totally cheat if you can't figure something out
15:20.57starseekerhehe
15:21.16starseekercan get Tk to tell him the windowing system in use...
15:21.26brlcadbu doesn't have tk
15:21.42brlcadand the tcl it has in some places is getting removed
15:21.49starseekerI know - get the windowing system value and pass it to libged, which passes it to bu
15:22.31brlcadkeeping editit() as an mged function instead of a libged function could be a viable answer too
15:22.43brlcadas it is application specific, how to edit something
15:23.20starseekernods - 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.57brlcadaffects wcodes/rcodes/edcodes/ted/red
17:33.32*** join/#brlcad talcite (n=matthew@dhcp-143-151.mcme-students.carleton.ca)
17:44.45talcitebrlcad: ping?
18:23.24*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
18:46.38CIA-82BRL-CAD: 03erikgreenwald * r37408 10/isst/trunk/src/ (gui.c isst.h): handle passing mesh list to library for filling
18:47.01CIA-82BRL-CAD: 03erikgreenwald * r37409 10/brlcad/trunk/src/adrt/ (adrt.h load.c load_g.c): fill mesh name list on load
18:53.13``Erikhah, exploring the show "heroes" :D http://www.reallifecomics.com/
19:05.55CIA-82BRL-CAD: 03erikgreenwald * r37410 10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c: count triangles
19:06.57CIA-82BRL-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.37CIA-82BRL-CAD: 03brlcad * r37412 10/brlcad/trunk/TODO: the tree command should work with full paths
19:36.27brlcadlooks 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.09CIA-82BRL-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.28CIA-82BRL-CAD: 03brlcad * r37414 10/brlcad/trunk/src/libbu/vls.c:
20:21.28CIA-82BRL-CAD: wow, OLD OLD bug here. bu_vls_prepend wasn't incrementing the book-keeping size
20:21.28CIA-82BRL-CAD: of the vls after appending something. this resulted in chars getting nibbled
20:21.28CIA-82BRL-CAD: off the end until eventually an overflow is encountered. curiously, we weren't
20:21.28CIA-82BRL-CAD: even using this function before r37413 change to edcodes (at least not any
20:21.30CIA-82BRL-CAD: more).
20:22.20CIA-82BRL-CAD: 03brlcad * r37415 10/brlcad/trunk/src/libged/editit.c: minor ws
20:23.01CIA-82BRL-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.57CIA-82BRL-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.13CIA-82BRL-CAD: 03erikgreenwald * r37418 10/brlcad/trunk/src/adrt/librender/cut.c: disable mesh marking for now, seems to cause infinite loop...
20:31.32CIA-82BRL-CAD: 03brlcad * r37419 10/brlcad/trunk/TODO: note to look at the globbing code. noticed some debackslashing/slashing code in there.
20:38.28CIA-82BRL-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.10CIA-82BRL-CAD: 03brlcad * r37421 10/brlcad/trunk/src/libged/ (14 files): remove most all references to MGED, eliminate some dead code, cleanup comments
21:28.06CIA-82BRL-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``Erikwe 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.06max1234I am looking for a good program to do 2d renderings of datacad houses on, can anyone help me?
22:09.21max1234hello
22:22.45*** join/#brlcad Nohla (n=jesica@168.226.178.47)
22:23.24starseekerbrlcad: is http://sourceforge.net/projects/expect/ relevant to the MGED terminal dicussion?  specifically, http://www.mel.nist.gov/msidlibrary/doc/libes96a.ps
22:23.38brlcadmildly
22:24.43brlcadnot directly, applicable though -- it would be good for automating interactions with a given tty application
22:25.11starseekerso the libes96a.ps paper is something else?
22:25.28``Eriknifty, nmgmodel gives me the same error's I've been seeing in my cube crap
22:28.38brlcadstarseeker: not exactly
22:28.45brlcadwhat that paper is doing is basically what we need
22:29.02brlcadthe use of expect, though, is basically a "cheat"
22:29.22brlcadmost of the useful work he shows there actually has little to do with expect
22:31.34brlcadlike 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.17brlcadthey use expect to get the tty and also as a pseudo libtermio for handling the character control codes
22:32.30brlcadat least that's what it looks like at a glance
22:32.38starseekernods
22:32.50brlcadcould be usable.  expect is a bit of a "large" extension iirc
22:33.48brlcadthe bit that expect provides could probably be rewritten with a simple C function or two
22:34.02starseekercool
22:34.25brlcadyou could start similar to how they start, invoking a SHELL, etc
22:34.27brlcadsee where things go
22:34.52brlcadjust instead of using expect, make your own functions that give a tty, and other functions that do pass-throughs to libtermio
22:34.56brlcador curses
22:35.10starseekeryou said someone had done a tk curses implementation?
22:35.40brlcadyes and no, someone made a curses-like interface
22:36.11brlcaddon't think there's a reason you couldn't just have a binding layer to an actual termio library
22:38.59starseekernods.
22:39.16starseekerfinds cTk, which appears to be a curses backend for Tk??
22:39.21starseekerhow very odd
22:40.14starseekershakes himself - need to get back to actually changing the current code here...
22:42.35starseekermore fun to play with the tkterm ;-)
22:46.45starseekerwinces - /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.55starseekerbrlcad: 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.12brlcadideally not
23:12.27*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
23:12.39brlcadundefined void pointers on a public interface are usually a deficiency/incompleteness of the interface to support something
23:13.23starseekercrud
23:13.30starseekerwell, there goes that idea

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.