| 00:16.37 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168055344.dsl.bell.ca) |
| 01:01.02 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (README configure.ac NEWS include/config_win.h): update to next developer release, 7.9.0, indicating intentions for the next release to be a minor update not just a patch update as 7.10.0 |
| 01:19.49 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: add an --enable-ef-build option to configure with aliases of ef, endgame, and more providing BUILD_EF for automake |
| 01:23.29 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/conv/ (g-acad.1 g-acad.c): Make it more explicitly clear that ACAD is not AutoCAD. It's the 'Advanced Computer-Aided Design' system developed and used in-house by Lockheed Martin (formerly by General Dynamics). |
| 01:34.28 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/external/README: documentation on the soon to be added external EndgameFramework module |
| 01:35.52 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/conv/nmg-bot.c: prevent a few potential null dereferencings |
| 02:50.30 | Maloeran | Ahah. How was I complaining about 93 triangles per sector... There are a few >= 200 in that truck |
| 02:51.23 | Maloeran | Oh, a 459 triangles one. Okay, this needs immediate fixing |
| 02:54.45 | Maloeran | That sure explains how the rate hops between 4.5m/s and 1.0m/s. as I fly through it |
| 03:26.20 | *** part/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168055344.dsl.bell.ca) |
| 12:30.21 | *** join/#brlcad rossberg (n=rossberg@bz.bzflag.bz) |
| 13:24.40 | Maloeran | So Erik, is now a good time? :) |
| 13:25.40 | brlcad | g'morning rossberg |
| 13:25.51 | ``Erik | heh, walking into a meeting with wendy ina minute, actually :) |
| 13:25.52 | brlcad | or afternoon for you I suppose |
| 13:26.01 | ``Erik | also; failure on build, posix_memalign |
| 13:26.54 | Maloeran | Isn't that POSIX.1d ? |
| 13:28.38 | rossberg | brlcad: good afternoon |
| 13:28.47 | Maloeran | I would have used my mm.c functions, though that's outside the raytracer library ; rather dirty to copy mm.c everywhere until I figure out these rumored "convenience libraries" |
| 13:29.04 | ``Erik | it's not on bsd, irix, solaris, or osX... just linux as fara s i can see |
| 13:29.22 | ``Erik | but the functionality is listed by many other names... *shrug* |
| 13:29.54 | Maloeran | memalign() is not garanteed to be able to be free()'d, which is a very akward limitation |
| 13:30.27 | ``Erik | *read* as far as I can tell, 1d is not a standard, just a draft proposal for realtime os stuff |
| 13:30.29 | Maloeran | Anyhow, I'll just import some mm.c functions as I did from rfmath.c, it gets nasty |
| 13:30.50 | ``Erik | okie, meeting time |
| 13:30.53 | Maloeran | Have fun! |
| 13:35.42 | rossberg | brlcad: may a gpl library contain bsd code? |
| 13:36.07 | rossberg | (or lgpl library) |
| 13:36.09 | Maloeran | Sure, not the other way around though |
| 13:39.00 | rossberg | libregex contains an unusual passage regarding the acknowledgement |
| 13:53.28 | brlcad | bsd code can be used easily in other codes, the license is rather flexible |
| 13:53.53 | brlcad | basically just requires that you don't claim authorship for that code |
| 13:57.27 | rossberg | i mentioned the bsd part in the readme file of the brlcad.dll release |
| 13:58.01 | rossberg | the large brlcad realeses contain the acknowledgement anyway |
| 13:59.03 | brlcad | right |
| 14:00.29 | brlcad | if i'm not mistaken, the library uses the original bsd license, which has the endorsement clause on advertising |
| 14:01.03 | brlcad | would be good to update to a more recent version of that library to get the updated bsd license (and hopefully performance enhancements) but it's not a major issue in the least |
| 14:01.36 | brlcad | it's still bsd and lets you basically do anything with it so long as you give them credit (which brl-cad does, and you've done in your dll.. should be plenty) |
| 14:05.30 | rossberg | thats what i thought |
| 14:07.00 | brlcad | about time we finally got a release posted.. hopefully we can stick on track now and get back to monthlies |
| 14:09.19 | brlcad | the automated builds should hopefully be on-line soon so it really will be just a matter of setting a tag, copying up the files, and sending out announcements |
| 14:10.01 | *** topic/#brlcad by brlcad -> http://brlcad.org/ || BRL-CAD is an open source solid modeling software suite || Developers needed! Read the HACKING file for details on getting involved || Release 7.8.4 is posted, next release will be 7.10.0 |
| 14:14.20 | rossberg | will these automatic builds work for ms windows too? |
| 14:19.24 | brlcad | :) |
| 14:20.09 | brlcad | ideally the will eventually .. though the windows builds still need a lot of work |
| 14:23.58 | brlcad | getting your dll to auto-build will likely be a lot easier to automate first |
| 14:24.42 | brlcad | i've got a windows dev system that should be coming on-line soon (read: within a month or two) so I should be able to polish up things where bob left off, get things automating like they need to be |
| 14:25.01 | brlcad | using features of the vc6 build system that you added like autogenerating the vers.c files, etc |
| 14:25.35 | rossberg | likely; do you know SCons? |
| 14:26.34 | Maloeran | Compiling in mingw with Makefiles might well be far less trouble |
| 14:26.44 | Maloeran | And the VC6 optimisation is abysmal |
| 14:26.58 | rossberg | it's a cross plattform build tool based on Python |
| 14:29.39 | rossberg | is it possible to build windows binaries with gcc on *nix? |
| 14:32.24 | brlcad | rossberg: quite familiar with scons |
| 14:34.02 | brlcad | setting up a scons build system would require about as much work as has already gone into the autotools build system, and adds another layer of complexity for supporting older systems |
| 14:35.19 | brlcad | the biggest detriment is maturity, scons still has a lot of issues with correct cross-platform behavior, it doesn't really manage complexity much better (for large projects) than autotools does |
| 14:36.08 | brlcad | it should eventually eclipse autotools, but that's at least five years out if I had to estimate |
| 14:37.17 | brlcad | there are other benefits and downsides, but the fundamentals just aren't there for a mild benefit -- and it only solves one (rather minor) problem of a build system. pure windows devs still generally prefer studio projects. |
| 14:40.29 | Maloeran | Probably. It just seems far less of an effort to support an additional gcc target, as MS tools don't support C99, C extensions, etc. |
| 14:41.06 | brlcad | heh, "C extensions" are "GCC extensions" ;) |
| 14:41.28 | Maloeran | Supported by Intel, Pathscale and a couple others ;) |
| 14:41.32 | brlcad | it does support c99, though, vc8 is particularly better at conforming |
| 14:41.50 | brlcad | sure, but still a set of things "invented by gcc" |
| 14:41.53 | Maloeran | Really? I'm surprised, I heard otherwise even recently |
| 14:43.18 | brlcad | i'd be curious to know what someone thinks it didn't support -- there's only a limited set of api calls in the standard that are outside of the expected namespace, but they are still provided -- syntax-wise, it should be pretty conformant |
| 14:43.47 | brlcad | it lets you do some things that it really shouldn't, but that's a different issue |
| 14:46.04 | rossberg | i don't have that impression that C99 is a main issue, operating system interfaces as e.g. POSIX are more important, some are supported by Windows and some not |
| 14:46.32 | brlcad | that is quite true |
| 14:47.17 | brlcad | though for a lot of the posix interfaces, there's a #definable solution that works just named something different |
| 14:47.29 | Maloeran | Quite right. It's just one less issue to worry about when porting with mingw |
| 14:49.02 | brlcad | a mingw port is quite easy and holistic, but need to test out how well that works for making distributable clickable apps for things like mged |
| 14:49.17 | brlcad | still doesn't solve the "I want to use Studio" problem, but it gets a full build |
| 14:50.09 | rossberg | hard to believe, the mutithread interfaces aren't compatible |
| 14:50.33 | brlcad | one approach I may consider is a make target that generates the studio project files -- shouldn't be too difficult as the file format is relatively straightforward xml or text (depending on whether vc678 is targetted) |
| 14:51.15 | rossberg | btw, SCons can generate the vs project files (VS6.0 and .NET) |
| 14:51.28 | brlcad | ooh, nice -- did not know that |
| 14:52.27 | rossberg | but, as you said, it |
| 14:52.34 | rossberg | is still alpha |
| 14:53.39 | brlcad | yeah, I still wouldn't jump to scons just yet because of the variety of other issues |
| 14:53.47 | brlcad | that would be nice icing though |
| 14:59.36 | brlcad | more important is to actually get a complete build on windows, seeing as there is only 10% of the binaries ported, and an equivalent environment to run them in (a brl-cad shell) |
| 15:01.56 | brlcad | to get all the binaries, it's either 1) something with mingw/cygwin, 2) generate studio project files, 3) manual generation in studio like was started, or 4) give scons a go |
| 15:02.29 | brlcad | and that's roughly in order towards the level of effort, issues, and time that would be involved, increasingly |
| 15:04.01 | brlcad | 3 and 4 are inherintly problematic, but if someone (tm) else is willing to do the work then great ;) |
| 15:06.06 | brlcad | I'll be working on both 1 and 2 as they are maintainable solutions and would stay in sync with the current build infrastructure, which has been working out quite well so far |
| 15:13.34 | rossberg | i havn't tried any build with mingw or cygwin yet; all i can say is the cygwin X server works for me |
| 15:15.01 | rossberg | on the other hand, building project files isn't the problem, however threading features and open a shell are (as e.g. in vdeck) |
| 15:34.58 | Maloeran | There's really something weird about the output from asc2g |
| 15:35.34 | Maloeran | There are 93 triangles in that sector : http://www.rayforce.net/grah.png all long and thin, from an edge to the other |
| 15:40.08 | Maloeran | As much as the frame only looks like made of 3-4 planes. I'll make the prep handles such cases, but that's still some strange geometry |
| 16:47.35 | brlcad | hmm |
| 16:47.50 | brlcad | ~nslookup www.rayforce.net |
| 16:50.01 | ``Erik | has a whois record, though |
| 16:50.20 | brlcad | ~ping 205.178.190.21 |
| 16:50.24 | ibot | pong 205.178.190.21 |
| 16:50.32 | brlcad | getting massive packet loss to his name servers |
| 16:50.33 | ``Erik | takeing off the www. makes it work |
| 16:50.51 | brlcad | not here |
| 16:51.03 | brlcad | i think it's just wiggin out |
| 16:51.05 | ``Erik | hrmmmm, probably just gimpy ns |
| 16:51.22 | brlcad | what's the ip? |
| 16:52.12 | ``Erik | heh, sone of a bitch, got the pic but now I can't get the ip, heh |
| 16:52.19 | ``Erik | s/e / / |
| 16:53.22 | brlcad | post the pic up somewhere more respectable then :) |
| 16:55.16 | Maloeran | That could be problematic for emails if that's a real problem |
| 16:56.41 | brlcad | ``Erik: just 'erik' |
| 16:56.49 | ``Erik | oh, woops, heh |
| 16:57.19 | brlcad | public_html will work too |
| 16:57.27 | ``Erik | whu? /usr/tmp/ permission denied? O.O |
| 16:57.53 | brlcad | there is no /usr/tmp |
| 16:58.00 | brlcad | <PROTECTED> |
| 16:58.35 | brlcad | can toss it into /usr/web/ftp.brlcad.org/tmp too for web viewing |
| 16:58.38 | ``Erik | why the hell isn't there a /usr/tmp??? (and it's ~erik/public_html/grah.png now) |
| 16:59.11 | brlcad | ah, http://ftp.brlcad.org/~erik/grah.png there we go |
| 16:59.35 | ``Erik | ah, s/^/ftp./ |
| 16:59.36 | Maloeran | Thanks brlcad |
| 16:59.43 | ``Erik | I just tried brlcad.org/~erik/ |
| 16:59.51 | ``Erik | computers are hard |
| 16:59.56 | brlcad | heh |
| 17:00.06 | brlcad | brlcad.org is sf.net |
| 17:00.21 | brlcad | ftp.brlcad.org or bzflag.bz map to that host |
| 17:00.25 | ``Erik | aight, gotcha |
| 17:00.48 | ``Erik | huh, and I've been pussyfooting about downloading from http://brlcad.org to keep your bandwidth down, heh |
| 17:00.50 | brlcad | sort of matching the old ftp.arl.mil |
| 17:01.25 | brlcad | most of the larger downloads on brlcad.org actually link to ftp.brlcad.org (e.g. for the .pdf files) |
| 17:01.33 | brlcad | otherwise sf.net throttles them to like 4k |
| 17:01.47 | Maloeran | There isn't much to see in the pictures anyhow, but it's peculiar to have many packed thin long triangles there |
| 17:03.04 | brlcad | yeah, i'm not seeing it :) |
| 17:03.36 | Maloeran | Erik, do you have some time now? |
| 17:03.48 | ``Erik | 'fraid not, I'm off to another meeting in a few minutes :( |
| 17:04.53 | Maloeran | Will that last until you get home? |
| 17:05.09 | ``Erik | no, this is the last one, and hopefully it'll be short |
| 17:05.16 | Maloeran | All right |
| 17:18.53 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: oop, the EndgameFramework directory isn't added to the repository yet, so leave it out |
| 17:23.11 | brlcad | well it sure as hell doesn't configure fast |
| 17:25.49 | Maloeran | My fastest box is a single core Athlon64 overclocked by 37%, very noisy for being cooled by two 110V fans. I'm due for an upgrade ;) |
| 17:44.41 | brlcad | ahh, almost 5 minutes to build, not "too" shabby |
| 17:45.07 | brlcad | altix still beats it by about 50%, but the cost ratio is certainly a bit skewed there.. ;) |
| 17:46.20 | Maloeran | Quite :) |
| 17:47.14 | brlcad | ahh, cached configure is much better.. less than a minute |
| 17:47.25 | Maloeran | I still await AMD's reply to Intel's new toy, I have been biased towards AMD since the amd-k6 |
| 18:12.46 | *** join/#brlcad Malfoo (n=maloeran@glvortex.net) |
| 18:13.06 | Malfoo | Ah, that's what I get for connecting through the neighbours wireless |
| 18:26.49 | brlcad | woo, almost 15K VGRs on the 8-way AMD |
| 18:28.45 | brlcad | (that's just a little faster than the 12-way altix, now ~3 years old) |
| 18:31.11 | Malfoo | Hum, VGRs? |
| 18:31.43 | brlcad | Malfoo: it's a base unit of performanc measurement used by the brl-cad benchmark suite |
| 18:32.34 | brlcad | it's a linear performance metric, similar to FLOPS |
| 18:33.05 | brlcad | equates to average estimated ray-trace and overall cpu performance |
| 18:33.33 | Malfoo | *nod* Good, I guess you mesure memory bandwidth and several other factors |
| 18:34.48 | brlcad | it's not just a raw computation metric -- it actually performs several various "real" ray-trace renderings, so that you can compare the end user result, not just some theoretical integer/floating max for example |
| 18:35.18 | brlcad | so yeah, it takes memory into account, cache sizes, bus performance, cpu performance, etc |
| 18:35.52 | Malfoo | I see. Such specific tests can perform nicely or poorly due to many factors... The chip's branch prediction, for example |
| 18:37.19 | Malfoo | Do you have some idea how ADRT compares with OpenRT/Intrace or some other high-performance raytracers out there? |
| 18:38.59 | brlcad | yeah, sensitive to compilation options and compiler performance too, which is part of the entire point -- what does the performance look like when all is said and done |
| 18:41.09 | Malfoo | I'm a bit annoyed at the complete lack of reliable raw numbers on the performance of kd-trees, from all the papers of the conference |
| 18:41.29 | Malfoo | Doing 5 times faster than ADRT is one thing, I wish I had a clue how it compares with others |
| 18:41.46 | brlcad | hold a sec |
| 19:04.38 | *** join/#brlcad Maloeran (n=maloeran@glvortex.net) |
| 19:18.16 | brlcad | there wasn't much in the way of performance numbers at rt06, siggraph would be a better source |
| 19:20.25 | Maloeran | I realized that, a conference on interactive raytracing with very little focus on raw numbers ; everybody probably gets the same thing for all using the same techniques |
| 19:22.28 | brlcad | that and none of the numbers have really changed since they were last presented, so it'd be redundant |
| 19:23.32 | brlcad | vaguely remember reschetov's presentation having numbers presented rather clearly a couple years ago |
| 19:24.10 | brlcad | and afaik, he's still got the fastest published results at least for first-hit optical with non-degenerate scenes |
| 19:24.37 | Maloeran | Oh? I don't suppose you remember any number? |
| 19:24.54 | brlcad | heh, my memory's not that good |
| 19:25.15 | Maloeran | I really would love to know how sector graphs mesure against the best kd-tree implementations |
| 19:25.29 | brlcad | ingo made a comment about it at siggraph iirc about how close they were to his results with their approach |
| 19:25.39 | brlcad | though they still didn't get what he was getting |
| 19:25.55 | Maloeran | Was it > 10 million rays per second per processor core? |
| 19:26.15 | brlcad | i really don't recall the raw numbers, or what his hardware was |
| 19:27.13 | brlcad | he was demo'ing it on his laptop at siggraph when it was presented, spinning detailed models around in real time with reasonable framerates |
| 19:27.21 | brlcad | look up his paper, it's got to have the numbers |
| 19:28.01 | Maloeran | So can I with the old slow prototype. Any idea on the paper title? |
| 19:28.24 | brlcad | nope, but he's not got a lot published |
| 19:30.57 | brlcad | ahh |
| 19:56.45 | Maloeran | The OpenRT performance sure is pathetic in there, but I think MLRTA exceeds my prototype |
| 20:02.31 | brlcad | i think adrt comes in just a little under openrt, but more or less in line |
| 20:03.12 | ``Erik | grar, some people are r-tards |
| 20:04.02 | Maloeran | Probably twice as slow as ADRT uses SSE |
| 20:04.11 | Maloeran | How was the meeting, Erik? :) |
| 20:04.40 | ``Erik | <km> the results of rt and adrt don't line up exactly, so I have to find the breakage <erik> do you know if your adrt is built to use floats or doubles? <km> floats, the problem goes away when using doubles <erik> yeah, uh, rt uses doubles, you're seeing fp roundoff <km> yeah, but I still have to get the rays so I can see where the problem is |
| 20:04.46 | ``Erik | hurrrrrr *head explodes* |
| 20:05.50 | Maloeran | Tiny differences or real flaws? I don't know if the the ADRT constants to overcome rounding were perfectly accurate |
| 20:06.35 | ``Erik | um, after a series of mutilations, the in and out points were "identical to eight places" but still claiming a thickness of 0.001 or something |
| 20:07.07 | ``Erik | but, dude, the problem goes away when using doubles and the results are identical... km's task is to see if the results are identical... |
| 20:07.14 | ``Erik | and librt uses doubles... |
| 20:07.17 | ``Erik | it ain't rocket science |
| 20:07.20 | Maloeran | Eheh, neat |
| 20:07.41 | ``Erik | so, yeah, *grar* |
| 20:07.57 | ``Erik | what's the name of the milestone spreadsheet? |
| 20:08.04 | Maloeran | Oh by the way, are long doubles of any interest or I can forget them? |
| 20:08.18 | ``Erik | "long doubles" as in 128b? |
| 20:08.28 | Maloeran | Hum, mine is called Rayforce_Meeting_Minutes.060822.doc |
| 20:08.41 | Maloeran | As in whatever long doubles happen to be on the arch |
| 20:08.57 | ``Erik | hm, I thought there was an excel file |
| 20:08.59 | Maloeran | I just need to fix my #ifdef all over the code if you want more than float and double |
| 20:10.02 | Maloeran | The excel file is included in that one for me, I don't think I have anything else |
| 20:13.31 | Maloeran | If possibe, I would like to get some time to complete the prep and raytracing pipelines, including multiple intersections and segment construction, before getting into distributed processing |
| 20:14.14 | Maloeran | It is akward to distribute processing for code that is... incomplete |
| 20:38.44 | Maloeran | Ew, sorry. |
| 20:52.50 | ``Erik | jfc. |
| 20:52.50 | ``Erik | OK |
| 20:52.54 | ``Erik | now I'm at my computer. |
| 20:53.54 | ``Erik | regression suite isn't running yet? |
| 20:58.16 | Maloeran | No, I was waiting to get a good model to stick to, the truck will do |
| 20:58.39 | Maloeran | Although I'm not entirely certain what it's supposed to do, takes a bunch of screenshots, check for correctness and record performance? |
| 20:58.51 | ``Erik | pretty much, yeah |
| 20:59.14 | Maloeran | Okay, that really won't take long |
| 20:59.42 | ``Erik | if the machine it'll be cron'd on has brlcad, we can use pixdiff or pixcmp or something |
| 20:59.45 | Maloeran | As for the API, it has been completed since before the contract started |
| 20:59.58 | Maloeran | All right, so noted |
| 21:00.49 | ``Erik | voxels down to 15 days? |
| 21:01.02 | Maloeran | Seems reasonable to me, it should be very simple |
| 21:01.16 | ``Erik | "prep and pipeline" right now? how many days? 15? |
| 21:01.41 | Maloeran | Two weeks would be great, though distributed processing will be tight with two weeks |
| 21:02.05 | ``Erik | hmmm, distributed would be after mpi/ip? |
| 21:02.26 | Maloeran | That's pretty much the same thing in my book :) |
| 21:02.55 | ``Erik | <-- is shuffling numbers and order here, tryin gto figure out what to present up |
| 21:03.24 | Maloeran | It's probably because I try to get every part fully done as I move on, rather than just meet some basic requirements |
| 21:03.24 | ``Erik | well, half, and teh big ones are at the end |
| 21:03.30 | ``Erik | probably |
| 21:03.44 | Maloeran | I have written a bunch of stuff for dynamic geometry already |
| 21:03.44 | ``Erik | can we cut down on dynamic geometry, then? move some time there to prep&pipeline? |
| 21:04.09 | Maloeran | Maybe a week, but I could use a while there ; there are unsolved questions to explore |
| 21:04.41 | ``Erik | you have 47 days listed, if I can hoist some to prep&pipeline... |
| 21:05.02 | ``Erik | <-- would like to show 'em something saying that you're at or ahead of what the schedule says you should be :D |
| 21:05.22 | Maloeran | Agreed :), hrm |
| 21:05.57 | Maloeran | One week to finish the prep, one week to finish raytracing pipelines including multiple intersection ( which leads to segment construction ) |
| 21:06.10 | ``Erik | can you cope with 'excel'? or do I need to be in a different format |
| 21:06.22 | Maloeran | ooffice2 can cope |
| 21:06.57 | Maloeran | One extra week on distributed processing ( IP/MPI ) ; Two weeks out of voxel, one week out of dynamic geomerty |
| 21:07.13 | Maloeran | What do you think? |
| 21:07.32 | Maloeran | Actually, I won't need two weeks on segment construction, that's easy |
| 21:08.07 | ``Erik | efnet... |
| 21:09.25 | Maloeran | Received, a bunch of ### in there |
| 22:09.59 | Twingy | moo |
| 22:43.56 | *** join/#brlcad pra5ad (n=prasad@pool-70-16-21-23.balt.east.verizon.net) |
| 22:44.36 | pra5ad | where can i find the slad directory online? |
| 22:44.46 | pra5ad | or is there one i can access from home? |
| 22:46.32 | Maloeran | Hey prasad, long time no see here, not that I can be of any help on the questions |
| 22:47.37 | pra5ad | hey man |
| 22:47.42 | pra5ad | how's life as a contractor |
| 22:48.41 | Maloeran | I would like to say "relaxing", but the work is fairly demanding while quite enjoyable. Do you still have some vague interest in the dream of building raytracing hardware? ;) |
| 22:52.12 | pra5ad | sure do |
| 22:53.34 | Maloeran | I don't think you have access to the cvs, I'll hand some url to a very short document on the techniques used if you are interested |
| 22:55.06 | Maloeran | If you have a look, feel free to share if it makes some sense, it's... rather short and right to the point |
| 22:56.14 | pra5ad | will take a look |
| 22:56.26 | pra5ad | what is the slad intranet url? |
| 22:56.28 | pra5ad | anyone? |
| 23:10.54 | ``Erik | which, uh, intranet url? heh |
| 23:17.06 | pra5ad | nm |
| 23:17.17 | *** part/#brlcad pra5ad (n=prasad@pool-70-16-21-23.balt.east.verizon.net) |
| 23:39.30 | Maloeran | Seems he doesn't plan on hanging around |
| 23:42.25 | ``Erik | he sucks |
| 23:42.45 | ``Erik | too busy chasing tail I guess |
| 23:45.33 | Maloeran | That's a metaphor for spending time on unproductive things? |
| 23:50.34 | ``Erik | heh, uh |
| 23:50.46 | ``Erik | not unproductive.. .more... reproductive... |
| 23:50.47 | ``Erik | O:-) |
| 23:52.11 | Maloeran | Oh, hum. Unproductive too then |
| 23:54.27 | ``Erik | heh |
| 23:56.08 | Maloeran | I can vary performance vs memory consumption a whole lot, I suppose the regression test suite should try a few settings |
| 23:56.49 | ``Erik | if we can express that as a curve and tehn map the progression of the curve over time, that'd be gnarly |
| 23:56.52 | Maloeran | I'm annoyed by the huge amount of memory the prep takes, I could reduce that greatly by sacrificing a bit of graph quality |
| 23:57.32 | Maloeran | What about a text file? :) Not that generating curves take a long time to write |
| 23:58.01 | ``Erik | 'curve' might be a couple numbers in the end |
| 23:58.14 | ``Erik | as long as we can do SOMETHING to achieve some understanding of the change over time |
| 23:58.22 | Maloeran | Sure, okay |
