| 00:21.23 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 02:05.53 | starseeker | They're going to fight hard to insist on no internal copies of libraries. Grr... |
| 02:06.12 | starseeker | Or I should say, it may depend on who we can interest... |
| 02:07.16 | louipc | tell them to fix it then they'll turn around :D |
| 02:08.08 | louipc | on the other hand if they succeed great! |
| 02:09.30 | starseeker | Sean's got it in good shape - we just need to get TCL 8.5 and all its friends to release stable versions. |
| 02:10.22 | starseeker | I'm still unclear if there are one or two cases where it's just a full-on name conflict. |
| 02:11.00 | louipc | between 8.4 and 8.5? |
| 02:11.03 | starseeker | If we have to depend on an unstable tcl, brl-cad will remain masked. And it sounds like some of the Gentoo devs think that's how it shoudl be |
| 02:11.10 | starseeker | no, between other libs |
| 02:11.26 | louipc | oh you mean for installing in /usr/lib* |
| 02:11.31 | starseeker | I'm arguing for /usr/brlcad or /opt/brlcad for an install path, and a lot of them are going to want it in there |
| 02:11.51 | louipc | yeah I put it in /opt/brlcad for archlinux |
| 02:12.00 | starseeker | It's simpler and safer. |
| 02:12.21 | starseeker | And if tcl 8.5 isn't available, I want to use the internal version rather than fail. That didn't seem to sit well either. |
| 02:12.23 | louipc | it thought that gentoo used /opt for large packages like brlcad |
| 02:12.25 | starseeker | Sigh. |
| 02:12.32 | louipc | java... dunno what else qt? |
| 02:12.36 | starseeker | The policy I saw said binaries only |
| 02:12.41 | louipc | oh heh |
| 02:12.49 | starseeker | We could have an ebuild for the binary build of BRL-CAD I suppose... |
| 02:12.54 | starseeker | seems a shame though |
| 02:13.02 | louipc | it's been a year since i've used gentoo! haha |
| 02:13.07 | louipc | actually not yet a year |
| 02:13.25 | starseeker | archlinux work better? |
| 02:13.25 | louipc | have both! |
| 02:13.33 | louipc | archlinux is awesome |
| 02:13.43 | starseeker | I find gentoo very clean and well integrated |
| 02:13.50 | louipc | I don't have to waste my time compiling every single package |
| 02:13.54 | starseeker | just a bit stubborn about package management ;-) |
| 02:14.13 | louipc | yikes I found gentoo to be quite messy |
| 02:14.19 | starseeker | really? |
| 02:14.22 | louipc | but I hear that they've improved |
| 02:14.28 | starseeker | I guess I'm mental ;-) |
| 02:14.48 | louipc | yeah portage would mess up my system every once in awhile if I tried to --sync |
| 02:14.53 | starseeker | ah |
| 02:15.02 | louipc | need to completely reinstall |
| 02:15.03 | starseeker | yeah, they had a few bad moments a while back. |
| 02:15.21 | starseeker | I had to completely reinstall after putting BRL-CAD in /usr ;-) |
| 02:15.38 | louipc | and I have a PIII 866MHz so compiling every damned thing was a PAIN |
| 02:15.59 | louipc | starseeker: ouch |
| 02:16.05 | starseeker | I'm hoping the guy I was arguing with in #gentoo will hop onto the bug for the ebuild and Sean can hang him out to dry ;-) |
| 02:16.07 | Maloeran | Gentoo is like Linux from Scratch with package management, it's not bad for developpers or people who know what they are doing |
| 02:16.18 | louipc | starseeker: ;) |
| 02:16.19 | starseeker | louipc: ouch |
| 02:16.42 | starseeker | Heh - I've got a nice fast P4 now (my old machine died, probably to excessive code compiling) |
| 02:17.47 | starseeker | 8 cores?? You young whippersnappers, in my day we lived with one core so primitive it didn't even need it's own power feed, and we liked it! |
| 02:17.48 | louipc | yeah I was thinking Gentoo might be better viewed as an automatic-distro-making tool |
| 02:18.14 | starseeker | I've got two cores now, and I'm still getting used to how nice it is. |
| 02:18.33 | louipc | I think I'm getting a laptop next |
| 02:18.39 | starseeker | Thought I was buying one core - heh, was rather surprised when gkrellm popped up two displays ;-) |
| 02:18.44 | louipc | dual core |
| 02:18.51 | louipc | sweet |
| 02:18.54 | Maloeran | I still had Gentoo fall apart in horrible ways, more than once. The last time was when I emerged a 32 bits X emulation library, and just that killed PAM ( can no longuer log in ), deleted fsck, and plenty of other "system" packages |
| 02:19.08 | starseeker | Owowowow |
| 02:19.20 | Maloeran | I never understood how that happened, but it's kind of bothersome. For anyone who doesn't know Linux in depth, that would be a pain to fix |
| 02:19.28 | starseeker | No kidding. |
| 02:20.01 | starseeker | Usually in situations that extreme, I would get out the install CD, boot it, mount the partitions without starting the install steps, and then start debuggind using the CD environment |
| 02:20.08 | louipc | yeah it sucks when you can't even find the problem and you have to reinstall. it's like you've been defeated |
| 02:20.14 | starseeker | amazing flexible and powerful - saved my tail a number of times |
| 02:20.31 | Maloeran | Yes... I just plugged the hard drive in another box and fixed the mess there |
| 02:20.40 | starseeker | BRL-CAD took the cake though - even revdep-rebuild didn't fix it. |
| 02:21.31 | louipc | how many gentoo devs are there? |
| 02:21.56 | starseeker | A fair number, but probably less than are needed for the software they have listed. Debian does better there. |
| 02:22.17 | louipc | debian hardly releases though hah |
| 02:22.23 | starseeker | Heh - true |
| 02:23.07 | starseeker | The distros are too used to small packages that can easily follow their rules - when it comes to things like Axiom, BRL-CAD, OpenDX, GRASS, etc. it becomes much more difficult |
| 02:24.05 | louipc | haha yeah I was telling an archlinux dev and he was saying 'oh no it's easy to make packages' |
| 02:24.19 | louipc | and I said 'yeah usually, but not THIS one' |
| 02:24.34 | louipc | starseeker: never! |
| 02:24.55 | starseeker | louipc: Of course, what was I thinking - we wouldn't have a decent text editor |
| 02:25.33 | starseeker | Just curious - what do y'all think about literate programming? |
| 02:25.56 | louipc | what's that? |
| 02:26.30 | starseeker | Donald Knuth developed it - it's a programming philosophy where source code and text are woven together in a single document, intended for human readibility |
| 02:26.38 | starseeker | readability sorry |
| 02:26.51 | starseeker | The TeX typesetting system is created in that fashion |
| 02:27.01 | starseeker | you can buy the TeX source code in book form |
| 02:27.36 | Maloeran | I find source code perfectly readable by itself, as I think most good programmers would |
| 02:28.03 | louipc | a philosophy where you comment code nicely and use good variable and function names? |
| 02:29.50 | starseeker | Well... here's an example: |
| 02:30.00 | starseeker | hang on, gotta find it... |
| 02:32.04 | starseeker | http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.8.lisp.pdf/download |
| 02:33.44 | starseeker | I guess I like the idea of having thinks like citations to mathematical research for mathematical code, etc. |
| 02:34.26 | louipc | so it's a class of computer language eh? |
| 02:35.18 | louipc | programming language rather |
| 02:36.03 | Maloeran | Looks like a lot to read to understand the concept... but I'm really skeptical of the idea |
| 02:36.05 | starseeker | not really - just a mark-up convention that allows source code extraction |
| 02:36.25 | starseeker | Many people don't care for it |
| 02:36.36 | starseeker | It might be that it is only really appropriate for special situations |
| 02:36.52 | louipc | well it makes sense kind of |
| 02:37.16 | louipc | I might use something like doxygen otherwise |
| 02:37.53 | starseeker | http://www.literateprogramming.com/ might be a good place as an intro |
| 02:38.47 | starseeker | Maloeran: It's only really useful to those who don't intimately understand the code, or perhaps the coding language |
| 02:39.32 | Maloeran | *nods* Right |
| 02:39.49 | starseeker | it has a certain appeal for open source (and particularly for Axiom, where a lot of the code is complex mathematics) where you have many developers who need to quickly understand both the code and the reasons for writing the code the way it was written |
| 02:39.51 | Maloeran | I'm not generally fond of documentation, it's good for high-level stuff, but the low-level source code should speak by itself |
| 02:40.12 | louipc | well documentation can save time rather than having to go over every line of code to understand what it does |
| 02:40.20 | Maloeran | That's high-level documentation, yes |
| 02:40.47 | starseeker | cl-web is a parser for literate documents, itself written as a literate document. |
| 02:41.18 | starseeker | the idea is almost anyone with a basic Lisp knowledge could read it and know how and why. |
| 02:41.52 | starseeker | In the end Axiom will probably use a more flexible system, but it was a good exercise ;-) |
| 02:42.00 | Maloeran | Perhaps it's just me, but I find it faster and clearer to read the actual source code than most typical low-level documentation found within the source |
| 02:42.29 | Maloeran | It seems to mostly get in the way, taking screen space... until you run a script to strip all comments out |
| 02:43.32 | starseeker | Depending on the goal and context this is true. One of the most able Axiom developers (able to read straight code) ended up forking the code base to avoid the drive towards literate programming |
| 02:43.38 | louipc | literal programming probably does a better job there the way it sounds |
| 02:43.40 | starseeker | (among other reasons) |
| 02:44.09 | starseeker | Mathematics has a way of creating maximally confusing code, I think ;-) |
| 02:45.39 | louipc | looks like it's just a different way to write code actually might be less verbose than the lower level stuff... |
| 02:45.43 | starseeker | more complex literate tools that are tightly integrated with a compiler can do tricks like reporting where in the document to find code that uses any particular code - a densely hyperlinked document. |
| 02:46.20 | starseeker | I think Knuth's tools were like that, but the problem with those tools is they become specific to one language. |
| 02:46.22 | louipc | print Hello there |
| 02:46.39 | louipc | rather than printf("Hello there"); |
| 02:47.19 | starseeker | No, in that case the grammar for your first part would end up being so long the space saved wouldn't pay for itself ;-) |
| 02:47.31 | Maloeran | I still prefer to see logic presented in code rather than in a maths form, but... that's just a matter of experience with code algorithms versus maths |
| 02:48.10 | starseeker | That's quite true. Axiom is a special case, as it is a computer algebra system - many of its primary contributors would (hopefully) be mathematicians first and coders second |
| 02:48.23 | starseeker | in such a case, making the code close to the mathematics is logical |
| 02:48.42 | Maloeran | Right, makes sense |
| 02:49.58 | starseeker | Also, if Axiom manages to outlive all of its original developers, it may someday be critical to survival for less skilled coders to be able to understand it and work with it |
| 02:50.19 | starseeker | That's my idealistic side showing ;-) |
| 02:50.47 | louipc | less skilled will get more skilled if they're determined enough :D |
| 03:03.07 | starseeker | night all ;-) |
| 03:17.04 | ``Erik | http://www.collegehumor.com/picture:1599962 that's walking distance from where I used to live in missouri O.o |
| 06:05.28 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) | |
| 07:30.38 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) | |
| 09:43.44 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-095-192.pools.arcor-ip.net) | |
| 13:05.03 | *** join/#brlcad Apathy (n=Matt@74.86.45.130) | |
| 13:59.03 | *** join/#brlcad Elperion (n=Bary@p54876BB1.dip.t-dialin.net) | |
| 14:32.44 | MinuteElectron | Good afternoon all. |
| 14:32.58 | MinuteElectron | It appears my connection troubles have evaporated. :) |
| 14:35.01 | brlcad | sweet |
| 14:36.27 | ``Erik | brlcad, staying in for lunch? |
| 14:51.45 | MinuteElectron | ``Erik: You work in the same office as brlcad? |
| 14:52.56 | *** mode/#brlcad [+o MinuteElectron] by ChanServ | |
| 14:54.45 | Maloeran | They do, yes |
| 14:55.05 | MinuteElectron | Ooh, cool. |
| 14:55.37 | ``Erik | same building, same team... not the same physical office, though :) |
| 14:56.58 | MinuteElectron | Oh, I see. |
| 14:57.25 | MinuteElectron | ... |
| 15:20.43 | ``Erik | we have 2-3 person offices, not a cube farm... :) |
| 15:21.36 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/ (364 files in 43 dirs): removed trailing whitespace |
| 15:22.04 | MinuteElectron | ``Erik: So you get paid to do this? |
| 15:22.11 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/other/ (1102 files in 65 dirs): removed trailing whitespace |
| 15:22.40 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/ (538 files in 44 dirs): removed trailing whitespace |
| 15:22.50 | ``Erik | yup |
| 15:23.07 | MinuteElectron | nice |
| 15:23.15 | ``Erik | *shrug* it's a yob |
| 15:23.27 | MinuteElectron | yob? |
| 15:23.30 | ``Erik | job |
| 15:23.30 | ``Erik | :D |
| 15:23.35 | MinuteElectron | oh, right. |
| 15:23.36 | ``Erik | mehican style O.o |
| 15:42.47 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/rt/Makefile.am: use AM_LDFLAGS instead of user-settable LDFLAGS |
| 17:16.38 | *** join/#brlcad Elperion (n=Bary@p54876BB1.dip.t-dialin.net) | |
| 17:32.27 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/conv/g2asc.c: eliminate trailing whitespace in g2asc output |
| 17:37.02 | *** join/#brlcad yukonbob (n=yukonbob@198.235.198.234) | |
| 17:44.52 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/ (6 files in 5 dirs): change c++/c99 "//" comments to more portable c89 /* */ comments |
| 17:47.03 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/include/dm_xvars.h: change c++/c99 "//" comments to more portable c89 /* */ comments |
| 17:51.39 | CIA-4 | BRL-CAD: 03johnranderson * 10brlcad/src/tclscripts/mged/text.tcl: |
| 17:51.39 | CIA-4 | BRL-CAD: Greenwald identified a bug in tab expansion. I could not reproduce the segfault |
| 17:51.39 | CIA-4 | BRL-CAD: that he saw, but did add a check for an open database before attempting |
| 17:51.39 | CIA-4 | BRL-CAD: object expansion, and a check for a valid path prior to expansion. |
| 17:52.28 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/mged/clone.c: pad out multi-line and doxygen comments |
| 18:09.14 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/libbu/htester.c: cast to fix incompatible pointer warning |
| 18:11.58 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/include/bu.h: change various ints and longs to size_t for pointer/offset stuff |
| 18:16.25 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/nirt/showshot.c: need common.h for config.h defines |
| 18:16.25 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/sig/coswin.c: include stdlib.h for malloc() |
| 18:24.26 | ``Erik | <PROTECTED> |
| 18:24.42 | ``Erik | minute... about? |
| 18:25.24 | MinuteElectron | Who you work for :D |
| 18:25.39 | *** join/#brlcad JJZ (n=kvirc@81.90.250.169) | |
| 18:25.54 | ``Erik | army research lab |
| 18:26.23 | MinuteElectron | And does john work at the same place as erik. And if so is erik a lower ranking officer than erik (you get refered to as 'Greenwald' XD) |
| 18:26.33 | ``Erik | heh |
| 18:26.34 | MinuteElectron | I ask too many qquestions. |
| 18:26.53 | MinuteElectron | And does brlc ad work at the same place as erik and john. |
| 18:27.17 | ``Erik | kinda |
| 18:27.24 | MinuteElectron | heh |
| 18:27.46 | ``Erik | john is technically on a different team... one I used to be on... there was a split, I went on the sucky side of it, but I moved back to the side that does cad |
| 18:28.26 | ``Erik | but all of johns BRL-CAD contributions these days are donated work in his spare time, he's not getting paid for it and the pointy hairs can go fuck themselves if they dont' like what he's doing :D |
| 18:28.37 | MinuteElectron | heh |
| 18:57.04 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/mged/clone.c: minor cleanup |
| 19:22.09 | brlcad | several of the files also necessarily had dos line endings, did you check that they weren't "fixed"? |
| 19:29.06 | brlcad | gah, and your tclIndex files are wrong |
| 19:31.36 | ``Erik | eh? |
| 19:31.45 | brlcad | ``Erik: you need to fix/revert the tclIndex file changes .. for whatever reason, the system you committed from is blowing most of the indices away |
| 19:32.21 | ``Erik | hrmmm |
| 19:33.00 | brlcad | looks like all of the incr tcl indices are gone |
| 19:33.05 | ``Erik | hrmmm, musta missed those when skimming the diff |
| 19:34.41 | brlcad | there's not really any point to "cleaning up" the src/other files.. just makes merging an incremental update harder, their code their mess |
| 19:35.26 | ``Erik | yeah *shrug* it was a one-liner, it walked into other, updating in other just blows away what is there, so'z I didn't worry about it :/ |
| 19:35.27 | brlcad | that's why there was a ton in src/other, but not much in the rest of the package .. there's a ws script that does the cleanup/exclusions automatically |
| 19:36.15 | brlcad | that's my point, it's not always a blow-away update .. sometimes it's a patch applied |
| 19:36.19 | brlcad | that just causes conflicts |
| 19:36.58 | ``Erik | heh, and admin -o will probably mess up the cvs2svn script? |
| 19:37.15 | brlcad | nah, don't admin it |
| 19:37.21 | brlcad | it's fine .. just for "next time" |
| 19:37.50 | ``Erik | I mean the tclIndex stuff atm |
| 19:42.25 | brlcad | hm, i'd just revert cleanly |
| 19:42.47 | brlcad | ala cvs revert -j 1.3 -j 1.2 tclIndex.tcl, etc.. |
| 19:43.07 | brlcad | used to have a script that got the last revision, and reverted to the previous .. but pretty quick to do by hand too |
| 19:43.26 | ``Erik | 'revert'? O.o |
| 19:43.51 | ``Erik | merge? |
| 19:43.54 | brlcad | hm? |
| 19:44.05 | ``Erik | revert isn't a cvs command... are ya thinkin' svn? |
| 19:44.16 | brlcad | oh, typo |
| 19:44.18 | brlcad | update |
| 19:44.28 | brlcad | svn has revert |
| 19:44.50 | brlcad | cvs update, join from 1.3 to 1.2 |
| 19:45.10 | brlcad | i.e., revert back one (presuming 1.3 was head rev) |
| 19:45.12 | ``Erik | <-- was doing 'cvs -z3 update -pr 1.2 tclIndex > tclIndex', the merge update seems to do the samet hing |
| 19:46.49 | brlcad | ah, hm .. I'd be afraid of cvs dying on the pipe wiping out the file it was reading from |
| 19:46.58 | brlcad | at least for some older versions |
| 19:47.23 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/src/tclscripts/ (7 files in 7 dirs): re-add indices accidently clobbered when removing trailing whitespace. My bad. |
| 19:47.35 | brlcad | s/pipe/output redir/ |
| 19:47.37 | ``Erik | heh, since it's a reversion, it doesn't matter... if the pipe craps itself, run it again, it's still in the repo |
| 19:47.49 | ``Erik | stream, whatever |
| 19:56.11 | ``Erik | probably just drift from printing floating point numbers |
| 20:05.17 | *** join/#brlcad iraytrace (n=iraytrac@c-76-23-15-187.hsd1.ut.comcast.net) | |
| 20:07.30 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/ (17 files in 11 dirs): |
| 20:07.30 | CIA-4 | BRL-CAD: The c89 headers are all fair game since it's been a requirement since the move |
| 20:07.30 | CIA-4 | BRL-CAD: to ANSI c89 compliance. So.. remove the HAVE_STDLIB_H checks and just use the |
| 20:07.30 | CIA-4 | BRL-CAD: header. The headers <complex.h>, <fenv.h>, <inttypes.h>, <stdbool.h>, |
| 20:07.31 | CIA-4 | BRL-CAD: <stdint.h>, and <tgmath.h> were added with C99 and still need to be checked. |
| 20:07.33 | CIA-4 | BRL-CAD: There are several other c89 headers that we could just use, though, that are |
| 20:07.35 | CIA-4 | BRL-CAD: still being checked. |
| 20:08.48 | brlcad | ``Erik: yeah, that's a nasty tolerance bug .. kudos if you figure out why :) |
| 20:09.48 | brlcad | it probably is just drift, but when you push it through again, you're pushing through a v5 asc which has more digits than the v4 it started from so it shouldn't be different |
| 20:13.23 | iraytrace | Looks like a commit storm in the logs today ;0) |
| 20:17.55 | brlcad | all hail the 'ws' commits |
| 20:20.47 | ``Erik | but I got a bunch of non-ws commits in, too |
| 21:44.28 | poolio_ | hmm, quite off topic but I was wondering if any of you guys knew of some sort of dynamics simulator...like an aerodynamics simulator where i could throw in an object and get something like a drag coefficient back |
| 21:44.51 | brlcad | er, the flight simulator has things for that |
| 21:44.56 | brlcad | s/er/hmm/ |
| 21:45.28 | brlcad | http://www.flightgear.org/ |
| 21:45.56 | brlcad | not sure if you could do a single wing, but it does the computations and you can feed custom geometry |
| 21:57.03 | poolio_ | hmm, thanks |
| 22:55.27 | *** join/#brlcad cad31 (n=54aef384@bz.bzflag.bz) | |
| 23:05.38 | ``Erik | um |
| 23:05.48 | ``Erik | flightgear has a couple coarse emulation models |
| 23:05.57 | ``Erik | that require experiemental details entered |
| 23:06.03 | ``Erik | jsim and uhhh something else |
| 23:06.20 | ``Erik | xplane uses 'blade theory' to generate force sums, there're plenty of papers on the idea |
| 23:09.34 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: might as well also list the c89 and c95 headers |
| 23:10.29 | *** join/#brlcad archivist (n=archivis@host217-35-76-52.in-addr.btopenworld.com) | |
| 23:18.00 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/ (librt/wdb_obj.c mged/ged.c): don't bother checking for errno.h, it's c89 |
| 23:31.24 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/ (configure.ac src/mged/ged.c): don't check for errno.h, we can assume at least c89 compliance |
| 23:41.19 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/ (6 files in 5 dirs): math.h and float.h are also fair game, c89 baby |