X-Git-Url: https://git.ucc.asn.au/?a=blobdiff_plain;f=irc%2Flog;h=d799f2dec9152253ff08a1048f6923baa6998ed0;hb=1fff2a882c5c873e89e6f31b2336ee38938d133e;hp=ad3abf9c612872a6f11cc0a5ad5e072bb33e7d19;hpb=df1a9751a2d23cc9d43bf49c069ac9effc2a752f;p=matches%2FMCTX3420.git diff --git a/irc/log b/irc/log index ad3abf9..d799f2d 100644 --- a/irc/log +++ b/irc/log @@ -4470,3 +4470,1063 @@ 18:01 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev 19:37 -!- MctxBot [~twang@106-68-47-96.dyn.iinet.net.au] has quit [Ping timeout] 21:16 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +--- Day changed Wed Oct 09 2013 +08:29 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +09:20 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit [Ping timeout] +09:54 -!- MctxBot [~twang@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +10:52 -!- jtanx [~asfa@130.95.133.152] has joined #mctxuwa_softdev +10:55 -!- jtanx_ [~asfa@130.95.54.13] has joined #mctxuwa_softdev +10:56 < jtanx_> welp the usb microscope arrived +10:56 < jtanx_> it uses uvcvideo too +11:07 -!- jtanx [~asfa@130.95.133.152] has quit [Connection reset by peer] +12:00 < jtanx_> shit, we have to coordinate one report across the whole cohort +12:02 < sam_moore> Yeah, shit +12:03 < sam_moore> This unit has not been run very well +12:03 < sam_moore> Except the tutorials +12:06 < sam_moore> If I still cared I +12:06 < sam_moore> d try and take charge of putting the report together +12:07 < sam_moore> But I know that if no one else does it we'll all pass anyway since you can't fail an entire class +12:07 < sam_moore> So terrible +12:07 < sam_moore> We should just start writing a chapter on the software +12:09 < sam_moore> I wonder if we could use the wiki format and export it as a pdf somehow +12:11 < sam_moore> https://github.com/szmoore/MCTX3420/wiki/Hardware:-Pneumatics +12:11 < sam_moore> Hilarious +12:41 < jtanx_> ~.~ +12:41 < jtanx_> our final report will be the wiki! +12:42 < jtanx_> made some progress on the camera +12:42 < jtanx_> lowering the resolution to 352x288 +12:42 < jtanx_> and it will work with openc +12:42 < jtanx_> opencv +12:42 < jtanx_> ffmpeg's fine with 640x480 though +12:42 < jtanx_> opencv just sucks +12:57 < jtanx_> good 'ol stream.html +13:05 < jtanx_> those fatal checks in sensor.c are bad +13:05 < jtanx_> because half the time adc reads will fail and the whole program just crashes +13:07 < jtanx_> oh right I saw your email, nevermind +13:08 < jtanx_> I'm not getting the warnings that you're seeing either +13:12 < sam_moore> Yeah, those warnings were actually on my laptop though, they don't seem to appear on the BeagleBone +13:12 < sam_moore> I'm redoing the sensors code a fair bit +13:12 < sam_moore> You'll probably hate it :P +13:12 < sam_moore> Well, it's not really redoing the structure of how they work +13:13 < sam_moore> Just separating the logic of how sensors get read from all that control loop stuf +13:14 < sam_moore> I'm going to keep with the "one thread per sensor" idea, because that is definitely the simplest +13:16 < sam_moore> Did you tell Omid that they shouldn't assume anything about the state of the GPIO pins before the software starts? +13:16 < sam_moore> Which means that if (unlikely, but I don't know what they're doing) having two pins on at once would cause a catastrophic failure... +13:16 < sam_moore> By murphy's law, it will almost certainly happen +13:33 -!- jtanx_ [~asfa@130.95.54.13] has quit [Ping timeout] +13:59 -!- jtanx [~asfa@130.95.121.247] has joined #mctxuwa_softdev +13:59 -!- jtanx [~asfa@130.95.121.247] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +14:51 -!- jtanx [~asfa@130.95.248.194] has joined #mctxuwa_softdev +14:52 < jtanx> oh yah, somehow electronics ordered a non-powered usb hub +14:52 < jtanx> I'm pretty sure we told them to get a powered usb hub... +14:57 < sam_moore> Yep, and I remember them saying that is what they were going to get +14:57 < sam_moore> Dammit, I'm stuck trying to pick the best name for something -_- +14:57 < sam_moore> The worst place to be stuck +15:19 < jtanx> ?? +15:19 < jtanx> thesaurus.com +15:23 < sam_moore> Hahaha +15:23 < sam_moore> I decided the thing didn't really need to exist +15:23 < sam_moore> Problem solved +15:24 < sam_moore> If someone who knows absolutely nothing about programming tries to add sensors to our program they will still be confused +15:24 < jtanx> Hahaha +15:24 < sam_moore> But I hope I've made it easier for someone who knows what they're doing +15:24 < jtanx> Okay +15:24 < jtanx> what were the compiler warnings that you got +15:25 < sam_moore> pin_test.c:41:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] +15:25 < sam_moore> pin_test.c:48:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] +15:25 < sam_moore> More on lines 54, 128, 190,204 +15:25 < jtanx> weird +15:25 < jtanx> I never saw any of those +15:25 < sam_moore> Also I think the code I just wrote for the Strain sensors gives some as well +15:25 < sam_moore> Yes, it does +15:26 < jtanx> did you change GPIO_Export to use int type +15:26 < jtanx> wait +15:26 < jtanx> what am I saying +15:26 < sam_moore> It already uses int type? +15:26 < sam_moore> But it's something like that +15:26 < sam_moore> It looks like you're using unsigned char for something +15:27 < sam_moore> int gpio_num = Strain_To_GPIO(id); +15:27 < sam_moore> GPIO_Export(gpio_num); +15:27 < sam_moore> Is the sort of thing that causes the warning +15:27 < sam_moore> But I have "bool GPIO_Export(int pin)" in bbb_pin.c +15:27 < jtanx> oh right +15:27 < sam_moore> So it makes no sense +15:28 < jtanx> hmm +15:29 < sam_moore> Ooh +15:29 < sam_moore> It must be something to do with the "stub" functions +15:29 < jtanx> Is this on compilation on the BBB +15:29 < sam_moore> No, BBB was fine last time I checked +15:29 < jtanx> okay,w ell I'm not getting any warnings +15:29 < sam_moore> Compiling on my laptop because it's faster +15:30 < sam_moore> #define GPIO_Export(pin) True_Stub((void*)pin) +15:30 < sam_moore> That means the int is getting cast to a void* +15:30 < jtanx> yeah on my computer it's not putting out any warnings +15:30 < jtanx> int to void* is fine +15:30 < jtanx> anything to void* is fine +15:30 < jtanx> actually +15:30 < jtanx> is your system 64 bit +15:30 < sam_moore> 64 bit +15:31 < jtanx> yeah +15:31 < sam_moore> (You still have 32 bit :P) +15:31 < jtanx> well that would explain it +15:31 < sam_moore> Ok, it doesn't matter +15:31 < sam_moore> The stub function doesn't actually do anything with the value +15:31 < jtanx> cast int to int64 or whatever it is +15:32 < sam_moore> That would cause warnings on the BBB though? +15:32 < jtanx> only for the stub functions +15:32 < jtanx> and only for 64 bit +15:32 < jtanx> more ifdefs, yay +15:32 < sam_moore> ... +15:32 < jtanx> or we could get rid of the stubs +15:32 < sam_moore> I'm just going to ignore the warnings +15:32 < sam_moore> That could also work +15:32 < sam_moore> It doesn't really matter +15:32 < jtanx> and just do Wno-unsued-function or someting +15:32 < jtanx> yeah, oh well +15:35 < jtanx> One of the suggestions for the dilatometer was to just take a photo at the start and at the end +15:35 < jtanx> then do comparison +15:35 < sam_moore> Um, ok +15:35 < sam_moore> If they just want 2 data points +15:35 < jtanx> well +15:35 < jtanx> if we can find something other than opencv +15:36 < sam_moore> Ah +15:36 < sam_moore> How slow is it? +15:36 < jtanx> that may help, because right now opencv only plays nice with 352x288 or some other crap resolution +15:36 < jtanx> it's not that it's slow +15:36 < jtanx> is that it only works if the resolution is ~ 350 pixels x 2xx pixels +15:37 < jtanx> ffmpeg is fine with 640x480 afaik +15:37 < jtanx> it could probably do higher but haven't tested that +15:38 < sam_moore> http://libccv.org/ +15:38 < sam_moore> Maybe +15:39 < jtanx> or what if we framegrabbed with some external softare +15:39 < jtanx> then used opencv to process the saved image +15:39 < sam_moore> Yes, I was about to suggest that +15:39 < sam_moore> I'm assuming the problem with OpenCV is that it doesn't like taking images from cameras directly of that resolution +15:39 < sam_moore> And not some underlying problem with having large CvMats or something +15:40 < jtanx> no idea why +15:40 < jtanx> some obscure setting can probably fix it or something +15:40 < jtanx> but I'm not about to trawl though opencv documentaiton now +15:40 < sam_moore> Actually OpenCV works with my 640x480 webcam, so it's probably some low level arm specific problem +15:40 < sam_moore> Which would probably mean that other image processing libraries would also suck +15:40 < jtanx> it may be that too +15:41 < jtanx> I know that with ffmpeg it was spitting warnings at 640x480 +15:41 < jtanx> like non-monotonically increasing timestamp +15:41 < jtanx> and some other crap +15:41 < jtanx> I was running guvcview though +15:42 < jtanx> and it seemed to take 640x480 just fine +15:42 < jtanx> it was quite slow with x-forwarding and all, but at least it worked +15:44 < sam_moore> Hmm +15:44 < sam_moore> I would be inclined to say that taking a bunch of data points at low resolution is probably more useful than taking 2 data points at high resolution +15:45 < sam_moore> The best solution is to find some way of reading at the higher resolution though +15:46 < sam_moore> ... I'm worried about what Kieran is going to produce if he writes this dilatometer algorithm +15:46 < sam_moore> It's going to return an array isn't it... +15:46 < sam_moore> I have no idea why +15:47 < jtanx> :3 +15:47 < jtanx> brb ~5 mins while I relocate to a lecture theatre +15:47 < sam_moore> Ok +15:47 -!- jtanx [~asfa@130.95.248.194] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +15:54 -!- jtanx [~asfa@130.95.248.194] has joined #mctxuwa_softdev +16:13 < sam_moore> Ok, this is both terrible and awesome +16:13 < sam_moore> But I've written a test "sensor" that is essentially just an external program +16:17 < sam_moore> So... if anyone complains about not being able to use python... they can use python +16:17 < sam_moore> And they don't have to reinvent all of our FastCGI stuff +16:17 < sam_moore> Although apparently that's easy in python anyway +16:17 < sam_moore> It's the thought that counts +16:21 < jtanx> :P +16:21 < jtanx> flup +16:30 < jtanx> http://zacharyvoase.com/2009/09/08/sendfile/ +16:30 < jtanx> this could be interesting +16:31 < jtanx> replace static with our fastcgi app +16:31 < jtanx> http://wiki.nginx.org/XSendfile +17:00 -!- jtanx [~asfa@130.95.248.194] has quit [Ping timeout] +17:52 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +18:07 < jtanx> mmm feature creep +18:08 < sam_moore> Meh, it was better than dealing with that switch statement +18:09 < jtanx> yeah +18:09 < sam_moore> Also it made it really easy to decide where to put mutexes +18:10 -!- MctxBot [~twang@106-68-47-96.dyn.iinet.net.au] has quit [Ping timeout] +18:10 < sam_moore> Given that I would have had to write a "strain.c" and do about the same amount of work anyway, I think the solution is a good one +18:10 < jtanx> it kind o makes sense though +18:11 < jtanx> you can't particularly generalise that much to each sensor type +18:11 < jtanx> so it makes sense to separate out based on what type of sensor it is +18:11 < sam_moore> Yes +18:11 < sam_moore> The Piped sensor is definitely feature creep though :P +18:12 < jtanx> ^-^ +18:12 < sam_moore> Although... +18:13 < sam_moore> If we wanted to distribute the sensors with a "master slave" system +18:13 < sam_moore> The code would end up looking alot like that +18:13 < sam_moore> Except with a network socket instead of a unix domain socket +18:14 < sam_moore> Also I'm not sure why I called it piped given that it doesn't use a pipe +18:14 < sam_moore> I suppose it sounds cooler than "uds" +18:20 < jtanx> So with electronics +18:20 < jtanx> the reason why they were having issues with getting the psu approved +18:20 < jtanx> was because they wanted to cut the leads and solder directly to the board +18:21 < jtanx> Oliver suggested that they use extension connectors +18:21 < jtanx> and cut the lead on the extension +18:21 < jtanx> but why they didn't think of that first, I don't know +18:37 -!- MctxBot [~twang@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +18:45 < jtanx> now to watch this week's lecture... +21:31 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +--- Day changed Thu Oct 10 2013 +08:11 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +09:40 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +13:30 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +23:04 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +--- Day changed Fri Oct 11 2013 +08:21 -!- Rowan [~Rowan@130.95.129.225] has joined #mctxuwa_softdev +08:42 -!- Rowan [~Rowan@130.95.129.225] has quit [EOF From client] +09:19 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +09:59 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +15:09 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +15:10 < jtanx> urgh +15:10 < jtanx> burning the midnight oil trying to get my cits2232 project done +15:10 < jtanx> but +15:10 < jtanx> it has taught me a lot about django +15:10 < jtanx> which may be of use, especially for the whole admin stuff +15:11 < jtanx> one possibility is that we have two separate 'logins' +15:11 < jtanx> one gains you access to the site +15:11 < jtanx> one gains control over the bbb (eg the server api) +15:12 < jtanx> what you could do is keep the 'bind' functionality for the api, but make it check against the django user database for credentials +15:12 < jtanx> I'll look into it, if not today then probably tomorrow +19:39 < sam_moore> That sounds good +19:48 < sam_moore> Should we do something like this: http://stackoverflow.com/questions/8988855/include-another-html-file-in-a-html-file (The accepted answer) to do with our sidebar/menu stuff +19:48 < sam_moore> Although... +19:48 < jtanx> well +19:48 < jtanx> if we use django it has really cool templating stuff +19:48 < sam_moore> That solution is actually about as much as just copy/pasting the sidebar at the moment +19:48 < jtanx> yeah +19:49 < sam_moore> So Django does parts of our GUI as well as the user management system? +19:49 < jtanx> Well yeah +19:49 < jtanx> so django would be ui mostly +19:49 < jtanx> then tack on to that our api +19:49 < jtanx> which remains exactly the same +19:49 < jtanx> except that it uses the django database for checking authorizaiton +19:50 < jtanx> so right before you commence an experiment, you try to 'gain control' of the bbb, you resupply your login creds +19:50 < sam_moore> Sure, that's a good solution, I thought django would just do user management though (rather than replace the JavaScript GUI) +19:50 < jtanx> well if you do use django +19:50 < jtanx> it's a good idea to change some of it, because of the templating system +19:51 < jtanx> and that it can conditionally show content +19:51 < sam_moore> Ok +19:51 < jtanx> some of the javascript stuff will stay though, definitely +19:51 < jtanx> especially all the live update stuff +19:51 < jtanx> but this is getting ahead of myself, because i'm not even sure if this will work +19:51 < sam_moore> Hahaha +19:52 < sam_moore> You're entering a territory where I can't help much +19:52 < jtanx> yeah, well all of this 'web development' is new area for me too :P +19:52 < jtanx> I'm supposed to be majoring in computation, not web tech... +19:52 < sam_moore> You know more/better jQuery than me +19:52 < jtanx> jquery is pretty easy to learn though +19:53 < jtanx> i picked it up completely from this project +19:53 < sam_moore> Well, that's one reason why we went with it, since I used it briefly for something and it wasn't too hard, and James said he'd used it before too +19:54 < jtanx> Yeah +19:54 < sam_moore> If you want to replace stuff with django, I'm ok with that, if it's simpler +19:55 < jtanx> I'll see how it goes, hopefully it shouldn't be too hard to setup +19:55 < sam_moore> It just seems silly to copy/paste this Navigation Menu into every file +19:55 < jtanx> yep +19:55 < sam_moore> But copy/pasting the code (stack overflow) to automatically make it is also annoying +19:55 < jtanx> We can roll with the jquery soln if I don't get this working +19:56 < sam_moore> Unless you could include that in the "runBeforeLoad()" ? +19:56 < jtanx> can't you just have a placeholder +19:56 < jtanx> and on document load, you load it? +19:56 < sam_moore> Yeah +19:56 < jtanx> It'll look a bit crap because you'll see it before the sidebar loads +19:56 < sam_moore> Actually that's how you're doing other things +19:56 < jtanx> yeah +19:56 < sam_moore> But the navigation menu is hard coded html +19:56 < sam_moore> I'm just reading the existing code :P +19:56 < jtanx> haha +19:57 < jtanx> yeah it's hardcoded - it's the easiest solution +19:57 < jtanx> I've got my case study for 2402 this/next week too +19:57 < sam_moore> Um... I think it's fairly easy to call load from a file +19:57 < sam_moore> I'll look into that +19:57 < jtanx> ok +19:58 < sam_moore> The case study was reasonable, although he wanted a lot more detail from us +19:58 < jtanx> what did you do? +19:58 < sam_moore> Despite struggling to cram it into 4 pages +19:58 < sam_moore> The pencil +19:58 < sam_moore> That's a good one +19:58 < jtanx> ah +19:58 < sam_moore> Lots of youtube videos +19:58 < jtanx> we're doing pet bottles +19:58 < jtanx> there's this megafactories one on the coke plant which was prettyc ool +19:58 < jtanx> but yeah the pencil one also has a lot +19:58 < jtanx> i think i saw the how its made one +19:59 < jtanx> Ha +19:59 < jtanx> http://wiki.nginx.org/HttpSsiModule +19:59 < jtanx> if you want to get server specific +19:59 < jtanx> you can do ssi +19:59 < jtanx> let's not do that if possible :P +20:00 < sam_moore> Wait... +20:00 < sam_moore> It looks like you put html comments and they get sent to the server? +20:00 < sam_moore> How is that a thing? +20:00 < jtanx> +20:00 < jtanx> nah what happens +20:00 < jtanx> is the server reads the html file +20:00 < jtanx> and where there's special placeholders +20:00 < jtanx> it does stuff +20:00 < sam_moore> Ah +20:01 < sam_moore> No, do it client side +20:01 < jtanx> yeah +20:01 < sam_moore> There's like jQuery.load +20:01 < sam_moore> I'd probably keep django for user auth to start with +20:01 < sam_moore> But I think jQuery should be sufficient for the GUI +20:02 < jtanx> I think if you roll with django +20:02 < jtanx> you should use jQuery for all the interactive stuff +20:02 < jtanx> (which you'd have to anyway) +20:02 < jtanx> but you should use the templating system that django's got +20:03 < sam_moore> Ok, what does django give you exactly then, I'm not quite sure what the "template" stuff is, I assume it's nothing like a C++ template +20:03 < jtanx> OK +20:03 < jtanx> hmm +20:03 < jtanx> I'll give you access to my cits2232 repo temporarily +20:03 < jtanx> so you can see +20:03 < sam_moore> If it lets you easily include bits of html that's cool, but jQuery looks to be able to do that easily as well +20:03 < sam_moore> Alright +20:04 < jtanx> actually you know what +20:04 < jtanx> i'll just post it on pastebin or something +20:05 < jtanx> http://privatepaste.com/ec22ba7238 +20:05 < jtanx> That's the base template +20:05 < jtanx> http://privatepaste.com/07499e4a19 +20:05 < jtanx> That's the index +20:05 < jtanx> {{variable_name}} will display a variable name +20:05 < jtanx> sorry, the contents of that variable +20:06 < jtanx> {% %} blocks are for control +20:06 < sam_moore> Hmm +20:07 < jtanx> the base template got a bit out of hand for that project +20:07 < sam_moore> Well, if you want to use something like that I'm ok with it +20:07 < sam_moore> Although I think the thing that I was originally complaining about can be solved in jQuery :P +20:08 < jtanx> yeah +20:08 < sam_moore> But you should probably ask everyone else involved with the GUI for input too +20:08 < jtanx> Yeah, good point +20:09 < sam_moore> ... Really I didn't want to be involved with the GUI, but I kind of need to mess around with at least some basic graph stuff to work out if I need to change the server sensors/actuators api +20:09 < jtanx> well let's just say that i did not envision doing the gui either +20:09 < sam_moore> I'll try and keep what I do consistent with the overall style though +20:09 < sam_moore> Which is how I got sidetracked complaining about copy/pasting things :P +20:10 < sam_moore> I think the GUI we have so far is pretty good +20:10 < jtanx> hehehe +20:10 < jtanx> yeah it's not too bad +20:11 < jtanx> the only thing that I wouldn't know how to do is that admin stuff +20:11 < sam_moore> user admin or experiment admin? +20:11 < jtanx> um +20:11 < jtanx> I dunno, whatever that 'admin' functionality needs to be +20:11 < jtanx> like 'access the full logs' +20:11 < sam_moore> Oh, right +20:12 < jtanx> unless you start implementing permissions in the api +20:12 < sam_moore> Hmm, we might have to +20:13 < sam_moore> It should just be an enum for the user type that gets returned/set by the authentication handler and checked for certain operations +20:13 < sam_moore> But as you mentioned the other day, you don't want someone to be able to login after someone else has started an experiment and cancel it +20:13 < sam_moore> Actually +20:13 < sam_moore> Do you? +20:13 < jtanx> admin only? +20:13 < sam_moore> Exactly +20:14 < jtanx> how difficult is that to do though +20:14 < sam_moore> Store the username of who owns the current experiment +20:14 < sam_moore> Store an enum of the user type of whoever is currently logged in +20:14 < sam_moore> If someone tries to stop the experiment, unless their username matches, or they are an admin, refuse +20:14 < sam_moore> There could be a safety issue there? +20:15 < jtanx> the only thing is +20:15 < sam_moore> If someone needs to stop the experiment but isn't an admin? +20:15 < jtanx> everything's based off the control key +20:15 < sam_moore> Meh... add another cookie +20:15 < sam_moore> ... That escalated quickly +20:15 < jtanx> you've already used the nameless cookie +20:15 < jtanx> if you add another cookie +20:15 < jtanx> you have to do string parsing +20:15 < jtanx> and have named cookies +20:16 < sam_moore> Hmmm +20:16 < sam_moore> "Beyond the scope of the project" ? +20:16 < jtanx> i think the format was +20:16 < jtanx> key=value; key=value2 +20:16 < jtanx> yeah, beyond the scope :P +20:16 < sam_moore> Yeah, that is ever so annoying +20:16 < jtanx> let's leave it for now +20:16 < jtanx> come back to it +20:16 < sam_moore> Because if it were something like "key=value&key=value2" you could potentially reuse the FCGI parser +20:17 < jtanx> yeah +20:17 < jtanx> you could modify it +20:17 < sam_moore> That would be the way to go +20:17 < jtanx> generalise it +20:17 < sam_moore> But it's low priority now +20:17 < jtanx> yep +20:17 < jtanx> wow i'm getting seriously sidetracked +20:18 < jtanx> this mechatronics project is more interesting than any of my other projects though +20:18 < sam_moore> Haha +20:19 < sam_moore> I know what you mean +20:19 < sam_moore> I want to compile a RT linux kernel on my laptop (since they have x86 versions) +20:19 < sam_moore> So that I can look at how much the consistency in sample rate could theoretically improve... +20:20 < sam_moore> If someone managed to port the RT linux kernel to the BeagleBone +20:20 < jtanx> RT linux on your computer +20:20 < jtanx> isn't that generally bad +20:20 < jtanx> because RT screws up other stuff +20:21 < sam_moore> Like what? +20:21 < jtanx> decreased performance to meet the deadlines +20:21 < sam_moore> Also, I don't have to permanently replace my existing kernel, just add another bootloader entry +20:22 < sam_moore> If it screws up nginx that would be annoying though +20:23 < jtanx> while you're at it, try running the bfs scheduler instead of the cfs scheduler :P +20:23 < sam_moore> Maybe +20:42 < sam_moore> Ok, the solution to the copy/paste is just something like $("#sidebar").load("static/sidebar.html") +20:42 < sam_moore> However, whilst running this in the document.ready function on a test page works, running it in index.html appears to have no effect +20:43 < sam_moore> Oh +20:43 < sam_moore> I know why +20:43 < sam_moore> Because runBeforeLoad is failing +20:43 < sam_moore> Presumably you still want to load content like the navigation bar even if the server isn't running +20:44 < sam_moore> So... there is ".done()" and ".fail()" ... is there ".either()"? +20:46 < sam_moore> Ahahaha +20:47 < sam_moore> Of course, there is ".always()" +20:49 < sam_moore> Hmm, I wouldn't want to design any sort of large system with a language like this, but it is an interesting style +20:51 < jtanx> haha +20:52 < sam_moore> So, a lot of the header stuff can be moved into .html files and just jQuery.loaded, which should make things cleaner +20:52 < sam_moore> I will refrain from doing that now though +20:53 < jtanx> don't be too tempted to do a lot of templating with javascript +20:53 < jtanx> because it will load asynchronously, stuff will look weird +20:53 < jtanx> and if the js breaks +20:53 < jtanx> well, your page is more screwed than before +20:54 < sam_moore> Ok... but you could still potentially have at least one html file in the static directory +20:54 < sam_moore> With all the header and navigation stuff +20:55 < sam_moore> Just have a .fail() function! +20:55 < sam_moore> That's what it's for, right :P +20:56 < sam_moore> $("#thing").load("static/thing.html").fail($("#thing").html("
Something fucked up
") +20:56 < sam_moore> Oh dear +20:58 < jtanx> ~.~ +20:58 < jtanx> django here: https://mctx.us.to:8043/databases +20:58 < jtanx> login with testuser:testuser +20:58 < jtanx> ignore that it looks a lot like our gui +20:58 < jtanx> except it doesnt work anymore +21:00 < sam_moore> Well, django's used for UCC for member administration +21:01 < sam_moore> Except it's entirely seperate from LDAP which we use for authentication +21:01 < sam_moore> Except it's not really because it binds to LDAP for authentication :S +21:01 < sam_moore> Wheels within wheels... +21:02 < jtanx> ookay +21:04 < sam_moore> You need LDAP for shell access +21:04 < sam_moore> In fact... +21:04 < sam_moore> We could potentially give pheme users shell access to the BeagleBone +21:04 < sam_moore> But there's not really any point +21:04 < jtanx> is that a good idea +21:05 < sam_moore> No +21:05 < sam_moore> It's an awful idea +21:05 < sam_moore> Just saying it's possible :P +21:06 < sam_moore> Someone could do this: :(){ :|:& };: +21:06 < sam_moore> And break the entire thing +21:08 < jtanx> is that the fork bomb +21:09 < jtanx> ok the site works now +21:09 < jtanx> sort of +21:10 < sam_moore> 400 Bad Request +21:10 < jtanx> hurr +21:10 < sam_moore> I think iceweasel is being dumb and ignoring https:// ? +21:10 < sam_moore> Although it was fine before +21:11 < jtanx> nah probably screwed up the nginx config +21:11 < sam_moore> No, it works, I just had to type the https:// instead of copy paste +21:11 < sam_moore> Wierd +21:11 < sam_moore> The test login doesn't work though +21:11 < jtanx> testuser doesn't work for some reason +21:11 < jtanx> yeah just register +21:12 < sam_moore> Will it actually send an email? +21:12 < jtanx> urgh +21:12 < jtanx> no +21:12 < sam_moore> haha +21:12 < jtanx> okay no the config is still broken +21:16 < sam_moore> I'll have to come back to this tomorrow +21:16 < sam_moore> Bye +21:17 < jtanx> ok bye +23:09 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +--- Day changed Sat Oct 12 2013 +10:20 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +13:49 -!- jtanx_ [~asfa@124-169-73-222.dyn.iinet.net.au] has joined #mctxuwa_softdev +13:49 -!- MctxBot_ [~twang@124-169-73-222.dyn.iinet.net.au] has joined #mctxuwa_softdev +14:03 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit [Ping timeout] +14:05 -!- MctxBot [~twang@106-68-47-96.dyn.iinet.net.au] has quit [Ping timeout] +14:34 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +14:39 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +14:46 -!- jtanx_ [~asfa@124-169-73-222.dyn.iinet.net.au] has quit [Ping timeout] +14:47 -!- MctxBot_ [~twang@124-169-73-222.dyn.iinet.net.au] has quit [Ping timeout] +--- Log closed Sat Oct 12 17:39:23 2013 +--- Log opened Sat Oct 12 22:41:38 2013 +22:41 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #mctxuwa_softdev +22:41 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal] +22:41 -!- Irssi: Join to #mctxuwa_softdev was synced in 2 secs +22:41 -!- You're now known as sam_moore +--- Day changed Sun Oct 13 2013 +08:30 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +10:18 < jtanx> yeah, about the django stuff, I'm not sure if we should do that now +10:18 < jtanx> two options I considered: +10:19 < jtanx> if you kept the 'bind' module, but added a method to authenticate against the django database, that could work, but it's a lot of effort +10:19 < jtanx> - there's two ways - one is to manually do it via interaction with the sqlite database and parsing the user string etc etc +10:20 < jtanx> the other way is to call the python function from c +10:20 < jtanx> I explored the 'call python from c' option and it does work, but it's quite cumbersome +10:20 < jtanx> I didn't bother exploring the 'manual interaction with sqlite' because that would be even more cumbersome +10:21 < jtanx> The other way, which I got working quite easily +10:21 < jtanx> is to protect one of the modules with nginx +10:21 < jtanx> say /api/control now becomes an 'internal' only module +10:21 < jtanx> so it's not usually accessible from outside +10:22 < jtanx> with django, say you got the address /databases/control +10:23 < jtanx> it can send back a request with header 'X-Accel-Redirect' to /api/control +10:23 < jtanx> Because it was sent by django, which is an internal application, it works +10:23 < jtanx> such that /databases/control looks like /api/control to the user +10:24 < jtanx> the problem with this setup is that then your api becomes entirely dependent on django to work +10:24 < jtanx> I guess you could replace 'django' with any other authrorization frontend +10:31 < jtanx> let's just stick with what we've got +10:36 < jtanx> hahahaha and that x-accel-redirect just crashed my server after I held down f5 +10:36 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has quit [Connection reset by peer] +10:39 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +19:19 < jtanx> I think I'll try to get in early tomorrow to work on whatever needs to be done +19:56 < jtanx> For the actuators, do you really want it to crash (Fatal) if the user supplies a step say of 0,1,40000,2? +21:19 < jtanx> working on the graphs now +23:29 < jtanx> ookay +23:29 < jtanx> too tired to check, but I refactored it and I think it still works +23:30 < jtanx> I'll just leave it in my fork for now +23:30 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has quit ["bye"] +--- Day changed Mon Oct 14 2013 +10:03 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +10:03 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +19:15 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +19:19 < jtanx> this is stupi +19:19 < jtanx> d +19:19 < jtanx> flot is still the easiest to use +19:20 < jtanx> chart.js can only plot a line chart, so all the data series must share the same x-axis points +19:20 < jtanx> jqplot sucks +19:21 < jtanx> oh well, I'll work on this some other time +19:21 < jtanx> stick with flot for now +19:40 < sam_moore> Re actuators: No, Fatal is probably not the correct response to an invalid user input :P +19:40 < sam_moore> Re just using flot: OK +19:43 < sam_moore> I think we need to do a grep -R "Fatal" and get rid of the ones that don't actually need to be Fatal +19:43 < sam_moore> Which is probably most of them +19:44 < sam_moore> Working on more useful user based control now +19:45 < jtanx> ok +19:46 < jtanx> I wonder if it's possible to selectively colour text in a textarea with javascript +19:47 < sam_moore> Probably? +19:47 < jtanx> I have a feeling that you'd have to surround those ones inblocks +19:48 < sam_moore> Hmm, but that would make them all on new paragraphs +19:48 < jtanx> fine, s +19:48 < sam_moore> That makes sense +19:48 < jtanx> but you'd probably need to surround highlighted text in some sort of <> block +19:48 < jtanx> so you can style it +19:48 < sam_moore> Makes sense +19:48 < sam_moore> What are you going to colourise? +19:49 < jtanx> say if there's a fatal message +19:49 < jtanx> you colour it red? +19:49 < jtanx> make it blink, 90s style +19:52 < sam_moore> Hahaha +19:52 < sam_moore> Sounds good +19:53 < sam_moore> Colourising the labels for the graph might be useful too +19:53 < sam_moore> (Possibly easier than adding labels to the flot plot?) +19:53 < jtanx> hmm +19:54 < jtanx> what I was thinking of doing was to use nvd3, which generates the graphs using the svg element instead of a canvas +19:54 < jtanx> then you can use something like http://code.google.com/p/canvg/ to render the svg in js to a png file +19:55 < sam_moore> Interesting +19:55 < jtanx> no idea if it will work +19:56 < sam_moore> Do you even have to render it to png? SVG is a good format for graphs +19:56 < jtanx> i mean if you want to save it +19:56 < jtanx> i dunno, most users will go +19:56 < jtanx> what's this svg format +19:56 < sam_moore> That's what I mean; can you save it as an svg? +19:56 < sam_moore> Hahaha +19:56 < jtanx> probably +19:56 < sam_moore> If it were me, I would *want* the svg format +19:56 < sam_moore> You can edit the graph in inkscape +19:57 < sam_moore> Really easily +19:57 < jtanx> yeah +19:57 < jtanx> I'd prefer the svg format too +19:57 < sam_moore> Get SVG working and if you really want, add a radio box to choose the file format +19:57 < jtanx> yep +19:58 < sam_moore> I thought FCGI_LockControl was being called on any user action, but it looks like it's only called in login.c now +19:58 < sam_moore> Is that the change you were talking about earlier? +19:59 < jtanx> nah +19:59 < jtanx> fcgi_lockcontrol should only be called in login.c +19:59 < jtanx> there was this leftover part in control.c +19:59 < sam_moore> Oh, right, nevermind +19:59 < jtanx> that called it too +20:00 < sam_moore> I was thinking of FCGI_HasControl,that's ok +20:00 < jtanx> yeah +20:10 < MctxBot> . +20:12 < sam_moore> ? +20:12 < sam_moore> MctxBot: Have you become sentient yet? +20:12 < jtanx> I was just testing notification on all messages for chatzilla +20:14 < sam_moore> Ok +20:53 < sam_moore> I think the correct way to do this is to store more stuff in the FCGI_Context +20:54 < sam_moore> Like the name of the experiment currently being conducted +20:54 < jtanx> hmm +20:54 < sam_moore> I noticed that control.c avoids storing the actual name of the experiment anywhere +20:54 < sam_moore> But it's late and I'm just going to hack something together +20:55 < jtanx> yeah +20:55 < jtanx> I don't particularly like how 'experiments' were handled in control.c +20:55 < sam_moore> g_control stores the user name of whoever last succeeded in doing an "action=start" +20:55 < sam_moore> I can rework it, but not tonight +20:55 < jtanx> that's fine +21:41 < sam_moore> ==21160== Uninitialised value was created by a stack allocation +21:41 < sam_moore> ==21160== at 0x6A22DBE: __md5_crypt_r (md5-crypt.c:121) +21:41 < sam_moore> :S +21:41 < jtanx> ..... +21:41 < sam_moore> Not causing an error, but still +21:41 < jtanx> what does that even mean +21:42 < sam_moore> It's nice to know that the linux crypt functions that are used for parsing /etc/shadow have uninitialised values +21:42 < jtanx> you sure you're calling it correctly +21:42 < jtanx> ? +21:42 < sam_moore> The full text (brace for impact) +21:42 < sam_moore> ==21160== Conditional jump or move depends on uninitialised value(s) +21:42 < sam_moore> ==21160== at 0x6D75188: ??? (strcpy.S:98) +21:42 < sam_moore> ==21160== by 0x6A230E7: __md5_crypt_r (md5-crypt.c:249) +21:42 < sam_moore> ==21160== by 0x40A5F6: Login_Shadow (login.c:93) +21:42 < sam_moore> ==21160== by 0x40AA7B: Login_Handler (login.c:243) +21:42 < sam_moore> ==21160== by 0x404CE3: FCGI_RequestLoop (fastcgi.c:548) +21:42 < sam_moore> ==21160== by 0x4052AE: main (main.c:143) +21:42 < sam_moore> ==21160== Uninitialised value was created by a stack allocation +21:42 < sam_moore> ==21160== at 0x6A22DBE: __md5_crypt_r (md5-crypt.c:121) +21:42 < sam_moore> if (strcmp(crypt(pass, salt), buffer+passwd_index) == 0) +21:43 < sam_moore> Looks like the correct usage to me +21:43 < sam_moore> I mean, it's *working* +21:43 < jtanx> ~.~ +21:43 < jtanx> well then +21:44 < sam_moore> It's probably someone being lazy with initialising things +21:44 < jtanx> https://bugzilla.redhat.com/show_bug.cgi?id=760262 +21:44 < sam_moore> GCC under linux usually initialises things to zero +21:44 < jtanx> https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=699917 +21:44 < sam_moore> But under other things (like Mac OSX) it doesn't; if it's not initialised you can't assume anything +21:45 < jtanx> I thought C standard was any global variables were zeroed +21:45 < jtanx> anything else is undefined +21:45 < sam_moore> Well it's probably not a global variable then +21:45 < sam_moore> But I think you're right +21:45 < sam_moore> I just remember in CITS1210 +21:45 < jtanx> from the bug report - 'This is an annoying, but harmless false positive warning.' +21:46 < sam_moore> We had a bunch of variables that weren't initialised +21:46 < sam_moore> gcc under debian/ubuntu was zeroing them for us +21:46 < sam_moore> So things still worked +21:46 < jtanx> yeah +21:46 < sam_moore> Go to the Mac lab... +21:46 < sam_moore> Everything exploded +21:46 < jtanx> hahahaha +21:46 < jtanx> ah... CITS1210 +21:46 < jtanx> when did you take it? +21:46 < sam_moore> Aaages ago +21:46 < sam_moore> 2009? +21:47 < jtanx> that was long ago +21:47 < sam_moore> Yes +21:47 < jtanx> 2011 for me +21:47 < sam_moore> We got 100% though :) +21:47 < sam_moore> For the second project +21:47 < jtanx> sweet +21:47 < jtanx> I think I got that too +21:47 < jtanx> they docked marks off the first one for some stupid reason +21:47 < sam_moore> (He had an infinite loop in the sample solution, which we found and eliminated in our solution, I think that was the main reason) +21:48 < jtanx> ook +21:48 < sam_moore> (He probably didn't appreciate the #ifdef BE_REALLY_STUPID // Replicate the behaviour *exactly* as requested by the lecturer) +21:48 < jtanx> :P +21:48 < sam_moore> Good fun +21:49 < jtanx> yeah, one of the comments on mine was 'did not exactly match whitespace of output' +21:49 < sam_moore> Haha, it was pretty harsh with the replicating exactly +21:49 < sam_moore> We had a long debate about whether we should replicate the infinite loop or not +21:49 < sam_moore> I think we actually submitted it with "BE_REALLY_STUPID" defined :S +21:50 < jtanx> hahahaha +22:24 < jtanx> now to look into nvd3 +22:36 < sam_moore> I've pushed some progress, I will try and clean it up later this week (it's pretty hacky) +22:36 < jtanx> cool +22:37 < sam_moore> I do like the idea of having svg plots, if it works it will be much nicer than flot +22:37 < jtanx> hopefully +22:37 < jtanx> it doesn't work in ie8 without this compat library +22:37 < sam_moore> Ah +22:37 < jtanx> and with compat it'll probably be slow +22:37 < jtanx> but oh well +22:38 < sam_moore> Fallback to flot if browser is ie8? :P +22:38 < jtanx> yeah +22:38 < jtanx> maybe +22:38 < jtanx> that could work +22:39 < sam_moore> I'm pretty sure it's within our rights to say "You need to use one of these browsers" since it's so easy to install browsers +22:39 < jtanx> true +22:39 < jtanx> ie8 is more an afterthought anyway +22:39 < sam_moore> But I suppose if they have some stupid SOE that only includes ie6... +22:39 < jtanx> if you use ie6 you'd be screwed anyway +22:39 < sam_moore> Haha +22:40 < sam_moore> The first flot page I made didn't work in my phone's browser, but that's probably a JavaScript setTimeout thing +22:40 < jtanx> do browsers even support the canvas element +22:40 < jtanx> *mobile browsers +22:41 < sam_moore> Well it showed the first set of data but didn't update +22:41 < jtanx> oh +22:41 < jtanx> right +22:41 < sam_moore> Don't worry, we don't need to support phone browsers +22:41 < sam_moore> Or at least, until we tell Adrian that we don't support phone browsers, we won't have to support phone browsers :P +22:42 < jtanx> hehehe +23:12 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has quit [Connection reset by peer] +23:13 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +23:20 < jtanx> hahaha nvd3 crashed firefox +23:20 < jtanx> let me try again +23:20 < jtanx> if I disconnect, you know why +23:22 < jtanx> well it didn't crash, but it didn't work +23:22 < jtanx> oh well, I'll try again tomorrow +23:22 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has quit ["bye"] +--- Day changed Tue Oct 15 2013 +12:08 < sam_moore> http://jayrambhia.com/blog/capture-v4l2/ +12:08 < sam_moore> Might be useful? +12:08 < sam_moore> I suspect the issue with the cameras is related to the colour format +12:08 < sam_moore> MJPEG fails, but YUVU (whatever the hell that is) succeeds +12:09 < sam_moore> Although it is still only giving 320x240 +12:13 < sam_moore> I noticed uvccapture, etc are quite buggy on my own debian laptop +12:13 < sam_moore> I'm hoping that it might actually be a shitty userspace error that we can fix by using the v4l2 API directly +12:13 < sam_moore> Although it's not likely +12:14 < sam_moore> May as well try +12:14 < sam_moore> But uvccapture just likes to hang forever +12:14 < sam_moore> If you give it larger resolutions +18:52 -!- james__ [~chatzilla@CPE-58-160-245-20.wa.bigpond.net.au] has joined #mctxuwa_softdev +19:29 -!- james__ [~chatzilla@CPE-58-160-245-20.wa.bigpond.net.au] has quit [Ping timeout] +21:27 -!- James__ [~chatzilla@CPE-58-160-245-20.wa.bigpond.net.au] has joined #mctxuwa_softdev +21:31 < James__> Hey Sam +21:39 < James__> Having Issues uploading to the GUI to git but i have successfully tested it on Firefox, Chrome and IE. I will continue trying to upload but if i can't i will see if i can find you or Jeremy tomorrow +21:57 -!- James__ [~chatzilla@CPE-58-160-245-20.wa.bigpond.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +--- Day changed Wed Oct 16 2013 +13:39 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has quit [Ping timeout] +13:59 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +13:59 < jtanx> ... +13:59 < jtanx> I brought the bbb home +14:00 < jtanx> booted it off an ubuntu image, and uvccapture can take 800x600 images fine from my webcap +14:00 < jtanx> webcam* +14:00 < jtanx> I don't know if it's because it's a different camera, or because it's a different os +14:34 < jtanx> I just tested with the api/image and I can get 800x600 fine +14:34 < jtanx> too +14:38 < jtanx> I can even do 1600x1200 images just fine +14:38 < jtanx> ................ +14:38 < jtanx> ._. +14:38 < jtanx> I'll be bringing this in tomorrow, see if it works with the cameras that we're going to be using +14:39 < jtanx> Since my 1gb sd card was not big enough to opencv, I've actually flashed the internal memory with ubuntu +14:39 < jtanx> (so I could install opencv) +14:41 < jtanx> wowthat is so stupid +14:42 < jtanx> so either it's the cameras that we bought, or the os +14:42 < jtanx> but it works at 1600x1200 +14:42 < jtanx> (max resolution of my webcam) +14:43 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +15:00 < jtanx> ok, I just tried it with the os we've been running before (on your 32gb sd card), and it also works at 1600x1200 +15:00 < jtanx> so it's an issue with the camera +15:01 < jtanx> (e.g selecting a camera that actually works with the BBB +15:14 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has quit ["brb"] +15:16 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +20:10 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has quit [Ping timeout] +21:41 -!- jtanx_ [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +21:56 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has quit [Ping timeout] +23:28 -!- jtanx_ [~asfa@220-253-133-241.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +23:28 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +--- Day changed Thu Oct 17 2013 +09:16 -!- jtanx [~asfa@130.95.54.13] has joined #mctxuwa_softdev +09:17 < jtanx> .... +09:17 < jtanx> I just ran the bBB with ubuntu and used the usb microscope +09:17 < jtanx> and it worked +09:18 < jtanx> and so too does it work on the original os +09:18 < jtanx> wtf +09:33 < jtanx> hahahaa +09:33 < jtanx> it crashed because it ran out of memory +09:33 < jtanx> I tried having both cameras at once +09:33 < jtanx> and switching between them +09:34 < jtanx> but other than that it works +09:34 < jtanx> this is weird +09:44 < jtanx> about 1/5 tries fails at 1600x1200 with 'select timeout' +09:44 < jtanx> probably because it can't buffer that fast or something +09:45 < jtanx> but definitely to run both cameras at once (or at least have them connected), you require an external power source, either for the beaglebone or for the usb hub +09:47 < jtanx> yep +09:47 < jtanx> if you do +09:47 < jtanx> modprobe uvcvideo nodrop=1 +09:47 < jtanx> It will only display part of the image +09:47 < jtanx> probably because it hasn't filled the buffer yet +09:48 < jtanx> but if you load uvcvideo with normal settings +09:48 < jtanx> it either displays the full image, or no image at all +09:48 < jtanx> the problem is, I don't know how you detect this in opencv +10:10 -!- jtanx [~asfa@130.95.54.13] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +13:47 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +14:55 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has quit [Ping timeout] +17:14 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +17:20 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has quit ["leaving"] +17:22 -!- MctxBot [~twang@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +22:38 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +--- Log closed Fri Oct 18 11:45:55 2013 +--- Log opened Fri Oct 18 11:46:19 2013 +11:46 -!- sam_moor1 [matches@motsugo.ucc.gu.uwa.edu.au] has joined #mctxuwa_softdev +11:46 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal] +11:46 -!- Irssi: Join to #mctxuwa_softdev was synced in 8 secs +11:56 -!- sam_moore [matches@motsugo.ucc.gu.uwa.edu.au] has quit [Ping timeout] +16:03 -!- You're now known as sam_moore +16:03 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal] +16:03 < sam_moore> MctxBot: Tell your master that snoopy is broken +17:41 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +17:42 < jtanx> woops +17:42 < jtanx> I probably screwed up fstab on the sd card when trying to enable swap space +17:42 < jtanx> sorry about not replying earlier +19:42 < sam_moore> Haha +19:42 < jtanx> ~.~ +19:42 < sam_moore> We used ubuntu to test the pressure sensor and microphone +19:42 < jtanx> what were you doing with the BBB? +19:42 < jtanx> oh +19:42 < jtanx> how did that go? +19:43 < sam_moore> Alright, flot and/or JavaScript suck at large numbers of points though +19:43 < jtanx> yeah +19:43 < jtanx> did you finally get your hands on a voltage divider or something +19:44 < jtanx> or hsa the electronics team finished their stuff +19:44 < sam_moore> We just made one, but electronics does have one +19:45 < sam_moore> "We have 2 boards and 2 of them don't work" +19:45 < sam_moore> GPIO can't trigger the relays it would seem +19:45 < jtanx> well +19:46 < jtanx> what are they going to do about that +19:46 < sam_moore> Although we only tested 2 outputs, apparently some are 4mA some are 6mA and the thing needs 5mA +19:47 < sam_moore> I don't know? Try every single pin, actually measure the current drawn by the relay switch +19:47 < sam_moore> Replace the transistors on the relay +19:47 < jtanx> haha +19:47 < jtanx> that sounds so dodge +19:47 < sam_moore> We tried 2 GPIO pins at once :S +19:47 < jtanx> in parallel? +19:47 < sam_moore> Didn't work +19:48 < sam_moore> Yeah +19:48 < jtanx> hahaha +19:48 < sam_moore> But I think that might cause one to draw current from the other +19:48 < jtanx> hmm +19:49 < sam_moore> Need to actually look at the GPIO circuit diagram to work out what that would do +19:49 < sam_moore> Our software can sample more than fast enough for the microphone +19:50 < jtanx> that's cool +19:50 < jtanx> could you see it on the graph +19:50 < sam_moore> But plotting it in flot crashes the browser +19:50 < sam_moore> Sort of +19:50 < sam_moore> Had to change start_time to get all the points +19:51 < jtanx> Flot doesn't sound too reliable +19:51 < sam_moore> It crashes after ~1s +19:51 < sam_moore> min +19:51 < sam_moore> not second +19:51 < jtanx> But can we just cut down on the number of data points +19:51 < jtanx> how many datapoints is that after 1 min +19:51 < sam_moore> It's obviously incredibly inefficient +19:52 < sam_moore> I will see if averaging points helps flot +19:52 < sam_moore> Or if it's actually JavaScript not liking really big arrays +19:52 < jtanx> yeah +19:52 < jtanx> I think having large arrays consumes an enormous amount of memory in js, for some reason +19:53 < sam_moore> Dammit +19:54 < sam_moore> We could make a python GUI using requests and pyplot :P +19:54 < jtanx> -.- +19:54 < jtanx> wouldn't it be worse, trying to plot it on the beaglebone +19:55 < jtanx> given that you're using a full blown computer to plot it +19:55 < sam_moore> No, you still plot it on the client +19:55 < jtanx> How does that work +19:56 < jtanx> You'd have to render it on the BBB, no? +19:56 < sam_moore> Nope; get data the same way through HTTP and plot on the client +19:56 < jtanx> what's the difference? +19:57 < sam_moore> The BBB doesn't gave a problem transferring data points +19:58 < sam_moore> The browser ie JavaScript sucks at coping with them +19:58 < jtanx> Yeah, but if you say plot on the client, how do you plot on the client? +19:58 < jtanx> ohhhhhhh +19:58 < jtanx> Right I understand now +19:59 < sam_moore> Python has modules for plotting +19:59 < sam_moore> And modules for HTTP requests +19:59 < jtanx> You're saying instead of a web interface a python gui instead +19:59 < sam_moore> Maybe +19:59 < jtanx> ?? +19:59 < sam_moore> I can at least do a proof of concept +19:59 < jtanx> I'm lost +20:00 < sam_moore> But we probably shouldn't redesign the entire GUI... +20:00 < jtanx> Hey, I'm all for it if it can be done +20:20 < jtanx> Now, to do this control page +20:20 < jtanx> A username can only contain alphanumeric characters +20:21 < jtanx> right? +20:21 < sam_moore> Yep +20:21 < jtanx> okay +20:21 < jtanx> was just thinking if someone had say .. in their username... +20:25 < sam_moore> You can allow other characters +20:25 < jtanx> well as in +20:25 < sam_moore> Not '=' though +20:25 < jtanx> having .. in their username would move you up a directory +20:26 < sam_moore> Ah, cunning +20:26 < sam_moore> Thwarted by general paranoia though +20:26 < jtanx> :P +20:26 < sam_moore> No stupid characters in usernames +20:27 < sam_moore> Definitely no '/' allowed +20:27 < jtanx> hahaha +20:27 < jtanx> I think an alphanumeric limitation is good +20:27 < jtanx> until the university stipulates having random characters in usernames +20:28 < sam_moore> You forget that if the university does that they will have to cope with the same kind of bullshit +20:29 < jtanx> Yeah, true that +21:42 < sam_moore> I pushed a python plotting thing, but I don't really think we should be switching to it at this stage. +21:42 < jtanx> Okay +21:42 < sam_moore> I'll try tweak the flot GUI tomorrow to make it less shit +21:43 < jtanx> hahaha +21:58 < jtanx> urgh +21:58 < jtanx> barely started on the control page +21:59 < jtanx> I guess I'll have to complete it tomorrow +21:59 < jtanx> even though we're probably (maybe) going with james gui +22:00 < jtanx> I've removed the width restriction +22:00 < jtanx> and you can hide the navigation bar +22:00 < jtanx> for more space +22:11 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +--- Day changed Sat Oct 19 2013 +07:59 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has joined #mctxuwa_softdev +10:39 < jtanx> blegh, now to start on the js for the control page +11:10 < jtanx> what would you say if instead of all this chdir business +11:10 < jtanx> one of the initial options to start the software is to specify where you want experiments to be held +11:11 < jtanx> e.g /usr/share/experiments or whatever +11:11 < jtanx> then you build the path based on the username +11:25 < sam_moore> That sounds good +11:26 < jtanx> Okay, I'll try to do that then +14:37 < sam_moore> There's some kind of error in mctx.gui.js now +14:37 < jtanx> what's happening? +14:37 < sam_moore> A syntax error +14:37 < jtanx> let me check +14:38 < jtanx> what page is this on? +14:38 < sam_moore> Line 272 (mctx.gui.js): outdiv[0].scrollHeight - outdiv.height() +14:38 < sam_moore> Caused by loading graph.html +14:38 < jtanx> ahhhh +14:38 < jtanx> I know why +14:38 < jtanx> maybe +14:39 < jtanx> I decided to just to $("#errorlog").seterrorlog in mctx.gui.js +14:39 < jtanx> so I don't have to repeat that on every page +14:39 < sam_moore> The debug function also causes some error in chromium +14:39 < jtanx> but if the page deosn't have an error log +14:39 < jtanx> hahaha +14:39 < jtanx> chromium +14:39 < jtanx> what does it say +14:39 < sam_moore> Didn't I tell you that something was causing iceweasel to segfault? I have no choice! :( +14:40 < jtanx> :P +14:40 < sam_moore> console.log.apply(this, arguments); causes an uncaught type error: illegal invocation +14:40 < sam_moore> I shall replace it with "alert" +14:40 < jtanx> hmm +14:41 < jtanx> it's because chrome has a different implementation of console.log +14:41 < jtanx> http://stackoverflow.com/questions/9521921/why-does-console-log-apply-throw-an-illegal-invocation-error +14:41 < jtanx> for that bug +14:41 < sam_moore> Right +14:42 < sam_moore> Why is the call to outdiv.scrollTop on line 272 spread over 3 lines? +14:42 < sam_moore> ... That's probably why it syntax errors +14:42 < jtanx> nah +14:42 < jtanx> it's legit +14:43 < jtanx> the problem is there's no div there if you don't define #errorlog somewhere in your html +14:43 < sam_moore> I thought the html was supposed to load any elements specific to that page +14:44 < sam_moore> Which should avoid this sort of thing happening +14:44 < jtanx> Yeah, except that we were repeating the same sort of load code +14:44 < jtanx> in most of the pages +14:44 < jtanx> I've just added a check in seterrorlog +14:44 < jtanx> which should ignore if there's no such div anyway +14:44 < sam_moore> ok +14:44 < jtanx> that whole 'experiment dir' thing is ~.~ +14:44 < jtanx> I think it's mostly done +14:45 < sam_moore> Ok +14:45 < jtanx> so +14:45 < jtanx> instead of having a file 'name.exp' +14:45 < sam_moore> Yeah that was hacky +14:45 < jtanx> it's a folder 'name.exp' +14:45 < jtanx> all the stuff for one experiment gets stuck in that folder +14:45 < sam_moore> That's slightly less hacky +14:45 < jtanx> so you have something like +14:45 < sam_moore> Makes sense +14:46 < jtanx> /experiments_folder/username/experiment_name.exp +14:46 < sam_moore> Cool +14:46 < sam_moore> If it ever is changed to use local user accounts you can just set experiments_folder to /home +14:47 < jtanx> yeah +14:47 < jtanx> experiments_folder is just an argument you pass to it when you start it +14:47 < jtanx> -e experiment_folder +14:49 < sam_moore> Found a syntax error in graph.html now +14:49 < jtanx> just pushing stuff now +14:49 < jtanx> but what's the errro? +14:50 < sam_moore> There's an unterminated bracket on the runBeforeLoad.done +14:50 < sam_moore> I think +14:50 < jtanx> ah +14:50 < sam_moore> So many brackets +14:50 < jtanx> hehehe +14:50 < jtanx> yeah you're probably right +14:50 < jtanx> netbeans is giving angry red on the bracket +14:51 < jtanx> do you want me to push the fix for that? +14:51 < sam_moore> Well there are other issues with the page +14:52 < sam_moore> No method "always" where it's being chained on the document.ready +14:53 < jtanx> no wait +14:53 < sam_moore> Wait what the hell is it meant to do there +14:53 < jtanx> [14:52:32.186] ReferenceError: mctx is not defined @ http://localhost:8383/MCTXWeb/static/mctx.graph.js:8 +14:53 < jtanx> hmm +14:53 < jtanx> I broke something +14:53 < sam_moore> That's not the problem I'm getting, but generally there are lots of wierd things here +14:53 < jtanx> yeah +14:53 < jtanx> sorry +14:53 < jtanx> it was probably working before I pushed changes yesterday +14:54 < sam_moore> You have runBeforeLoad.done() calling $(document).ready which does nothing, but is chained to .always which will then call $(document).ready which then loads $("#graph-controls").setDevices() +14:55 < sam_moore> ... I think what I originally had was runBeforeLoad.always() calling $("#graph-controls").setDevices +14:55 < sam_moore> Possibly inside a document.ready +14:55 < sam_moore> But now mctx.gui.js is calling document.ready itself... +14:55 < jtanx> waiit +14:55 < jtanx> I think it's ok now +14:56 < jtanx> it was just brackets +14:56 < jtanx> I'll try it on my server first +14:58 < jtanx> yeah, I see what you mean +15:01 < jtanx> ahh +15:01 < sam_moore> Well I fixed it enough to test stuff +15:01 < jtanx> yeah +15:02 < jtanx> you planning on modifying stuff? +15:02 < sam_moore> I think it's just a matter of having runBeforeLoad().done() call $(document).ready() and then initialise stuff +15:02 < jtanx> I'll just keep it in my repo for now +15:03 < sam_moore> With runBeforeLoad.fail if you want to handle bad stuff +15:03 < jtanx> I just made it +15:03 < jtanx> runBeforeLoad().always(function() { +15:03 < jtanx> $(document).ready(function() { +15:03 < jtanx> $("#graph-controls").setDevices(); +15:03 < jtanx> }); +15:03 < jtanx> }); +15:03 < sam_moore> Yep, that's what I just did +15:03 < sam_moore> You can commit it and I'll pull it +15:03 < jtanx> okay +15:03 < sam_moore> If you fix the console and the errorlog things as well +15:03 < jtanx> yep +15:03 < jtanx> pushed that too +15:05 < sam_moore> Hmm, start_time = -1 is not actually giving the most recent second of data +15:05 < sam_moore> That might be a server API problem +15:05 < jtanx> hmmm +15:05 < sam_moore> But it might also explain why things were shitting themselves so much with the fast sampling rate +15:06 < jtanx> what is it giving? +15:06 < sam_moore> Because the jQuery would be getting hundreds of thousands of points... +15:07 < sam_moore> At the moment the server API is not giving any points and giving back a stupid value for start_time +15:07 < sam_moore> I think I might have broken it when I changed all the clocks +15:07 < jtanx> when did you change ti? +15:07 < sam_moore> Just now +15:07 < jtanx> ah +15:07 < sam_moore> I'm hoping that my first assumption about the thousands of points was the case before I broke it as well :P +15:08 < sam_moore> (ie: It was already broken before I broke it more) +15:08 < jtanx> ahahahah +15:08 < jtanx> I can try +15:08 < jtanx> I still have the old version +15:09 < jtanx> with start_time=-1 it returns nothing +15:09 < jtanx> start_time in the response is constant +15:11 < sam_moore> Yeah I get wierd stuff +15:11 < sam_moore> start_time = 17889.590701 +15:12 < sam_moore> "current_time" : 18589.539255 +15:12 < jtanx> is that with clock_gettime? +15:12 < sam_moore> "running_time" : 699.948554, +15:12 < sam_moore> Yes +15:13 < sam_moore> Oh herdurp +15:13 < sam_moore> start_time in the JSON response is *not* the same as start_time the parameter to the sensor +15:13 < jtanx> yeah +15:13 < sam_moore> .... should probably change that +15:13 < jtanx> start time of experiment +15:14 < jtanx> experiment_start_time? +15:14 < jtanx> long variable names... +15:14 < sam_moore> I think it's actually the program start time +15:14 < jtanx> nup +15:14 < jtanx> experiment starttime +15:14 < sam_moore> Alright +15:14 < jtanx> oh +15:14 < jtanx> actually you may be right +15:14 < sam_moore> Haha +15:14 < jtanx> I thought i changed it +15:14 < jtanx> wway back when i did the control stuff +15:15 < jtanx> initially +15:15 < sam_moore> ControlData has a start_time variable +15:15 < jtanx> yeah +15:15 < sam_moore> But g_options has a start_time variable +15:15 < sam_moore> -_- +15:15 < jtanx> that's confusing +15:15 < jtanx> hahaha +15:15 < sam_moore> Yeah, what idiot designed this... +15:15 < jtanx> ~.~` +15:19 < sam_moore> Right, sensor values are being saved relative to Control_GetStartTime (experiment starting time) +15:19 < sam_moore> That's fine +15:19 < jtanx> yep +15:19 < sam_moore> Sensor_Handler gets "current_time" from that as well +15:19 < jtanx> Thread safety on that is dodgey +15:19 < jtanx> I must say +15:20 < jtanx> but it's probably fine +15:20 < sam_moore> It's fine, clock_gettime is posix thread safe +15:21 < sam_moore> Oh, do you mean if the experiment changes +15:21 < jtanx> yeah +15:21 < jtanx> the whole *Control_GetStartTime() looks dodgy too +15:22 < sam_moore> Perhaps just a "double Control_CurrentTime()" would be better +15:22 < sam_moore> But it works +15:22 < jtanx> hmm +15:24 < sam_moore> Anyway, I think start_time=-1 is not giving any data because the default sampling rate is 1s and therefore current_time - 1 is outside the data range most of the time +15:25 < sam_moore> start_time=-3 gives a single point with the default sampling rate +15:25 < sam_moore> Increasing the sampling rate then you appear to get the right points +15:31 < sam_moore> I'm going to repeat my timestamp test with the current software under regular kernel and RT linux +15:32 < sam_moore> I know we can't ever get RT linux but I want to see if it makes much of a difference +15:46 < jtanx> okay +15:50 < jtanx> finally... back to actually coding the control page +22:59 -!- jtanx [~asfa@220-253-133-241.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]