| --- Log opened Thu Aug 15 00:00:55 2013 |
| 00:14 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 00:16 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer] |
| 00:16 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 00:18 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer] |
| 00:23 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 00:25 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer] |
| 00:26 | | You're now known as TheWatcher[T-2] |
| 00:29 | <&McMartin> | Oh, Hell yes |
| 00:29 | <&McMartin> | I'd missed somehow that SDL2 was relicensed to zlib |
| 00:33 | <&ToxicFrog> | What was it before? |
| 00:36 | | You're now known as TheWatcher[zZzZ] |
| 00:40 | <&McMartin> | LGPL. |
| 00:42 | <&ToxicFrog> | Aah. |
| 00:48 | | Reiv_ is now known as Reiv |
| 01:08 | <@gnolam> | And that is a glorious thing. |
| 01:08 | <@gnolam> | I'm pretty surprised though... I thought they'd rewrite the entire API as well, but it's pretty much the same. |
| 01:11 | <@gnolam> | And by "pretty much" I mean "bloody identical". |
| 01:12 | <&McMartin> | The graphical side is significantly modified. |
| 01:12 | <&McMartin> | The API now bifurcates "dealing with GPU entities" and "dealing with CPU entities" |
| 01:13 | <&McMartin> | Also, in-library support for rotozoom and logical window size separate from physical window size :frogsiren: :frogsiren: :frogsiren: |
| 01:14 | <&McMartin> | UQM has a large and messy layer dedicated to faking a 320x240 screen for the benefit of all the game logic, and then rendering it sensibly at higher resolutions |
| 01:14 | <&McMartin> | And we never did acceptably solve the aspect ratio problem. |
| 01:15 | <@gnolam> | The graphics functions I used from it were pretty much limited to "gimme a GL context" and "load me this here image so I can chuck it into a texture". |
| 01:15 | <@gnolam> | The rest was... well, better suited to something other than raw SDL. |
| 01:15 | <@gnolam> | ... frogsiren? |
| 01:16 | <~Vornicus> | http://i.somethingawful.com/forumsystem/emoticons/emot-frogsiren.gif |
| 01:17 | <&McMartin> | Yes, if you're only using SDL to replace GLUT, the only thing that SDL2 gives you is the ability to get contexts that your version of GLX probably doesn't support. |
| 01:18 | <&McMartin> | If, however, you were using SDL to replace *DirectDraw*, you will have to rewrite everything, and will probably get significant performance improvements depending on what you were doing. |
| 01:19 | <&McMartin> | The API docs strongly imply that part of this is "handles the render-to-texture bullshit for you" |
| 01:19 | <&McMartin> | Thus letting you do Actual Fullscreen for your games that naturally live in 480p. |
| 01:29 | | Derakon[AFK] is now known as Derakon |
| 01:34 | <@Alek> | hrm. |
| 01:35 | <@Alek> | personally, per aspect ratio, I'd leave the game display proper in 4:3, and use the extra screenspace for displaying some bonus stuff. |
| 01:36 | <@Alek> | if you want the bonus stuff displayable in all aspect ratios, I'd cut down 4:3 resolutions and fit the bonus around, not just to the sides. |
| 01:36 | <@Alek> | but I dunno how applicable that could be to UQM. |
| 01:37 | | RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has quit [[NS] Quit: Gone.] |
| 01:37 | <@Alek> | also, I think there's some games that basically pad out the sides with wallpaper, for widescreen. |
| 01:40 | | RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has joined #code |
| 01:44 | <&McMartin> | Alek: Generally speaking, in UQM if you try to go fullscreen it tries to resize your desktop. |
| 01:44 | <&McMartin> | Since that's how SDL 1.2 fullscreen works. |
| 01:45 | <&McMartin> | SDL2 you tell it "I want to pretend the screen size is X by Y, and I want to be fullscreen at the desktop resolution", and then it is. |
| 01:45 | <&McMartin> | It handles the scaling and padding for you. |
| 01:51 | < Reiv> | ... I've forgotten how to create a table and do INSERTS. |
| 01:51 | < Reiv> | How the fuck? |
| 01:52 | < Azash> | CREATE TABLE Connection ( foo INTEGER NOT NULL, bar INTEGER NOT NULL, FOREIGN KEY (foo) REFERENCES Preferences(id), FOREIGN KEY (bar) REFERENCES User(id), PRIMARY KEY (foo, bar)) ; |
| 01:52 | < Reiv> | Here I am, writing windowed analysis scripts to partition data and optimise performance before pivoting the stuff into the desired output with string formatting... and I've forgotten how to write a CREATE TABLE. |
| 01:52 | < Azash> | INSERT INTO Table [(column_name, column_name)] VALUES (value, value); |
| 01:53 | < Reiv> | Haha, yeah, thanks ;) |
| 01:53 | < Reiv> | It was more a ... this is like engineering a bridge and halfway through calculating the static load values, you forgot how bolts work :p |
| 01:54 | < Azash> | Yeah :P |
| 02:21 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [[NS] Quit: brb] |
| 02:23 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 02:24 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer] |
| 02:24 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 02:25 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer] |
| 02:31 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code |
| 02:31 | | mode/#code [+o Alek] by ChanServ |
| 02:44 | | VirusJTG_ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| 02:47 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [Ping timeout: 121 seconds] |
| 02:48 | | ktemkin is now known as ktemkin[awol] |
| 03:45 | | VirusJTG_ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 04:18 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 04:33 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Client closed the connection] |
| 04:33 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 04:39 | < Syka_> | Azash: that table makes me confused |
| 04:39 | < Syka_> | oh i see now |
| 04:39 | < Syka_> | dual primary key |
| 04:40 | < Syka_> | i should probably make this app i have use foreign keys |
| 04:54 | | McMartin [mcmartin@Nightstar-eb476be7.pltn13.sbcglobal.net] has quit [Operation timed out] |
| 04:54 | | McMartin [mcmartin@Nightstar-eb476be7.pltn13.sbcglobal.net] has joined #code |
| 04:54 | | mode/#code [+ao McMartin McMartin] by ChanServ |
| 05:13 | | Derakon is now known as Derakon[AFK] |
| 05:17 | | Turaiel is now known as Turaiel[Offline] |
| 05:31 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Client closed the connection] |
| 05:41 | | Kindamoody[zZz] is now known as Kindamoody |
| 05:43 | | celticminstrel [celticminst@Nightstar-ae361035.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 07:02 | | Karono [Karono@Nightstar-13c26ed9.optusnet.com.au] has joined #code |
| 07:42 | | You're now known as TheWatcher |
| 08:07 | | Kindamoody is now known as Kindamoody|out |
| 08:21 | | cpux [cpux@Nightstar-98762b0f.dyn.optonline.net] has quit [Connection reset by peer] |
| 08:26 | | thalass [thalass@Nightstar-de48278f.bigpond.net.au] has joined #code |
| 10:23 | | AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has joined #code |
| 11:07 | | AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has quit [[NS] Quit: Leaving] |
| 13:06 | | * TheWatcher eyes this chunk of comment |
| 13:07 | <@TheWatcher> | Who needs steenking // or /* */ ? Just surround your comment in #if 0 .... #endif! |
| 13:07 | < Azash> | What |
| 13:08 | <@TheWatcher> | http://pastebin.starforge.co.uk/581 - yes |
| 13:09 | <@Tamber> | ... |
| 13:18 | <@froztbyte> | hahaha |
| 13:20 | | ktemkin[awol] is now known as ktemkin |
| 13:23 | < Azash> | Possibly old but quite gold https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755cdbe 0acce6f1dafc8beb84f2ac |
| 13:23 | < Azash> | That install.sh diff |
| 13:24 | <~Vornicus> | That is the most unfortunate bug ever |
| 13:25 | <@Tamber> | ...oh dear. |
| 13:28 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 13:38 | < Azash> | http://www.cavecanen.org/linux/humour/horrorstories.txt |
| 13:39 | < Azash> | Search your way to "have you ever left your terminal" |
| 13:41 | | celticminstrel [celticminst@Nightstar-ae361035.dsl.bell.ca] has joined #code |
| 13:41 | | mode/#code [+o celticminstrel] by ChanServ |
| 13:42 | | thalass [thalass@Nightstar-de48278f.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 13:43 | < Syka_> | ahahahahaa |
| 13:46 | | * TheWatcher eyes the first few paragraphs, shudders |
| 13:47 | <@TheWatcher> | (that said, `# cd` should have gone to /root not to /, but anyway) |
| 14:26 | <@Alek> | possibly depends on FS, but I agree. |
| 14:27 | < Azash> | They mention / home folder elsewhere as well, I think |
| 14:27 | < Azash> | Guessing it was A Thing back then |
| 14:28 | | ktemkin is now known as ktemkin[awol] |
| 14:29 | <@gnolam> | TheWatcher: ... |
| 14:29 | <@gnolam> | How... just... how... |
| 14:29 | <@gnolam> | That person /must/ at some point have seen a comment. |
| 14:31 | <@TheWatcher> | Oh, indeed. |
| 14:32 | < Azash> | gnolam: Embrace the future of documentation |
| 14:32 | <@TheWatcher> | In fact, http://pastebin.starforge.co.uk/582 |
| 14:36 | <@gnolam> | ... |
| 14:37 | <@gnolam> | And this is why beginner programmers should be made to wear shock collars... |
| 14:41 | < Xon> | no kidding |
| 14:42 | | * TheWatcher notes that this is from the source code for a released game >.> |
| 14:45 | <@gnolam> | Wat |
| 14:45 | <@froztbyte> | Azash: damn, that bug would hurt |
| 15:40 | | Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has quit [Ping timeout: 121 seconds] |
| 15:43 | | Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has joined #code |
| 16:07 | | Karono [Karono@Nightstar-13c26ed9.optusnet.com.au] has quit [Client closed the connection] |
| 17:30 | | Derakon [chriswei@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 17:30 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 17:31 | | * Derakon sends an email to the camera vendor: "So, uh, when we try to take images at your stated maximum rate +.1ms, we tend to get repeat images or even images that are partially old and partially new data. What the heck?" |
| 17:32 | <&Derakon> | Best guess: the camera's saying it's done writing out image data before it actually is; combined with re-use without re-initialization of memory buffers (even though they get free'd and then malloc'd again, they're probably the same as before), we get stale image data. |
| 17:32 | <&Derakon> | Workaround for the moment is to take another .2ms between each frame. |
| 17:32 | <&Derakon> | There are times when I love the kinds of problems I have to solve at this job... |
| 17:36 | <@TheWatcher> | ... is any of the hardware you need to deal with there actually doing what the documentation says? >.> |
| 17:37 | <&Derakon> | Actually, yes. The motorized sample holder has excellent documentation and does what it's supposed to. |
| 17:38 | <&Derakon> | ...if you ignore the fact that it doesn't drop dead Ethernet connections and can only have one connection at a time, anyway. |
| 17:38 | <&Derakon> | But I worked around that by setting up a proxy that never drops the client-side and which can add/drop connections freely. |
| 17:42 | <&Derakon> | I'd say about 75% of the problems with this hardware is that most of the people who make it are all engineers and scientists themselves, not software developers~ |
| 17:42 | <&Derakon> | Of course, I'd hate to see the camera a software developer would make. |
| 19:01 | <@Tarinaky> | Derakon: http://stackoverflow.com/questions/16159203/why-does-this-java-program-terminate -despite-that-appears-that-it-shouldnt-and Was this you? :p |
| 19:01 | <&Derakon> | Nah, we're an optical microscopy lab. |
| 19:01 | <&Derakon> | I don't think our microscope is worth more than $1.5 million or so. |
| 19:05 | <&Derakon> | Also, if I'd written that code I would have had more thread-safety. |
| 19:05 | | * ToxicFrog eyes that code |
| 19:05 | <&ToxicFrog> | 40K lines of unthreadsafe lock-and-modify shared-memory concurrency. |
| 19:05 | <&ToxicFrog> | :clustergonk: |
| 19:05 | <&Derakon> | Is that actually an emote? |
| 19:05 | <&ToxicFrog> | No. |
| 19:06 | <&Derakon> | Alas. |
| 19:06 | <&ToxicFrog> | But if it were, it would be a SHARCNET supercomputing cluster running :gonk: on every node in parallel. |
| 19:07 | <&Derakon> | That might be difficult to represent in a 20px-tall GIF. |
| 19:09 | <&Derakon> | "Unthreadsafe lock-and-modify" -- I'm guessing the concern here is over the potential for deadlocks? |
| 19:09 | <&Derakon> | I mean, lock-and-modify is a pretty standard concept. |
| 19:23 | <&ToxicFrog> | Derakon: yeah, but that doesn't mean it's a good one. |
| 19:24 | <&ToxicFrog> | There's a reason parallel programming libraries/languages are increasingly ditching it in favour of message-passing and STM. |
| 19:25 | <&Derakon> | Software Transactional Memory? |
| 19:29 | <&ToxicFrog> | Yeah. |
| 19:29 | <&ToxicFrog> | Anyways. Lock-modify-unlock is really easy to get wrong, has lots of ways to go wrong, and when it goes wrong it tends to go wrong in really confusing, subtle, hard to debug ways. |
| 19:33 | <&ToxicFrog> | I suspect it's only been popular for as long as it has because concurrency hasn't been super important until recently, with per-core performance flattening out, and all the people running on supercomputing clusters have been using message-passing anyways. |
| 19:36 | <@Tarinaky> | Plus C++ has only /just/ gotten out of the box mutex handling, never mind anything fancier :p |
| 19:45 | <&Derakon> | TF: well, lock-modify-unlock is also often all you need if your threads are only used to maintain multiple execution contexts, as opposed to for performance. |
| 19:45 | <&Derakon> | In that kind of situation it becomes much easier to make accurate statements about control flow and ensure that things won't go Horribly Wrong. |
| 19:49 | <&ToxicFrog> | Derakon: yeah, but in that case you just use coroutines and no actual locking occurs (or is needed) |
| 19:50 | <&ToxicFrog> | Which also means there's no chance you'll fuck up the locking and end up with parallel execution by mistake. |
| 19:52 | <&Derakon> | I admit I still don't have a strong grasp on how coroutines function in practice. |
| 19:52 | <&Derakon> | And not to toot my own horn, but if I don't get it, then there must be legions of other people who are even worse off~ |
| 19:53 | < Azash> | Derakon: I guess it's more race condition than deadlock |
| 19:53 | <&ToxicFrog> | Derakon: So just imagine how bad it is with shared-memory threading, which is even more complicated, much easier to get wrong, and breaks much more horribly when it goes go wrong! |
| 19:54 | <&jerith> | Shared-memory threading is probably about the most horrible concurrency model available. |
| 19:54 | <&ToxicFrog> | (more seriously, coroutines are pretty simple, but not, IME, widely implemented) |
| 19:55 | <&Derakon> | (That's probably why I don't grok them then) |
| 19:55 | <&jerith> | Derakon: Do you know the reactor model? |
| 19:55 | <&Derakon> | ISTR Pyrel's user-prompt system being described as a coroutine system. |
| 19:55 | <&Derakon> | But it's done with Python generators and thus has some syntactical ugliness. |
| 19:55 | <&ToxicFrog> | (it's conceptually basically threads, except only one can run at a time, and all locking/concurrency constructs are replaced with "pass control to other_thread", which then continues execution at the point where it last relinquished control) |
| 19:55 | <&Derakon> | Jerith: I know practically zero models by their names. |
| 19:56 | <&Derakon> | (Ahh, like cooperative multitasking in pre-OSX Macs~) |
| 19:56 | <&jerith> | Derakon: Twisted? Ruby's EventMachine? |
| 19:56 | <&ToxicFrog> | (in practice a lot of impls, including lua's, split that into yield/resume - you call resume to start another coroutine running, and yield to return control to the coroutine that resumed you) |
| 19:56 | <&ToxicFrog> | (so you don't need to keep track of who started you running) |
| 19:56 | <&Derakon> | Jerith: no to either. I have little time to spend playing with different languages, in practice. |
| 19:57 | <&jerith> | Anyway, that's not quite coroutines but it's close enough. |
| 19:57 | | Kindamoody|out is now known as Kindamoody |
| 19:57 | <&Derakon> | Wow, the Wikipedia article on the reactor pattern is horrible. |
| 19:58 | <&Derakon> | Almost as bad as some mathematical articles I've tried to read. |
| 19:58 | <&jerith> | It's conceptually quite simple, but trickier to work with until you've wrapped your head around it. |
| 19:59 | <&ToxicFrog> | Derakon: yeah, actually. Coroutines are the ur-cooperative-multitasking. |
| 20:02 | <&jerith> | Basically, the reactor is a big select() loop or whatever. It calls your code when stuff arrives and goes back to waiting when your code's done. |
| 20:04 | <&jerith> | Your code can easily block the whole process if you're silly, but nothing has to be thread-safe because context-switches can only happen at known points. |
| 20:04 | <&ToxicFrog> | Sounds similar to copas? |
| 20:04 | <&ToxicFrog> | select() on sockets (or more generally "events"), when something comes in the selector resumes() the corresponding coroutine |
| 20:05 | <&ToxicFrog> | Actions in the coroutine that would normally block instead yield() back to the selector, which is free to resume other coros in the meantime. |
| 20:05 | <&ToxicFrog> | All the organizational benefits of one-thread-per-socket, but only one thread. |
| 20:05 | <&Derakon> | Hm. |
| 20:06 | <&Derakon> | In wxWidgets you can register event handlers, which all run in the main thread by default. Seems basically similar. |
| 20:06 | <&ToxicFrog> | (usually this means you pass the coroutine something that duck-types as a socket but where all blocking operations are just 'yield()') |
| 20:06 | <&Derakon> | ...no, because the event processing system can only call one handler at a time. |
| 20:06 | <&Derakon> | Nemmind. |
| 20:07 | <&Derakon> | Hm, live band outside. I'ma go listen to them. |
| 20:07 | <&ToxicFrog> | Derakon: the distinctiction here is that event processing can be interleaved; a typical setup is that the "event" that triggers the creation of a coro is a new client connecting. |
| 20:07 | <&ToxicFrog> | A coro then takes ownership of that socket and does everything with it as though it were an independent thread calling blocking operations like :recv and :send |
| 20:07 | <&ToxicFrog> | ...but instead of blocking, it yields back to select(), which can create/resume other coros for other sockets that aren't blocked. |
| 20:08 | <&ToxicFrog> | Whereas in a typical GUI framework, an event handler must run to completion before anything else can happen; if it wants to perform long-running operations like disk IO the entire UI freezes. |
| 20:10 | <&jerith> | The idea is that the reactor provides APIs for otherwise-blocking operations. |
| 20:11 | <&jerith> | You make a network call and the reactor calls you back when it gets a response. |
| 20:11 | <&ToxicFrog> | Without ending up in a maze of twisty little callbacks, all alike; it looks like you're just making a normal blocking call. |
| 20:11 | <&jerith> | Well. Twisted uses Deferreds. |
| 20:12 | <&jerith> | I'm uncomfortable with things that look like normal blocking code but aren't. |
| 20:15 | <&ToxicFrog> | Well, as a practical matter, it is; it's just that the "blocked time" is spent running other coros. |
| 20:15 | <&ToxicFrog> | What is a Deferred? |
| 20:15 | <&jerith> | It's a container for callbacks. |
| 20:16 | <&jerith> | You call "make_http_request()" and it gives you back a Deferred. |
| 20:17 | <&jerith> | Then you call "d.addCallback()" and/or "d.addErrback()". |
| 20:18 | <&jerith> | The callback gets called with the result of the blocking operation. |
| 20:19 | <&ToxicFrog> | That's the maze of twisty little callbacks design, which I hate. |
| 20:22 | <&ToxicFrog> | It makes things much more complicated and doesn't actually buy you anything. |
| 20:25 | <&jerith> | There's also an @inlineCallbacks decorator that abuses generators to make it less twisty. |
| 20:30 | <&ToxicFrog> | Or you could just yield~ |
| 20:34 | | * Derakon returns, reads up. |
| 20:34 | <&Derakon> | Yeah, if I need to do anything expensive due to an event handler, I spin up a new thread. |
| 20:34 | <&jerith> | ToxicFrog: That's what the decorator/generator hackery does. |
| 20:34 | <&Derakon> | I have a handle decorator "util.threads.callInNewThread" for functions that should always run in new threads. |
| 20:35 | <&jerith> | It would be much cleaner if generators could return values when they were done. |
| 20:36 | <&jerith> | All the nastiness is it trying to work around that. |
| 20:44 | <&ToxicFrog> | Aah. |
| 20:44 | <&ToxicFrog> | Yeah, Python generators are like crippled coroutines, aren't they? |
| 20:46 | <&Derakon> | AIUI they were implemented to let you provide things to iterate over without having to create the entire iterable set all at once. |
| 20:46 | <&Derakon> | The fact that they can be used as coroutines was sort of a happy accident. |
| 20:46 | <&Derakon> | And wasn't taken into account when it came to their syntax. |
| 20:48 | <&McMartin> | Yeah, generators "feel" to me like they're clearly intended to be lazy lists |
| 20:54 | | Kindamoody is now known as Kindamoody[zZz] |
| 20:57 | <&ToxicFrog> | Right, but IIRC python doesn't have actual coroutines, so generators are the best you're going to get. |
| 21:40 | | * Derakon tries to dig into Windows' system logs to see if he can get any information on why a program crashed. |
| 21:40 | <&Derakon> | "Faulting module name: MSVCR90.dll". Hm. |
| 21:40 | <&Derakon> | So the question is, is the runtime bad, or is it my use of the runtime~? |
| 21:42 | <&ToxicFrog> | The answer is almost always the latter. |
| 21:42 | <&ToxicFrog> | Usually because you've accidentally whacked malloc's accounting table or something. |
| 21:42 | <&Derakon> | Yyyyyeah, I think I'm going to chalk this crash up to the same thing that was causing corrupted image data that I described earlier. |
| 21:43 | <&Derakon> | The camera vendor's software is doing something horribly wrong, and it's just that most of the time it happens to not crash. |
| 21:54 | <&Derakon> | I have come up with a hypothesis. |
| 21:54 | <&Derakon> | The sequence here is: |
| 21:54 | <&Derakon> | 1) We allocate a buffer. |
| 21:54 | <&Derakon> | 2) We hand the buffer to the camera API. |
| 21:55 | <&Derakon> | (Repeate 1 and 2 an arbitrary number of times) |
| 21:55 | <&Derakon> | 4) We ask the camera to tell us when it has an image. |
| 21:55 | <&Derakon> | 5) The camera passes us a pointer to one of those buffers. |
| 21:55 | <&Derakon> | 6) We copy the buffer. |
| 21:55 | <&Derakon> | 7) We free the buffer. |
| 21:55 | <&Derakon> | During 5-7 the camera is still writing to the buffer! I think. |
| 21:56 | <&Derakon> | Which is why we get corrupted data sometimes. |
| 21:56 | <&Derakon> | And also probably why we crash, more rarely, if the camera writes to the buffer after it has been freed. |
| 21:57 | <@Tamber> | So the times it's been working, you've just been really lucky? |
| 22:03 | <&Derakon> | Well, I suspect the behavior is triggered by high framerates. |
| 22:25 | <@gnolam> | Is it specced to do continuous shooting like that? |
| 22:26 | <&Derakon> | Yeah, it's supposed to be able to sustain a high framerate indefinitely. |
| 22:39 | <@gnolam> | Ah. 'twas just a thought. Some cameras are funny like that. :) |
| 22:42 | < RichyB> | ToxicFrog, Python's generators are indeed crippled coroutines. |
| 22:44 | < RichyB> | ToxicFrog, the specific thing that is broken is that you can't in a generator subroutine a() call another generator subroutine b() and yield directly from b() |
| 22:44 | < RichyB> | the closest that can happen is that b() can yield to a(), which can then immediately yield that result |
| 22:45 | < RichyB> | aiui in a real coroutine system you should be able to call things that'll themselves yield as if you had. |
| 22:45 | <&Derakon> | Agh, flashbacks to the old experiment execution code I had. |
| 22:45 | <&Derakon> | Which had tons of generator functions that all had to be invoked as "for i in call_function(): yield i". |
| 22:46 | < RichyB> | If you deeply nest generators in Python, you end up with O(depth) time being wasted passing values up and down the stack in loops that look like "for val in some_other_generator(): \n\t yield val" |
| 22:46 | < RichyB> | stupid bloody thing |
| 23:09 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 23:09 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 23:16 | <&jerith> | RichyB: I think 3.something has "yield from" |
| 23:17 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| 23:27 | <&ToxicFrog> | RichyB: in a "real" coroutine system the only valid operation is resume C, IIRC; "yield" is just resuming the coro that last resumed you. |
| 23:28 | <&ToxicFrog> | Most coro systems I've used have separate resume/yield and disallow cycles. |
| 23:29 | <&McMartin> | The IEC 62304 standard calls out certain cautions on using software, particularly software of unknown pedigree or provenance, called SOUP in the standard. The standard spells out a risk-based decision model on when the use of SOUP is acceptable, and defines testing requirements for SOUP to support a rationale on why such software should be used. |
| 23:29 | <&McMartin> | NO SOUP FOR YOU |
| 23:34 | <@TheWatcher> | ... |
| 23:34 | <@Alek> | COME BACK, NEXT YEAR |
| 23:36 | | You're now known as TheWatcher[T-2] |
| 23:41 | | You're now known as TheWatcher[zZzZ] |
| 23:58 | | Derakon [chriswei@Nightstar-a3b183ae.ca.comcast.net] has quit [[NS] Quit: leaving] |
| --- Log closed Fri Aug 16 00:00:11 2013 |