X-Git-Url: https://git.ucc.asn.au/?a=blobdiff_plain;f=irc%2Flog;h=53734fd6be7a685a0a28dee9de60f4a96fa190a6;hb=8a030a36013e278c5d0e4b3dbf3dcf16760a6638;hp=438cc0dc7b3f4bc11b59bf00a62db92a0114646c;hpb=522183cf7a5815ec321c22f51d3cdf0595694ae1;p=matches%2FMCTX3420.git diff --git a/irc/log b/irc/log index 438cc0d..53734fd 100644 --- a/irc/log +++ b/irc/log @@ -4347,3 +4347,328 @@ 22:09 < jtanx> weird, getting http 500 when trying to access our github repo 23:16 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] 23:27 -!- Rowan [~Rowan@106-68-70-204.dyn.iinet.net.au] has quit [EOF From client] +--- Day changed Mon Oct 07 2013 +10:44 -!- Rowan [~Rowan@130.95.117.19] has joined #mctxuwa_softdev +12:45 -!- callum [~chatzilla@130.95.91.11] has joined #mctxuwa_softdev +12:47 < callum> you guys in g19? +14:46 -!- callum [~chatzilla@130.95.91.11] has quit [Ping timeout] +14:55 -!- callum [~chatzilla@130.95.54.13] has joined #mctxuwa_softdev +14:59 -!- Rowan [~Rowan@130.95.117.19] has quit [Ping timeout] +16:11 -!- callum [~chatzilla@130.95.54.13] has quit [Ping timeout] +18:22 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +18:44 < jtanx> ha, you can clone a wiki +18:45 < jtanx> git clone https://github.com/szmoore/MCTX3420.wiki.git +20:50 < sam_moore> Yeah, I know +20:51 < sam_moore> I don't really think it's great to be relying on the BeagleBone to serve all these additional requirements +20:51 < jtanx> Yeah, probably not +20:52 < jtanx> I've just been playing around with django for my CITS2232 project +20:52 < jtanx> it's like a python based cms +20:53 < sam_moore> That might work +20:53 < jtanx> It's actually not too bad +20:53 < jtanx> but incredibly annoying to learn how to use +20:53 < jtanx> it's got its own inbuilt user system +20:54 < sam_moore> How could we query it from our server though? +20:54 < jtanx> as in? +20:54 < jtanx> you can still query directly from the browser +20:54 < jtanx> from django itself +20:54 < jtanx> I'm definitely sure there's a json parsing library +20:55 < jtanx> (python at least should have one) +20:56 < sam_moore> As in, if we want to "login" +20:56 < sam_moore> How do we authenticate? +20:57 < sam_moore> From within the FastCGI process +20:57 < jtanx> Okay, there's two approaches I guess +20:58 < jtanx> if you want to continue to use fastcgi to login I guess you could get django to figure out +20:58 < jtanx> who's logged in +20:58 < jtanx> If you use django's login system +20:58 < jtanx> hmm +21:00 < jtanx> but one thing I haven't done yet is how do you prevent concurrent access in django +21:01 < jtanx> but say this: +21:01 < sam_moore> I think binding to an LDAP server is pretty standard for this sort of thing +21:01 < sam_moore> I think Django can even let you bind to LDAP for using it +21:01 < jtanx> probably +21:01 < jtanx> I think class2go was built using django +21:01 < jtanx> if you've ever used that crappy website +21:02 < jtanx> say for the fastcgi process we revert to +21:02 < jtanx> /api/control?lock +21:02 < jtanx> /api/control?unlock +21:02 < jtanx> etc +21:02 < jtanx> but /api/control is only visible to django +21:02 < sam_moore> Ah, I see +21:02 < sam_moore> Um... +21:02 < jtanx> then django can query it +21:02 < jtanx> and conditionally return the control key? +21:03 < jtanx> i dunno +21:03 < sam_moore> I'd be slightly nervous about adding additional systems that have to work together though +21:03 < jtanx> yeah +21:03 < jtanx> that's the problem +21:03 < sam_moore> I mean, if it works, it's fine +21:03 < sam_moore> If it breaks, suddenly anyone (or noone) can access the real underlying hardware +21:03 < jtanx> Yeah +21:04 < jtanx> especially if someone screws up the server config +21:04 < sam_moore> I think I'd prefer to stick with the current login handler +21:04 < sam_moore> There's some flexibility with how you actually do the authentication +21:04 < jtanx> Sure +21:06 < jtanx> I'm just thinking, how would we implement the 'admin' features +21:06 < jtanx> you'd then have to have some sort of list distinguishing normal users from admins +21:06 < jtanx> unless you hardcode admins?... +21:07 < sam_moore> With LDAP you can store admin as a user field and check it +21:08 < sam_moore> With /etc/shadow, have 2 files +21:08 < sam_moore> One for admin, one for regular users +21:08 < sam_moore> (When I say /etc/shadow I just mean the style of auth, not necessarily actually using *the* /etc/shadow) +21:08 < sam_moore> In fact +21:09 < sam_moore> We could possibly do a minimalist user management with python cgi and a custom /etc/shadow style file +21:10 < jtanx> say what +21:11 < jtanx> so use the python cgi to modify it +21:11 < sam_moore> Yeah +21:11 < jtanx> our c fastcgi to read +21:11 < sam_moore> Yes +21:11 < jtanx> that could work +21:11 < jtanx> have a look at flask +21:11 < sam_moore> It's also probably possible to easily do a lot of the things Adam wanted +21:12 < jtanx> flask is like the simpler version of django +21:12 < sam_moore> At least, you can get python cgi to send emails to people with a temporary password and ask them to change it +21:12 < jtanx> i think I still have an example too +21:15 < sam_moore> If you want and it doesn't require rewriting large parts of the FastCGI process +21:15 < sam_moore> Personally I don't think I have the time +21:16 < jtanx> well if it's completely separate from the fastcgi process +21:16 < sam_moore> Sure +21:17 < jtanx> hmm +21:18 < sam_moore> Just a simple CGI script might do the job though +21:18 < jtanx> yeah +21:18 < jtanx> except nginx doesn't have normal cgi +21:19 < sam_moore> Wat +21:19 < jtanx> only fastcgi +21:19 < sam_moore> Damn +21:19 < sam_moore> And I guess apache2 only has normal cgi and not fastcgi? +21:19 < jtanx> there may be mod_fastcgi +21:19 < jtanx> but +21:19 < jtanx> before we get ahead of ourselves +21:20 < jtanx> okay no, nginx doesn't have fastcgi +21:20 < jtanx> sorry cgi* +21:20 < jtanx> we could do it in php +21:21 < jtanx> urgh +21:21 < sam_moore> urgh indeed... +21:21 < sam_moore> I dunno +21:22 < sam_moore> We *did* tell Adam that we wouldn +21:22 < sam_moore> 't be able to do the user management system +21:22 < jtanx> haha +21:23 < sam_moore> I really think getting our program to interface with an LDAP server is reasonable +21:23 < jtanx> yeah +21:23 < sam_moore> Ok, I need to fix CITS3003 some more +22:46 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +22:53 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has joined #mctxuwa_softdev +22:53 < jtanx> brainspark: we can probably use django to proxy api requests +22:53 < jtanx> so it goes like this: user <-> django <-> server api +22:54 < jtanx> then you don't even have to expose the server api at all +22:54 < jtanx> although if I ever end up trying this I don't know +22:55 < jtanx> (by expose I mean that django can conditionally pass on the results from queries to the api) +22:55 < jtanx> but yeah, it's probably best to leave it how it is right now +22:55 < jtanx> as I doubt I have the time to implement this +23:10 < jtanx> it would definitely add overhead too +23:40 -!- jtanx [~asfa@106-68-47-96.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"] +--- Day changed Tue Oct 08 2013 +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]"]