| --- Log opened Thu Sep 03 00:00:34 2009 |
| --- Day changed Thu Sep 03 2009 |
| 00:00 | < Rhamphoryncus> | Derakon[work]: I see. I can understand that having a wide variation in compressibility |
| 00:00 | < Rhamphoryncus> | Derakon[work]: I wonder if swapping the x and y axis would affect it much |
| 00:01 | < Derakon[work]> | There's four axes, actually: x, y, z, and time. |
| 00:01 | < Derakon[work]> | So it's a sequence of lightmaps. |
| 00:01 | < Rhamphoryncus> | ahh |
| 00:03 | < Rhamphoryncus> | I assume you want lossless compression? |
| 00:04 | < Derakon[work]> | Definitely. |
| 00:04 | < Derakon[work]> | So we were talking about this with the PI, and people were discussing trying to adapt lossless JPEG to it, and I thought "why not just try bzip?" |
| 00:06 | < Rhamphoryncus> | Well, bzip2 is based on huffman coding, so it's not necessarily the right thing for images |
| 00:06 | < Derakon[work]> | Yeah, but it's a) better than nothing, and b) easy to use. |
| 00:07 | < Rhamphoryncus> | true |
| 00:07 | < Derakon[work]> | Given that these files are originally hundreds of megs, the savings is significant. |
| 00:07 | < Rhamphoryncus> | tried png? Although I bet it sucks too |
| 00:07 | < Derakon[work]> | Nope; I just tried gzip and bzip2. |
| 00:07 | < Rhamphoryncus> | I think png uses zlib underneath |
| 00:07 | < Derakon[work]> | That sounds familiar, yeah. |
| 00:08 | < Derakon[work]> | Idly! Trying to get NumPy built and usable without doing a system-wide install. |
| 00:09 | | * Rhamphoryncus ponders inventing his own compression algorithm.. although that sounds like a bad idea ;) |
| 00:09 | < Derakon[work]> | I can do python setup.py build, but python setup.py install --install-base ~/numpy fails with "error: install-base or install-platbase supplied, but installation scheme is incomplete" |
| 00:10 | < Derakon[work]> | It looks like it wants the Lapack sources for some reason...any idea why? |
| 00:10 | < Derakon[work]> | ...or rather, any idea why it's failing at install time instead of at build time? |
| 00:10 | < Rhamphoryncus> | no clue |
| 00:10 | < Derakon[work]> | Bahhh... |
| 00:11 | < Derakon[work]> | The install action is clearly doing more than just mv/cp, since the stuff in the build directory is unusable. |
| 00:11 | < Derakon[work]> | (Try to run numpy.test(); it complains that it can't do "import numeric") |
| 00:15 | < Rhamphoryncus> | mmm fourier transforms |
| 00:29 | < Derakon[work]> | Urge to work on build issues...falling... |
| 00:30 | < Derakon[work]> | It is *such* a bad sign when, having done nothing except create a copy of the source code (on the same machine as the original developer's copy), I can't build anything. |
| 00:30 | < Derakon[work]> | And the dependencies are a fantastic mess. |
| 00:30 | < Derakon[work]> | I'm seriously considering saying "Bugger this for a lark" and working on instead rewriting everything as a Python app with C libraries where needed. |
| 00:32 | | * Derakon[work] does a quick spot check with one of his coworkers: yep, the existing binary hasn't been built since the original developer left, which was IIRC three years back. |
| 00:32 | < Derakon[work]> | Ever since then all changes have been made in Python instead. |
| 00:52 | <@AnnoDomini> | I like how the new version of OO fixed the annoying delete bug where it erased the formatting on the following line if you used delete on the previous line and it happened to contain just a linebreak. |
| 00:54 | | You're now known as TheWatcher[T-2] |
| 00:55 | | AnnoDomini [AnnoDomini@Nightstar-29123.neoplus.adsl.tpnet.pl] has quit [Quit: Juffo-Wup is a *candle*. It is filled with many *candy bars*.] |
| 00:55 | | Derakon[work] [~Derakon@Nightstar-6042.ucsf.edu] has quit [Quit: Leaving] |
| 00:56 | | You're now known as TheWatcher[zZzZ] |
| 01:18 | | Attilla [~The.Attil@92.21.240.ns-3266] has quit [Quit: ] |
| 01:33 | | Derakon[AFK] is now known as Derakon |
| 01:44 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has quit [Quit: Z?] |
| 02:45 | | Vornicus [Vornicus@Admin.Nightstar.Net] has quit [Quit: ] |
| 02:47 | | Vornicus [~vorn@ServicesOp.Nightstar.Net] has joined #code |
| 02:47 | | mode/#code [+o Vornicus] by ChanServ |
| 04:04 | <@Vornicus> | God I love being a math nerd. |
| 04:04 | < Rhamphoryncus> | Derakon: yeah, that is a bad sign |
| 04:04 | < Rhamphoryncus> | Vornicus: yay math! I was smirking yesterday about using math to "win" an argument |
| 04:06 | <@Vornicus> | THe usual algorithm to discover a polynomial (given only that it is a polynomial and nothing else) is to keep picking points until the previous points successfully predict one. |
| 04:06 | <@Derakon> | Rhamphoryncus: it's my desperate hope that I can limit the C/C++ code to just the bits that interface with the hardware, and do everything else in properly-designed Python. |
| 04:07 | <@Vornicus> | However, I have discovered that for any deterministic point-picking algorithm, you can attack it and get it to guess a polynomial of your choosing (of order 2 lower than the polynomial you use for the attack) |
| 04:08 | < Rhamphoryncus> | Derakon: *nod* |
| 04:08 | < Rhamphoryncus> | Vornicus: I'll pretend I understand polynomials enough to understand that ;) |
| 04:09 | <@Vornicus> | heh |
| 04:09 | <@Derakon> | It sounds like he's basically saying that you can trick the polynomial discovery algorithm into thinking it's done early. |
| 04:09 | <@Derakon> | Presumably by making your polynomial behave as if it were lower order in the areas the algorithm is checking. |
| 04:09 | <@Vornicus> | Precisely. |
| 04:11 | <@Vornicus> | It only works of course if you can predict what locations the algorithm will check. |
| 04:13 | <@Derakon> | Naturally. |
| 04:15 | < Rhamphoryncus> | sounds like you're cheating to get a less accurate result |
| 04:17 | <@Vornicus> | but it works marvellously. Take for instance f(x) = x^3 - 6x^2 + 12x - 6. If your guesser tries x = 1,2,3... then your prediction points will come back (1,1), (2,2), (3,3) ... and at the third one it will go "Oh, it's linear!" and get f(x) = x. |
| 04:17 | <@Vornicus> | Which obriously isn't true. |
| 04:22 | | * Derakon mutters at Grapher, tries to figure out how to get it to mark integers on the axes instead of .8, 1.6, 2.4... |
| 04:23 | <@Derakon> | Heh, yes, that function goes 1, 2, 3, 10... |
| 04:33 | <@Derakon> | Vorn, you might find this interesting: http://www.bay12games.com/forum/index.php?topic=41327.0 |
| 04:35 | <@Vornicus> | Mmm, tricky bit is that there's 16 cards in the hand. |
| 04:36 | <@Derakon> | In other words, more than is required for any one play. |
| 04:36 | <@SmithKurosaki> | Blarghity Flail |
| 05:13 | | Consul [~Consul__@Nightstar-1744.dsl.sfldmi.ameritech.net] has quit [Quit: Leaving] |
| 06:17 | | Derakon is now known as Derakon[AFK] |
| 06:25 | | Orthia [~Orthianz@Nightstar-9186.xdsl.xnet.co.nz] has joined #Code |
| 06:34 | <@Reiver> | Vornicus! |
| 06:34 | <@Reiver> | I have a mathy programmy question for you. |
| 06:35 | <@Reiver> | Looking at modding a game. Apparently part of it requires trigonometric matrixes to enter turret position data? This scares me. O.o |
| 06:36 | <@Vornicus> | THat's not actually surprising. Matrices are useful for describing location, size, and orientation. |
| 06:36 | <@Vornicus> | Especially as you can usually just throw them at your gl and have it work. |
| 06:43 | <@Reiver> | Hrn. I suppose so, then. |
| 06:44 | <@Reiver> | I should just get good with a graphics calculator, then?~ |
| 06:46 | < Chi> | or pirate Mathematica. :P |
| 06:47 | <@Vornicus> | I've never done matrix stuff on a graphing calculator. |
| 06:50 | <@Vornicus> | Excel might be more appropriate. |
| 06:51 | <@McMartin> | OpenGL's tutorial is pretty good. |
| 06:51 | <@McMartin> | That is, the enormous red tome |
| 07:06 | | Thaqui [~Thaqui@121.98.166.ns-22683] has joined #code |
| 07:06 | | mode/#code [+o Thaqui] by ChanServ |
| 08:10 | | * Kazriko likes the enormous red tome. |
| 08:11 | | * Kazriko needs to eventually study it again. |
| 08:11 | | * McMartin has a Purple Dragon here. |
| 08:15 | | AnnoDomini [AnnoDomini@Nightstar-29123.neoplus.adsl.tpnet.pl] has joined #Code |
| 08:15 | | mode/#code [+o AnnoDomini] by ChanServ |
| 08:56 | | Attilla [~The.Attil@92.21.240.ns-3266] has joined #code |
| 08:56 | | mode/#code [+o Attilla] by ChanServ |
| 09:49 | | AnnoDomini [AnnoDomini@Nightstar-29123.neoplus.adsl.tpnet.pl] has quit [Ping Timeout] |
| 09:50 | | AnnoDomini [AnnoDomini@Nightstar-29123.neoplus.adsl.tpnet.pl] has joined #Code |
| 09:50 | | mode/#code [+o AnnoDomini] by ChanServ |
| 10:31 | | You're now known as TheWatcher |
| 10:51 | | Rhamphoryncus [~rhamph@Nightstar-3964.abhsia.telus.net] has quit [Quit: Rhamphoryncus] |
| 11:01 | | Thaqui [~Thaqui@121.98.166.ns-22683] has quit [Client exited] |
| 11:17 | | NSGuest-2173 [~Thaqui@121.98.166.ns-22683] has joined #code |
| 11:47 | | NSGuest-2173 [~Thaqui@121.98.166.ns-22683] has quit [Operation timed out] |
| 12:04 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has joined #Code |
| 12:04 | | mode/#code [+o gnolam] by ChanServ |
| 12:28 | | Consul [~Consul__@Nightstar-1744.dsl.sfldmi.ameritech.net] has joined #code |
| 12:28 | | mode/#code [+o Consul] by ChanServ |
| 13:52 | | Thaqui [~Thaqui@121.98.166.ns-22683] has joined #code |
| 13:52 | | mode/#code [+o Thaqui] by ChanServ |
| 14:54 | <@TheWatcher> | Ugh |
| 14:58 | <@TheWatcher> | This would be so much easier if ther was a way to tell perl's regexp engine "Match from $stok to $etok, and if any $stok are encountered before an $etok, the number of $etoks must match the number of $stoks" |
| 14:59 | | AnnoDomini [AnnoDomini@Nightstar-29123.neoplus.adsl.tpnet.pl] has quit [Ping Timeout] |
| 15:05 | | AnnoDomini [AnnoDomini@Nightstar-28353.neoplus.adsl.tpnet.pl] has joined #Code |
| 15:05 | | mode/#code [+o AnnoDomini] by ChanServ |
| 15:08 | | AnnoDomini [AnnoDomini@Nightstar-28353.neoplus.adsl.tpnet.pl] has quit [Ping Timeout] |
| 15:10 | | * TheWatcher ponders doing two passes, one that does s/<pre>/sprintf("<pre:%02d>", $count++)/e; s{</pre>}{sprintf("</pre:%02d>", --$count)}e; and then another that just pulls out the matches I need... hmm |
| 15:12 | | AnnoDomini [AnnoDomini@Nightstar-28353.neoplus.adsl.tpnet.pl] has joined #Code |
| 15:12 | | mode/#code [+o AnnoDomini] by ChanServ |
| 16:08 | <@TheWatcher> | Which, of course, won't work *headslaps, modifies it so it will* |
| 16:21 | | Derakon[work] [~Derakon@Nightstar-6042.ucsf.edu] has joined #code |
| 16:40 | < Derakon[work]> | I really wonder why Sebastien thought it was a good idea to dedicate nearly 500 lines of C++ code to an LCD-style clock for the UI for a micrsocope. |
| 16:49 | | * Chi twitches |
| 16:50 | < Chi> | well, of course a clock in a microscope would be useful - like for timing the speed of something - but that many lines seems a leetle excessive. >_> |
| 16:56 | < Derakon[work]> | That's not the point, really. |
| 16:56 | < Derakon[work]> | The point is that the computer already has a clock. There's no need to have two. |
| 16:59 | < Derakon[work]> | (These things all are using the wx library...if you didn't mind having everything in one window, I could reimplement them both in under a hundred lines of Python using PyGame and my own event handlers...) |
| 17:00 | | Thaqui [~Thaqui@121.98.166.ns-22683] has quit [Client exited] |
| 18:30 | | Rhamphoryncus [~rhamph@Nightstar-3964.abhsia.telus.net] has joined #code |
| 18:37 | < Derakon[work]> | Hullo, Rhamphoryncus. |
| 18:37 | < Rhamphoryncus> | heya Derakon[work] |
| 18:52 | < Derakon[work]> | Hmm, question for you. |
| 18:52 | < Derakon[work]> | I'm trying to track down a memory leak in some Python/Numpy code. |
| 18:53 | < Derakon[work]> | Would this code cause problems? http://paste.ubuntu.com/264565/ |
| 18:53 | < Derakon[work]> | Because every time it runs, it creates a new class definition, doesn't it? |
| 19:04 | < Derakon[work]> | Hrm...some tests seem to indicate that that assumption is false. |
| 19:09 | < Derakon[work]> | Okay, back to first assumption: there's another reference to that thing hanging around somewhere... |
| 20:14 | < Rhamphoryncus> | sorry, not paying attention |
| 20:15 | < Rhamphoryncus> | That does create a new class object each time you call it |
| 20:15 | < Rhamphoryncus> | You might need the tracing GC to collect them. Not sure |
| 20:16 | < Rhamphoryncus> | use gc.collect() to force it. Also possible to get debugging output from it |
| 20:16 | < Derakon[work]> | Well, I copied that code and ran it a few million times and it didn't seem to increase in size any. |
| 20:19 | < Rhamphoryncus> | hum. Looks like the closure only includes the variable names you use, so there's no cycle to the class name |
| 20:23 | < Rhamphoryncus> | But it does require the tracing GC |
| 20:23 | < Rhamphoryncus> | It's possible that the tracing GC triggered more quickly on the smaller footprint of your test |
| 20:23 | < Rhamphoryncus> | Whereas the real code has a bigger footprint, so it doesn't GC as often |
| 20:24 | < Derakon[work]> | Hmm...it's also possible that Python 2.5 vs. 2.4 makes a difference. |
| 20:24 | < Derakon[work]> | I'm running 2.5 on my lappy, but the actual installation is 2.4. |
| 20:25 | < Derakon[work]> | The really annoying bit here is that I can't actually test the microscope unless nobody needs it to do science. |
| 20:29 | < Rhamphoryncus> | oh, for your small case try doing gc.set_debug(gc.DEBUG_STATS) before starting it |
| 20:30 | < Rhamphoryncus> | Should see if that's causing it to clean them up |
| 20:30 | < Derakon[work]> | It does seem to be triggering rapidly. |
| 20:31 | < Rhamphoryncus> | gc: done, 13 unreachable, 0 uncollectable, 0.0123s elapsed. |
| 20:31 | < Derakon[work]> | Goddammit, I wish Python would allow me to redirect streams properly. "python classinfunction.py 2>&1 > /tmp/t.txt" still dumps output to the console! |
| 20:31 | < Rhamphoryncus> | Any unreachables like that? |
| 20:31 | < Derakon[work]> | Generally several hundred, yes. |
| 20:31 | < Rhamphoryncus> | o.O I don't think python can break that |
| 20:31 | < Rhamphoryncus> | okay, then the tracing GC is collecting stuff |
| 20:32 | < Derakon[work]> | Here's the test script I'm running: http://paste.ubuntu.com/264605/ |
| 20:34 | < Rhamphoryncus> | you can add gc.DEBUG_LEAKS if you want to see what it's collecting, although that also includes a flag that saves all the leaked objects |
| 20:34 | < Derakon[work]> | Ehh, in the test script I know what it's collecting, since there's so little in it. |
| 20:34 | <@AnnoDomini> | Hmm. Anyone here know anything about raster scan? |
| 20:35 | < Rhamphoryncus> | More for curiosity's sake. You get to see a bunch of objects that compose a class ;) |
| 20:35 | < Derakon[work]> | Ahh. |
| 20:35 | <@AnnoDomini> | Particularly, why that is apparently used in LCD monitors as well as CRT monitors. |
| 20:35 | < Rhamphoryncus> | tuples and cells and member_descriptors, oh my! |
| 20:35 | < Derakon[work]> | You sure about that DEBUG_LEAKS? "gc.set_debug(gc.DEBUG_LEAKS)" threw an AttributeError. |
| 20:36 | < Rhamphoryncus> | PEBKAC. DEBUG_LEAK |
| 20:37 | < Rhamphoryncus> | How many times are you creating these classes? Classes in python are kinda heavy |
| 20:37 | < Derakon[work]> | Shouldn't be too often. Once every ten minutes, I think it was. |
| 20:37 | < Rhamphoryncus> | how long do you run for? |
| 20:38 | < Derakon[work]> | This particular run was two hours, IIRC. |
| 20:38 | < Derakon[work]> | Might've been more. |
| 20:38 | < Rhamphoryncus> | 12 times.. shouldn't matter |
| 20:38 | < Rhamphoryncus> | You could do gc.disable() on your test, then let it do a few thousand of them |
| 20:41 | <@McMartin> | 12:35 <@AnnoDomini> Particularly, why that is apparently used in LCD monitors as well as CRT monitors. |
| 20:41 | <@McMartin> | If I had to guess, it's because you have to get the pixels through the little data pipe *somehow* |
| 20:41 | <@McMartin> | It may as well be in raster order |
| 20:41 | <@AnnoDomini> | Er, I mean why the blanking? |
| 20:41 | <@McMartin> | Well, traditionally, that's where the magic happens |
| 20:42 | <@McMartin> | We have decades of experiences using blanking periods to avoid tearing artifacts |
| 20:42 | <@AnnoDomini> | I'm not sure I can write that in my paper. 'Magic' is one of those words that draws attention. :P |
| 20:42 | < Rhamphoryncus> | AnnoDomini: I don't understand the question.. are you talking about VGA? |
| 20:43 | < Derakon[work]> | Hm, correction. I just got a copy of the debug log, and that code's getting called 888 times. |
| 20:43 | < Rhamphoryncus> | Derakon[work]: heh |
| 20:43 | <@AnnoDomini> | Rhamphoryncus: Is what happens in TV VGA? |
| 20:43 | < Rhamphoryncus> | .. TV? |
| 20:43 | <@AnnoDomini> | Television? |
| 20:43 | < Rhamphoryncus> | TV != VGA |
| 20:43 | <@AnnoDomini> | That's my point. AFAIK, VGA is just a resolution/display standard. |
| 20:44 | <@AnnoDomini> | The technology of getting the picture on the screen is something else, IIRC. |
| 20:44 | < Rhamphoryncus> | I don't understand what you're asking about. "raster" is just pixelization |
| 20:44 | <@AnnoDomini> | http://en.wikipedia.org/wiki/Raster_scan |
| 20:45 | < Rhamphoryncus> | Are you asking why it uses scan lines? |
| 20:45 | <@AnnoDomini> | Well, sure. Shouldn't the way LCD is made allow random access to pixels? |
| 20:46 | < Rhamphoryncus> | ahh |
| 20:46 | < Derakon[work]> | Presumably to maintain compatibility with cathode-ray-tube TVs. |
| 20:46 | <@AnnoDomini> | Derakon[AFK]: :D |
| 20:46 | < Derakon[work]> | Which had a photon gun that could only excite one pixel at a time. |
| 20:46 | < Rhamphoryncus> | one moment |
| 20:47 | <@AnnoDomini> | "Reverse compatibility with CRT" is a great answer to the tricky question I'm trying to plan against. |
| 20:47 | < Rhamphoryncus> | I think the general answer is they're designed for bulk transfer. There's no use case for random access |
| 20:48 | < Rhamphoryncus> | And they're not stable if you don't continually refresh them |
| 20:49 | <@McMartin> | Right |
| 20:49 | <@McMartin> | What I'm saying is, you still need a VBlank because if you don't have one you'll get tearing |
| 20:49 | < Derakon[work]> | You could theoretically write a lightweight LCD display protocol for situations where large portions of the display are static, I guess. |
| 20:50 | < Rhamphoryncus> | McMartin: VBlank is a different issue, isn't it? |
| 20:50 | <@McMartin> | You could also have the monitor do double buffering or something and have a flip command |
| 20:50 | < Derakon[work]> | But as McM notes, if you, for example, are shooting a moving object, and you only update half of the screen, you can get a disconnect between the updated and unupdated portions. |
| 20:51 | <@McMartin> | Rhamphoryncus: VBlank and HBlank are the primary features of raster scan, I'd think. |
| 20:51 | <@McMartin> | The idea of "why transmit a picture in row-major order" doesn't strike me as terribly exciting. =P |
| 20:51 | <@McMartin> | Because seriously, it's perfectly legitimate to answer that one "Well, why the Hell not?" |
| 20:51 | <@AnnoDomini> | BTW, does 'personal use only' allow one to use the content in a paper? With a citation reference, et al. I'm not sure about the legalities. |
| 20:52 | <@AnnoDomini> | McMartin: I'm not sure the proffs will take well to that. :P |
| 20:52 | < Rhamphoryncus> | Derakon[work]: you could, but that'd be more about the transfer method, ie VGA/DVI/etc. The actual updating would be from a ram or flash chip. In fact, the XO-1 has a power saving mode that shuts off the CPU and ram while keeping the display up |
| 20:52 | < Derakon[work]> | Rhamphoryncus: further correction: the logfile contained logs from previous experiments. Actual results for that run are 280 passes before hitting the one that failed. |
| 20:52 | <@McMartin> | AnnoDomini: Which is why you wouldn't ask the question that way. =P |
| 20:53 | < Derakon[work]> | The microscope was looking at 8 sites; each site got a file generated once every 10 minutes. |
| 20:53 | < Rhamphoryncus> | McMartin: they're features of CRT and VGA. I don't know how much they exist on LCD and DVI. Obviously, it has to reset between rows, but that could be trivial |
| 20:53 | <@McMartin> | And re: "personal use only": Any results brief enough that you can just drop a quick citation in are probably small enough to be fair use anyway, which means that copyright holders get no say in what you do. IANAL, YMMV, etc. |
| 20:54 | <@McMartin> | Resetting between rows is HBlank, which I'm not sure about. |
| 20:54 | <@AnnoDomini> | I just want a picture. |
| 20:54 | <@McMartin> | Resetting between *screens* is VBlank, and you need some kind of down time to let the next frame get prepped regardless. |
| 20:54 | < Rhamphoryncus> | Derakon[work]: doesn't sound like it should be significant, unless you're pretty damn tight on memory |
| 20:54 | <@McMartin> | AD: Oh, a pic. Hm. Yeah, probably OK unless you're commercially publishing the thing. |
| 20:55 | <@AnnoDomini> | I'm not. If I have my way, the paper will never be read twice. |
| 20:55 | <@McMartin> | I'm pretty sure CC-NC-BY allows academic use |
| 20:55 | < Rhamphoryncus> | You can already be prepping the next frame while sending the old one |
| 20:55 | < Derakon[work]> | Rhamphoryncus: Yeah, I'm starting to lean towards "the memory leak is elsewhere, but isn't destructive until we get to this line". |
| 20:55 | < Derakon[work]> | Since when it fails, it always fails on that line. |
| 20:55 | <@McMartin> | Rhamphoryncus: If you have a dedicated graphics chip, maybe. |
| 20:55 | < Rhamphoryncus> | And since you may be limited by the bandwidth of your transport (DVI/VGA), at higher resolutions there's a strong motivations to continuously send out data |
| 20:55 | <@McMartin> | I know of several off the top of my head that exploit raster scan to get their effects. |
| 20:56 | < Rhamphoryncus> | Derakon[work]: you get a MemoryError from the class definition? Weird |
| 20:56 | < Derakon[work]> | No, I don't get a MemoryError. |
| 20:57 | <@McMartin> | If you're going that route, there's still a VBlank period, it's just that it's the same length as the distance between any two pixels. |
| 20:57 | < Derakon[work]> | I get a Visual Studio "would you like to see a debugger" message. |
| 20:57 | < Derakon[work]> | Remember, the app is C++ with Python hooks, not the other way around. |
| 20:57 | <@McMartin> | Attach to the process with WinDbg, if VS isn't cutting it |
| 20:57 | < Rhamphoryncus> | Shouldn't really be calling it a VBlank. VBlank is about time it *physically* takes to move the electron gun from the bottom to the top |
| 20:58 | < Rhamphoryncus> | Derakon[work]: ahhh. Nothing to do with python then. Probably memory corruption |
| 20:58 | < Derakon[work]> | :( |
| 20:58 | <@AnnoDomini> | Thanks for the help, guys. |
| 20:58 | <@McMartin> | On the programming side, a distinction without a difference |
| 20:58 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has quit [Quit: Bleh] |
| 20:58 | < Rhamphoryncus> | Could be a refcount bug. Releasing a common object early can do weird things |
| 20:59 | < Derakon[work]> | I really wish this was Python with C++ instead of the reverse. |
| 21:01 | | * Derakon[work] goes back to cataloguing what the C++ portion is doing, with the goal of replacing it wholesale. |
| 21:02 | < Rhamphoryncus> | Derakon[work]: it's possible to compile python without its own malloc wrappers, then use a generic tool to detect double frees |
| 21:02 | < Derakon[work]> | Rhamphoryncus: wouldn't a double free be fairly predictable, though? As a general rule? |
| 21:02 | < Derakon[work]> | Whereas sometimes this works and sometimes it doesn't; the only consistent bit is the last log message we see beforoe it does. |
| 21:03 | < Rhamphoryncus> | and fwiw, *VSync* avoids tearing, not VBlank. VSync is the switch between frames, VBlank is a large gap during the switch common to CRT |
| 21:04 | < Rhamphoryncus> | or rather, VSync is the act of synchronizing software with the switch |
| 21:06 | < Rhamphoryncus> | hmm interesting tidbit: it looks like there are no DVI CRTs. Or rather, DVI-D, as it is possible to send VGA signals over a DVI-A connector |
| 21:08 | < Rhamphoryncus> | doh. Looks like DVI-D does still use blanking intervals though.. god knows why |
| 21:10 | <@McMartin> | If you're using a display kernel like the old graphics processors did, you don't have time to prep the next frame during the current one |
| 21:10 | <@McMartin> | You're too busy racing the beam |
| 21:10 | <@McMartin> | The fact that the beam isn't a real beam is irrelevant |
| 21:11 | < Rhamphoryncus> | implies it was included for CRT: http://www.prophotohome.com/forum/pro-photo-wiki-select-articles/73306-dual-link -dvi.html |
| 21:11 | <@McMartin> | (That is, you're computing the *current* frame as it's sent) |
| 21:11 | <@McMartin> | (Then you use the blanking interval for more major computation) |
| 21:11 | <@McMartin> | Are they configurable? |
| 21:11 | < Rhamphoryncus> | nope |
| 21:11 | <@McMartin> | Does HDMI use it? |
| 21:11 | < Rhamphoryncus> | HDMI = DVI |
| 21:12 | < Rhamphoryncus> | there are some standards for other blanking intervals though |
| 21:13 | < Derakon[work]> | ...sigh, why are you using OpenGL to render user interface widgets? |
| 21:13 | < Derakon[work]> | And re-doing the draw logic everywhere? |
| 21:14 | < Derakon[work]> | I really, really want to just re-write this all in PyGame, though I should use wxPython instead probably. |
| 21:14 | <@McMartin> | Aiee, wx |
| 21:14 | < Derakon[work]> | That's what the UI's using. |
| 21:15 | <@McMartin> | I remain unconvinced that wx is actually a UI lib, and not merely a test suite for compiler error messages |
| 21:15 | < Derakon[work]> | I could switch to PyQt if I were willing to rewrite everything from the ground up. |
| 21:15 | < Derakon[work]> | Heh. |
| 21:15 | < Derakon[work]> | (Or I could rewrite everything in PyGame! I already know how to use all that! Of course, I'd have trouble supporting multiple windows and OS-appropriate ticky boxes and so on...) |
| 21:16 | <@McMartin> | My guess is they were using OpenGL because they couldn't get wx's actual widgetry to work~ |
| 21:16 | < Derakon[work]> | But here's the thing -- the clock and seven-segment-display widgets use wx to draw and work fine. |
| 21:17 | < Derakon[work]> | The histogram and the camera display, though, use OpenGL. |
| 21:17 | < Derakon[work]> | I guess because they're rasterized? |
| 21:17 | <@McMartin> | It would make more sense if they weren't |
| 21:17 | <@McMartin> | I'm not actually accusing them of fraud, mind you |
| 21:17 | <@McMartin> | I've personally seen two wx programs that run |
| 21:17 | < Derakon[work]> | Pffft. |
| 21:20 | < Derakon[work]> | ...wow, okay, the code for the camera view is like a post-apocalyptic version of my old TerrestrialObject class if I'd had, oh, three years' less experience in software development. |
| 21:20 | < Rhamphoryncus> | Looks like HDMI uses VBlank and HBlank for sending other data in packeted form. Audio and whatnot |
| 21:21 | < Derakon[work]> | The OnMouse function is 307 lines long. |
| 21:22 | < Rhamphoryncus> | Note that HDMI is signal-compatible with DVI-D. Those are literally the same VBlank and HBlank that DVI-D had on the assumption it'd use them for CRT, but never did. DVI-D just ignores the extra HDMI crap (or it gets turned off, not sure) |
| 21:47 | | * AnnoDomini scratches head. |
| 21:47 | <@AnnoDomini> | I seem to have two conflicting definitions of how raster scan works. |
| 21:48 | <@AnnoDomini> | Is the image-making turned on when the line is sloping, or when it's going horizontally? |
| 21:49 | <@AnnoDomini> | Or is it vendor-specific? |
| 22:00 | | * Derakon[work] sighs. "This code uses names like MyApp and MyFrame." |
| 22:02 | <@AnnoDomini> | Sounds like somebody is lazy. |
| 22:05 | < Derakon[work]> | Or just didn't realize that coming up with a more descriptive name is useful. |
| 22:05 | < Derakon[work]> | TMK this guy never got formal training in programming. |
| 22:06 | < Derakon[work]> | Wanna see the UI for the program whose source code I'm reading? http://derakon.dyndns.org/~chriswei/temp/omxscreenshot.PNG |
| 22:07 | <@TheWatcher> | ... oh, good lord |
| 22:07 | < Derakon[work]> | That's intuitive, right? Right? |
| 22:08 | < Derakon[work]> | I hadn't noticed that one of the buttons is labeled "Pete" before... |
| 22:10 | <@TheWatcher> | Yep, completely intuitive |
| 22:11 | < Derakon[work]> | Also note the "Old OMX (new)" in the bar at the bottom. |
| 22:12 | <@TheWatcher> | (the coder didn't work on Blender by any chance, did he~) |
| 22:12 | < Derakon[work]> | Har, funny guy. :p |
| 22:36 | | * Derakon[work] eyes this line: for(int i=0;i<NCAMS;i++) if(wxGetApp().cam_connected(i)) wait=true; |
| 22:46 | <@McMartin> | This is why HCI is its own specialty~ |
| 22:47 | <@McMartin> | Crypt is dark |
| 22:47 | <@McMartin> | Grue nommage chance: 97% |
| 22:51 | <@AnnoDomini> | Derakon[AFK]: What does this program do, anyway? |
| 22:51 | < Derakon[work]> | It's the user interface to a high-tech microscope. |
| 22:52 | < Derakon[work]> | The "Crypt" in this case is a special closet designed to be lighttight when the door is closed. |
| 22:55 | < Rhamphoryncus> | AnnoDomini: CRT actually always slopes. It's a very shallow slope while shooting electronics, a steeper slope when moving to the next line |
| 22:56 | <@AnnoDomini> | Mm'kay. |
| 22:57 | < Rhamphoryncus> | a zig-zag pattern |
| 22:58 | < Rhamphoryncus> | (although personally, I don't know why they couldn't rotate the whole thing ever-so-slightly so that the drawing portion is truly horizontal) |
| 23:03 | < Derakon[work]> | Man, I've only worked with Python for a bit over a half-year, and already I'm completely in favor of fully-specified namespaces. |
| 23:04 | < Derakon[work]> | I'm finding C++ includes to be confusing because I can't later tell how a library is used except by looking at what the library defines and what the file including that library uses. |
| 23:04 | <@McMartin> | Heh |
| 23:04 | <@McMartin> | Proper C++ namespace discipline gives it back~ |
| 23:04 | < Derakon[work]> | Yes, but nobody uses that. |
| 23:04 | <@TheWatcher> | which requires... yes ¬¬ |
| 23:05 | <@McMartin> | I never understood why people considered Java's requirement for namespaces and files to match to be a liability, tbqh |
| 23:05 | <@Vornicus> | Nor I. It is quite natural. |
| 23:05 | <@Vornicus> | (though Java is overly wordy) |
| 23:06 | <@McMartin> | (They were trying for a fully global namespace, which, given where they are most often used and deployed, turns out to be reasonable.) |
| 23:06 | <@TheWatcher> | In general, I have no real problem with it. But there's a few cases (like my VFS code) where distributing the classes over several headers because of language requirement would be a pain in the arse |
| 23:06 | <@McMartin> | (It wasn't until about Java 5, though~) |
| 23:06 | < Derakon[work]> | To be fair, Jetblade's code would be very wordy if the imports weren't done dynamically using a lot of implied paths. |
| 23:06 | < Derakon[work]> | E.g. "import data.objects.creatures.player.player" |
| 23:07 | < Derakon[work]> | As it stands, though, you just say "I want a creatures/player object" and the game goes and gets it for you. |
| 23:08 | <@TheWatcher> | I tend to prefer to arrange the code how I find it easiest, and just make bloody sure it's extensively documented. |
| 23:08 | < Rhamphoryncus> | IMO, the only way to justify not explicitly importing every name you want is if the IDE does it for you.. in which case it's still explicit, just automated |
| 23:09 | | * Vornicus tries to learn enough assembler to figure out the "right" way to do array-oid indexing. |
| 23:09 | <@McMartin> | mov %eax, [%ebx + 4*%edi] |
| 23:10 | < Derakon[work]> | 4 being the size of the element in the array? |
| 23:10 | <@McMartin> | Yes, but there are only a limited number of constants permitted. |
| 23:10 | <@McMartin> | The load-indexed instruction has dest, base, index, and index-multiple as parameters. |
| 23:11 | | * Vornicus actually meant on something other than x86. |
| 23:11 | <@McMartin> | Ah. |
| 23:11 | <@AnnoDomini> | M6800. :P |
| 23:11 | <@McMartin> | 6502~ |
| 23:11 | <@TheWatcher> | ZX80?~ |
| 23:12 | <@McMartin> | ZX80 is basically x86~ |
| 23:12 | < Derakon[work]> | PDP-11! |
| 23:12 | <@Vornicus> | Like, say, a RISC machine. |
| 23:12 | <@McMartin> | Oh. |
| 23:12 | <@McMartin> | MIPS is LD $dst, $src($index), I believe. |
| 23:12 | <@McMartin> | Where index is always a byte offset. |
| 23:13 | <@AnnoDomini> | CDC 6600. :p |
| 23:19 | | * Derakon[work] discovers ringbuffer.hh and ringbuffer.cpp. |
| 23:19 | < Derakon[work]> | Which appear to define a dumb container class. Like, it's just a container for some data. |
| 23:19 | < Derakon[work]> | The class that uses it does all the work of maintaining it as a ring buffer. |
| 23:19 | < Derakon[work]> | :gonk: |
| 23:20 | <@TheWatcher> | Impressive |
| 23:25 | <@Vornicus> | Der: your predecessor seems to enjoy giving you fail. |
| 23:26 | < Derakon[work]> | I can't bring myself to hate him overmuch...not yet, anyway. ?.? |
| 23:26 | < Derakon[work]> | His failing was in being more a physicist than a computer scientist. |
| 23:26 | < Derakon[work]> | (Much more) |
| 23:27 | < Derakon[work]> | And while I wish that he'd hired someone to design the program to his specifications, I don't think he knew his specifications; the program probably changed a lot while it was being developed. |
| 23:33 | | * Derakon[work] encounters some C++ code dealing with sockets. |
| 23:33 | < Derakon[work]> | And here we get into an area where I don't feel qualified to say "yes, this code can be replaced by Python" or "no, this code needs to stay". |
| 23:34 | < Derakon[work]> | Especially since the class in question implements and/or inherits from wxThread. |
| 23:36 | < Derakon[work]> | On the flipside, this code is actually reasonably well-commented. |
| 23:41 | < Derakon[work]> | while(!TestDestroy()) |
| 23:41 | < Derakon[work]> | { |
| 23:41 | < Derakon[work]> | if ( TestDestroy() ) |
| 23:41 | < Derakon[work]> | return NULL; |
| 23:41 | < Derakon[work]> | if ( TestDestroy() ) |
| 23:41 | < Derakon[work]> | return NULL; |
| 23:41 | < Derakon[work]> | (...) |
| 23:42 | | * TheWatcher blinks |
| 23:46 | < Namegduf> | ...what? |
| 23:46 | < Namegduf> | Is there any kind of explanation for that? |
| 23:47 | < Derakon[work]> | Of course not. |
| 23:47 | < Derakon[work]> | Oooh, how about this one? |
| 23:47 | < Derakon[work]> | LABLE: ; |
| 23:50 | < Rhamphoryncus> | after boggling at that I now wonder if that should be named TryDestroy() |
| 23:50 | < Rhamphoryncus> | Still insane, but at least that'd explain the loop |
| 23:52 | | * Derakon[work] eyes the documentation for TestDestroy, which is a wxThread function. |
| 23:52 | < Derakon[work]> | "This function should be called periodically by the thread to ensure that calls to Pause() and Delete() will work." |
| 23:52 | < Derakon[work]> | In other words, wxThreads use cooperative multitasking! |
| 23:53 | < Derakon[work]> | "If it returns true, the thread should exit as soon as possible. Notice that under some platforms (POSIX), implementation of Pause() also relies on this function being called, so not calling it would prevent both stopping and suspending thread from working. " |
| 23:53 | < Derakon[work]> | Docs, for the curious: http://docs.wxwidgets.org/trunk/classwx_thread.html#9a3acec44b06b2a2430c5659991a 3eac |
| 23:53 | < Rhamphoryncus> | heh |
| 23:54 | < Rhamphoryncus> | So, delete the loop and put a single call in |
| 23:54 | < Derakon[work]> | Well, there was more in the loop than just TestDestroy. |
| 23:54 | < Rhamphoryncus> | Ahhh |
| 23:54 | < Derakon[work]> | (Hence the "...") |
| 23:55 | < Rhamphoryncus> | Is that the main loop then? |
| 23:55 | < Derakon[work]> | It's a loop that reads image data off a socket. |
| 23:57 | < Rhamphoryncus> | What's after the loop though? Just "return NULL;"? (I hope) |
| 23:59 | < Derakon[work]> | Yeah. |
| 23:59 | < Derakon[work]> | So really, those "return NULL" statements should be break statements, but that's hardly the greatest of my worries. |
| 23:59 | < Rhamphoryncus> | I'd go the other way and make it while (True) |
| --- Log closed Fri Sep 04 00:00:23 2009 |