IRC log for #brlcad on 20071217

01:43.14CIA-29BRL-CAD: 03brlcad * 10brlcad/include/machine.h: BOOL_T isn't even used any more
02:14.37CIA-29BRL-CAD: 03brlcad * 10brlcad/include/raytrace.h: ws
02:15.16CIA-29BRL-CAD: 03brlcad * 10brlcad/include/config_win.h: no longer should be using nor needing the bzero/bcopy macros -- should be using memset and memcpy throughout now
02:17.35CIA-29BRL-CAD: 03brlcad * 10brlcad/ (52 files in 8 dirs): removal of the FAST declaration throughout. now using register or letting the compiler sort things out.
02:23.05CIA-29BRL-CAD: 03brlcad * 10brlcad/src/libdm/dm-wgl.c: revert int back to BOOL, windows thing
02:32.07brlcadahhh...crrrrraaaaap.
02:33.10brlcadshould NOT be static .. in fact static becomes very bad on SMP machines, which explains all these random crashes I've been having
03:01.42*** join/#brlcad SWPadnos___ (n=Me@dsl107.esjtvtli.sover.net)
03:05.09*** join/#brlcad CIA-29 (n=CIA@208.69.182.149) [NETSPLIT VICTIM]
03:05.10*** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) [NETSPLIT VICTIM]
03:05.11*** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM]
03:05.36*** join/#brlcad PrezzKennedy (i=Matt@74.86.45.130)
03:13.22*** join/#brlcad brlcad (n=sean@pdpc/supporter/silver/brlcad) [NETSPLIT VICTIM]
03:13.22*** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT VICTIM]
03:13.22*** mode/#brlcad [+o brlcad] by irc.freenode.net
03:33.34*** join/#brlcad brlcad (n=sean@pdpc/supporter/silver/brlcad) [NETSPLIT VICTIM]
03:33.34*** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT VICTIM]
03:33.34*** mode/#brlcad [+o brlcad] by irc.freenode.net
05:46.00*** join/#brlcad starseeker (n=CY@ip72-218-17-237.hr.hr.cox.net)
05:54.09CIA-29BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/ (5 files in 5 dirs): revert the rest of the bad tclIndex files that were clobbered during the 2007/11/28 commit with log "LOCAL->static, per machine.h deprecation list"
06:03.36*** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com)
06:33.55CIA-29BRL-CAD: 03brlcad * 10brlcad/doc/html/manuals/Install.html: remove references to LOCAL and FAST
07:07.12*** join/#brlcad elite01 (n=elite01@195.37.106.60)
07:48.43*** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6)
07:53.59CIA-29BRL-CAD: 03brlcad * 10brlcad/src/ (46 files in 5 dirs): my bad deprecation instruction, revert/remove the LOCAL -> static conversion. LOCAL is only static for non-SMP systems, but usually auto.
07:54.53CIA-29BRL-CAD: 03brlcad * 10brlcad/include/machine.h: poof, make LOCAL go away entirely. the deprecation instruction was wrong/bad -- LOCAL shouldn't go to static, it just goes away (so we get auto).
08:12.43*** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch)
08:17.49CIA-29BRL-CAD: 03brlcad * 10brlcad/src/librt/g_hf.c: remove silly rcsid printing
08:30.30CIA-29BRL-CAD: 03brlcad * 10brlcad/src/lgt/reflect.c: add last partition param
08:47.38*** join/#brlcad Defcon (n=def@74.17-246-81.adsl-static.isp.belgacom.be)
09:45.09*** join/#brlcad Defcon (n=def@74.17-246-81.adsl-static.isp.belgacom.be)
11:06.00*** join/#brlcad elite01 (n=elite01@dslc-082-082-089-199.pools.arcor-ip.net)
11:31.29*** join/#brlcad docelic (n=docelic@213.147.110.16)
12:03.23*** join/#brlcad CIA-29 (n=CIA@208.69.182.149) [NETSPLIT VICTIM]
12:28.24*** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz)
13:25.25CIA-29BRL-CAD: 03d_rossberg * 10brlcad/src/libbu/temp.c: time() is declared in time.h
13:34.16CIA-29BRL-CAD: 03d_rossberg * 10brlcad/src/conv/comgeom/f2a.c: bu_exit() is declared in bu.h
13:54.23brlcadhello d_rossberg
13:56.08d_rossberghello brlcad
13:56.16CIA-29BRL-CAD: 03d_rossberg * 10brlcad/src/librt/db_tree.c: do not forget to copy a string's terminating 0
14:08.49brlcadhm, suppose I should review all instances and make sure they're manually null-terminated
14:09.04brlcadat least for the strncat/strncpy calls
14:11.03*** join/#brlcad Elperion (n=Bary@p54875545.dip.t-dialin.net)
14:11.18brlcadhm, which there are 89 and 742 respectively
14:11.19d_rossbergmaybe you should write a bu_strncpy which ensures that the last byte of the buffer is always 0
14:11.38brlcadyeah, that's what I was thinking
14:11.54brlcador something like what you had earlier for strlcpy
14:12.04brlcadmaybe a bu_strlcpy
14:12.25d_rossbergstd::string ?
14:12.34brlcadheh
14:12.51brlcadthat'd be a pretty major change
14:14.11brlcaddon't presently require a c++ compiler just yet
14:14.15d_rossbergyes, and i don't think that all sources woulg go through as .cpp
14:15.53brlcadto date, all the libs (and almost all the sources) have been moving towards strict ansi/iso compliance, pure C lib path
14:16.27brlcadthe opennurbs work was the first major "good reason" to adopt c++, so maybe as that work completes and it's integrated non-optional
14:17.25brlcadstill, gut feeling is to keep them pure C and have C++ libs that build on top of them, new OO API akin to what you started, maybe even using that code as a starting point
14:19.08brlcadand even for opennurbs, to hide it as implementation detail instead of keeping the current exposure
14:21.20d_rossbergit's true, i'm using my own C++ wrapper to access brlcad library, but i've never published it
14:42.14``Erikhum, a release of bzflag
14:42.18``Erik2.0.10 O.o
14:48.24*** join/#brlcad jaminkle (i=JiE@60.53.124.14)
14:53.14``Erik*scrollscrollscroll* seems brlcad was busy this weekend
14:55.53brlcad``Erik: that was about a month ago (bz release)
14:56.01``Erikstatic is only bad if the function is supposed to be reentrant, and that can break on single proc machines if the ccontext switch happens in the func
14:56.08``Erikoh, it just made happypenguin :)
14:56.30brlcadyeah, we didn't notify this time, so it's just been usual word-of-mount spread
14:56.48``Erikhow's the jaw? back to real food yet?
14:56.49brlcadmany of the functions in librt are supposed to be re-entrant
14:57.00brlcads/many/most/
14:57.07*** join/#brlcad motoko (n=motoko@snapper.mrfisho.com.au)
14:57.20``Erikyeah, but I believe there is no annotation to say which are or are not intended to be that way
14:57.53``Erikd'no how critical that is, but I think that'd make it easier for a new coder to not break things
14:58.03brlcadI don't think *any* are intentionally not that way, just not used in parallel yet or known to not work or not worth the effort
14:58.39``Erikheh, then static without semaphores or something is just plain bad juju :D
14:58.52brlcadsome of the libbu routines exist because they were made reentrant when the same/similar C interface was not necessarily
15:00.00brlcadhello jaminkle
15:01.49``Erikpng 1.2.24
15:02.09CIA-29BRL-CAD: 03brlcad * 10brlcad/NEWS: parker fixed asc2g bug on Windows that caused a crash on exit
15:02.28brlcadwhile you were koreaning
15:02.35``Erikstill no fix for mikes uhhh cubit ?
15:02.44brlcadfix?
15:02.59brlcadhis crash-on-exit bug?
15:02.59``Erikit doens't exit clean, so he forces an exit(), right?
15:03.21``ErikI gave him shit about it last week, hoping it'd distract him enough to let bob work
15:03.29``Erik:D
15:03.45brlcadheh, he forces an abort(), exit() would still call the destructors
15:03.54``Erik*shudder*
15:04.09``Erikis it bad dependancy chain stuff? or a broken destructor? or what?
15:04.33brlcadI think he's not deallocating objects he's allocated in the proper order
15:04.48brlcador he's freeing something he shouldn't like a singleton
15:05.09brlcadhighly suspect the latter based on a comment he made a couple weeks ago
15:05.21brlcadbut still tbd
15:05.22``Erikheh, unfortunately, the cubit code isn't open enough for me to bother with unless I'm told to :D
15:05.49brlcadCGM is pretty open, it's lgpl
15:06.32brlcadjust mostly useless by itself, it depends on ACIS so you can't compile it stand-alone iirc without ACIS
15:08.45``Erikya in today? bob is talking about lee's hunan
15:09.22brlcadon my way
15:10.22motokolearnHA
15:10.30``Erikheh
15:10.40``Erikhttp://freshmeat.net/projects/freedup/?branch_id=70879&release_id=267779
15:11.31``Eriknothing like http://freshmeat.net/projects/epac/
15:11.32``ErikO.o
15:11.59*** join/#brlcad motokolearn (n=motokole@snapper.mrfisho.com.au)
15:12.20brlcadhey, I know that guy
15:12.48jaminkle?
15:12.52brlcadI've run across that program about a half-dozen times
15:13.05``Erikwhich now? what? O.o
15:13.12brlcadsorta like ping where the NIBM is rampant
15:13.40Z80-Boybrlcad: ping is from BRL isn't it?
15:13.40``Erikhehehe
15:13.41brlcadpeople writing the same app when others exist
15:13.47``Erikyes, mike muuss wrote the original
15:13.52Z80-Boyhehe :)
15:15.03``Erikwhen I interveiwed at fedex, that epac program was enough to impress their gurus quite a bit, "this guy really understands how filesystems work", so "is this guy technically competent" part was nonexistant
15:15.15brlcadZ80-Boy: any way you could re-encode your video+audio to an mpeg stream, or provide me the audio track separately (then I could more easily re-encode as an mpeg stream)
15:15.46brlcadI don't mind *also* putting up the OGG, but if there's not an mpeg version, 99% of the audience won't see it
15:16.15``Erik*nod* having it "just work" on a vanilla windows computer is an unfortunate necessity :(
15:16.49``ErikI watched 3 episodes of kung fu, serenity, and generally chummed with a buddy who drove down from pennsylvania over the weekend. :D
15:17.16MaloeranAnd over the last 2 weeks? :) Gez fine, let me know if you got something for me
15:17.24MaloeranI'll have plenty of time to code over the next month, I think
15:17.32``Erikoh, ummm
15:17.41*** join/#brlcad motokolearn (n=motokole@snapper.mrfisho.com.au)
15:17.43``ErikI've been gridning on learning, uh, javascript (again)
15:17.59Defconhaha
15:18.11``Erikbut I'm still backing it with php, um, downloaded a lithp webserver thing
15:18.19MaloeranYuck. Ready for anything server-side in C yet?
15:18.35``Erikhunchentute or something
15:18.38Defconserverside C ??
15:18.41``Erikheheheh newp, lithp :D
15:19.11``Eriklisp has the sexiness of being updated live
15:19.26``Erikno "restart" command needed
15:19.42MaloeranFine, I'll code the thing as shared libraries to be reloaded on the run
15:20.09``ErikI did that with one program, there're still advantages to the lithp approach
15:20.16MaloeranSuch as?
15:20.25``Erikalso; I like the sexy curves ( Y )
15:20.32``Erikintrospection
15:21.33MaloeranWell then... I guess the question is, would you rather have me do it in highly optimized C or write the lithp code?
15:21.57``Erikrun sbcl in a screen, run the server aspect and slime server in it, attach emacs to it live (with significant hand twisting), be able to slap out quick one line functions and just groove in it, with the data set just sitting there live, mebbe self-optimizing...
15:22.27*** join/#brlcad motoko (n=motoko@snapper.mrfisho.com.au)
15:22.31``Erikwell, you're throwing out a dirty word there
15:23.09``Erik"optimized"... I think for this application, cpu cycles are not the precious resource, notions like "time to market", bugfix responsiveness, etc are all vastly more important
15:23.49``Erikbut I'm still working on learning the presentation platform... web crap sure has changed in the last 10 years
15:24.12``Erikthere's all this javscript crap, this "css" thingie, ...
15:24.28MaloeranAt the pace this is going, I think it will be mucg faster if I do it in C rather than wait for you to come up with the lithp :)
15:24.29``Erikat least dhtml died
15:24.34Maloeranmuch* faster
15:24.35``Erikhehehe
15:26.01MaloeranWell then, feel free to keep me updated
15:26.21``ErikI'm hoping to do something productive, um, on thursday, while flying
15:27.11MaloeranThat sounds brief
15:27.35``Erikyeah... that's the power of lithp, the code happens really fast
15:28.08``Erikso the "figuring out what you want to do" looks radically large in comparison...
15:29.14``Erikand the code tends to be short and dense, so the seperation notions (which is at least as big in C) seems disproportionately large (it's all parenthesis!... but still less parenthesis than equivelant C, weird)
15:29.25MaloeranSo I suspect you won't need any good C code?
15:29.31``Erikdunno
15:30.22``ErikI imagine that lisp is extremely well suited, so I intend to use that at first, and when it proves itself to be insufficient, THEN I'll start shoving C in
15:30.23``Erik:)
15:32.01*** join/#brlcad motoko (n=motoko@snapper.mrfisho.com.au)
15:32.06``ErikI've also found that when I try to use python or ruby, it works dandy until things start getting tougher, and then they start seeming awfuly kludgy and hard to used compared to the scheme or lisp solutions... O.o
15:32.56MaloeranI have come to think the same thing of about any language as complexity rises, except C
15:33.35``ErikC has its own issues *shrug* but it's a simple language so the issues are tractable... lisp is similarly simple, but it has a different purpose
15:33.59``ErikI mean, C is fuckin' awesome for writing drivers or kernel stuff... not so much for user apps mangling data sets
15:34.06MaloeranSo you intend to have to rewrite the thing once lisp proves itself insufficient? I really would start with C right away
15:34.33``Eriksee, a lot of the C code I write has me saying "I wish I could write this in scheme, it'd be so much easier"
15:34.35MaloeranOh, I got the code for data sets, memory management or whatever already
15:34.54``Erikyeah, I have a massive personal library, too... *shrug*
15:35.32``Erikbut when every function I'm writing has a single line of scheme describing it in the comment... :D
15:35.50MaloeranOh well. Erik, I can start whenever you want if you want C code
15:36.14``Erikhehehe, and here I thought you'd thrown some lisp out in your day :D
15:36.44MaloeranI have tried, I always came back to C when things were getting more complex
15:37.11``ErikI had that phase with scheme, but as I learned more of the heavier hitting scheme, the balance shifted
15:37.17MaloeranLisp just would not provide the proper and efficient solutions I would seek to get at the assembly level
15:38.20``Erikthe x86 is a horrible chip to start with, judging a language by the x86 machien code of an implementation might not always be appropriate
15:38.57MaloeranIt might be horrible but it's what we got, and the architecture design is there to stay
15:39.23MaloeranI won't pick a language because it can be "theorically" better on some hypothetical ideal computers. I prefer to deal with reality
15:39.37``Erikyeah, the g5 was lovely, but apple jumped ship because of cult of the gigahertz :(
15:40.13``Eriknotionally, the web delivery thing lets you control reality a bit more instead of just sucking it up and going with the rest of the sheep
15:41.26MaloeranFine fine... In that case, let me know when lithp proves itself insufficient and you decide to start over in C :)
15:42.20``Erikhehehe, I'm quite certain I'll find fault with javascript and ie far before lisp :D
15:43.59*** join/#brlcad motoko (n=motoko@snapper.mrfisho.com.au)
15:53.00*** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6)
15:53.54*** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6)
16:00.11*** join/#brlcad motoko (n=motoko@snapper.mrfisho.com.au)
16:02.35jaminkleok this is going to work
16:03.04jaminkleoh noes
16:03.09jaminklei killed him
16:03.39*** join/#brlcad motokolearn (n=motokole@snapper.mrfisho.com.au)
16:06.05``Erikheh
16:11.35jaminklemotokolearn hello
16:11.47motokolearnjaminkle: Hello there, it is nice to be obsessed with that!
16:11.55jaminkle:/
16:22.41*** join/#brlcad prasad_ (n=psilva@70.108.244.218)
16:52.59minuteCan you send me a screenshot of the troubles in Safari 2, appers to be working alright in Safari 3 BETA.
16:53.13minute(I don't have a Mac, unfourtunatley :()
17:15.22jaminkle>.>
18:24.45CIA-29BRL-CAD: 03bob1961 * 10brlcad/src/libdm/ (dm-ogl.c dm-wgl.c): Set flag to clear back buffer in drawBegin routine.
18:32.05*** join/#brlcad PrezKennedy (i=Matt@74.86.45.130)
19:02.24*** join/#brlcad yukonbob (n=yukonbob@198.235.198.234)
19:29.38CIA-29BRL-CAD: 03bob1961 * 10brlcad/src/tclscripts/archer/Archer.tcl: Move call to itk_initialize up a bit. This fixes the problem of the main canvas' background not getting set. Added a call to writePreferences in the destructor.
20:01.10CIA-29BRL-CAD: 03erikgreenwald * 10brlcad/src/librt/db_tree.c: s/shaderlen/shader_len/
20:02.42minutejaminkle: <.<
20:03.30``ErikO.o
20:05.11CIA-29BRL-CAD: 03erikgreenwald * 10brlcad/src/adrt/adrt.h: force enum values instead of "hoping". define the name size limit.
20:11.07CIA-29BRL-CAD: 03erikgreenwald * 10brlcad/src/adrt/isst/slave/main.c: change naming prefix
20:12.13*** join/#brlcad Z80-Boy (i=clock@77-56-64-193.dclient.hispeed.ch)
20:59.58CIA-29BRL-CAD: 03erikgreenwald * 10brlcad/src/adrt/isst/slave/ (Makefile.am load.c load.h slave.c slave.h): reorg to reduce prototypes
21:07.01CIA-29BRL-CAD: 03bob1961 * 10brlcad/src/tclscripts/archer/ArcherCore.tcl: Move a few methods related to editing from ArcherCore to Archer.
21:23.03CIA-29BRL-CAD: 03brlcad * 10brlcad/ (NEWS src/external/ProEngineer/proe-brl.c):
21:23.10CIA-29BRL-CAD: update the pro/e plugin so that it also now implements the first half of sf
21:23.17CIA-29BRL-CAD: request [ 1159469 ] "Pro/E converter improvements" whereby it now more
21:23.23CIA-29BRL-CAD: appropriately parses the part number to part name mapping file and allows part
21:23.27CIA-29BRL-CAD: names that have spaces in the name. instead of stopping at the first
21:23.34CIA-29BRL-CAD: whitespace, it now reads until the end of the line and extracts the part name,
21:23.39CIA-29BRL-CAD: allowing for an arbitrary amount of surrounding whitespace that it trims off.
21:38.31*** join/#brlcad CIA-29 (n=CIA@208.69.182.149) [NETSPLIT VICTIM]
21:47.58CIA-29BRL-CAD: 03brlcad * 10brlcad/TODO: improve the framebuffer support for HDR imagery, an alpha channel for transparency, and configurable timeouts on remove framebuffers.
22:06.44*** join/#brlcad docelic (n=docelic@212.15.176.104)
23:05.58CIA-29BRL-CAD: 03brlcad * 10brlcad/src/nirt/usrfmt.h: ws consistency cleanup
23:06.30CIA-29BRL-CAD: 03brlcad * 10brlcad/src/nirt/nirt.c: major ws and style consistency cleanup
23:07.41CIA-29BRL-CAD: 03brlcad * 10brlcad/src/nirt/ (interact.c dist_def.c): use c99 fmax instead of max macro, might need configure support
23:08.17CIA-29BRL-CAD: 03brlcad * 10brlcad/src/nirt/ (if.c command.c): use c99 fabs() instead of abs macro, might need configure support
23:09.44CIA-29BRL-CAD: 03brlcad * 10brlcad/src/nirt/nirt.h: clean ws and style consistency, document origin, remove min/max/abs and DEBUG_FORMAT (raytrace.h provides it), add header wrapper protection
23:15.28CIA-29BRL-CAD: 03brlcad * 10brlcad/src/nirt/interact.c: ws and style consistency cleanup
23:19.45``Erikhehehe
23:20.34louipcI always thought lisp was a scripting language.
23:20.57starseekerIt can be used that way, but I don't think it usually is
23:21.23louipcso you can make binaries from the code eh?
23:21.43starseekerSort of.  It's like java - you need the environment
23:21.58louipcoh
23:22.57starseekerIt's a pretty awesome language for flexibility and power, but it's lib support is a bit behind
23:25.29starseeker(especially on the graphics side - McCLIM has the potential to be incredible but it needs a lot of work)
23:27.51``Erikum, actually, some implementations and spew out standalone that doesn't need the environment
23:28.10*** join/#brlcad CIA-29 (n=CIA@208.69.182.149)
23:28.18starseekerSome of the commercial ones maybe
23:28.19louipcvlisp isn't along the lines of vbasic or vc++ is it? hehheh
23:28.21``Erikand I know there're a couple schemes that can spew out C to compile, or some even compile into jvm .class files
23:28.31starseekerlouipc:  It claims to be a verified scheme
23:28.36starseekerlouipc:  whatever that means
23:29.05starseekerhttp://citeseer.ist.psu.edu/guttman95vlisp.html
23:29.10``Erik<-- on the scheme side, not the cl... so knows the pretty toys for scheme :D bigloo, sisc, schemetoc, ...
23:30.49``Erikit's a neat idea, but cosmic rays still blow bits clean off the silicon :( I think some of hte ultrasparcs and ibm biggies actually did a given computation several times in parallel and made sure the results are all the same
23:31.07starseekerOh, sure - you have to verify the hardware
23:31.24``Erikpretty similar, but there're some big gotchas... like functions live in a seperate symbol space than variables
23:31.34CIA-29BRL-CAD: 03brlcad * 10brlcad/src/nirt/ (bsphere.c command.c dist_def.c): more ws and style consistency cleanup
23:32.02``Erikin lisp... that's been screwing me up, you get weirdness like defvar defun, etc... and you can't just USE the variable, like scheme can do ((alpha) 'beta)
23:32.17``Erikwhere alpha returns a function, and that snipped executes that function with beta as the arg
23:32.19starseekerHmm.  From the standpoint of a CAS with integrated proof software, a foundation like VLISP might be a Really Really Good Thing
23:32.41``Erikother than that, just library stuff, mostly
23:32.46``Erikand macros
23:33.02``Erikscheme usually offers both hygenic and 'lispy' macros
23:33.21starseekerCool.
23:33.24``Erikthough the hygenic ones are the only mandated ones in r5
23:35.25``Erikdoubt it, a major philosophy is to keep the core language tiny and extend it with srfi's
23:35.53starseekerMight be some merit to that - Lisp's monumental spec still didn't specify enough
23:37.10starseekerIt would be an interesting exercise to attempt porting the "major" lisp apps and libraries over to a scheme - I wonder what the practical differences would be
23:38.10starseekerNow if someone has done a verified Machine Forth...
23:39.17starseekerapparently not
23:39.39starseekerHrm.
23:40.28starseekerAmazing really - every time I turn around I find another major piece of work on verification I didn't know existed.  It must take the real pros years of full time reading to learn the field
23:50.58``ErikI imagine there'd be a lot of hunting for the right scheme to do a port like that... all those toys built into cl... kinda like javas class library

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