| 01:43.14 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/include/machine.h: BOOL_T isn't even used any more |
| 02:14.37 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/include/raytrace.h: ws |
| 02:15.16 | CIA-29 | BRL-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.35 | CIA-29 | BRL-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.05 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/libdm/dm-wgl.c: revert int back to BOOL, windows thing |
| 02:32.07 | brlcad | ahhh...crrrrraaaaap. |
| 02:33.10 | brlcad | should 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.09 | CIA-29 | BRL-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.55 | CIA-29 | BRL-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.59 | CIA-29 | BRL-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.53 | CIA-29 | BRL-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.49 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/librt/g_hf.c: remove silly rcsid printing |
| 08:30.30 | CIA-29 | BRL-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.25 | CIA-29 | BRL-CAD: 03d_rossberg * 10brlcad/src/libbu/temp.c: time() is declared in time.h |
| 13:34.16 | CIA-29 | BRL-CAD: 03d_rossberg * 10brlcad/src/conv/comgeom/f2a.c: bu_exit() is declared in bu.h |
| 13:54.23 | brlcad | hello d_rossberg |
| 13:56.08 | d_rossberg | hello brlcad |
| 13:56.16 | CIA-29 | BRL-CAD: 03d_rossberg * 10brlcad/src/librt/db_tree.c: do not forget to copy a string's terminating 0 |
| 14:08.49 | brlcad | hm, suppose I should review all instances and make sure they're manually null-terminated |
| 14:09.04 | brlcad | at least for the strncat/strncpy calls |
| 14:11.03 | *** join/#brlcad Elperion (n=Bary@p54875545.dip.t-dialin.net) | |
| 14:11.18 | brlcad | hm, which there are 89 and 742 respectively |
| 14:11.19 | d_rossberg | maybe you should write a bu_strncpy which ensures that the last byte of the buffer is always 0 |
| 14:11.38 | brlcad | yeah, that's what I was thinking |
| 14:11.54 | brlcad | or something like what you had earlier for strlcpy |
| 14:12.04 | brlcad | maybe a bu_strlcpy |
| 14:12.25 | d_rossberg | std::string ? |
| 14:12.34 | brlcad | heh |
| 14:12.51 | brlcad | that'd be a pretty major change |
| 14:14.11 | brlcad | don't presently require a c++ compiler just yet |
| 14:14.15 | d_rossberg | yes, and i don't think that all sources woulg go through as .cpp |
| 14:15.53 | brlcad | to date, all the libs (and almost all the sources) have been moving towards strict ansi/iso compliance, pure C lib path |
| 14:16.27 | brlcad | the 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.25 | brlcad | still, 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.08 | brlcad | and even for opennurbs, to hide it as implementation detail instead of keeping the current exposure |
| 14:21.20 | d_rossberg | it's true, i'm using my own C++ wrapper to access brlcad library, but i've never published it |
| 14:42.14 | ``Erik | hum, a release of bzflag |
| 14:42.18 | ``Erik | 2.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.53 | brlcad | ``Erik: that was about a month ago (bz release) |
| 14:56.01 | ``Erik | static 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 | ``Erik | oh, it just made happypenguin :) |
| 14:56.30 | brlcad | yeah, we didn't notify this time, so it's just been usual word-of-mount spread |
| 14:56.48 | ``Erik | how's the jaw? back to real food yet? |
| 14:56.49 | brlcad | many of the functions in librt are supposed to be re-entrant |
| 14:57.00 | brlcad | s/many/most/ |
| 14:57.07 | *** join/#brlcad motoko (n=motoko@snapper.mrfisho.com.au) | |
| 14:57.20 | ``Erik | yeah, but I believe there is no annotation to say which are or are not intended to be that way |
| 14:57.53 | ``Erik | d'no how critical that is, but I think that'd make it easier for a new coder to not break things |
| 14:58.03 | brlcad | I 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 | ``Erik | heh, then static without semaphores or something is just plain bad juju :D |
| 14:58.52 | brlcad | some of the libbu routines exist because they were made reentrant when the same/similar C interface was not necessarily |
| 15:00.00 | brlcad | hello jaminkle |
| 15:01.49 | ``Erik | png 1.2.24 |
| 15:02.09 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/NEWS: parker fixed asc2g bug on Windows that caused a crash on exit |
| 15:02.28 | brlcad | while you were koreaning |
| 15:02.35 | ``Erik | still no fix for mikes uhhh cubit ? |
| 15:02.44 | brlcad | fix? |
| 15:02.59 | brlcad | his crash-on-exit bug? |
| 15:02.59 | ``Erik | it doens't exit clean, so he forces an exit(), right? |
| 15:03.21 | ``Erik | I gave him shit about it last week, hoping it'd distract him enough to let bob work |
| 15:03.29 | ``Erik | :D |
| 15:03.45 | brlcad | heh, he forces an abort(), exit() would still call the destructors |
| 15:03.54 | ``Erik | *shudder* |
| 15:04.09 | ``Erik | is it bad dependancy chain stuff? or a broken destructor? or what? |
| 15:04.33 | brlcad | I think he's not deallocating objects he's allocated in the proper order |
| 15:04.48 | brlcad | or he's freeing something he shouldn't like a singleton |
| 15:05.09 | brlcad | highly suspect the latter based on a comment he made a couple weeks ago |
| 15:05.21 | brlcad | but still tbd |
| 15:05.22 | ``Erik | heh, unfortunately, the cubit code isn't open enough for me to bother with unless I'm told to :D |
| 15:05.49 | brlcad | CGM is pretty open, it's lgpl |
| 15:06.32 | brlcad | just mostly useless by itself, it depends on ACIS so you can't compile it stand-alone iirc without ACIS |
| 15:08.45 | ``Erik | ya in today? bob is talking about lee's hunan |
| 15:09.22 | brlcad | on my way |
| 15:10.22 | motokolearn | HA |
| 15:10.30 | ``Erik | heh |
| 15:10.40 | ``Erik | http://freshmeat.net/projects/freedup/?branch_id=70879&release_id=267779 |
| 15:11.31 | ``Erik | nothing like http://freshmeat.net/projects/epac/ |
| 15:11.32 | ``Erik | O.o |
| 15:11.59 | *** join/#brlcad motokolearn (n=motokole@snapper.mrfisho.com.au) | |
| 15:12.20 | brlcad | hey, I know that guy |
| 15:12.48 | jaminkle | ? |
| 15:12.52 | brlcad | I've run across that program about a half-dozen times |
| 15:13.05 | ``Erik | which now? what? O.o |
| 15:13.12 | brlcad | sorta like ping where the NIBM is rampant |
| 15:13.40 | Z80-Boy | brlcad: ping is from BRL isn't it? |
| 15:13.40 | ``Erik | hehehe |
| 15:13.41 | brlcad | people writing the same app when others exist |
| 15:13.47 | ``Erik | yes, mike muuss wrote the original |
| 15:13.52 | Z80-Boy | hehe :) |
| 15:15.03 | ``Erik | when 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.15 | brlcad | Z80-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.46 | brlcad | I 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 | ``Erik | I watched 3 episodes of kung fu, serenity, and generally chummed with a buddy who drove down from pennsylvania over the weekend. :D |
| 15:17.16 | Maloeran | And over the last 2 weeks? :) Gez fine, let me know if you got something for me |
| 15:17.24 | Maloeran | I'll have plenty of time to code over the next month, I think |
| 15:17.32 | ``Erik | oh, ummm |
| 15:17.41 | *** join/#brlcad motokolearn (n=motokole@snapper.mrfisho.com.au) | |
| 15:17.43 | ``Erik | I've been gridning on learning, uh, javascript (again) |
| 15:17.59 | Defcon | haha |
| 15:18.11 | ``Erik | but I'm still backing it with php, um, downloaded a lithp webserver thing |
| 15:18.19 | Maloeran | Yuck. Ready for anything server-side in C yet? |
| 15:18.35 | ``Erik | hunchentute or something |
| 15:18.38 | Defcon | serverside C ?? |
| 15:18.41 | ``Erik | heheheh newp, lithp :D |
| 15:19.11 | ``Erik | lisp has the sexiness of being updated live |
| 15:19.26 | ``Erik | no "restart" command needed |
| 15:19.42 | Maloeran | Fine, I'll code the thing as shared libraries to be reloaded on the run |
| 15:20.09 | ``Erik | I did that with one program, there're still advantages to the lithp approach |
| 15:20.16 | Maloeran | Such as? |
| 15:20.25 | ``Erik | also; I like the sexy curves ( Y ) |
| 15:20.32 | ``Erik | introspection |
| 15:21.33 | Maloeran | Well 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 | ``Erik | run 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 | ``Erik | well, 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 | ``Erik | but I'm still working on learning the presentation platform... web crap sure has changed in the last 10 years |
| 15:24.12 | ``Erik | there's all this javscript crap, this "css" thingie, ... |
| 15:24.28 | Maloeran | At 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 | ``Erik | at least dhtml died |
| 15:24.34 | Maloeran | much* faster |
| 15:24.35 | ``Erik | hehehe |
| 15:26.01 | Maloeran | Well then, feel free to keep me updated |
| 15:26.21 | ``Erik | I'm hoping to do something productive, um, on thursday, while flying |
| 15:27.11 | Maloeran | That sounds brief |
| 15:27.35 | ``Erik | yeah... that's the power of lithp, the code happens really fast |
| 15:28.08 | ``Erik | so the "figuring out what you want to do" looks radically large in comparison... |
| 15:29.14 | ``Erik | and 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.25 | Maloeran | So I suspect you won't need any good C code? |
| 15:29.31 | ``Erik | dunno |
| 15:30.22 | ``Erik | I 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 | ``Erik | I'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.56 | Maloeran | I have come to think the same thing of about any language as complexity rises, except C |
| 15:33.35 | ``Erik | C 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 | ``Erik | I mean, C is fuckin' awesome for writing drivers or kernel stuff... not so much for user apps mangling data sets |
| 15:34.06 | Maloeran | So you intend to have to rewrite the thing once lisp proves itself insufficient? I really would start with C right away |
| 15:34.33 | ``Erik | see, 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.35 | Maloeran | Oh, I got the code for data sets, memory management or whatever already |
| 15:34.54 | ``Erik | yeah, I have a massive personal library, too... *shrug* |
| 15:35.32 | ``Erik | but when every function I'm writing has a single line of scheme describing it in the comment... :D |
| 15:35.50 | Maloeran | Oh well. Erik, I can start whenever you want if you want C code |
| 15:36.14 | ``Erik | hehehe, and here I thought you'd thrown some lisp out in your day :D |
| 15:36.44 | Maloeran | I have tried, I always came back to C when things were getting more complex |
| 15:37.11 | ``Erik | I had that phase with scheme, but as I learned more of the heavier hitting scheme, the balance shifted |
| 15:37.17 | Maloeran | Lisp just would not provide the proper and efficient solutions I would seek to get at the assembly level |
| 15:38.20 | ``Erik | the 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.57 | Maloeran | It might be horrible but it's what we got, and the architecture design is there to stay |
| 15:39.23 | Maloeran | I 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 | ``Erik | yeah, the g5 was lovely, but apple jumped ship because of cult of the gigahertz :( |
| 15:40.13 | ``Erik | notionally, 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.26 | Maloeran | Fine fine... In that case, let me know when lithp proves itself insufficient and you decide to start over in C :) |
| 15:42.20 | ``Erik | hehehe, 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.35 | jaminkle | ok this is going to work |
| 16:03.04 | jaminkle | oh noes |
| 16:03.09 | jaminkle | i killed him |
| 16:03.39 | *** join/#brlcad motokolearn (n=motokole@snapper.mrfisho.com.au) | |
| 16:06.05 | ``Erik | heh |
| 16:11.35 | jaminkle | motokolearn hello |
| 16:11.47 | motokolearn | jaminkle: Hello there, it is nice to be obsessed with that! |
| 16:11.55 | jaminkle | :/ |
| 16:22.41 | *** join/#brlcad prasad_ (n=psilva@70.108.244.218) | |
| 16:52.59 | minute | Can you send me a screenshot of the troubles in Safari 2, appers to be working alright in Safari 3 BETA. |
| 16:53.13 | minute | (I don't have a Mac, unfourtunatley :() |
| 17:15.22 | jaminkle | >.> |
| 18:24.45 | CIA-29 | BRL-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.38 | CIA-29 | BRL-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.10 | CIA-29 | BRL-CAD: 03erikgreenwald * 10brlcad/src/librt/db_tree.c: s/shaderlen/shader_len/ |
| 20:02.42 | minute | jaminkle: <.< |
| 20:03.30 | ``Erik | O.o |
| 20:05.11 | CIA-29 | BRL-CAD: 03erikgreenwald * 10brlcad/src/adrt/adrt.h: force enum values instead of "hoping". define the name size limit. |
| 20:11.07 | CIA-29 | BRL-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.58 | CIA-29 | BRL-CAD: 03erikgreenwald * 10brlcad/src/adrt/isst/slave/ (Makefile.am load.c load.h slave.c slave.h): reorg to reduce prototypes |
| 21:07.01 | CIA-29 | BRL-CAD: 03bob1961 * 10brlcad/src/tclscripts/archer/ArcherCore.tcl: Move a few methods related to editing from ArcherCore to Archer. |
| 21:23.03 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/ (NEWS src/external/ProEngineer/proe-brl.c): |
| 21:23.10 | CIA-29 | BRL-CAD: update the pro/e plugin so that it also now implements the first half of sf |
| 21:23.17 | CIA-29 | BRL-CAD: request [ 1159469 ] "Pro/E converter improvements" whereby it now more |
| 21:23.23 | CIA-29 | BRL-CAD: appropriately parses the part number to part name mapping file and allows part |
| 21:23.27 | CIA-29 | BRL-CAD: names that have spaces in the name. instead of stopping at the first |
| 21:23.34 | CIA-29 | BRL-CAD: whitespace, it now reads until the end of the line and extracts the part name, |
| 21:23.39 | CIA-29 | BRL-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.58 | CIA-29 | BRL-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.58 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/nirt/usrfmt.h: ws consistency cleanup |
| 23:06.30 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/nirt/nirt.c: major ws and style consistency cleanup |
| 23:07.41 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/nirt/ (interact.c dist_def.c): use c99 fmax instead of max macro, might need configure support |
| 23:08.17 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/nirt/ (if.c command.c): use c99 fabs() instead of abs macro, might need configure support |
| 23:09.44 | CIA-29 | BRL-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.28 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/nirt/interact.c: ws and style consistency cleanup |
| 23:19.45 | ``Erik | hehehe |
| 23:20.34 | louipc | I always thought lisp was a scripting language. |
| 23:20.57 | starseeker | It can be used that way, but I don't think it usually is |
| 23:21.23 | louipc | so you can make binaries from the code eh? |
| 23:21.43 | starseeker | Sort of. It's like java - you need the environment |
| 23:21.58 | louipc | oh |
| 23:22.57 | starseeker | It's a pretty awesome language for flexibility and power, but it's lib support is a bit behind |
| 23:25.29 | starseeker | (especially on the graphics side - McCLIM has the potential to be incredible but it needs a lot of work) |
| 23:27.51 | ``Erik | um, 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.18 | starseeker | Some of the commercial ones maybe |
| 23:28.19 | louipc | vlisp isn't along the lines of vbasic or vc++ is it? hehheh |
| 23:28.21 | ``Erik | and I know there're a couple schemes that can spew out C to compile, or some even compile into jvm .class files |
| 23:28.31 | starseeker | louipc: It claims to be a verified scheme |
| 23:28.36 | starseeker | louipc: whatever that means |
| 23:29.05 | starseeker | http://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 | ``Erik | it'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.07 | starseeker | Oh, sure - you have to verify the hardware |
| 23:31.24 | ``Erik | pretty similar, but there're some big gotchas... like functions live in a seperate symbol space than variables |
| 23:31.34 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/nirt/ (bsphere.c command.c dist_def.c): more ws and style consistency cleanup |
| 23:32.02 | ``Erik | in 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 | ``Erik | where alpha returns a function, and that snipped executes that function with beta as the arg |
| 23:32.19 | starseeker | Hmm. From the standpoint of a CAS with integrated proof software, a foundation like VLISP might be a Really Really Good Thing |
| 23:32.41 | ``Erik | other than that, just library stuff, mostly |
| 23:32.46 | ``Erik | and macros |
| 23:33.02 | ``Erik | scheme usually offers both hygenic and 'lispy' macros |
| 23:33.21 | starseeker | Cool. |
| 23:33.24 | ``Erik | though the hygenic ones are the only mandated ones in r5 |
| 23:35.25 | ``Erik | doubt it, a major philosophy is to keep the core language tiny and extend it with srfi's |
| 23:35.53 | starseeker | Might be some merit to that - Lisp's monumental spec still didn't specify enough |
| 23:37.10 | starseeker | It 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.10 | starseeker | Now if someone has done a verified Machine Forth... |
| 23:39.17 | starseeker | apparently not |
| 23:39.39 | starseeker | Hrm. |
| 23:40.28 | starseeker | Amazing 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 | ``Erik | I 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 |