| --- Log opened Wed Oct 17 00:00:59 2012 |
| 00:03 | | OrthiaLap [orthia@Nightstar-6ca59a6f.callplus.net.nz] has quit [Ping timeout: 121 seconds] |
| 00:25 | | You're now known as TheWatcher[T-2] |
| 00:27 | | You're now known as TheWatcher[zZzZ] |
| 00:33 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 00:41 | | Derakon[AFK] is now known as Derakon |
| 00:47 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 00:47 | | mode/#code [+o himi] by ChanServ |
| 00:47 | < syksleep> | Rhamphoryncus: nothin more complex than downloading a zip and using ClockworkMod :P |
| 00:47 | < syksleep> | well, for me, anyway |
| 00:47 | | * syksleep cuddles her gnex |
| 00:47 | < Rhamphoryncus> | Well, at this point I'm just going to do a wipe and fresh install |
| 00:48 | < Rhamphoryncus> | Since I've found nothing to clarify the update procedure, and I can't tell if it's even available with this branch |
| 00:49 | < syksleep> | well, depends if you're using anything special |
| 00:49 | < Rhamphoryncus> | define special :P |
| 00:49 | < syksleep> | but 'updating' CM is just downloading the .zip, flashing it using ClockworkMod, wiping Dalvik cache and rebooting |
| 00:49 | < Rhamphoryncus> | nothing I've seen so far seems "normal" |
| 00:50 | < syksleep> | Rhamphoryncus: have you got ClockworkMod installed, with CM already on it? |
| 00:51 | | * syksleep might update her ROM while she's at it |
| 00:51 | < Rhamphoryncus> | I've yet to understand the partition architecture, except to know it varies a fair bit, and that it was changed since I installed |
| 00:51 | < Rhamphoryncus> | Yup |
| 00:52 | < syksleep> | owO I don't think that you need to partition anything... |
| 00:52 | < syksleep> | not sure |
| 00:52 | < Rhamphoryncus> | Afaik it reparitioned some when I installed it |
| 00:52 | < syksleep> | the non-Samsung Nexus phones and not-HTC sometimes have derptarded devs |
| 00:53 | < Rhamphoryncus> | but not all of it. Apparently the "sdcard" partition (which isn't an sdcard, and wouldn't be even if I had one) stayed the same.. or maybe I'm confusing it with another partition |
| 00:53 | < Rhamphoryncus> | it's a galaxy s3 |
| 00:53 | < syksleep> | uhhh yes |
| 00:53 | < syksleep> | you have two sections of memory |
| 00:53 | < syksleep> | the ROM and the user partition |
| 00:53 | < syksleep> | the ROM is like ~2GB or something, and holds Android and apps |
| 00:53 | < syksleep> | the rest shows up as 'sdcard' |
| 00:54 | < syksleep> | wait does the S3 have removable memory? |
| 00:54 | < Rhamphoryncus> | You mean flash memory? |
| 00:54 | < Rhamphoryncus> | yes, I just don't have a card |
| 00:54 | < syksleep> | well it seems that generally sdcard shows up as that |
| 00:54 | < syksleep> | so that apps don't break |
| 00:54 | < syksleep> | and then the SD card would show up as sdcard0 or something |
| 00:55 | < syksleep> | /sdcard is old in ICS, it's all under /storage/ now |
| 00:55 | < Rhamphoryncus> | Hmm, I've seen sdcard0 mentioned by apps |
| 00:55 | < Rhamphoryncus> | huh |
| 00:55 | < Rhamphoryncus> | Funny: the CM wiki mentions neither: http://wiki.cyanogenmod.com/wiki/Overview_of_Modding#Common_Partitions |
| 00:56 | < Rhamphoryncus> | I saw mention that the repartition involves adding /datadata and reworking what /data is |
| 00:57 | < syksleep> | ...I might recommend wiping it and starting again if they've switched the partition table from under you |
| 00:57 | < Rhamphoryncus> | Wouldn't that also nuke the "sdcard", presumably where the new rom is stored? |
| 00:58 | < Rhamphoryncus> | Oh, they're switching to LVM |
| 01:04 | < syksleep> | lol |
| 01:05 | < Rhamphoryncus> | god damnit, my wireless won't even stay on for 30 seconds |
| 01:06 | < Rhamphoryncus> | and they've gleefully disabled the usb mass storage option. Which normally I'd be fine with, but since I have no way to get my backup off the device.. |
| 01:06 | < syksleep> | uh |
| 01:06 | < syksleep> | try um |
| 01:06 | < syksleep> | SSHDroid |
| 01:10 | | * syksleep flops off to work |
| 01:10 | | syksleep is now known as sykwerk |
| 01:10 | | Attilla [Obsolete@Nightstar-c0d703de.as43234.net] has quit [Ping timeout: 121 seconds] |
| 01:18 | < Rhamphoryncus> | Oh right, usb mass storage doesn't allow file sharing. It exports the partition itself, which restricts it to the horrid dos format |
| 01:22 | < Rhamphoryncus> | wifi options would be more useful if the phone's wifi would stay on/come back on |
| 01:41 | < Rhamphoryncus> | It seems to stay on while a download is active |
| 01:41 | < Rhamphoryncus> | So I may just get this done |
| 01:42 | < Rhamphoryncus> | damnit, I think it failed |
| 01:42 | < Rhamphoryncus> | it didn't SAY it failed, but it wasn't fully transferred |
| 01:44 | < Rhamphoryncus> | md5sums don't match |
| 01:49 | < Rhamphoryncus> | got it started again |
| 01:50 | < Rhamphoryncus> | How the heck am I going to transfer a backup off? It's much bigger :( |
| 01:53 | <&Derakon> | Quick sanity check: making a backup onto an external drive. "rsync -avvPh files target"? |
| 02:01 | < Rhamphoryncus> | failed again |
| 02:13 | < Rhamphoryncus> | my desktop doesn't see it when plugged in as usb >.< |
| 02:22 | | * Derakon compresses the old backup he had, watches files scroll by, snerks at the pause at spacecollage-this-is-a-huge-file-im-not-kidding.tif. |
| 02:23 | <&Derakon> | (That being the full-resolution file for the 5'x5' print I made) |
| 02:42 | < sykwerk> | heh |
| 02:42 | < sykwerk> | i've not used rsync much |
| 02:42 | < sykwerk> | i'm using it for syncing my new website right now |
| 02:42 | < sykwerk> | i was like "...wait, it can do checksum based file copying over ssh? why have I not been using this for EVERYTHING" |
| 02:43 | < sykwerk> | since to-the-minute uploads are possible which is beautiful @v@ |
| 02:57 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 03:03 | | FurryHelix [tamber@furryhelix.co.uk] has joined #code |
| 03:03 | | Tamber [tamber@furryhelix.co.uk] has quit [Connection reset by peer] |
| 03:07 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 03:07 | | mode/#code [+o himi] by ChanServ |
| 03:23 | | OrthiaLap [orthia@Nightstar-6ca59a6f.callplus.net.nz] has joined #code |
| 04:15 | | Kindamoody is now known as Kindamoody|breakfast |
| 04:58 | | Kindamoody|breakfast is now known as Kindamoody |
| 05:00 | | celticminstrel [celticminst@Nightstar-05d23b97.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 05:07 | | iospace is now known as iospacedout |
| 05:51 | | mac [NSwebIRC@Nightstar-fe8a1f12.il.comcast.net] has joined #code |
| 05:54 | < mac> | do any of you guys over-clock your cpu's? |
| 05:55 | < sykwerk> | I overclocked my raspberry pi once! |
| 06:39 | | Derakon is now known as Derakon[AFK] |
| 07:00 | | Syloq_Home [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Client closed the connection] |
| 07:15 | | ErikMesoy|sleep is now known as ErikMesoy |
| 07:31 | | OrthiaLap [orthia@Nightstar-6ca59a6f.callplus.net.nz] has quit [Ping timeout: 121 seconds] |
| 07:52 | | mac [NSwebIRC@Nightstar-fe8a1f12.il.comcast.net] has left #code [""] |
| 08:08 | | Attilla [Obsolete@Nightstar-c0d703de.as43234.net] has joined #code |
| 09:22 | < Rhamphoryncus> | So I finally got the rom copied over and the backups copied off (by moving closer to the router and setting it to not shut off the screen while charging), rebooted, cleared cache, installed the rom, installed the gapps zip, rebooted.. and everything was intact. Nothing gave an indication of a partitioning change, all my apps and data were there without restoring from backups |
| 09:23 | < Azash> | Magic |
| 09:26 | < Rhamphoryncus> | So the information I read about partition changes, which was talking about this rom, was wrong. Perhaps an autoupdater script using it? |
| 09:27 | | * Azash scrolls up to read |
| 09:29 | < sykwerk> | Rhamphoryncus: sure it didnt mean 'coming from another rom'? |
| 09:30 | < Rhamphoryncus> | nope. It clearly mentioned updating within the rom and that at a certain date (last month) the partition format was changed |
| 09:31 | < sykwerk> | lol |
| 09:31 | < sykwerk> | nobody_knows.gif |
| 09:34 | | You're now known as TheWatcher |
| 09:56 | | McMartin [mcmartin@Nightstar-3895ee8e.pltn13.sbcglobal.net] has quit [Ping timeout: 121 seconds] |
| 09:56 | | McMartin [mcmartin@Nightstar-3895ee8e.pltn13.sbcglobal.net] has joined #code |
| 09:56 | | mode/#code [+ao McMartin McMartin] by ChanServ |
| 09:58 | | Rhamphoryncus [rhamph@Nightstar-cc6253d6.abhsia.telus.net] has quit [Client exited] |
| 10:24 | | sykwerk is now known as Syk |
| 10:31 | | Kindamoody is now known as Kindamoody|out |
| 11:35 | < AnnoDomini> | http://www.netfunny.com/rhf/jokes/91q3/cerrors.html |
| 11:40 | | OrthiaLap [orthia@Nightstar-6ca59a6f.callplus.net.nz] has joined #code |
| 11:49 | | Moltare [Moltare@583787.FF2A18.190FE2.4D81A1] has quit [Ping timeout: 121 seconds] |
| 11:52 | | Moltare [Moltare@583787.FF2A18.190FE2.4D81A1] has joined #code |
| 12:10 | | Attilla [Obsolete@Nightstar-c0d703de.as43234.net] has quit [Ping timeout: 121 seconds] |
| 12:13 | | Attilla [Obsolete@Nightstar-c0d703de.as43234.net] has joined #code |
| 12:56 | | OrthiaLap [orthia@Nightstar-6ca59a6f.callplus.net.nz] has quit [Ping timeout: 121 seconds] |
| 13:01 | | iospacedout is now known as iospace |
| 13:45 | | celticminstrel [celticminst@Nightstar-05d23b97.cable.rogers.com] has joined #code |
| 14:25 | < gnolam> | It works! I can't believe it! And they said imitation diamond^W capacitors weren't good enough! |
| 14:27 | <@TheWatcher> | ...? |
| 14:28 | < gnolam> | Soldered together a voltage regulator for the radiacomputer. |
| 14:28 | < gnolam> | Except there was a part missing, so I had to go dig through my own box of components to find a replacement. |
| 14:29 | < iospace> | heh |
| 14:29 | < iospace> | so today, when i get back to work, back to working on BIT! |
| 14:31 | < gnolam> | Next up: finding out the polarity of the DC connector. |
| 14:32 | <&jerith> | gnolam: That shouldn't matter. All DC connectors should go through a bridge and a regulator on the board. |
| 14:33 | < gnolam> | I kinda doubt it. |
| 14:33 | <&jerith> | I said "shouldn't", not "doesn't". |
| 14:34 | <@TheWatcher> | Hooray, radical specification change half way through development! \o/ |
| 14:34 | < gnolam> | TheWatcher: ? |
| 14:35 | <&jerith> | I've let the magic smoke out of enough hardware that assumes you're only ever going to plug the correct power supply in and will never use an identical-looking adapter from /the same manufacturer/ that supplies a different voltage at a different polarity through the same connector. |
| 14:37 | < gnolam> | The connector on the board is Murphy-safe, and I assume there's a reason. |
| 14:37 | <@TheWatcher> | gnolam: Writing a system that uses Arcane and Forbidden Incantations (ie: perl) to take student MSc thesis submissions out of moodle, apply various operations to them, mails them to a staff member to push into turnitin (*spit*) and shove them into another system that staff use to mark them. |
| 14:38 | < gnolam> | Not to mention that with a form factor of 100x72, you don't want to stick any redundant components on there. |
| 14:38 | <@TheWatcher> | except that the requirements surrounding the submission process keep changing, as do the things I need to do to put stuff into the marking system. |
| 14:38 | <&jerith> | gnolam: So it's not one of those round ones that everyone uses? |
| 14:39 | < gnolam> | On one end. And that's the one I need to check which pole is which. |
| 14:41 | | ErikMesoy [Erik@Nightstar-bd2f5f93.80-203-16.nextgentel.com] has quit [Client closed the connection] |
| 14:47 | | ErikMesoy [Erik@A08927.B4421D.B81A91.464BAB] has joined #code |
| 15:08 | | Syloq_Home [Syloq@NetworkAdministrator.Nightstar.Net] has joined #code |
| 15:25 | | * McMartin mutters at MinGW generally and CodeBlocks specifically |
| 15:27 | <&McMartin> | I really should not have to play GLEW-like games just to have programs not mangle their command-line arguments -_- |
| 15:28 | <&McMartin> | Ah, apparently MinGW fixed this later. |
| 15:28 | <&McMartin> | (-municode - for when you'd like to actually call filenames the same thing the filesystem does! \o/) |
| 15:29 | <&McMartin> | (... and not supported in this version of CodeBlocks, so I have to use a wrapper that rips its argv out of unrelated Win32 systemcalls) |
| 15:29 | <&McMartin> | That said, I also have to *legitimately* play some GLEW-style jackassery games to make this work the way I want on XP and Vista simultaneously. |
| 15:31 | <&McMartin> | Since the "look, I know I'm a 32-bit application, but don't go into 64-bit compatibility mode" wasn't added until Vista. |
| 15:31 | <&McMartin> | Now, what mighty task am I working on here that requires such effort? |
| 15:31 | <&McMartin> | ... an abstraction layer over listing directories that will work on Mac/Linux/Win32. -_- |
| 15:32 | | * AnnoDomini chuckles. "// exit if ENTER" |
| 15:35 | <&jerith> | McMartin: That isn't possible. |
| 15:35 | <&jerith> | Not without breaking on certain corner cases. |
| 15:36 | <&jerith> | (It's arguably not even possible just on Windows.) |
| 15:37 | <&jerith> | On some systems (POSIX, IIRC) filenames are byte arrays. On others, they're encoded text. |
| 15:38 | <&McMartin> | jerith: That is correct. |
| 15:38 | <&McMartin> | However, I don't have to *do* anything with it other than keep it in a form I can later pass back. |
| 15:38 | <&jerith> | Ah. |
| 15:38 | <&McMartin> | I also have no requirement that SystemPath be the same type on each system. |
| 15:38 | <&jerith> | You don't have to display it? |
| 15:38 | <&McMartin> | No. |
| 15:38 | <&jerith> | You don't have to manipulate it? |
| 15:38 | <&jerith> | You're all sorted, then. :-) |
| 15:39 | <&McMartin> | "Apply this function to each file in this directory and its subdirectories". |
| 15:39 | <&jerith> | (Assuming you're using the same family of Windows APIs on both sides.) |
| 15:39 | <&McMartin> | The only requirement is that the files be full of bytes, and I'm sorted there. |
| 15:39 | <&jerith> | What if they don't have any bytes in them? |
| 15:39 | <&McMartin> | That is a vector of bytes of size zero. |
| 15:40 | < RichyB> | You're going to run a callback, to which you pass a FILE *, at every point in the tree? |
| 15:40 | <&McMartin> | RichyB: More or less. |
| 15:40 | <&McMartin> | I'd like to use fstreams, but I can't because MinGW sucks. |
| 15:40 | <&jerith> | FILE* makes me sad. |
| 15:40 | | * RichyB can't think of anything else that you can do that's immediately portable other than passing in an open FILE*. |
| 15:40 | <&McMartin> | Yes. |
| 15:40 | <&jerith> | Mostly because I'm trying to talk to C code that wants it from pypy which doesn't have it. |
| 15:41 | < RichyB> | jerith: can you not eliminate your disquiet by using fdopen() to get a FILE* for the file descriptor that you do have? |
| 15:42 | <&McMartin> | Basically, what I really want is boost::filesystem, or three functions from it without choking on the huge amount of extra crap boost::filesystem brings in. |
| 15:42 | <&jerith> | RichyB: Yes, but then do you leak the buffers and such? |
| 15:43 | <&jerith> | I don't know what the arbitrary C code is going to want to do with the FILE*. |
| 15:43 | <&McMartin> | Arbitrary C code isn't allowed to dick around with the contents of the FILE *. |
| 15:43 | < RichyB> | the C code should be specified to either fclose() it, or leave it open for you to fclose(). |
| 15:43 | <&McMartin> | You are allowed to summon nasal demons if they try to mess with FILE's internals directly. |
| 15:44 | <&jerith> | RichyB: Yes, but there's nowhere on a Python file object to attach the FILE* so it stays around as long as the file does. |
| 15:45 | <&jerith> | So you can't get the *same* FILE* in two different calls. |
| 15:46 | < RichyB> | Uh, store it in a ctypes.pointer on an object whose __del__ calls fclose() on it. |
| 15:46 | <&jerith> | RichyB: I don't have such an object. I have a Python file object. |
| 15:48 | <&jerith> | Originally, I was trying to implement PyFile_AsFile() in the pypy CPython extension API hackery. |
| 15:48 | < RichyB> | You're entirely at liberty to subclass file. |
| 15:49 | < RichyB> | Yeah, that's not going to be easy. |
| 15:49 | <&jerith> | Which means I get a Python file object as a parameter and I cannot modify it. |
| 15:50 | <&jerith> | That API only exists because CPython 2.x has a FILE* inside its file object. |
| 15:50 | <&jerith> | This is not the case for CPython 3.x or pypy. |
| 15:50 | < RichyB> | PyFile_AsFile's documentation makes it clear that it does not in any way cause the original PyFile object to be preserved, and code that uses the FILE* should increment and decrement the PyFile's refcount. |
| 15:50 | <&McMartin> | jerith: For the record, the rule is that Windows filenames are UTF-16 unless you're writing your application wrong, Mac filenames are UTF-8, and Linux filenames are byte arrays that are *probably* UTF-8 but at the very least you get to assume match the system locale making them safe to dump directly to stdout. |
| 15:51 | < RichyB> | By "makes it clear" I mean "assuming that I'm reading this right..." ;) |
| 15:51 | <&McMartin> | (Or rather, Mac filenames come out of the OS API in whatever encoding you desire and WHY ISN'T THAT UTF-8 YOU TWAZZOCK) |
| 15:51 | <&jerith> | McMartin: What if I mount an NTFS filesystem on my Mac and it contains data written from Linux? :-P |
| 15:52 | <&McMartin> | NTFS is UTF-16 internally, but the Mac's filesystem drivers are supposed to relocalize when you check via OSX's own APIs. |
| 15:52 | <&McMartin> | Officially, it gives you an NSString and you give no fucks. |
| 15:53 | <&McMartin> | Since you don't want NSStrings, your compat layer turns it into std::string, and if you do that with any encoding other than UTF-8 - which NSString supports - you are Doing It Wrong. |
| 15:53 | <&McMartin> | Likewise, the many FSes Windows support use a variety of codepages, but if you use FindFirstFileW and FindNextFileW and CreateFileW and friends, your API is All UTF-16BE All The Time. |
| 15:54 | <&McMartin> | Well. All UTF-16, byte order is arbitrary but is BE when written to files in things like registry dumps. |
| 15:55 | <&jerith> | RichyB: Yes, but the underlying assumption is that Python will take care of the fclose() because it has the same FILE*. If it can't, because there's no FILE* until you create one for the C code, there's nobody to deallocate it. |
| 15:55 | <&jerith> | So you leak the buffers or whatever. |
| 15:56 | <&jerith> | This time around I'm using cffi which allows a more sensible approach. |
| 15:57 | < RichyB> | jerith: ah. Yeah, "Python will take care of the fclose()" is the problematic bit. |
| 15:57 | <&jerith> | Except it doesn't actually have the FILE* special case code in it yet, because nobody's written it. |
| 15:57 | | celticminstrel [celticminst@Nightstar-05d23b97.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 15:59 | <&jerith> | The idea with cffi is that you call "ffi.new('int *', 0)" (where the second parameter is optional) and it owns that memory until the Python object it returns gets GCed. |
| 16:00 | <&jerith> | You have to handle the lifetime of the object appropriately, but that's stuff that it can't do for you anyway. |
| 16:48 | | Derakon [chriswei@31356A.8FA1FE.CF2CE9.D6CF77] has joined #code |
| 16:48 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 16:48 | <&Derakon> | Ahh, producer-consumer systems. |
| 16:49 | <&Derakon> | Got a camera producing images, and a viewer consuming them by displaying them to the user. The viewer's not doing a great job of keeping up when images come in rapidly though. |
| 16:49 | <&Derakon> | Yesterday's optimizations were a big help; I can push the framerate down further than before. But when it hits the limit, it starts behaving badly. |
| 16:50 | <&Derakon> | (I.e. far fewer frames get displayed than could be displayed if it just dropped some of them) |
| 16:50 | <&Derakon> | Part of the problem being that anything that touches OpenGL has to be done in a specific thread. |
| 16:51 | <&Derakon> | But there's other non-main-thread stuff that needs to be done beforehand. |
| 16:51 | <&Derakon> | Currently I just seize a lock in the main thread and do everything. |
| 16:52 | <&Derakon> | I could see having a system where the "new image arrived" function just adds the image to a queue, and there's another thread removing images from the queue, doing the non-main-thread work, and then telling the main thread to draw... |
| 16:52 | <&Derakon> | Gets complicated fast though. |
| 16:52 | < Syk> | what's it bottlenecking on? |
| 16:53 | < Syk> | logic or the drawing |
| 16:53 | <&Derakon> | Yes. |
| 16:53 | < Syk> | heh |
| 16:53 | < Syk> | well, tired syka flailing suggestions |
| 16:53 | < Syk> | but would possibly downsampling the images help? |
| 16:54 | < Syk> | i mean, if it's taking long to draw, maybe sacrificing some information might be worth it |
| 16:54 | <&Derakon> | .594s total time, .283 of which were spent loading OpenGL textures and .244s of which were spent analyzing numbers. |
| 16:54 | < Syk> | so you're getting an fps of like 4 |
| 16:54 | <&Derakon> | No, sorry, that was for 40 updates. |
| 16:54 | < Syk> | oh |
| 16:55 | < Syk> | so ~70fps? |
| 16:55 | < Syk> | doesn't sound too bad to me? |
| 16:55 | <&Derakon> | Theoretically, but it jams up in actual practice when images arrive too quickly. |
| 16:55 | < Syk> | hmm |
| 16:55 | < Syk> | well if you had a queue of images |
| 16:55 | <&Derakon> | (The profiler has to eschew the threading stuff because otherwise profiling doesn't really work properly) |
| 16:55 | < Syk> | with a time sort of tag |
| 16:55 | <&Derakon> | A priority queue? |
| 16:56 | < Syk> | and then when it's done rendering the exiting frame, it looks for the image next in the queue with the closest tag |
| 16:56 | < Syk> | so say .000 renders |
| 16:56 | < Syk> | meanwhile .100, .200 and .300 come in |
| 16:56 | <~Vornicus> | Syk: except apparently there's no frame skip involved, so if you're getting more than 70 frames a second coming in it takes much longer to display |
| 16:57 | < Syk> | and it takes 320ms to do it, it grabs .300 and just disregards .100 and .200 |
| 16:57 | < Syk> | hum |
| 16:58 | < Syk> | well, theoretically, you could have a really high amount of images coming in |
| 16:58 | < Syk> | as long as the adding to the queue wasn't blocking... |
| 16:59 | < Syk> | i /may/ be absolutely clueless here |
| 16:59 | <&Derakon> | At some point images need to be discarded so that what is actually displayed is vaguely close to what's actually going on. |
| 16:59 | < Syk> | yeah |
| 16:59 | < Syk> | so with the queue, it just grabs the latest off the top |
| 16:59 | <~Vornicus> | the right way I guess is for each loop to only grab the /last/ image that came in, discarding the rest after saving but before sending to opengl |
| 16:59 | < Syk> | yeah |
| 16:59 | <&Derakon> | Otherwise you can end up with e.g. 500 images in the queue and the camera viewer just kind of spinning on for several seconds after data collection ends. |
| 16:59 | < Syk> | like what Vornicus said |
| 16:59 | <&Derakon> | Vorn: so, LIFO? |
| 16:59 | < Syk> | is generally what i'm trying to stab at |
| 17:00 | <&Derakon> | Let me break down what we actually do in more detail. |
| 17:00 | < Syk> | just pull the one off the top, discard the queue, take the one off the top once you've rendered |
| 17:01 | <&Derakon> | 1) New image comes in. |
| 17:01 | <~Vornicus> | Der: ...yeah, a stack would work. If the producer knows when it's done, then it can put a None or something on the stack and that would tell you that you can stop rendering now. |
| 17:01 | <&Derakon> | 2) We set self.imageData to the new image |
| 17:01 | <&Derakon> | 3) We analyze the data so that we know how it is distributed (for drawing a histogram later on). |
| 17:01 | <&Derakon> | 4) We parcel up the image into chunks of at most 512x512 pixels. |
| 17:02 | <&Derakon> | 5) The chunks are loaded onto graphics memory. |
| 17:02 | <&Derakon> | 6) We redraw. |
| 17:02 | <&Derakon> | Steps 4, 5, and 6 have to be done in the main thread. |
| 17:02 | < Syk> | mgh, I am no good at thinking about high performance |
| 17:03 | | * Syk 's idea of 'high performance' is "oh hey, this datagridview took less than 3 seconds to paint this time!" |
| 17:03 | <&Derakon> | They also are currently set to read from self.imageData, so ideally it wouldn't be changed out from under them by step 2... |
| 17:03 | <~Vornicus> | Okay. So you, uh |
| 17:03 | <&Derakon> | But in hindsight I think they can just accept the image as a parameter. |
| 17:06 | < Syk> | warning, horrible idea incoming |
| 17:07 | < Syk> | make an array of whatever image datas is, just keep adding to it |
| 17:07 | < Syk> | then instead of reading self.imagedata, just read self.a_imagedata(self.a_imagedata.length-1) and use that? |
| 17:08 | < Syk> | i dunno |
| 17:08 | <&Derakon> | You still end up with the issue that a new element could be added to the array, so how do you know which index to use? |
| 17:08 | <&Derakon> | You can't just store every image ever. |
| 17:09 | < Syk> | self.a_imagedata(self.a_imagedata.length - 1) will return the last value in an array, unless something weird happens and the .length is processed, then something is added |
| 17:09 | < Syk> | in which case you will get the second last image |
| 17:10 | < Syk> | which is close enough |
| 17:10 | <&Derakon> | Right, there's another thread potentially adding things to the array. |
| 17:10 | <&Derakon> | And presumably chopping things off the front of it too. |
| 17:10 | < Syk> | or you just wipe the entire thing |
| 17:26 | <~Vornicus> | does your loading and drawing thing block until you've finished drawing? |
| 17:26 | <~Vornicus> | Or at least finished loading? |
| 17:27 | <&Derakon> | The expensive part is getting the texture data from main RAM to graphics RAM. |
| 17:27 | <&Derakon> | But all OpenGL calls have to be singlethreaded. |
| 17:28 | <~Vornicus> | If so, then just having an array of images and always asking for images[-1] should work. the dereference will always work and always get you just one image. |
| 17:31 | < Syk> | yeah |
| 17:31 | < Syk> | worst that happens is that the .length -1 value becomes less than the true .length - 1 |
| 17:31 | < Syk> | which means you'll get a slightly outdated image |
| 17:32 | < Syk> | BUT you couldn't render the true -1 anyway |
| 17:32 | < Syk> | as that would have been written after you got the normal .imagedata |
| 17:33 | <&Derakon> | Hm, as a quick patch job, I've just tweaked the code so that recalculating the histogram is done in a separate thread. |
| 17:33 | <&Derakon> | It doesn't matter, there, if the image data is slightly out of data because the histogram isn't of top importance. |
| 17:34 | <&Derakon> | So that roughly doubles my peak framerate. |
| 17:34 | < Syk> | using the array method |
| 17:34 | < Syk> | theorettically |
| 17:34 | < Syk> | should make your fps uncoupled |
| 17:35 | <&Derakon> | Right, though I'd probably just use Python's threadsafe Queue construct. |
| 17:35 | <&Derakon> | It would make the code more complicated though. |
| 17:36 | <&Derakon> | Since this one minor tweak has removed the visible stuttering problem, I think I'm OK for now. |
| 17:36 | <&Derakon> | Thanks for the advice though! |
| 17:38 | <~Vornicus> | hoorays |
| 17:38 | <&Derakon> | (That said, I'm not going to try to handle the case where we're at true-max framerate -- that's over 400FPS!) |
| 17:39 | <&Derakon> | (My monitor's probably limited to 60 anyway!) |
| 17:47 | | Syk is now known as syksleep |
| 18:05 | | Kindamoody|out is now known as Kindamoody |
| 18:31 | | * Derakon takes a moment to note holy FUCK his experiment code is cleaner than the old system. |
| 18:32 | <&Derakon> | It's something like half the size, too! |
| 18:35 | <&jerith> | \o/ |
| 18:36 | | * jerith has put the "reap" attachment on the refactor tractor and is driving it through this code with a heavy hand. |
| 18:36 | < FurryHelix> | We've switched jerith's "reap" attachment out for the "eviscerate" attachment; let's see if he notices. |
| 18:37 | | FurryHelix is now known as Tamber |
| 18:37 | | mode/#code [+o Tamber] by ChanServ |
| 18:37 | <&jerith> | Tamber: I did notice. Your version isn't as wantonly destructive. ;-) |
| 18:37 | <@Tamber> | :D |
| 18:38 | <&Derakon> | Yeah, evisceration tends to leave a lot of bloody chunks on the body; reaping implies that you remove them and throw them out. :p |
| 18:39 | < gnolam> | <Derakon> Steps 4, 5, and 6 have to be done in the main thread. |
| 18:39 | < gnolam> | Why does step 4) need to be done in the main thread? |
| 18:40 | <&Derakon> | Gnolam: construction of the chunks involves creation of new textures. |
| 18:46 | < gnolam> | It doesn't have to, does it? I mean, "creation of new textures" sounds like step 5) to me. |
| 18:47 | <&Derakon> | Okay, I mislabeled step 4. |
| 18:47 | <&Derakon> | Step 4 is "create new textures" and step 5 is "load texture data into graphics RAM". |
| 18:48 | <&Derakon> | Step 4 can be omitted if the image size hasn't changed, incidentally. |
| 18:48 | <&Derakon> | Since the textures already exist. |
| 19:34 | < AnnoDomini> | Yay, my game is taking on some shape. |
| 19:37 | < iospace> | i feel dirty... |
| 19:40 | | * iospace intentionally wrote a goto T_T |
| 19:41 | < AnnoDomini> | You're treating goto like a heresy. |
| 19:41 | < froztbyte> | iospace: jmp jmp |
| 19:41 | < froztbyte> | (read like it was the Chef muppet saying it) |
| 19:42 | < iospace> | it is heresy! |
| 19:43 | < iospace> | actually there's a good reason why i need one, it's just :< |
| 19:48 | <&McMartin> | goto is the C way to get local exceptions~ |
| 19:48 | < iospace> | this is C so :P |
| 19:48 | <@Tamber> | Filling your code with crap and turning it into spaghetti, because you're opposed to correctly using a tool the language gives you, should be the heresy. ?? |
| 19:48 | < iospace> | and now i get to break the build! |
| 19:48 | < iospace> | yay! |
| 19:48 | | * iospace dances |
| 19:48 | <@Tamber> | "${X} considered harmful" considered harmful. :p |
| 19:49 | | Kindamoody is now known as Kindamoody[zZz] |
| 19:49 | <&McMartin> | The guy who considered GOTO harmful also considered more than one return statement per function harmful. Fuck that guy~ |
| 19:50 | | RichyB [richardb@Nightstar-3b2c2db2.bethere.co.uk] has quit [[NS] Quit: Leaving] |
| 19:50 | <&Derakon> | The important thing is being able to trace the flow of program logic. |
| 19:51 | <&Derakon> | Goto theoretically means that you could start executing at a given line of code from any other line in the program, but in practice that doesn't work unless all your state is global~ |
| 19:51 | <&McMartin> | There are a handful of optimizations that rely on this~ |
| 19:52 | <&McMartin> | It's true that a computed goto whose value depends on unsolved mathematical problems as opposed to, say, a table lookup, is problematic when you attempt to break a program into basic blocks. |
| 19:52 | <&McMartin> | Also, where you came from is much less important than where you're going next~ |
| 19:53 | <&Derakon> | But where you're going next depends on current program state, which depends on where you came from. |
| 19:53 | <&McMartin> | Yes, this is why it's called a "dataflow analysis" |
| 19:55 | < iospace> | oh right |
| 19:55 | <&McMartin> | It is true that any interesting program analysis question is undecidable. |
| 19:55 | <&McMartin> | However, it is also true that this is not an excuse. |
| 19:55 | | * iospace realizes why her build fails, goes to fix |
| 19:56 | <&McMartin> | ("All gotos are local" is something you can enforce at the intermediate-representation level, even if by the time you've turned it into code you have multiple functions jumping into each other because they share a suffix) |
| 19:58 | <&McMartin> | Also, in 6502 assembler, one of the peephole optimizations is to change the instruction sequence JSR label; RTS to JMP label |
| 19:58 | < iospace> | i forgot that in the EDK2 shell, there's functions that make devel simpler but they don't exist outside it |
| 19:58 | < iospace> | Dx |
| 20:04 | <~Vornicus> | hooray, tail call stuff |
| 20:07 | | * iospace eyes her code |
| 20:08 | < iospace> | ok, clean build |
| 20:08 | < iospace> | maybe that'll help my include issues -_-;; |
| 20:14 | | * iospace eyes firefox |
| 20:14 | < iospace> | over a gig of memory? Really? |
| 20:16 | <@TheWatcher> | firefox likes its rammeats |
| 20:17 | | * Azash met professor today, was impressed, probably has new project to work on \o/ |
| 20:26 | < iospace> | oh fuck me |
| 20:26 | < iospace> | caps |
| 20:26 | < iospace> | Dx |
| 20:29 | <&jerith> | Oh, wow. Getting rid of this horrible background task manager from the async side of our codebase was easier than I expected. |
| 20:30 | <&jerith> | All we're using it for here is to push a message onto a queue, and we have better tools for that on the async side. |
| 20:35 | | * iospace makes jerith work with UARTs |
| 20:35 | <&jerith> | iospace: I've done that. |
| 20:35 | <&jerith> | I wrote a bit-basher SPI interface once, too. |
| 20:36 | <&McMartin> | I had to make one speak NTSC for my digital design final, IIRC |
| 20:36 | < iospace> | hah |
| 20:36 | <&McMartin> | (digital camera over uart to NTSC) |
| 20:36 | <&jerith> | And on that note, I'm heading out to get some food. |
| 20:37 | <&McMartin> | Mit Wissenschaft |
| 20:41 | | Attilla_ [Obsolete@Nightstar-e3245d77.as43234.net] has joined #code |
| 20:42 | < iospace> | god dammit vb.net |
| 20:42 | < iospace> | got me sloppy |
| 20:43 | | Attilla [Obsolete@Nightstar-c0d703de.as43234.net] has quit [Ping timeout: 121 seconds] |
| 20:43 | | Attilla_ is now known as Attilla |
| 20:45 | < Azash> | iospace: How fares your low levelling? |
| 20:45 | < iospace> | decent |
| 20:45 | < iospace> | i may have derped though on something |
| 20:46 | < Azash> | Oh dear |
| 20:46 | < iospace> | yeah |
| 20:46 | < iospace> | though every time i want to see a change... |
| 20:47 | < iospace> | i have to reload the firmware |
| 20:47 | < iospace> | Dx |
| 20:47 | < Azash> | >reload firmware >go for coffee >come back >fence post error |
| 20:47 | < Azash> | "Nooo" |
| 20:47 | < iospace> | heh |
| 20:47 | < iospace> | by reload firmware I mean I press one button and it does it all :P |
| 20:48 | < iospace> | takes 2.5 minutes though about Dx |
| 20:48 | < Azash> | Ah |
| 20:49 | < Azash> | I have a friend working for nvidia, and he mentioned that due to the way they work, compiling can take closer to an hour |
| 20:49 | < Azash> | Said that he's been forced to learn to look through his changes before compiling :P |
| 20:52 | < iospace> | oh clean builds take ~5-10 minutes |
| 20:55 | < Azash> | One more exam today and I get a nice two weeks of straight deving~ |
| 20:55 | < Azash> | tomorrow |
| 20:56 | < iospace> | :P |
| 21:07 | < iospace> | why are you giving me invalid parameter D< |
| 21:12 | | * Azash apologizes |
| 21:14 | | Derakon [chriswei@31356A.8FA1FE.CF2CE9.D6CF77] has quit [Ping timeout: 121 seconds] |
| 21:14 | | Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 21:16 | | Derakon [chriswei@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 21:18 | | Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 21:23 | < iospace> | ... |
| 21:23 | < iospace> | anyone here besides me familiar with UEFI? |
| 21:26 | <&McMartin> | BIOS's successor? |
| 21:26 | < iospace> | yeah |
| 21:26 | < iospace> | as in a code level familiarity :P |
| 21:28 | < gnolam> | Hey, 5 A if I short-circuit these things. This might actually work. |
| 21:29 | <&McMartin> | That is a Considerable Number of amps. |
| 21:50 | <&McMartin> | Man |
| 21:50 | <&McMartin> | Things C++ probably has to answer for |
| 21:50 | <&McMartin> | I just assigned a variable inside an if statement clause and this is clearly the right thing to do. |
| 21:51 | < Azash> | Well, it depends |
| 21:51 | <&McMartin> | The idiom in question being: |
| 21:51 | <&McMartin> | if (X *x = dynamic_cast<X *>(y)) { ... stuff dealing with x ... } |
| 21:51 | < Azash> | Something like if((c = readThatInput()) == targetChar) |
| 21:51 | < Azash> | Is probably okay, I see it done now and again |
| 21:51 | <&McMartin> | Yeah, what you quoted I consider insanely dodgy |
| 21:55 | | * Derakon disapproves of McM's idiom for a separate reason. |
| 21:55 | < Derakon> | That being, "X* x" is clearly superior to "X *x". |
| 21:57 | <~Vornicus> | except that X* x is wrong when you declare multiple variables |
| 21:58 | <&McMartin> | Yeah, X* x is wrong. |
| 21:58 | <&McMartin> | Because X* x, y defines a pointer to X named x and an *instance* of X named y. |
| 21:58 | <&McMartin> | The correct way to declare two pointers to X is X *x, *y. |
| 21:58 | < Derakon> | This is a flaw in the language and also why I generally only declare one variable per line. |
| 21:59 | < Derakon> | Granting that what you say is perfectly accurate, it's morally the wrong way to write code. |
| 21:59 | < Derakon> | (Like mixing tabs and spaces) |
| 21:59 | <&McMartin> | When dealing with a language with flaws I do not react to them by singing loudly and pretending those flaws do not exist |
| 21:59 | <&McMartin> | Mixing tabs with spaces is *actually* wrong because it makes obscures the intent. |
| 22:00 | <&McMartin> | X* x also obscures the intent while pretending declarations mean something else. |
| 22:00 | < Derakon> | Howso? |
| 22:00 | <&McMartin> | s/makes // |
| 22:01 | <&McMartin> | "X* x" is the one that is equivalent to mixing tabs and spaces here. |
| 22:01 | <&McMartin> | It looks all right and it actually works as long as you add additional code constraints |
| 22:01 | <&McMartin> | While mixing tabs and spaces in Python code is legal as long as it's 8 spaces per tab and that looks all right if you set the editor appropriately. |
| 22:02 | < Derakon> | Bleh...can we at least agree that the language syntax is wrong? >.> |
| 22:02 | <&McMartin> | Both violate the spirit of the language - In Python, that indentation should be of a consistent form because it is semantically significant, and in C, because pointers aren't part of the type specification in C. |
| 22:03 | <&McMartin> | I'm cranky, so no~ |
| 22:03 | < Derakon> | Even though they bloody well should be. |
| 22:03 | <&McMartin> | Feel free to put it in your "the entire world is mad" bin |
| 22:03 | <&McMartin> | The only languages I can think of that do what you want don't actually have non-pointer types. |
| 22:05 | <&McMartin> | (Or do something much better, by which I mean 'are statically typed, therefore use type inference because they can') |
| 22:05 | <&McMartin> | Actually, I'm wrong |
| 22:05 | <&McMartin> | Pointers *are* part of type specifications. |
| 22:05 | <&McMartin> | Except in variable specifications, except when it's via a type specification. |
| 22:06 | <~Vornicus> | Double layered rule exceptions, hooray |
| 22:06 | <&McMartin> | "typedef X* pX; pX x, y;" declares two pointers. |
| 22:06 | < Derakon> | Yie. |
| 22:06 | <&McMartin> | As my example shows, this is a case where we are supposed to beleive that Hungarian Notation is the answer. |
| 22:06 | <&McMartin> | I cannot bring myself to accept this. |
| 22:07 | <@TheWatcher> | Ugh, hungarian notation. |
| 22:07 | <&McMartin> | Yeah, pretty much |
| 22:07 | <@TheWatcher> | MY CODE BLOCKS ARE FULL OF EELS |
| 22:07 | <&McMartin> | Anyway, it's ugly and somewhat inconsistent. |
| 22:08 | <&McMartin> | However, given the books written specifying the language and how they are formatted, I'm not willing to grant that it's outright wrong. |
| 22:08 | <&McMartin> | (Admittedly, when you get cranky about having to declare variables *at all*, in a static language, as I do, one's threshold for what counts as 'more wrong' is going to be more casual.) |
| 22:25 | | * McMartin realizes that when running vertex or fragment shaders, he should really be intoning GO FORTH, MY ARMY OF ROBOTS |
| 22:27 | | * Derakon blarghs, can sense his brainpower leaking into the atmosphere. |
| 22:27 | < gnolam> | Then people would think you were running Forth on a GPU.~ |
| 22:34 | <&McMartin> | I bet you could~ |
| 22:34 | <~Vornicus> | looking at some shader builders I've seen, it's not far off~ |
| 22:34 | <&McMartin> | [programming] zarf says, "I am using a C++ std::vector for possibly the first time" |
| 22:34 | <&McMartin> | [programming] zarf says, "it's like a real programming language, but made out of razors and broken glass." |
| 22:34 | < Derakon> | Has he created an iterator for the vector yet? |
| 22:35 | | * Vornicus tries to remember, is pretty sure zarf is someone partially famous... |
| 22:35 | <&McMartin> | Andrew Plotkin |
| 22:35 | <&McMartin> | Derakon: Probably not |
| 22:35 | | * Vornicus was right! |
| 22:35 | <&McMartin> | It's best to keep some things a surprise |
| 22:35 | < Derakon> | Heh. |
| 22:36 | < Derakon> | I forget the syntax, I just remember it being a bit absurd. |
| 22:39 | <&McMartin> | Remember not to confuse std::vector<std::pair<std::string, std::string> >::iterator and std::vector<std::pair<std::string, std::string> >::const_iterator |
| 22:40 | <&McMartin> | Or that space between those two >s, or the lexer will slay you. |
| 22:40 | < Derakon> | I'd forgotten about the >> problem, thanks. |
| 22:52 | <&ToxicFrog> | |
| 22:54 | | celticminstrel [celticminst@Nightstar-05d23b97.cable.rogers.com] has joined #code |
| 22:54 | <~Vornicus> | ladies and gentlemen, the reason we don't code in C++ unless we absolutely fucking have to. |
| 22:55 | <&McMartin> | I think Java may have the same problem. |
| 22:56 | <&McMartin> | The actual lesson here is not to have any repeatable lexemes in your language that, when repeated, produce an entirely different lexeme. |
| 23:00 | < celticminstrel> | ?? |
| 23:00 | < Derakon> | >> is the bitshift operator. |
| 23:00 | < Derakon> | It is also tempting to write when you're closing a double template. |
| 23:01 | < Derakon> | But that's wrong! |
| 23:01 | < celticminstrel> | Not anymore... |
| 23:01 | < iospace> | I AM IOSPACE |
| 23:02 | < iospace> | I BREAK BUILDS D< |
| 23:02 | <&McMartin> | No, it's wrong as long as anyone anywhere is using a C++08 compiler. |
| 23:02 | <&McMartin> | And that's, well, everyone. |
| 23:02 | < celticminstrel> | Okay, fair enough I guess. |
| 23:02 | < iospace> | though my co-worker did commit changes that broke everyone's builds |
| 23:02 | < celticminstrel> | I'm not using it though, so for me it's fair game unless I plan to share the code in the next five years or whatever. |
| 23:02 | < celticminstrel> | ie, I'm using C++11 when programming C++ |
| 23:11 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 23:27 | < Derakon> | Freaking cameras. |
| 23:27 | < Derakon> | I forgot that changing the camera's exposure time automatically puts it into internal-triggered mode, and you have to put it back on external trigger before it'll work again. |
| 23:28 | < Derakon> | (Internal trigger: software tells the camera to take an image. External trigger: a cable plugged into the camera's box tells it to take an image) |
| 23:28 | <~Vornicus> | why would... |
| 23:29 | < Derakon> | Because the camera has to be continually ready to take images when in external trigger. |
| 23:29 | < Derakon> | So setting the exposure time first aborts the camera's current activity (waiting for a trigger), then sets the exposure time, then puts it on internal trigger since it has to choose something and doesn't know what the prior state was. |
| 23:31 | < Reiv> | That actually makes sense, in a slightly-stupid way. |
| 23:31 | | ErikMesoy is now known as ErikMesoy|sleep |
| 23:34 | < Derakon> | Hm, the cockpit overhaul is at 9275 lines of code. |
| 23:35 | < Derakon> | For comparison, the original had 21322 lines of Python and 3111 lines of C++, not counting generated code. |
| 23:44 | < iospace> | coworker is a derp! yay! |
| 23:49 | | Derakon [chriswei@Nightstar-a3b183ae.ca.comcast.net] has quit [[NS] Quit: leaving] |
| --- Log closed Thu Oct 18 00:00:14 2012 |