| --- Log opened Wed Oct 24 00:00:45 2012 |
| 00:29 | | RichyB [richardb@Nightstar-3b2c2db2.bethere.co.uk] has quit [[NS] Quit: Leaving] |
| 00:50 | | Attilla_ [Obsolete@Nightstar-699a2f89.as43234.net] has joined #code |
| 00:50 | | Attilla [Obsolete@Nightstar-7be0cbe0.as43234.net] has quit [Ping timeout: 121 seconds] |
| 01:18 | | himi [fow035@D741F1.243F35.CADC30.81D435] has joined #code |
| 01:18 | | mode/#code [+o himi] by ChanServ |
| 01:35 | | Attilla_ [Obsolete@Nightstar-699a2f89.as43234.net] has quit [[NS] Quit: ] |
| 01:42 | | Derakon[AFK] is now known as Derakon |
| 01:42 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 02:22 | | Vash [Vash@Nightstar-3ba4108e.wlfrct.sbcglobal.net] has joined #code |
| 02:22 | | mode/#code [+o Vash] by ChanServ |
| 02:31 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 02:31 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 02:31 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 04:11 | | Kindamoody[zZz] is now known as Kindamoody |
| 04:44 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has quit [[NS] Quit: Well, most things get better when I kick them!] |
| 05:17 | | Vash [Vash@Nightstar-3ba4108e.wlfrct.sbcglobal.net] has quit [[NS] Quit: I lovecraft Vorn!] |
| 06:07 | | Kindamoody is now known as Kindamoody|breakfast |
| 06:17 | | 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!] |
| 06:21 | | Derakon is now known as Derakon[AFK] |
| 06:43 | | himi [fow035@D741F1.243F35.CADC30.81D435] has quit [Ping timeout: 121 seconds] |
| 07:04 | | Noah [nbarr@Nightstar-e4b6966f.tn.comcast.net] has joined #code |
| 07:04 | | Noah [nbarr@Nightstar-e4b6966f.tn.comcast.net] has quit [Connection reset by peer] |
| 07:58 | | Kindamoody|breakfast is now known as Kindamoody |
| 08:17 | | Kindamoody is now known as Kindamoody|out |
| 08:26 | | Attilla [Obsolete@Nightstar-699a2f89.as43234.net] has joined #code |
| 10:39 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 10:39 | | mode/#code [+o himi] by ChanServ |
| 11:07 | | himi-cat [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 11:07 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 11:14 | | RichyB [richardb@Nightstar-3b2c2db2.bethere.co.uk] has joined #code |
| 11:15 | | himi-cat [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 11:31 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 11:31 | | mode/#code [+o himi] by ChanServ |
| 11:46 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Connection closed] |
| 12:12 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 12:12 | | mode/#code [+o himi] by ChanServ |
| 12:32 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Client closed the connection] |
| 12:32 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 12:32 | | mode/#code [+o himi] by ChanServ |
| 13:10 | | RichyB [richardb@Nightstar-3b2c2db2.bethere.co.uk] has quit [Operation timed out] |
| 14:39 | | celticminstrel [celticminst@Nightstar-05d23b97.cable.rogers.com] has joined #code |
| 14:40 | | syksleep [the@Nightstar-7d752098.lnk.telstra.net] has quit [[NS] Quit: leaving] |
| 14:40 | | Syka [the@Nightstar-7d752098.lnk.telstra.net] has joined #code |
| 15:00 | | Syloq_Home [Syloq@NetworkAdministrator.Nightstar.Net] has quit [[NS] Quit: ] |
| 15:09 | | Syloq_Home [Syloq@NetworkAdministrator.Nightstar.Net] has joined #code |
| 15:14 | | RichyB [richardb@Nightstar-3b2c2db2.bethere.co.uk] has joined #code |
| 15:55 | | 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!] |
| 18:08 | | Derakon [chriswei@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 18:08 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 18:09 | <&Derakon> | Interesting problem, this... |
| 18:10 | <&Derakon> | We have three components: the cockpit, a camera, and a signal source. |
| 18:10 | <&Derakon> | The cockpit says "Take an image!" This goes through the abstraction layers and tells the signal source to fire a signal, which reaches the camera, which takes an image, and returns it to the cockpit. |
| 18:11 | <&Derakon> | The cockpit then says "Take another image!", etc. until we get to the signal source, which says "Hold on a second, I'm not done recovering from the last one" and throws an exception. |
| 18:11 | <&Derakon> | At which point the cockpit sits there waiting for an image to arrive indefinitely. |
| 18:12 | <&Derakon> | The obvious solution is to code in a timeout in the cockpit... |
| 18:12 | <&Derakon> | But the cockpit doesn't actually know that taking an image can fail; why should any particular operation be error-prone? |
| 18:13 | <@Azash> | Return the same image again? Return a null image? |
| 18:13 | <&Derakon> | Ideally, I think, the signal source should just wait until it is ready and then take an image. |
| 18:13 | <&Derakon> | I think that's a safe precedent to set... |
| 18:19 | <&Derakon> | There is some concern about the general pattern of "fire off some function, assume it will result in an event, and wait for that event to occur". |
| 18:20 | <&Derakon> | The proper solution there would be some kind of timeout system, I guess. |
| 18:20 | | * Azash embraces paranoid programming where no part makes assumptions |
| 18:21 | <&Derakon> | The trick is to do that without peppering your code with boilerplate . |
| 18:21 | <@Azash> | Mm |
| 18:24 | <~Vornicus> | what happens if the camera stops responding |
| 18:24 | <~Vornicus> | Or throws any error condition other than "not ready" |
| 18:24 | <&Derakon> | That hasn't been known to happen. |
| 18:25 | <&Derakon> | The cameras are pretty reliable. |
| 18:25 | <&Derakon> | (In the sense that when they don't do what you want, it's because you didn't set them up properly, not because they had some weird timing glitch) |
| 18:26 | <&Derakon> | Hm, though it does occur to me that we're limited to a 30FPS framerate on the cameras. |
| 18:26 | <&Derakon> | So some triggers will be ignored if sent too quickly. |
| 18:31 | | * Derakon adds logic to ensure we don't fire take-image actions too quickly for the cameras, then. |
| 18:33 | < RichyB> | Derakon: how sad is the cockpit going to be if it gets the same image twice? |
| 18:33 | < RichyB> | Stupid suggestion: run the camera run continuously, taking photos as fast as it can. |
| 18:33 | | * Vornicus wagers Pretty Sad: there are time series questions involved |
| 18:33 | <&Derakon> | That's not feasible, Richy. |
| 18:34 | <&Derakon> | Problem 1 is that every image damages the sample. |
| 18:34 | <&Derakon> | (Lasers are bad for cells!) |
| 18:34 | <&Derakon> | Problem 2 is that we need to time the camera-lightsource combination properly, so the cameras are exposing while the lasers shine on the samples. |
| 18:34 | <&Derakon> | A continuous camera would get out of sync from the lasers. |
| 18:35 | < RichyB> | Makes sense. |
| 18:35 | <&Derakon> | Problem 3 is that we're doing a series of images here to begin with -- stitching together a map of the sample by combining many images into a mosaic. |
| 18:36 | <&Derakon> | So if the camera sends two images, it might just send the second one after the cockpit had started waiting for another new image...and think that the second (a duplicate of the first) was actually a different, new image. |
| 18:36 | <&Derakon> | Which would screw up the mosaic. |
| 18:36 | | RichyB [richardb@Nightstar-3b2c2db2.bethere.co.uk] has quit [[NS] Quit: Leaving] |
| 18:37 | <&Derakon> | And there he goes. |
| 18:57 | | * Derakon takes a moment to admire how non-fucked-up the new mosaic code is. Old system: 1124/327/718 lines (total 2169). New system: 362/257/315 lines (total 934). |
| 18:58 | <&Derakon> | Granted I've eliminated some functionality, but almost all of it is there. |
| 18:58 | <&ToxicFrog> | Derakon: my immediate instinct there would be to assume that cockpit.takeImage() blocks until everything is ready, then takes the image, and throws if that's not possible (eg, camera is not set up right and won't be fixed by waiting) |
| 18:58 | <&Derakon> | TF: yeah, I just modified the imager interface to wait until everything's set. |
| 18:59 | <&Derakon> | But at some level I'm limited by the UI needing to not know exactly how the devices do their things. |
| 18:59 | <&Derakon> | E.g. I can't check that the cameras are on external-trigger non-frame-transfer mode. |
| 18:59 | <&Derakon> | I can call camera.getAmReadyToImage() or something, which would go to the device-specific code and do the same thing. |
| 18:59 | <&Derakon> | Layers of abstraction! |
| 19:04 | | * AnnoDomini tries to install CivNet. |
| 19:05 | <@AnnoDomini> | I... think I'm going to need another operating system. |
| 19:05 | <&ToxicFrog> | CivNet? |
| 19:05 | <@AnnoDomini> | The last iteration of the original Civilization. |
| 19:06 | <@AnnoDomini> | Wine manages to install the game, but not the Wing libraries. WinXP in a vbox fails to run the setups at all, citing 16bit programs being unrunnable. |
| 19:07 | | Kindamoody|out is now known as Kindamoody |
| 19:07 | <@AnnoDomini> | I'm going to try getting the Wing library files separately. |
| 19:09 | <&ToxicFrog> | If it's DOS or win3.x, dosbox is an option |
| 19:09 | <&ToxicFrog> | Or manually installing the Wing DLLs in Wine, assuming that they don't have some particularly convoluted install process |
| 19:11 | <&ToxicFrog> | Quick googling that says CivNet works in DOS, so dosbox is probably your best bet. |
| 19:12 | <@AnnoDomini> | Alright, I'll try that. |
| 19:15 | <&ToxicFrog> | (it's unclear whether there were separate DOS and win9x editions, or just one release for both) |
| 19:18 | <@AnnoDomini> | Are you sure it works under DOS? |
| 19:19 | <@AnnoDomini> | I can't find a download that isn't behind some registration/payment bullshit, and the version I have doesn't run under DOS. |
| 19:22 | <&ToxicFrog> | I don't know if it'll run in naked DOS but it definitely supports 3.1 |
| 19:23 | <&ToxicFrog> | Which runs fine in dosbox |
| 19:24 | <&ToxicFrog> | Also, for download: http://www.hotud.org/component/content/article/37-strategy/37/21211 |
| 19:26 | <@AnnoDomini> | Thanks. |
| 19:48 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
| 19:51 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
| 20:08 | | Vash [Vash@Nightstar-3ba4108e.wlfrct.sbcglobal.net] has joined #code |
| 20:08 | | mode/#code [+o Vash] by ChanServ |
| 20:14 | | Kindamoody is now known as Kindamoody[zZz] |
| 20:52 | <&Derakon> | Hm, wish I'd kept logs from our discussion of how to improve my camera viewers' responsiveness. |
| 20:52 | <&Derakon> | Alas I did not. |
| 20:53 | <&McMartin> | I may have them floating around |
| 20:53 | <&McMartin> | Is this the stuff about texture sizes and the like? |
| 20:53 | <&Derakon> | I think it was on the same day as that. |
| 20:53 | <&Derakon> | ...it occurs to me that my home computer may have been logged in, in which case I would have logs. |
| 20:53 | <&McMartin> | I thought that's what gave you the greatest gain |
| 20:54 | <&McMartin> | This machine has the logs, let me do a search |
| 20:54 | <&Derakon> | Yeah, I think the time-to-load-a-new-texture stuff is pretty well optimized now. |
| 20:54 | <&Derakon> | The remaining problem is that the viewer doesn't handle being spammed with new images very well. |
| 20:55 | <&Derakon> | Hm, if it's the same day as the texture discussion then I don't have it. |
| 20:56 | <&Derakon> | This was a discussion between me and TF and one other I can't remember, where they suggested using a queue to store incoming images. |
| 20:56 | <&McMartin> | Ah, OK |
| 20:56 | <&McMartin> | I wasn't part of that discussion I don't think |
| 20:58 | <&Derakon> | ...ah, found it. |
| 20:58 | <~Vornicus> | http://starforge.co.uk/irclogs/code/ have fun |
| 20:59 | <&Derakon> | Hooray for widespread surveillance! |
| 20:59 | <&Derakon> | It's okay if it's done by the civilians~ |
| 21:00 | | Courage [Moltare@583787.FF2A18.190FE2.4D81A1] has joined #code |
| 21:01 | | Moltare [Moltare@583787.FF2A18.190FE2.4D81A1] has quit [Ping timeout: 121 seconds] |
| 21:06 | | * AnnoDomini finds some old code and laughs. |
| 21:06 | <@AnnoDomini> | There's a function called AManIsCoughingInBrazil(int). |
| 21:07 | <@AnnoDomini> | It shuts down everything and exits. |
| 21:12 | | * Azash snorts |
| 21:15 | <~Vornicus> | What's it use the parameter for? |
| 21:15 | <@Tarinaky> | Exit code I imagine |
| 21:15 | <@Azash> | How many increments the dramatic face zoom uses |
| 21:16 | <@AnnoDomini> | Exit code, yes. |
| 21:24 | | Derakon [chriswei@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 21:24 | | Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 21:25 | <@gnolam> | AnnoDomini: Ah, 4-in-the-morning code. |
| 21:25 | | Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 21:51 | <@Tarinaky> | Part of me wants to try hacking an FPS engine to do cool shit. |
| 21:51 | <@Tarinaky> | But I don't have time atm :/ |
| 21:52 | <@Tarinaky> | Maybe during the summer -.- |
| 21:59 | | Derakon [chriswei@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 21:59 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 21:59 | <&Derakon> | Bleh...rapid image streams still cause the display to choke up horribly, and I don't know why. |
| 22:00 | <&Derakon> | Current setup: |
| 22:00 | <&Derakon> | when an image comes in, we stick it onto the end of a threadsafe Queue. |
| 22:00 | <&Derakon> | There's a thread continually pulling images off of the Queue. It always empties out the queue (non-blocking) and works with the most recent image. |
| 22:00 | <&Derakon> | Thus we shouldn't waste any time on stale images. |
| 22:01 | <&Derakon> | That thread does the Numpy histogram work, then tells the main thread to do the OpenGL work. |
| 22:01 | <&Derakon> | Then it blocks until a drawing Event is set. |
| 22:02 | <&Derakon> | At the end of the paint function (i.e. after the image has been displayed), that Event is set. |
| 22:02 | <&Derakon> | This causes the worker thread to go back to blocking on the Queue. |
| 22:02 | <&Derakon> | If I simply make two camera views and hold down the "take image" button then I get a horrible and horribly inconsistent framerate. |
| 22:11 | <&Derakon> | The really frustrating part of this is that the old cockpit's code can handle this stuff no problem...but the old cockpit's display code is a tangled mess of C++ and is one of the reasons I'm doing the revamp in the first place. |
| 22:14 | <@Azash> | http://linux.slashdot.org/story/12/10/24/1848203/ext4-data-corruption-bug-hits-l inux-kernel |
| 22:15 | <@Azash> | Derakon: Toothing~ |
| 22:16 | <&Derakon> | ? |
| 22:19 | <@Azash> | Like, if you come up with a decent solution for your problems, and keep the revamp clean, it probably won't have to be done again |
| 22:24 | <&Derakon> | Right, the question is, what's the decent solution? |
| 22:25 | <@Azash> | I'm not very good with concurrency, sorry :( |
| 22:31 | <&jerith> | Derakon: Do you know where the slow bits are? |
| 22:32 | <&jerith> | Also, are the threading bits all in Python? |
| 22:32 | <&jerith> | If so, are you being hit by the GIL? |
| 22:32 | <&Derakon> | Jerith: I don't know, that's part of the problem. |
| 22:32 | <&Derakon> | All the threading is in Python, yes, but I don't think the GIL is a likely culprit. |
| 22:33 | <&Derakon> | Since the threading is not so much for concurrency as it is for making sure that OpenGL operations only happen in one thread. |
| 22:34 | <&jerith> | Have you stuck timers around various bits and seen where the slow things are? |
| 22:34 | <&Derakon> | The problem is that slowness is inconsistent. |
| 22:34 | <&jerith> | Yes, but it's worth seeing if it's always in the same bits of code. |
| 22:34 | <&Derakon> | Like, with a single camera, I get an average framerate of anywhere from 13-25 or so. |
| 22:35 | <&Derakon> | But it's all over the place. |
| 22:35 | <&Derakon> | Also, with two cameras I can reliably get a framerate of zero by holding the "take image" button down. |
| 22:35 | <&jerith> | Ugh. |
| 22:35 | <&Derakon> | But if I just mash the button as fast as I can then the displays are responsive. |
| 22:35 | <&Derakon> | So I suspect there's something jamming up the main thread. |
| 22:36 | <&Derakon> | ...hang on, I think I found it. |
| 22:37 | <&jerith> | Logging timers should help eliminate things, at least. |
| 22:37 | <&Derakon> | Yeah, that makes sense. |
| 22:37 | <&Derakon> | My take-image code was asking the cameras how long they have to wait between exposures, so it knew if it was safe to take another image. |
| 22:37 | <&jerith> | What did you find? |
| 22:37 | <&Derakon> | It was doing this every time. |
| 22:37 | <&jerith> | Ah. |
| 22:37 | <&Derakon> | And each call involved a network call to the computer running the camera. |
| 22:37 | <&Derakon> | Slap a cache on her and she's good to go. |
| 22:37 | <&jerith> | Yeah, that would do it. |
| 22:38 | <&jerith> | Does that number change at all? |
| 22:38 | <&Derakon> | Yeah, it can. |
| 22:38 | <&Derakon> | Which is unfortunate, because there's no notification to the imager that it has. |
| 22:38 | <&Derakon> | But I can set up a sub-thread to check for changes every few seconds or something. |
| 22:38 | <&jerith> | Is there a mode switch or something? |
| 22:39 | <&Derakon> | There's a set of buttons that change the camera's mode, which affects its time between exposures. |
| 22:39 | <&Derakon> | But the imager cannot know about those buttons. |
| 22:39 | <&jerith> | Just have your cacher ask again if it's been some number of seconds since it last asked. |
| 22:39 | <&Derakon> | Right. |
| 22:40 | <&jerith> | But a background thread doing it moves its latency to somewhere more manageable. |
| 22:40 | <&Derakon> | Right. |
| 22:42 | <&Derakon> | Anyway, good to know that the actual display system is speedy enough. |
| 22:42 | <&Derakon> | I wasn't looking forward to further optimizing it. |
| 22:44 | | * Derakon maxes his two cameras out at ~30FPS each, see no bad behavior, gets no dropped frames. |
| 22:44 | <&jerith> | \o/ |
| 22:44 | <&Derakon> | The real test'll be upstairs, where we have 4 cameras, but this is good. |
| 22:45 | <&Derakon> | ...heh, okay, if I only run the faster of the two cameras, then my experiment code goes awry and gets 502 out of 1000 images...but the display is fine! |
| 22:45 | <&Derakon> | Ah yeah, I was trying to achieve 400FPS, which the camera doesn't like doing. |
| 22:45 | <&Derakon> | 100FPS is fine though. |
| 22:46 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 23:25 | | * AnnoDomini manages to produce a decent random Civ map. It has some obvious minor issues with transitioning, but is otherwise somewhat believable. |
| 23:31 | | Vash [Vash@Nightstar-3ba4108e.wlfrct.sbcglobal.net] has quit [[NS] Quit: I lovecraft Vorn!] |
| 23:45 | | Derakon [chriswei@Nightstar-a3b183ae.ca.comcast.net] has quit [[NS] Quit: leaving] |
| 23:55 | | * AnnoDomini peers. |
| 23:55 | <@AnnoDomini> | This is a rare inversion of a common error. == instead of =. |
| 23:56 | | * AnnoDomini generates random rivers. |
| 23:57 | <@AnnoDomini> | http://oi45.tinypic.com/2yx2m2g.jpg |
| 23:57 | <@AnnoDomini> | This is not exactly what I had in mind. |
| 23:59 | <~Vornicus> | I imagine not! |
| 23:59 | <@AnnoDomini> | Though I think the inhabitants of this world would take that as direct evidence of unintelligent creation. |
| --- Log closed Thu Oct 25 00:00:00 2012 |